目录
- 背景
- 过程
- 结论
- 解决方案
背景
- 公司的Flink集群是yarn session模式部署的，也就是这个集群是所有作业共享的一个flink集群
- 5.7号22:38分的时候有告警提示作业重启了，因为之前有几次重启没有恢复，所以这次重点排查重启未恢复原因
过程
-
先在JobManager的logs查看对应日志，日志比较多，是点击下载按钮然后在linux上wget下载下来。因为是session模式所以重启的时候application_id都没变
JobManager.png - 在JobManager里面对应时间看到，是某个taskManager心跳上报失败了，于是在日志里面再次找container_xxxxxxxxx这个taskManager相关信息，没啥特别的，只是找到了container_xxxxxxxxx@ 对应的机器ip xxxx，别的地方也能找到就是了，这边捞日志顺带看下心跳上报错误的ip
2025-05-07 22:38:04,382 INFO org.apache.flink.runtime.executiongraph.ExecutionGraph - Job xxx(xxxx) switched from state RUNNING to FAILING.
java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id container_xxxxxxxxx timed out.
at org.apache.flink.runtime.jobmaster.JobMaster$TaskManagerHeartbeatListener.notifyHeartbeatTimeout(JobMaster.java:1656)
at org.apache.flink.runtime.heartbeat.HeartbeatManagerImpl$HeartbeatMonitor.run(HeartbeatManagerImpl.java:339)
结论
- 找到对应心跳上报失败的ip之后，上机器看linux日志，并查看监控看cpu 内存 io等，发现cpu 内存使用量看着正常，但是io util有问题
grep "May 7 22:" /var/log/messages
超时.png
ioutil.png
- 可以看到ambari-agent (hadoop相关)的 metrics_monitor.py 脚本bug或依赖问题，反复崩溃导致 abrt记录core文件，abrt来不及清理，/var/spool/abrt被 crash dump 文件撑爆导致 I/O爆炸、负载爆表、abrt进程死锁加剧系统瓶颈，导致的io util被干爆，从而导致系统响应慢，导致心跳上报问题
解决方案
- 解决方案：/var/spool/abrt/单独挂载，或者设置系统级core dump限制或者限制/etc/abrt/abrt-action-save-package-data.conf arbt的dump大小
