Apache Dolphinscheduler - 无需重启 Master-Server 停止疯狂刷日志解决方案
记录的是一个 3.0 比较难搞的问题,相信不少使用过 3.0 的用户都遇到过 Master 服务中存在一些工作流或者任务流一直不停的死循环的问题,导致疯狂刷日志。不过本人到现在也没找到最关键的触发原因,只是看到一些连锁反应带来的结果……
影响因素
CPU飙高:每个工作流的运行在 Master 中都是一个线程,当这个线程一直没有结束时,是会占用CPU资源的,当服务中存在大量的线程死循环时,可想而知,服务器的资源压力有多大。
磁盘打满:循环的线程内存在日志打印,当大量的线程无时无刻在打印日志时,日志文件会迅速堆积,磁盘的大小是固定的,当磁盘使用率超过一定的阀值时,其他的程序也会因为磁盘可用空间不足而受影响。有些人设置了 Logback 等日志框架配置,限定了日志文件的总大小,但是这样也会引发日志快速覆盖问题,无法找到可用的日志。
数据库压力:每个循环里面都有相关的数据库查询操作,大量的查询会造成数据库压力短期内迅速增大,如果数据库性能不能很好的话,可能数据库就会先挂了。
异常分类
工作流异常:经过排查,大概率发现工作流 state = 4 状态的实例会刷日志
任务流异常:经过排查,大概率发现任务流 state = 6 状态的实例会刷日志
状态枚举异常:工作流、任务流一些异常状态会集中到一个异常状态集合里,监听该异常状态集合时,导致会刷日志
以上 3 种情况也分别对应代码里 3 个关键实体类:ProcessInstanceExecCacheManagerImpl、StreamTaskInstanceExecCacheManagerImpl、StateEventHandlerManager
我们见名知意可知,这 3 个实体类分别对应以上 3 种异常分类,而且都属于 Java 缓存级别管理类!
解决思路
基本的 master 服务处理工作流的一个事件流程,工作流的线程类(WorkflowExecuteRunnable)被放到缓存中,缓存的 key 是工作流实例的 ID,同时每一个工作流都有对应的事件,事件中存储工作流实例的 ID,每次执行事件时都会从缓存中获取线程类,当线程类执行失败时便重新创建一个事件加入事件队列中执行,依次往复,除非缓存中的数据被清除了,才会结束循环。具体流程如下图
- 清空异常的工作流或任务流实例(数据库),否则重启又会重新读取问题流实例数据,又开始刷……
- 清空以上相关的 Java 缓存(重点看异常分类的 3 个关键类),这一步是关键不重启也可解决刷日志问题,否则需要重启来替代清空缓存的操作(不优雅)
具体操作
1、进入 Master-Server 的日志目录
2、通过 grep 筛选日志中存在的问题流实例 ID(工作流实例、任务流实例)
# 工作流实例
cat dolphinscheduler-master.log |grep "ERROR" | awk -F 'WorkflowInstance-' '{print $2}'
| awk -F']' '{print $1}' | sort | uniq
# 任务流实例
cat dolphinscheduler-master.log |grep "ERROR" | awk -F 'TaskInstance-' '{print $2}'
| awk -F']' '{print $1}' | sort | uniq
Tips:这里有一点要注意,如果筛选出来有『0』的实例ID,这个经排查并没用,猜测属于系统默认ID(无视即可),而且发现规律:在日志中,如果 A 或 B 等于 0 或都等于 0,其实只要关心有正常业务值实例ID一方即可,意味着每次业务主要问题是由他(工作流实例或任务流实例)引起,如果都有正常值,那么属于任务流实例问题引起
……[WorkflowInstance-A][TaskInstance-B]……
3、分别在 Api-Server 和 Master-Server 搭建 Arthas 框架,将筛选出来的实例 ID 替换 OGNL 调用函数参数
- Arthas 快速入门见文档:快速入门 | arthas
4、删除工作流实例、任务流实例数据库数据(Api-Server 执行)
ognl '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteWorkProcessInstanceById("工作流实例ID")'
ognl '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteAllSubWorkProcessByParentId("工作流实例ID")'
ognl '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteWorkProcessMapByParentId("工作流实例ID")'
ognl '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteWorkTaskInstanceByProcessInstanceId("工作流实例ID")'
如果不想清空数据库实例,我们刚讲过主要也是因为 state = 4 引起的问题,可以通过改工作流数据库状态也是可以的
UPDATE t_ds_process_instance SET state = 5 WHERE state = 4 AND id = 工作流实例ID;
5、清空 Java 缓存(Master-Server 执行)
# 工作流实例缓存
ognl '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processInstanceExecCacheManagerImpl").removeByProcessInstanceId("工作流实例ID")'
# 任务流实例缓存
ognl '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("streamTaskInstanceExecCacheManagerImpl").removeByTaskInstanceId("任务流实例ID")'
# 异常枚举缓存
ognl '@org.apache.dolphinscheduler.server.master.event.StateEventHandlerManager@stateEventHandlerMap.clear()'
Tips:最后一步因为一刀切可能会误伤正常业务状态,所以最好等到只剩这些异常业务的时候再执行,也可进一步做一些定位异常业务的工作流实例ID进行精准清空(后续更新……)
附加
- Arthas - Can not read arthas version from: https://arthas.aliyun.com/api/latest_version
- Arthas - Unable to open socket file: target process not responding or HotSpot VM not loaded
-
近期在跟社区的沟通中,3.1.9 和 3.2.0 版本都有涉及过该 BUG 的代码修复,使得该问题已经得到解决,感兴趣可以了解最新版本