目录

• 背景
• 过程
• 结论
• 解决方案

---

背景

• 公司的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大小