1、问题描述

先说下我们生产环境的部署情况
azkaban-exec部署在prod11、prod12两台机器上，这两台都是物理机，同时还不部署了namenode、resourcemanafer、historyserver、hiverserver、metastore等

正常情况应该是两个azkaban-exec节点都能执行任务，但是昨天发现居然只有一个节点在执行任务

可以通过执行sql语句进行验证：

select * from executors;
 
+----+------------------------+-------+--------+
| id | host                   | port  | active |
+----+------------------------+-------+--------+
| 36 | hdfs-prod12.yingzi.com | 12321 |      1 |
| 35 | hdfs-prod11.yingzi.com | 12321 |      1 |
+----+------------------------+-------+--------+
 
#查看2022-02-22 00:00:00以后任务执行情况
select executor_id,count(1),FROM_UNIXTIME(max(update_time)/1000) from execution_flows where executor_id in (35,36) and update_time>=1645459200000 group by executor_id;
+-------------+----------+--------------------------------------+
| executor_id | count(1) | FROM_UNIXTIME(max(update_time)/1000) |
+-------------+----------+--------------------------------------+
|          35 |       41 | 2022-02-22 23:28:19.0980             |
|          36 |    16168 | 2022-02-23 17:38:34.3840             |
+-------------+----------+--------------------------------------+

可以看出prod11最近执行任务的时间是2022-02-22 23:28:19，并且22号一天也只执行了41次

再把时间往前推，发现prod11之前也是有问题的，只偶尔执行极少的任务。

虽然业务没有受到影响，但是全部离线任务都只能在prod12上执行，会导致prod12压力过大

而且会存在单点问题，万一prod12出问题，那离线任务就没法执行，影响业务了

2、发现-解决问题过程

这个问题其实早前就已经有端倪了，从年前开始，生产环境就会断断续续收到prod12的hiverserver2服务监控告警。
不过告警内容只是检测hiveserver2偶尔响应超时，查看应用JVM监控，并没有发现应用有什么异样。
hiverserver2本身是有部署多个节点的，并没有对任务执行产生影响。
而且这个告警很久才发生一次，所以并没有引起我们足够的重视。

2022-02-23凌晨，发生了多次hiverserver2的超时报警，都在prod12这台机
感觉事情没这么简单，于是开始重视起来
比较奇怪的是，hiveserver2也是部署在prod11和prod12节点，为啥都是只有prod12报，prod11从来不报的
对比两台机器的node监控，发现一些问题

prod11 CPU使用率：
在这里插入图片描述
prod12 CPU使用率：

prod11线程数监控：

prod12线程数监控：

prod11每秒fork进程数：

prod12每秒fork进程数：

可以看到：

CPU使用率prod11只有5左右，prod12峰值则高达60-70
prod12线程数差不多有prod11的两倍
还有每秒种fork的进程数，差别更大：prod11只有30不到，prod12最大都超过200了

这两台部署的服务是相近的，为何会差距这么大呢？
每秒fork的进程数，第一时间想到的就是azkaban
因为azkaban-exec执行任务都是通过调用shell命令的方式，每次shell调用都是fork新的进程

于是对azkaban进行检查，程序本身状态是很健康的。
但是通过sql查询任务执行情况，发现prod11基本不执行任务的
此时基本可以确定是因为任务全部在prod12执行，导致这台机压力过大，进而影响了hiveserver2的响应

至于prod11为什么不执行任务(偶尔执行)，则没有太好的思路
只看监控，应用本身是很健康的
于是只能去看azkaban代码，分析可能是哪一环节存在问题，再进行排查

排查了半天，并没有很大进展
尝试重启azkaban服务
没有意外，果然重启并不能解决问题。

还是只能继续啃代码，结合开发环境做实验来进行理解。
终于定位到问题点在哪里。

azkaban默认任务执行采用的推模式，由azkaban-web选择合适的executor，通过调用azkaban-exec http接口的方式，把任务"推"给executor执行
关键的核心就在于选择executor的代码，比较重要的是几个azkaban.executorselector.comparator前缀的配置。
查看生产环境azkaban-web的配置如下：

azkaban.executorselector.comparator.NumberOfAssignedFlowComparator=1
azkaban.executorselector.comparator.Memory=6
azkaban.executorselector.comparator.LastDispatched=1
azkaban.executorselector.comparator.CpuUsage=3

这里几个配置分别指：正在执行的任务数、系统可用内存、最近执行任务时间、CPU使用率等几个指标，配置的数字表示指标权重
大致策略是，把各个executor的指标进行对比，并根据权重求和，最终再进行对比，选择分数最高的那个

这几个指标的默认权重都是1，但是不知道是谁把权重调整成6了，已无从考究。
比较要命的是，prod11的内存占用，大部分时间都高于prod12(虽然实际内存都很充足)
因为内存的权重太高，导致内存基本成了选择executor的决定性因素，所以大部分任务都分发到prod12执行，和事实相符

因为azkaban是直接部署在物理机，混合部署了多个应用，所以单纯的根据内存和CPU来确定executor的优先级，其实是不靠谱的
所以我们决定把Memory和CpuUsage这两个指标去掉
直接注释掉相应的配置然后重启azkaban-web，问题得到解决

执行sql查看重启以后每个小时的任务执行情况：

select t.time_hour,sum(case executor_id when 38 then num else 0 end) num_prod11,sum(case executor_id when 36 then num else 0 end) num_prod12  from
    (
    select executor_id,FROM_UNIXTIME(update_time/1000,'%Y-%m-%d %H') time_hour,count(1) num from execution_flows where executor_id in (38,36) and update_time>=1645675200000 group by executor_id,FROM_UNIXTIME(update_time/1000,'%Y-%m-%d %H')
    )t group by t.time_hour;
 
 
+---------------+------------+------------+
| time_hour     | num_prod11 | num_prod12 |
+---------------+------------+------------+
| 2022-02-24 12 |        164 |        147 |
| 2022-02-24 13 |        178 |        134 |
| 2022-02-24 14 |        159 |        151 |
| 2022-02-24 15 |        153 |        163 |
| 2022-02-24 16 |        159 |        134 |
+---------------+------------+------------+

可以看到，两个节点都会执行任务了，基本比较平均
偶尔有些差异，推测是任务之间差异，有些大任务执行比较耗时，执行这些大任务的节点，执行的任务数相应也会降低。