详解 Flink 指标、监控与告警

整理：李培殿 & 杨伟海（Flink 区志愿者）

1. 监控告警链路：基于美团点评实时计算平台的实践

2. 常用的监控项：哪些指标可以高效地衡量作业

3. 指标的聚合方式：横看成岭侧成峰

4. 指标监控的应用：有哪些常见的表达方式供参考

为什么我们关注指标监控

我们将以天气举例。

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

• 可量化：比如最近天气很热。今天比昨天热吗京的温度比上海更热吗家就没有办法评判，所以温度就是这样一个指标，来量化我们天热的程度。

• 标准化：我们习惯说的温度是摄氏温度，如果有人跟你讲华氏温度，说今天77度，你就会觉得很奇怪，气温怎么会有这么高的数值，因此，我们的指标还需要是标准化的，需要有一个统一的标准。

• 多维度：南方的同学觉得35度闷得喘不过气来；北方的同学觉得35度好像也就那样。因为我们除了气温这个指标会影响人体的舒适度之外，还有一个指标叫空气湿度。所以衡量天气需要结合多个维度的指标。

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

• 实时：比如天气预 ，实时的预 才是我们需要的监控内容。

• 易用：相比于电视机里固定时间播 的天气信息，手机 App 就是易用的天气监控软件。

• 可查询历史：比如前几天某地一直在下雨，河流湍急，可能影响我出行的选择。

今天的分享从以下四个方面展开：

• 监控 警的链路——基于美团点评实时计算平台的实践

• 常用的监控 警项——哪些指标可以高效地衡量我的作业

• 指标的聚合方式——横看成岭侧成峰

• 指标监控的应用——有哪些常见的表达方式供参考

1. 监控 警的链路

1.1 监控 警链路

美团点评的指标监控 警的链路如下图所示。首先是我们对日志和指标都会进行统一的集中化的收集。Reporter （2.8和3.1中有介绍）把 Flink 作业的指标作为一条条日志打出来。然后再通过日志收集收上去，收到 Kafka 里面。接下来会通过实时作业做解析和聚合，再将得到的指标落到 Kafka 里，作为实时数据源。

下游会根据不同的需求，对不同的数据做不同的处理和展示。日志数据会落到 ES 里供查询使用，同时也会根据关键字接实时作业进行处理，做日志相关 警；数值指标会落到 OpenTSDB 里供大家查询，同时也支持各类的指标 警。最终这些内容还是会集中到我们的实时计算平台里，给用户做一个统一的展示。

整个链路下来，主要分为三个关键环节。

1. 日志收集部分，我们首先是要把这些日志和指标进行统一化、集中化的收集。对于这一环，之前两个讲师也讲过， Flink 现在提供的方式有三种：一个是在 Flink UI 上可以直接看到这个作业的一些指标；第二种 REST API 从作业上获取指标；第三种就是配各种第三方的 Reporter 。美团这边是在 slf4j 的基础上增加自己的维度信息格式化后往下发。

2. 解析展示部分，使用一些 Flink 作业去解析聚合平台所有作业的指标数据，展示给用户，也提供给下游使用。

3. 监控和 警部分，对于聚合完成了的指标，做一些个性化的可配置的规则 警。

2.2 如何确定哪些指标需要关注/strong>

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

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

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

另一方面是聚合的方式，如总和、均值、最大值、最小值、变化率等，需要注意是要消除统计误差，对数据取移动平均或者固定时间的平均来使曲线变得更加平滑。还有是差值，如上游数据量与下游数据量的差值、最新 offset 与消费的 offset 的差值。另外对于衡量 xx 率、xx 耗时可以使用 99 线。最后还有一点需要关注的，也是我们在实际工作中遇到的坑，即指标的缺失，如果没有拿到指标，作业状态则变成了黑盒，需要去关注作业的指标收集是否正常，需要监测是否存在指标丢失，是单个指标丢失还是整个作业的指标丢失。

4. 指标监控的应用

4.1 作业异常 警

• 作业状态异常：包括作业任务的异常状态如 failing，也包括 uptime 等指标的异常。

• 作业无指标上 ：作业无指标上 会给作业的负责人发 警；当上 的作业多到一定程度了，达到预值的时候会直接给平台的管理员发 警。

• 指标达到阈值：是大家最常用的 警项。比如：

• • 处理量跌0

  • 消费延迟（落后一定数量、持续一定时间）

  • 失败率、丢失率等

• 个性化：实时计算平台中有很多类任务，不同的任务它会有不同的特性。比如：

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

  • 聚合方式：不同的业务可能会有不同的 警的聚合的方式，这个也是需要尽量的兼容的。

• 错误日志、关键词日志：当错误日志到达一定量或者日志出现某关键词时，触发 警。

注意： 警系统本身的稳定性，放到第1位，避免出现误 、漏 、延迟。否则会影响业务方的准确判断。

4.2 指标大盘

• 反映平台整体的现状：

• • 异常值高亮

  • 多维度聚合

  • 时间线对比等

• 及时发现并快速定位到故障

• 给出平台可优化的方向

• 便于统筹资源分配

4.3 自动化运维

运维的几种阶段：

• 无法运维：没有指标，作业状态是个黑盒，出了问题一群人查代码。

• 手动运维：重启，扩容，回滚、迁移，降级，纠正错误代码，优化处理逻辑。手动运维表示无论在干什么，当 警电话一来，你需要掏出电脑、手机去排查问题。

• 辅助运维：当手动运维做多了，把大家的业务作业的各项指标都进行标准化，我们就可以得到一些参考值。把这些经验汇总，作为其他同学的运维的时候参考的建议，这样即使是新人也可以快速借助这些辅助工具进行处理，降低学习成本。

• 智能运维：智能运维是不需要人处理，当发生故障的时候，自动操作的运维方式。执行作业的机器挂了，自动拉起，自动把作业启动起来。资源不足了，自动去扩容。线上的作业有问题，自动切换到备用的作业……当然目前能做到的这些只能解决一部分问题，一些代码问题带来的故障还是需要人为介入修复 bug。

你在看」吗img src=”https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy84QXNZQmljRWVQdTcyUXF1YXNkanVYaWF5d3JMemljNmoxVFNXQmljeW1HZTQ2bm5qOGljYWN2T211bk9pYjFsQnQ2dTRWR3hkQmlhY2ljcVZpYXZpYU1GeTBiVmVnVmcvNjQw-oss-process=image/format,png”>