一般来讲，checkpoint配置10s-60s都是合理的，默认的超时时间是600s，在业务逻辑不复杂的情况下，极少会出现超时的情况
如果发生了超时。就需要先定位到具体的机器和进程。
然后再根据业务场景排查具体是什么问题引起的超时。
flink集群和上下游组件正常运行的情况下，由于业务逻辑处理或者数据问题导致超时的概率应该在99%以上，所以在排除系统问题的情况下，直接从业务逻辑定位问题是正确的方向。
排查思路分3步：
1. 先找到超时的subtask序号
如果超时正在发生，可以直接在
这里看到超时的那一条记录。
如果超时已经结束了，可以查看历史记录：
点击图中的位置找到超时的那条checkpoint记录
然后找到超时的subtask
注意2点：
- 这里的subtask=48 不是说在第48台机器。这点不要被误导；
- 这个列表的subtask序号是从1开始的。
2. 找到对应的机器和任务
curl “http://flinkip:8088/proxy/${application_id}/jobs/${job_id}/vertices/${vertice_id}”| python -m json.tool
执行这个命令，这个命令中有三个参数需要替换下：
- application_id和job_id 需要使用自己任务的，可以直接在ui中的url中拿到；
- vertice_id需要查一下，具体查找的方式如下：
打开控制台搜索一下vertices关键字，然后找到第一条信息2，点击进去，查到响应结果值3，根据你超时的subtask算子，找到对应序号的vertices_id
也可以直接 curl “http://flinkip:8088/proxy/${application_id}/jobs/${job_id}” | python -m json.tool 找到vertices的json块，拿到对应的vertices_id
最终拼接成一个链接，比如：
curl “http://flinkip:8088/proxy/application_1603111931177_15197/jobs/87431c768c9da649edb8239b7265c7a4/vertices/47d89856a1cf553f16e7063d953b7d42”| python -m json.tool
然后在终端请求一下，就可以找到每一个subtask对应的机器和端口号了。比如：
这里要注意的是，请求返回的json中subtask的序号是从0开始的，按照上面flink界面截图中subtask=48出现的checkoutpoint timeout的话，应该要找的是json中subtask=47的机器ip和端口。截图中展示的是subtask=95的信息，都是一样的。
3. 自行排查问题
知道出问题的subtask任务的机器和端口了，就可以去对应机器上找到任务，一般直接：
- netstat -nap| grep 端口号 就找到对应的pid了，
- 然后ps aux | grep pid 就找到任务目录和日志了。
然后就自行根据业务逻辑排查：
- error.log
- 自己的业务日志
- 进程是否频繁full gc
- 。。。。。。