文档章节

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

hblt-j
 hblt-j
发布于 01/18 18:50
字数 2877
阅读 7
收藏 0

 

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

复制代码
    <!-- 统计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

正确使用方法:

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

© 著作权归作者所有

共有 人打赏支持
hblt-j
粉丝 22
博文 195
码字总数 71424
作品 0
海淀
架构师
私信 提问
Oozie安装总结

权声明:本文为博主原创文章,未经博主允许不得转载。 一、使用CM添加服务的方式安装Oozie 如果在创建Oozie数据库时失败,且提示数据库已存在,如下图,则可能是之前已经安装过Oozie,没有卸...

Zero零_度
2016/09/23
48
0
oozie VS azkaban

Oozie 可以从失败点重启,azkaban不能 Oozie 的 flow 保存在 DB ,而azkaban 保存在内存 Azkaban 在启动job前,必须确定execution路径,然而 Oozie 允许节点自己决定 Azkaban 不支持事件触发...

晨磊
2016/04/11
239
0
HAWQ取代传统数仓实践(五)——自动调度工作流(Oozie、Falcon)

一旦数据仓库开始使用,就需要不断从源系统给数据仓库提供新数据。为了确保数据流的稳定,需要使用所在平台上可用的任务调度器来调度ETL定期执行。调度模块是ETL系统必不可少的组成部分,它不...

wzy0623
2017/05/18
0
0
基于Hadoop生态圈的数据仓库实践 —— ETL(三)

三、使用Oozie定期自动执行ETL 1. Oozie简介 (1)Oozie是什么 Oozie是一个管理Hadoop作业、可伸缩、可扩展、可靠的工作流调度系统,其工作流作业是由一系列动作构成的有向无环图(DAGs),协...

wzy0623
2016/07/11
0
0
【Oozie-4.1.0】Oozie-4.1.0 + hadoop-2.7.1

一、环境 maven-3.3.0 hadoop-2.7.1 二、编译 http://apache.mirrors.pair.com/oozie/4.1.0/oozie-4.1.0.tar.gz 三、配置 四、examples job.properties workflow.xml lib/oozie-examples-4.1......

HarryWu
2016/06/19
154
1

没有更多内容

加载失败,请刷新页面

加载更多

RabbitMQ入门

RabbitMQ是一个由erlang开发的基于AMQP(Advanced Message Queue)协议的开源实现。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面都非常的优秀。是当前最主流的消息中间...

watermelon11
今天
15
0
今天的学习

自动加载:方法一 function __autoload( $className ){在这里,完成加载B这个类文件的工作。}class A{} //这是一个类$a1 = new A(); //这里没有自动加载的发生,因为A这个类...

墨冥
今天
2
0
印刷工艺步骤

印刷厂从收到订单到交付整个流程,一般涉及到以下步骤 1.设计(经过软件如cdr,psd,ai等等设计需要印刷的名片,宣传单,画册等物料); 2.排版拼版(在电脑软件这区域完成); 3.出版、出硫...

focusone
昨天
4
0
virtualbox中安装ubuntu

virtualbox+ubuntu 安装virtualbox,当前版本是6.0.4 下载ubuntu安装盘,建议lubuntu,链接是http://mirrors.ustc.edu.cn/ubuntu-cdimage/lubuntu/releases/18.04.2/release/lubuntu-18.04.......

chuqq
昨天
5
0
exists 谓词的子查询

https://blog.csdn.net/qq_19782019/article/details/78730882

仟昭
昨天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部