Flink 指标、监控与告警

目录

监控报警的链路

指标展示:Grafana

系统指标

自定义指标

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

指标的聚合方式

作业异常报警

指标大盘

自动化运维


监控报警的链路

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

指标:衡量和描述对象的方式(可量化、标准化、多维度)
监控:对指标进行监测和控制(实时、易用、可查询历史)

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

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

指标展示:Grafana



相比于自研的指标展示工具,Grafana 配置界面会比较方便,省时省力,性价比高。如果只是想简单的展示一下所有的作业的指标的话,Grafana 是个很好的选择,它也可以被外嵌在其他的页面上。但是 Grafana 图的类型比较单一,在实际使用过程中可能还会有一些局限性。

系统指标

对于系统指标最常关注的是作业的可用性,如 uptime (作业持续运行的时间)、fullRestarts (作业重启的次数)。第二个关注的是作业的流量,可以通过 numRecordsInnumBytesInLocal 等相关指标来关注作业每天处理的消息数目高峰时间段的流量,通过关注这些指标可以观察作业的流量表现是否正常。然后是 CPU如:CPU.Load)、内存如:Heap.Used )、GC ( 如:GarbageCollector.Count、GarbageCollector.Time )及网络 ( inputQueueLength、outputQueueLength) 相关指标,这些指标一般是用来排查作业的故障信息

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

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

自定义指标

自定义指标是指用户可以在自己的作业逻辑中进行埋点,这样可以对自己的业务逻辑进行监控。现在的 Flink 作业更像是一种微服务,不仅关心作业是否把所有数据都处理完了,还希望作业可以7×24小时不间断的运行来处理数据。因此在业务逻辑中重要的指标在 Flink 中也会很重要。
【1】比如处理逻辑耗时打点,例如包含复杂逻辑的业务系统,可以通过在逻辑前后进行打点,这样可以查看每条消息处理完这个逻辑的耗时
【2】另一块是外部服务调用的性能, 在 Flink 作业中可能需要访问外部存储(如 Redis ), 可以通过打点来查看请求的耗时、请求的成功率等。
【3】还有是缓存命中率,有时候由于数据集过大,我们只访问热数据,此时会在内存中缓存一部分信息,我们可以监控缓存命中率,如果缓存命中率非常高说明缓存有效,如果缓存命中率非常低,一直在访问外部存储,就需要考虑缓存设计的是否合理。

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

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

第一点是作业状态相关的, 如作业是否出故障作业是否存活作业是否稳定运行、影响作业可用性的风险因素(如上次 checkpoint 是否成功、最近成功的 checkpoint 的时间)。
第二点是作业性能相关的,如作业的处理延迟数据倾斜性能瓶颈(如外部访问)等。
第三点是业务逻辑相关,如上游数据质量新上的逻辑是否存在问题数据是否存在丢失( Exactly once 语义中数据是否允许丢失)。

指标的聚合方式

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

首先是作业的聚合维度,细粒度的如 TaskOperator 维度,稍微大点的粒度如 Job机器集群或者是业务维度(如每个区域)。当查问题时从大的粒度着手,向细粒度进行排查。如果想看全局的现状则需要比较粗的粒度。可以将原始指标进行上报然后根据不同场景进行聚合。如果要做性能测试则需要细粒度的查询,如 task 粒度。

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

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

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

作业异常报警

作业状态异常:包括作业任务的异常状态如 failing,也包括 uptime 等指标的异常。
作业无指标上报:作业无指标上报会给作业的负责人发报警;当上报的作业多到一定程度了,达到预值的时候会直接给平台的管理员发报警。
指标达到阈值:是大家最常用的报警项。比如:处理量跌0消费延迟(落后一定数量、持续一定时间)、失败率丢失率等。
个性化:实时计算平台中有很多类任务,不同的任务它会有不同的特性。比如:
【1】报警时段:不同的时间段报警,可能需要有不同的域值,或者不同的报警方式(公司通讯软件报警、电话报警等)
【2】聚合方式:不同的业务可能会有不同的报警的聚合的方式,这个也是需要尽量的兼容的。
【3】错误日志、关键词日志:当错误日志到达一定量或者日志出现某关键词时,触发报警。

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

指标大盘

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

自动化运维

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

【问题】构建一整套指标系统,指标库如何维护?需要去对程序进行代码级别的修改,还是修改配置即可?
【解答】
既然想做一整套的监控系统自然希望这个指标尽可能是一个可适配的方式,那么我们需要做什么?
【1】在设计整套系统的架构时,需要有一定的兼容性,不能只关注一类指标。
【2】设计初期需要考虑有哪些类型的指标,每个类型的指标有什么样的特征,可能有哪些聚合的维度,用什么样的方式去聚合。
【3】搭建模型。
【4】设计,先把指标的特征提取出来,然后对这些特征去进行设计,最后做一个能兼容的系统,这样对于已知类型的指标,就只需修改配置就可以扩展了。

【问题】Grafana 平台的展示效果很好,但是报警不友好;报警这块有比较成熟的工具吗?
【解答】
可以看看 Prometheus,报警还是挺成熟的。报警比指标聚合更需要个性化的东西,如果需要功能非常完善的话,可能都需要考虑自研。

【问题】算子内部可以获取到 taskManager 的指标吗?
【解答】
通过 restful API 去拿,不推荐在算子内部做,指标这个东西本身不应该影响你作业本身的处理逻辑,监控应该是一个比较外围的东西。

【问题】指标数据量比较大,如何选择存储?
【解答】
可以选择 openTSDB,其他 TSDB 也是可以的,像其他 Hive 或者 OLAP引擎也是可以考虑的,指标数据作为一种时序数据,目前已有很多成熟的方案可以选择。

如今的大数据技术应用场景,对实时性的要求已经越来越高。作为新一代大数据流处理框架,由于非常好的实时性,Flink独树一帜,在近些年引起了业内极大的兴趣和关注。Flink能够提供毫秒级别的延迟,同时保证了数据处理的低延迟、高吞吐和结果的正确性,还提供了丰富的时间类型和窗口计算、Exactly-once 语义支持,另外还可以进行状态管理,并提供了CEP(复杂事件处理)的支持。Flink在实时分析领域的优势,使得越来越多的公司开始将实时项目向Flink迁移,其社区也在快速发展壮大。 目前,Flink已经成为各大公司实时领域的发力重点,特别是国内以阿里为代表的一众大厂,都在全力投入,不少公司为Flink社区贡献了大量源码。如今Flink已被很多人认为是大数据实时处理的方向和未来,很多公司也都在招聘和储备了解掌握Flink的人才。 本教程将Flink理论与电商数据分析项目实战并重,对Flink基础理论知识做了系统的梳理和阐述,并通过电商用户行为分析的具体项目用多个指标进行了实战演练。为有志于增加大数据项目经验、扩展流式处理框架知识的工程师提供了学习方式。 二、教程内容和目标 本教程主要分为两部分: 第一部分,主要是Flink基础理论的讲解,涉及到各种重要概念、原理和API的用法,并且会有大量的示例代码实现; 第二部分,以电商作为业务应用场景,以Flink作为分析框架,介绍一个电商用户行为分析项目的开发实战。 通过理论和实际的紧密结合,可以使学员对Flink有充分的认识和理解,在项目实战中对Flink和流式处理应用的场景、以及电商分析业务领域有更深刻的认识;并且通过对流处理原理的学习和与批处理架构的对比,可以对大数据处理架构有更全面的了解,为日后成长为架构师打下基础。 三、谁适合学 1、有一定的 Java、Scala 基础,希望了解新的大数据方向的编程人员 2、有 Java、Scala 开发经验,了解大数据相关知识,希望增加项目经验的开发人员 3、有较好的大数据基础,希望掌握Flink及流式处理框架的求职人员
©️2020 CSDN 皮肤主题: 鲸 设计师:meimeiellie 返回首页