oozie job 的挂了监控报警或重启

最新推荐文章于 2024-07-08 00:59:53 发布

weixin_34204722

最新推荐文章于 2024-07-08 00:59:53 发布

阅读量840

点赞数

文章标签： shell 数据库运维

原文链接：https://my.oschina.net/hblt147/blog/3003395

版权

2019独角兽企业重金招聘Python工程师标准>>>

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.html

input-events和output-events元素

一个Coordinator应用的输入事件指定了要执行一个Coordinator动作必须满足的输入条件，在Oozie当前版本，只支持使用dataset实例。
一个Coordinator动作可能会生成一个或多个dataset实例，在Oozie当前版本，输出事件只支持输出dataset实例。

Coordinator Job具有以上几个状态：

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

Coordinator 动作的状态集合，如下所示：

WAITING
READY
SUBMITTED
TIMEDOUT
RUNNING
KILLED
SUCCEEDED
FAILED

Oozie中工作流的定义:

参考：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包。

但是既然也可以脚本发EMAIL,那也应该可以error to shell :crontab ->oozie job -kill -rerun 等等:

重新run一个coordinator中的某个任务

可以有多种方法指定重跑的任务，这里介绍两个，一个是按照action id来重跑，一个是按时间的range来重跑

按照action id 重跑

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次。

复制代码

<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

正确使用方法:

1、oozie配置oozie

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

直接指定为ALL单独E0080这样的事件并没有效.

2、在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

转载于:https://my.oschina.net/hblt147/blog/3003395