oozie job 的掛了監控報警或重啓

時間  2019-11-06
標籤 oozie job 監控 報警 重啓 简体版
原文   原文鏈接

 

oozie Coordinator 的job 和actioni狀態不少，但好像不支持設置某狀態如failed後30分鐘後自動從新拉啓，因他的條件只有幾種:觸發條件能夠是一個時間頻率、一個dataset實例是否可用，或者多是外部的其餘事件。而input-events和output-events好像又支持DATASET，能夠想一想下在wf的error裏寫個文件做爲failed標識，在使其成爲每一個動做開始的判斷條件dataset，後在從新執行該動做，動做以前 還要在清理丟此falg，如此複雜 不說，且這個wf不必定能寫出來，或寫出來仍是個死循環，因正常JOB掛了必定是當時集羣資源或網絡有問題，要KILL掉整個JOB，後一段時間在從新執行（固然是你的wf邏輯要支持重複執行，而不執行時間和頻繁的影響），而報警應該能夠eroor to kill 里加個腳本發個email或使用email action啥得,具體參：https://www.cnblogs.com/wind-xwj/p/8946760.htmlhtml

  • input-events和output-events元素

一個Coordinator應用的輸入事件指定了要執行一個Coordinator動做必須知足的輸入條件，在Oozie當前版本，只支持使用dataset實例。
一個Coordinator動做可能會生成一個或多個dataset實例，在Oozie當前版本，輸出事件只支持輸出dataset實例。java

Coordinator Job具備以上幾個狀態：node

  • PREP
  • RUNNING
  • RUNNINGWITHERROR
  • PREPSUSPENDED
  • SUSPENDED
  • SUSPENDEDWITHERROR
  • PREPPAUSED
  • PAUSED
  • PAUSEDWITHERROR
  • SUCCEEDED
  • DONEWITHERROR
  • KILLED
  • FAILED

Coordinator 動做的狀態集合，以下所示：mysql

  • WAITING
  • READY
  • SUBMITTED
  • TIMEDOUT
  • RUNNING
  • KILLED
  • SUCCEEDED
  • FAILED

Oozie中工做流的定義:sql

參考：https://blog.csdn.net/gongxifacai_believe/article/details/81079134  https://marsorp.iteye.com/blog/1532983
Oozie中的工做流workflow包含控制流節點和Action節點。經過workflow.xml定義，經過schema進行約束。
Workflow的控制流節點包括：start、decision、fork、join、kill、end節點。
Action是執行或計算的任務，如 MapReduce job、Pig job、a shell command。跑的一個MapReduce任務就是一個MapReduce Action。Action節點有2個轉移：ok和error。
Workflow的Action節點包括：MapReduce Action、Pig Action、Fs（HDFS）Action、Ssh Action、Sub-workflow Action、Java Action。Oozie的Workflow裏面運行MapReduce、Hive、Sqoop或Shell腳本。
Action Extensions包括：Email Action、Shell Action、Hive Action、Hive 2 Action、Sqoop Action、Ssh Action、DistCp Action、Writing a Custom Action Executor。
Workflow的定義語言是基於XML的，叫作hPDL（Hadoop Process Defination Language）。節點名字範式：[a-zA-Z][\-_a-zA-Z0-9]*=，長度小於20個字符。
job.properties：用於指向workflow.xml文件所在的HDFS位置。
workflow.xml：包含start、action、kill、end。
lib 目錄：存放依賴的jar包。shell

可是既然也能夠腳本發EMAIL,那也應該能夠error to shell :crontab ->oozie job -kill -rerun 等等:bash

從新run一個coordinator中的某個任務網絡

能夠有多種方法指定重跑的任務，這裏介紹兩個，一個是按照action id來重跑，一個是按時間的range來重跑併發

按照action id 重跑app

oozie job -oozie http://abc.com/oozie/ -config job.properties -rerun 0043299-150916101131329-oozie-C  -action 1

經過-config指定oozie的properties（通常是固定的，就是提交oozie代碼的時候設定的config目錄），-action後面指定action id

還能夠同時指定多個action id在一次請求中：

oozie job -oozie http://abc.com/oozie -config job.properties -rerun 0000161-160506030003242-oozie-C  -action 1,2,3

若是coordinator有依賴job的話，一般上面兩種rerun方法都不能刷新依賴的狀態，若是某個coordinator有一個依賴條件是某個hive db partition，假設原本這個partition存在，在rerun以前把partition刪除了，那麼rerun仍是能繼續執行，並不會理會這個依賴條件其實已經不知足了，這樣最終會致使運算出錯，因此oozie rerun裏有一個參數是「-refresh」，保證rerun的時候從新去檢查一下依賴條件的狀態，看看是否能知足執行的條件，如：

oozie job -oozie http://abc.com/oozie -config job.properties -rerun 0000161-160506030003242-oozie-C  -refresh -action 1,2,3

按照時間的range重跑

oozie job -oozie http://abc.com/oozie/ -config job.properties -rerun 0065107-150916101131329-oozie-C -date 2016-02-20T00:10+0800::2016-02-21T14:00+0800

經過「-date」來指定時間的range，注意時間的格式是「xxxx-xx-xxTxx:xx+0800::xxxx-xx-xx」，「T」不能少，「0800」指定的是市區，中國處於東八區，因此是0800，兩個時間之間用「::」符號鏈接，這裏詳細說明下時間範圍的含義：

假設job是天天13點開始跑，那麼：

  • 2016-02-20T00:10+0800::2016-02-21T14:00+0800 => 會運行20,21號的任務，由於end time 超過了21號13:00
  • 2016-02-20T00:10+0800::2016-02-21T10:00+0800 => 只會運行20號的任務，由於end time 沒有超過了21號13:00

總之，就是取一個閉區間，執行這個區間內全部本該運行的任務:
[Begin_time, End_time]

oozie調度中的重試和手工rerun一個workflow
在oozie中有Bundle、Coordinator和Workflow三種類型的job，他們之間能夠有如下包含關係。

Bundle > Coordinator > Workflow。

1. 從新運行一個Coordinator job，能夠經過以下命令：

oozie job -rerun 0000034-180116183039102-oozie-hado-C -refresh -action 1-4
0000034-180116183039102-oozie-hado-C 表示coordinator的job id
-action 表示包含的action對應的序號的1-4，即從新運行歷史的4次job。


 

2. 若是隻想從新運行一個workflow job,能夠經過以下命令:

oozie job -rerun 0000411-180116183039102-oozie-hado-W -config rerun_workflow.xml
或者經過-D 參數直接設置 (上面rerun_workflow.xml中內容也是oozie.wf.rerun.failnodes=false的xml形式而已)
oozie job -rerun 0000411-180116183039102-oozie-hado-W -D oozie.wf.rerun.failnodes=false
不然會報錯以下：

Error: E0401 : E0401: Missing configuration property [oozie.wf.rerun.skip.nodes OR oozie.wf.rerun.failnodes]

oozie.wf.rerun.failnodes 參數含義：true指在失敗的節點從新運行，false指不在失敗的節點運行
oozie.wf.rerun.skip.nodes 指定跳過哪些節點運行
 

注意： 使用rerun從新運行workflow的job時，在coordinator中配置的參數會失效，所以一般是rerun一個coordinator程序。

 

另外在worfkflow程序中，也能夠按照以下配置來自動重試：

retry-max: 表示重試次數，若是該配置大於系統的配置最大重試次數，則取系統配置的最大次數

retry-interval: 重試時間間隔，3分鐘。 

整體能夠解釋爲：每3分鐘重試一次，一共重試5次。

複製代碼
    <!-- 統計day: dm_guba_loginlog -->
    <action name="hive-node"  retry-max="5" retry-interval="3">
        <hive xmlns="uri:oozie:hive-action:0.2">
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <job-xml>${hive_site_path}</job-xml>
            <configuration>
                <property>
                    <name>mapred.job.queue.name</name>
                    <value>${queueName}</value>
                </property>
            </configuration>
            <script>script.q</script>
            <param>tmp_table=tmp_dm_guba_loginlog_day</param>
            <param>params_dt=${params_dt}</param>
        </hive>
        <ok to="java-node"/>
        <error to="senderror"/>
    </action>
複製代碼

CDH oozie4.10

正確使用方法:

一、oozie配置oozie

oozie.service.LiteWorkflowStoreService.user.retry.error.code.ext=ALL

直接指定爲ALL單獨E0080這樣的事件並無效.

二、在hue的工做流中設置重試次數。（CDH5.8中default是沒效果的，必定要本身指定）

以上問題也多是我具體的版本纔會有。

那麼wf能夠在xml裏配置，coord能夠嗎，結果 是不行，coord的控制選項里根本不支持相關參數，wf里根本取不到coord_job_id相關信息，那隻好crood傳遞過來而後調用，可是仍是很蛋疼，最終仍是綜合wf,tetry email和crontab裏能腳本定時檢測實現，測試以下：

<workflow-app name="aapply_province_Workflow" xmlns="uri:oozie:workflow:0.5">
   <start to="sqoop-224d"/>
    <kill name="Kill">
        <message>Action failed, error message[${wf:errorMessage(wf:lastErrorNode())}]</message>
    </kill>
    <action name="hive-3aa5" cred="hive2" retry-max="3" retry-interval="1"><!--方案一：wf自動重試-->
        <hive2 xmlns="uri:oozie:hive2-action:0.1">
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <jdbc-url>jdbc:hive2://master:10000/default</jdbc-url>
            <script>${wf:appPath()}/hive-3aa5.sql</script>
        </hive2>
        <ok to="sqoop-224d"/>
        <error to="Kill"/>
    </action>

    <action name="sqoop-224d"><!--用於測試，有誤的sqoop腳本-->
        <sqoop xmlns="uri:oozie:sqoop-action:0.2" >
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <command>export --connect jdbc:mysql://172.16.60.65:3306/dm --username dw_all --password xxxxxxxx --table apply_province --export-dir /user/hive/warehouse/dm1.db/apply_province --columns province_name,apply_count --input-null-string \\N --input-fields-terminated-by \001 --input-null-non-string \\N -m 1 
</command>
        </sqoop>
        <ok to="End"/>
        <error to="email-kill"/>
    </action>

<action name="kill-shell"><!--方案二：coord.xml不支持，wf.xml裏也取不到coord_job_id,不可行-->
 <shell xmlns="uri:oozie:shell-action:0.2">
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<exec>oozie job </exec>
<argument> -rerun</argument>
<argument> ${coord:id()}</argument><!--${coord:id()}err:No function is mapped to the name "coord:id"-->
<argument> -date</argument>
<argument>${coord:formatTime(coord:dateOffset(coord:nominalTime(), 8, 'HOUR'), 'yyyy-MM-dd')}T00:00+0800::${coord:formatTime(coord:dateOffset(coord:nominalTime(), 8, 'HOUR'), 'yyyy-MM-dd')}T23:00+0800</argument><!--coord:formatTime ERR:no function 說明wf裏不能調crood的el變量-->
</shell>
<ok to="End"/>
<error to="Kill"/>
</action>

<action name="rerun"><!--方案二升級：思路 wf裏取不到coord裏傳遞過來-->
<shell xmlns="uri:oozie:shell-action:0.2">
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<exec>oozie job </exec>
<argument> -rerun</argument>
<argument> ${crood_job_id}</argument>
<argument> -date</argument>
<argument>${currentdate}T00:00+0800::${currentdate}T23:59+0800</argument>
</shell>
<ok to="End"/>
<error to="Kill"/>
</action>

<action name="email-kill"><!--方案三：在集羣故障、網絡環境等外在因素致使時以上方案依然成功不了，一直rerun，發email給運維-->
<email xmlns="uri:oozie:email-action:0.1">
<to>junjie.li@tuanche.com</to>
<subject>The wf ${wf:id()} killed.</subject>
<body>
try shell eg:oozie job -rerun 0000269-181030095623092-oozie-oozi-C -date 2019-01-11T00:00+0800::2019-01-11T23:00+0800
具體 -rerun coord_job_id 及-date 的當前job的執行時間區間，參考相關配置：
coord apth: oozie.coord.application.path//properties不明文設置 取不到\n 
The wf ${wf:id()} killed.\n 
wf path:${wf:appPath()}
</body>
</email>
<ok to="shell-kill"/><!--注意這裏EMAIL成功以否都調重啓腳本-->
<error to="shell-kill"/>
</action>

<action name="shell-kill"><!--方案四：網上crontab + oozie db 裏取被killed job id思路 ，改成shell 下rerun自啓,相較於升級版方案二參數設置簡單點，只須要wf建立時指定當前coord_job_name-->
<shell xmlns="uri:oozie:shell-action:0.2">
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<exec>rerun.sh</exec>
<argument>apply_province_Schedule</argument><!--${crood_job_name} 在rerun 過程當中好像改了Properties不會從新加載，寫死在wf裏便可-->
<file>rerun.sh</file>
</shell>
<ok to="Kill"/><!--注意這裏無論你是END仍是kill，都表示上邊wf流中的error你處理了，故這次crood job 是最終狀態由此shell狀態決定，而rerun查的crond 的成功以否，因此理論上還要wf改爲kill狀態，可是此shell也是job的一部分，執行過程當中並無付合條件的Kill記錄，因此這裏只能在在外部crontab裏定時檢測而後rerun.sh,關於oozie 的三種job:wf crood bunld,參考相關文章，他不只能夠處理複雜的數據處理流程如順序依賴和分支嵌套等外，還支持據於數據的複雜的調度流程和組合-->


<!因此最終結論是wf裏用方案一和三，retry 併發郵件，想定時檢測crood job 若是當時因環境等問題還沒成功，則在crontab 裏定時在從新rerun，固然前提是你的流容許在crontab裏隨時rerun，因crontab可沒有 crood 的一些複雜條件和時間順序判斷邏輯，來決定此job是否付合條件調度執行>
<error to="Kill"/>
</action>

<end name="End"/>
</workflow-app>
#!/bin/sh


# mysql鏈接
hostname="localhost"
port="3306"
username="oozie"
password="oozie"
dbname="oozie"

# job的名稱
appname=$1

#當前時間
nowtime=`date --date='0 days ago' "+%Y-%m-%d %H:%M:%S"`

# sql 查詢語句
select_sql=" 
select concat(a.job_id,',',a.action_number) from COORD_JOBS j,COORD_ACTIONS a 
 where j.id = a.job_id 
 and j.app_name = '${appname}' 
 and j.status = 'running' 
 and to_days(a.created_time) = TO_DAYS(now()) 
 and a.status != 'SUCCEEDED';
"

# 鏈接mysql查詢
result=(`mysql -h${hostname}  -P${port}  -u${username} -p${password} ${dbname} -N -e "${select_sql}"`)
echo ${result}

# 若是查詢結果不爲空，則執行oozie的rerun腳本,並跳過失敗的節點執行
if [ -n "${result}" ] ;then
  #echo ${result}
  IFS=',' arr=(${result})
  echo ${nowtime} ${appname} ${arr[0]}  ${arr[1]} >> job_rerun.log
  oozie job -rerun ${arr[0]} -refresh -action ${arr[1]} -D oozie.wf.rerun.failnodes=false
fi

感謝胖子的腳本， 哈哈，想改形成wf裏自動重啓執行，但最終失敗仍是crontab 了， https://www.cnblogs.com/30go/p/9244142.html

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程