怎么理解Flink指标、监控与告警

怎么理解Flink指标、监控与告警，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

指标：衡量和描述对象的方式

• 可量化： 比如最近天气很热。今天比昨天热吗？北京的温度比上海更热吗？大家就没有办法评判，所以温度就是这样一个指标，来量化我们天热的程度。
• 标准化： 我们习惯说的温度是摄氏温度，如果有人跟你讲华氏温度，说今天77度，你就会觉得很奇怪，气温怎么会有这么高的数值，因此，我们的指标还需要是标准化的，需要有一个统一的标准。
• 多维度： 南方的同学觉得35度闷得喘不过气来；北方的同学觉得35度好像也就那样。因为我们除了气温这个指标会影响人体的舒适度之外，还有一个指标叫空气湿度。所以衡量天气需要结合多个维度的指标。

监控：对指标进行监测和控制

• 实时：比如天气预报，实时的预报才是我们需要的监控内容。
• 易用： 相比于电视机里固定时间播报的天气信息，手机 App 就是易用的天气监控软件。
• 可查询历史： 比如前几天某地一直在下雨，河流湍急，可能影响我出行的选择。

• 监控报警的链路——基于美团点评实时计算平台的实践
• 常用的监控报警项——哪些指标可以高效地衡量我的作业
• 指标的聚合方式——横看成岭侧成峰
• 指标监控的应用——有哪些常见的表达方式供参考

1.1 监控报警链路

1. 日志收集 部分，我们首先是要把这些日志和指标进行统一化、集中化的收集。对于这一环，之前两个讲师也讲过， Flink 现在提供的方式有三种：一个是在 Flink UI 上可以直接看到这个作业的一些指标；第二种 REST API 从作业上获取指标；第三种就是配各种第三方的 Reporter 。美团这边是在 slf4j 的基础上增加自己的维度信息格式化后往下发。
2. 解析展示 部分，使用一些 Flink 作业去解析聚合平台所有作业的指标数据，展示给用户，也提供给下游使用。
3. 监控和报警 部分，对于聚合完成了的指标，做一些个性化的可配置的规则报警。

1.2 指标展示：Grafana

2.1 常用的指标

• 对于系统指标最常关注的是作业的可用性，如 uptime (作业持续运行的时间)、fullRestarts (作业重启的次数)。

• 第二个关注的是作业的流量，可以通过 numRecordsIn、numBytesInLocal 等相关指标来关注作业每天处理的消息数目及高峰时间段的流量，通过关注这些指标可以观察作业的流量表现是否正常。

• 然后是 CPU（如：CPU.Load）、内存（如：Heap.Used ）、GC ( 如：GarbageCollector.Count、GarbageCollector.Time )及网络 ( inputQueueLength、outputQueueLength) 相关指标，这些指标一般是用来排查作业的故障信息。

• 另外是 checkpoint 相关信息，例如最近完成的 checkpoint 的时长（ lastCheckpointDuration ）、最近完成的 checkpoint 的大小（ lastCheckpointSize ）、作业失败后恢复的能力（ lastCheckpointRestoreTimestamp ）、成功和失败的 checkpoint 数目（ numberOfCompletedCheckpoints、numberOfFailedCheckpoints ）以及在 Exactly once 模式下 barrier 对齐时间（ checkpointAlignmentTime ）。

• 还有就是 connector 的指标，例如常用的 Kafka connector ，Kafka 自身提供了一些指标，可以帮助我们了解到作业最新消费的消息的状况、作业是否有延迟等。
  

• 比如处理逻辑耗时打点，例如包含复杂逻辑的业务系统，可以通过在逻辑前后进行打点，这样可以查看每条消息处理完这个逻辑的耗时。

• 另一块是外部服务调用的性能， 在 Flink 作业中可能需要访问外部存储（如 Redis ）, 可以通过打点来查看请求的耗时、请求的成功率等。

• 还有是缓存命中率，有时候由于数据集过大，我们只访问热数据，此时会在内存中缓存一部分信息，我们可以监控缓存命中率，如果缓存命中率非常高说明缓存有效，如果缓存命中率非常低，一直在访问外部存储，就需要考虑缓存设计的是否合理。
  

2.2 如何确定哪些指标需要关注？

1. 第一点是作业状态相关的， 如作业是否出故障、作业是否存活、作业是否稳定运行、影响作业可用性的风险因素（如上次 checkpoint 是否成功、最近成功的 checkpoint 的时间）。

2. 第二点是作业性能相关的，如作业的处理延迟、数据倾斜、性能瓶颈（如外部访问）等。

3. 第三点是业务逻辑相关，如上游数据质量、新上的逻辑是否存在问题、数据是否存在丢失（ Exactly once 语义中数据是否允许丢失）。

4.1 作业异常报警

• 作业状态异常： 包括作业任务的异常状态如 failing，也包括 uptime 等指标的异常。
• 作业无指标上报： 作业无指标上报会给作业的负责人发报警；当上报的作业多到一定程度了，达到预值的时候会直接给平台的管理员发报警。
• 指标达到阈值： 是大家最常用的报警项。比如：
• 处理量跌0
• 消费延迟（落后一定数量、持续一定时间）
• 失败率、丢失率等
• 个性化： 实时计算平台中有很多类任务，不同的任务它会有不同的特性。比如：

• 报警时段：不同的时间段报警，可能需要有不同的域值，或者不同的报警方式（公司通讯软件报警、电话报警等）

• 聚合方式：不同的业务可能会有不同的报警的聚合的方式，这个也是需要尽量的兼容的。
• 错误日志、关键词日志： 当错误日志到达一定量或者日志出现某关键词时，触发报警。

4.2 指标大盘

• 反映平台整体的现状：
• 异常值高亮
• 多维度聚合
• 时间线对比等
• 及时发现并快速定位到故障
• 给出平台可优化的方向
• 便于统筹资源分配

4.3 自动化运维

• 无法运维： 没有指标，作业状态是个黑盒，出了问题一群人查代码。
• 手动运维： 重启，扩容，回滚、迁移，降级，纠正错误代码，优化处理逻辑。手动运维表示无论在干什么，当报警电话一来，你需要掏出电脑、手机去排查问题。
• 辅助运维： 当手动运维做多了，把大家的业务作业的各项指标都进行标准化，我们就可以得到一些参考值。把这些经验汇总，作为其他同学的运维的时候参考的建议，这样即使是新人也可以快速借助这些辅助工具进行处理，降低学习成本。
• 智能运维： 智能运维是不需要人处理，当发生故障的时候，自动操作的运维方式。执行作业的机器挂了，自动拉起，自动把作业启动起来。资源不足了，自动去扩容。线上的作业有问题，自动切换到备用的作业……当然目前能做到的这些只能解决一部分问题，一些代码问题带来的故障还是需要人为介入修复 bug。

• 在设计整套系统的架构时，需要有一定的兼容性，不能只关注一类指标。

• 设计初期需要考虑有哪些类型的指标，每个类型的指标有什么样的特征，可能有哪些聚合的维度，用什么样的方式去聚合。

• 搭建模型。

• 设计，先把指标的特征提取出来，然后对这些特征去进行设计，最后做一个能兼容的系统，这样对于已知类型的指标，就只需修改配置就可以扩展了。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。