详解 Flink 指标、监控与告警

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

校对：杨伟海（Flink 社区志愿者）

 

摘要：本文由美团点评研发工程师孙梦瑶分享，主要介绍 Flink 的指标监控和报警的内容，分为如下四部分：

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

2. 经常使用的监控项：哪些指标能够高效地衡量做业
   

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

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

Tips：点击「阅读原文」连接可查看做者原版 PPT 及分享视频～

 

为何咱们关注指标监控

咱们将以天气举例。

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

• 可量化： 好比最近天气很热。今天比昨天热吗？北京的温度比上海更热吗？你们就没有办法评判，因此温度就是这样一个指标，来量化咱们天热的程度。
• 标准化： 咱们习惯说的温度是摄氏温度，若是有人跟你讲华氏温度，说今天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. 监控和报警 部分，对于聚合完成了的指标，作一些个性化的可配置的规则报警。

1.2 指标展现：Grafana

Grafana 支持比较多的数据源格式，好比 ES、OpenTSDB 等；它有个变量的功能，能够看某个做业的指标，也能够一块儿对比看。

相比于自研的指标展现工具，Grafana 配置界面会比较方便，省时省力，性价比高。若是是只是想简单的展现一下全部的做业的指标的话，Grafana 是个很好的选择，它也能够被外嵌在其余的页面上。可是 Grafana 图的类型比较单一，在实际的直接使用过程当中可能还会有一些局限性。

2. 经常使用的监控项

下面咱们来关注下通常会使用哪些指标来衡量做业运行的情况。

2.1 经常使用的指标

■ 系统指标

系统指标在 Flink 官网有相应的说明。

• 对于系统指标最常关注的是做业的可用性，如 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 做业更像是一种微服务，不只关心做业是否把全部数据都处理完了，还但愿做业能够7×24小时不间断的运行来处理数据。所以在业务逻辑中重要的指标在 Flink 中也会很重要。

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

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

• 还有是缓存命中率，有时候因为数据集过大，咱们只访问热数据，此时会在内存中缓存一部分信息，咱们能够监控缓存命中率，若是缓存命中率很是高说明缓存有效，若是缓存命中率很是低，一直在访问外部存储，就须要考虑缓存设计的是否合理。
  

另外还有几类是关于做业的处理逻辑，若是处理逻辑抛出异常将会致使做业 fullRestarts，此时通常会将这些异常进行 catch 住，若是涉及复杂计算的能够经过重试机制多试几回，若是重试后未成功则丢弃数据 。此时能够将处理数据的占比或者数据的某些特征做为指标上报，这样能够观察此类数据的占比来观测数据处理是否存在异常。又如 filter 过滤的数据占比能够观测 filter 的逻辑是否正常，还有窗口等涉及时间的算子须要监测超时丢弃的数据的占比等。

2.2 如何肯定哪些指标须要关注？

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

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

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

3. 指标的聚合方式

在上面介绍了经常使用的监控指标，接下来介绍下这些指标应该怎么看。同一个指标可能在机器的角度去看，也可能在做业的角度去看，不一样的角度会得出不一样的结果。

首先是做业的聚合维度，细粒度的如 Task、Operator 维度，稍微大点的粒度如 Job、机器、集群或者是业务维度（如每一个区域）。当查问题时从大的粒度着手，向细粒度进行排查。若是想看全局的现状则须要比较粗的粒度。能够将原始指标进行上报而后根据不一样场景进行聚合。若是要作性能测试则须要细粒度的查询，如 task 粒度。

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

最后是在观察指标的时候可能须要多个指标复杂聚合查询，如常见的时间线对比，例如以前正常的做业在今天出现反压，能够经过查询今天数据量的同比昨天数据量的增加。另外不一样的业务有不一样的趋势，例如外卖存在高峰时间段，能够对比数据量在高峰时间段的环比增加来进行衡量。还有关注的指标的持续时间，如做业的数据延迟，若是延迟时间较长则做业可能存在异常；还有指标的周期性，若是指标的变化存在周期性，则考虑是否由于时间窗口的影响。

还有须要考虑的是结合外部系统进行计算，例如上游为消费 Kafka ，除了想知道当前消费的情况，还想查看上游的数据量。例如该图中，蓝线为上游 Kafka 的数据量，红线为做业的 source 算子的 output 数据量，能够看到在午高峰和晚高峰基本上是持平的状态， 上游数据在午高峰及晚高峰有较高的增加，虽然在高峰时刻有反压，但主要缘由是因为上游数据量的增加而不是因为做业的处理能力不足。若是上游有多个算子能够将多个算子的数据量进行相加，这也是咱们除了使用 Grafana 外还自研的前端进行展现的缘由，自研前端能够将指标更加灵活的进行展现。

4. 指标监控的应用

4.1 做业异常报警

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

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

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

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

4.2 指标大盘

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

4.3 自动化运维

运维的几种阶段：

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

Q&A

Q1：构建一整套指标系统，指标库如何维护？须要去对程序进行代码级别的修改，仍是修改配置便可？

A： 既然想作一整套的监控系统天然但愿这个指标尽量是一个可适配的方式，那么咱们须要作什么？

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

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

• 搭建模型。

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

Q2：Grafana 平台的展现效果很好，可是报警不友好；报警这块有比较成熟的工具吗？

A： 能够看看 Prometheus，报警仍是挺成熟的。报警比指标聚合更须要个性化的东西，若是须要功能很是完善的话，可能都须要考虑自研。

Q3：算子内部能够获取到 taskManager 的指标吗？

A： 经过 restful API 去拿，不推荐在算子内部作，指标这个东西自己不该该影响你做业自己的处理逻辑，监控应该是一个比较外围的东西。

Q4:   如何根据指标发现做业问题的根源？

A:   按照指标从粗到细，能够参考 2.8 节和 3.1 节老师的教程。

Q5:  指标数据量比较大，如何选择存储？

A:   能够选择 openTSDB，其余 TSDB 也是能够的，像其余 Hive 或者 OLAP引擎 也是能够考虑的，指标数据做为一种时序数据，目前已有不少成熟的方案能够选择。

点击「 阅读原文 」可回顾做者分享视频～

---

关注 Flink 中文社区，获取更多技术干货

你在看」吗？

本文分享自微信公众号 - Flink 中文社区（gh_5efd76d10a8d）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。