货拉拉实时研制渠道目标监控实践

布景

目标是体系可观测性的重要一环，关于体系的稳定性保证和性能优化，有着重要的效果。 flink 供给了原生的目标体系，可是flink的目标体系要结合可高度定制化的可视化看板和可高度定制化的告警功用，才干有用发挥其用处。飞流 flink 实时渠道原有的目标体系是依据开源的prometheus 和 grafana，特别是告警功用和运维问题，限制目标体系的发挥。本文介绍了一种依据公司告警体系 lala-monitor，能完成目标快速接入，目标灵敏操控，目标质量确保，目标可视化，装备灵敏化，能拓宽，能阻隔的计划。

经过该文，你将能收获到以下几个方面内容：

  1. Flink 的目标体系，以及怎么自界说目标和自界说目标 report
  2. 目标的通用处理方法
  3. 一种目标接入公司级监控的计划
  4. 依据目标的功用拓宽

1 链路演进

原有链路

货拉拉实时研发平台指标监控实践

原有链路运用 flink 原生供给的 prometheus report，推送搜集目标到一台中心 gateway 节点，prometheus 装备对 gateway 目标拉取，grafana 装备对 prometheus 数据进行可视化。原有链路存在以下问题：

  1. 经常遇到的问题是 gateway 节点内存满，经常收到机器告警，需求专门的去运维
  2. 因为内存满，新的目标发送不进来，整个链路阻塞 内存满的原因
  3. 上签到 gateway 的目标没有经过任何处理，同使命不同运转实例的目标会重复存储，需求专门且精确的整理机制
  4. 目标没有经过任何的处理，一些无用的 label 占用内存

新链路

货拉拉实时研发平台指标监控实践

针对原有链路的问题，咱们接入公司的监控告警渠道，来处理目标的存储展现以及告警装备问题。公司监控渠道的最小粒度是项目等级，只搜集项目机器上的目标；而飞流是一个使命办理渠道，使命运转在容器里，新链接需求打通使命目标到飞流机器的流程，即metrics report模块。新链接目标上签到kafka，项目机器上布置消费kafka的进程，露出数据给lala-monitor进行搜集。新链路具有以下长处：

  1. 高效处理了目标的存储展现以及告警装备
  2. kafka 的数据可用于其他场景运用，比方降维度预处理来削减 lala-monitor 的搜集量，假如用户有需求也能够消费处理
  3. kafka 的数据，不会呈现 prom 同维度不一同刻掩盖的场景，这样能够保存不一同刻的原始数据，可用于其他场景运用，比方 CEP 处理

2 链路总体设计

货拉拉实时研发平台指标监控实践

2.1 metrics-collect 模块介绍

模块定位：目标搜集，目标搜集的来源现在分成 4 部分:

  1. flink 使命供给的原生目标
  2. flink sql 使命，飞流渠道的埋点目标
  3. flink jar 使命，用户的埋点目标
  4. 飞流体系自己搜集的其他目标，主要是一些 flink 中不供给，或许不能直接运用的目标

2.2 Kafak 模块介绍

存储目标 topic，现在有 3 个：

  1. 自搜集目标 topic
  2. flink 目标 topic
  3. 预处理目标 topic

2.3 metrics-report 模块介绍

模块定位：消费 kafka 数据，进行预处理和操控，露出数据给 lala-monitor 搜集，露出 2 类目标：

  1. 使命里的事务目标
  2. metrics-report 搜集进程的过程目标

2.4 Metrics-alarm / Metrics-Display 模块介绍

模块定位：供给看版，供给告警

  1. 从用户和办理员视角，供给多种看板
  2. 供给使命维度，搜集链路维度，体系维度告警

3 metrics-collect 完成解析

Metrics-collect 经过自界说的 kafka-report，对目标进行办理和一定的预处理，上签到 kafka topic。

3.1 Kafka-report

Flink 原生供给的8种report中，没有kafka report，咱们自界说了kafka report，Kafka report里咱们做了以下事项：

1. kafka topic record 标准

目标以 json 的形式上报。目标添加 2 个字段标准，1 torrent_task_id, 2 report_timestamp。torrent_task_id 用于定位使命和运转实例的关系，用 torrent_task_id 不必 torrent_task_name，是因为 taskid 信息更少，传输信息更少，至于其他需求的一些信息，在 metrics-report 环节进行补全，这儿补全的数据，能依据实践值进行改变，完成了使命除 taskid 之前的其他属性能够修改，而不必重启使命上报新的目标来适配。report_timestamp 用来界说事情时刻，用来盯梢端到端推迟，也能够用来处理 flink 时刻语意。关于 report_timestamp，咱们关于同一个 TM 的同一搜集批次目标，进行相同的 timestamp 赋值，这个契合目标搜集的意义，不会形成时刻潇洒，影响依据时刻的预聚合逻辑。

2. 目标记载拆分

原始的目标会把归于同一个 tm 的数据进行聚合，一个 tm 上只有一条数据，这样的数据假如直接发送 kafka，会呈现单条记载偏大的状况，大记载对 kafka 不友好。一同 metircs-report 模块处理，或许其他预处理，都需求把各个维度进行拆开，才干按照不同的维度进行组合计算，在上报端就拆开，能够削减重复的解析流程。记载拆分供给了 task+metrics 更细粒度的 topic-key 制定，否则只能指定到 task 等级。更细的 key 指定，能够防止复杂使命都集合发往某个分区，导致分区分配存储不均以及后续的处理不均问题。

3. kafka topic record key 指定

不管是哪类目标，在发送 kakfa 的时分都要指定 key 进行发送。一致搜集用 task+metricname 的组合进行指定。这个是 kafka+lala-monitor 搜集存储原理决定。指定 key 能防止同一 label 维度的目标因为随机散布导致在不同的 topic，metrics-report 实例消费到不同 key 的数据，都进行露出，导致目标搜集掩盖，搜集重复问题。一同也能够防止数据不会在 topic 不同分区之间乱序，导致目标意义在不一同刻的乱序。

4. 目标预处理

关于 flink 目标里原生的 taskname 属性，因为这个意义和用户 sql 写法对应，有的写法，比方有许多个 sql 字段，这个姓名就会很长，导致单条记载就会很大。针对 taskname，咱们做了预处理，关于咱们现在不关心的非 source 和 sink 的中心算子目标，咱们用原生的 taskid 代替，taskid 是长度固定，可是被 hash 的字段，能够起到区分维度的效果。关于 source 和 sink 算子，因为咱们要做计算 source 和 sink 的目标，换了一种与处理方法，解分出表名进行替换，保存了语意的一同也起到了缩短内容的效果。

5. 添加自界说的维度

Flink 原生目标里只供给一些 host，taskname 等这些属性，咱们经过 scope 和 variables，添加了诸如 cp 编号，库表等维度。

6. kafka client

slot 同享下，一个 tm 实例，一般会有 2 个 kafka client，咱们优化成一个 tm 只会有一个 kafka client，削减 kafka server 的链接数。发送支撑 lz4 紧缩，削减发送和存储的大小。

3.2 目标管控

目标管控能防止自界说目标和原生目标的重复，对目标意义的影响。界说一致的目标命名标准，命名标准中能直接区分出是哪类目标。操控目标发送路由不同的topic和集群，完成阻隔和拓宽。对某个使命是否上报目标，某个目标是否上报进行操控，运转上报操控必要性包括以下几点：

  1. 削减送往 kakfa 的数据量；因为 flink 供给的目标许多，不是一切目标都是中心目标，没必要的数据不发送 kakfa。原生目标比方分为 Operate/ Task/机器/ 使命几类，从前到后，目标量级增长，主要敞开部分 task 等级和机器/使命等级的目标
  2. 降级，假如发现全体链路有问题，能够经过操控，优先确保中心链路的目标。
  3. 管控，一些没有经过管控的目标，直接发送，假如同名是会对其他目标照成影响。

4 metrics-report 完成解析

模块定位：消费 kafka 数据，进行转化和操控，露出数据给 lala-monitor 搜集。

4.1 预处理

metrics-collect搜集的原生的目标，咱们没有做太多的维度和维度内容的丢掉处理，是为了后续处理时，能够供给丰厚的信息，这些维度和内容假如直接露出给lala-monitor搜集的话，会照成label和label下维度的爆破，对搜集和存储都有影响。预处理是为操控label和label下的维度，现在有2种方法

1. metrics-report 预处理

metrics-report 依据事务意义和展现告警需求进行预处理，处理分成 2 个方面，一方面是丢掉一些维度，另外一个方面是对 label 属性进行处理。

label 丢掉的场景比方 flink_task_id 和 flink_task_name 是一个意义的 2 个表明方法，咱们选择有事务意义的 flink_task_name，丢掉 flink_task_id。比方 tm_id / subtask_index / host，咱们保存了 subtask_index 这个最细的粒度，确保目标不会掩盖；与之类似的 host ，咱们有进行保存，为了的后续依据机器维度的进一步剖析，比方热点问题等。

label 属性处理的场景依据 label 的意义，对 flink_task_name 进行处理，主要是削减内容，一同又保存意义，咱们的处理是只保存算子意义的 source 和 sink 算子（咱们在界说算子的时分有对算子进行命名）。不同 sink 的命名规则保持一致。关于不同使命中，相同是 source 同一个表，可是因为 sql 逻辑不一样，导致的算子原始 taskName 不一样，经过一致的处理之后，能够进行表维度的数据计算。一同能够把不同 sql 下本来归于同一 source 计算可是算子内容不同的高基维变 label 成低基维 label。

2. flink sql 预处理

因为 TM-task 等级的目标量会许多，可是咱们实践运用时，最终结果是依据使命的进行展现和告警，经过 flink-sql 使命消费 kafka topic，进行同维度处理聚合，把数据放到一个新的 topic，而不是放到原先的 topic，防止放进去的 topic 重复消费问题。kafka-report 中指定的同一时刻，便是为了处理这儿的聚合意义。

4.2 目标操控

metrics-collect阶段现已做了操控目标是否上报，metrics-report也做了相同的操控逻辑，原因有以下几点：

  1. metrics-report 的操控作为一种兜底。
  2. metrics-collect 现在没有完成实时操控，想要操控某些目标不上报，需求重启收效。
  3. 假如 metrics-collect 不是唯一的输入源，metrics-report 也能够进行操控。

操控场景

  1. 在功用除上线阶段，或许存在一些未考虑到的场景，操控是为了能够削减对 flink 使命/kafka/lala-monitor 的影响。
  2. 后续使命太多，目标太多的阶段，咱们的进程需求扩容，一同咱们的搜集或许会被服务端限速，咱们需求依据需求，进行目标是否上报的操控。

目标治理

  1. metrics-rport 搜集丢掉数。意义是消费到了数据，可是发现没注册目标或许目标是不允许上报的状态，这些消费到的目标，会被丢掉；虽然快速丢掉能削减 prom 目标的搜集量，可是 kafka 环节，还是存了这些无用目标。丢掉份额过多，就阐明 metrics-collect 阶段搜集了一些不需求的数据，这些数据或许是用户自己添加没在飞流体系注册办理的目标等，咱们需求进行处理，削减 kafka 的无用 qps，以支撑跟多有用的目标。
  2. flink/torrent 目标-prom 目标数据量计算，用于剖析某类目标是否过大，敞开是否合理，依据状况进行处理，削减对全体体系的影响。
  3. 使命-prom 目标数据量计算，用于剖析某个使命目标是否过大，是否合理，依据状况进行处理，削减对全体体系的影响。

4.3 目标数据质量等级确保

目标重复或许丢掉，都会影响目标数据的计算精确性。

4.3.1 目标呈现丢掉的场景

这儿主要说 metrics-report 侧的丢掉问题，呈现丢掉的场景就比较多，问题的中心是目标推送搜集端口，然后等服务端搜集的流程没有 ack 机制。

正常场景： 关于不能丢掉的数据，咱们是先 WAL，露出数据之后，在 commit offset。反常场景：这个时分露出的数据，有或许在搜集距离内，因为进程挂了，数据还没搜集到服务端，可是数据现已 commit，这个时分康复，咱们从 wal 康复，而且只康复归于本顾客的分区数据，防止其他分区重复露出，搜集重复。

WAL 的整理机制： 因为搜集是由另外一个进程经过 report 进程供给的端口露出的进行搜集，没有任何的回调机制和锁机制，所以只能找能确认数据现已被搜集的标志。

搜集 lag 标记： 咱们是在机器搜集数据中添加一个目标，该目标的意义是 report 赋值时体系的当前时刻，这条目标会和其他待搜集目标一同作为一批数据被搜集上去，假如这个目标的 value 和在服务端和当前时刻差值超多 N 分钟，就阐明搜集推迟了 N 分钟；运用这个推迟的时刻作为整理标记，进行 WAL 的整理，和一些不更新数据的 TTL 的整理。

4.3.2 目标呈现重复的场景

目标重复场景

  1. topic reblance，形成这个 reblance 的场景或许有进程中止，添加进程，进程 crash，机器 crash 等。topic reblance 会导致不持续归于本顾客的数据还持续露出在本机上，这些露出的数据和新分配在其他机器上顾客的数据，会目标重复，影响目标的精确性。
  2. 飞流使命不同的运转实例，会形成不同的 flink 使命，同一个飞流使命 2 次运转实例的目标是有或许不同的，比方散布的 yarn 机器不同，这些不同会导致前后 2 次实例露出出来的数据因为 yarn host 不同而重复，也会影响目标的精确性。
  3. 自动中止进程，露出的数据现已搜集，可是 WAL 的数据没及时整理，从 WAL 康复，这些数据会被在露出一遍。

处理手法：自动整理+自动 TTL

  1. 关于重复场景 1 – 自动整理：运用 kakfa 分区切换时分的钩子，获取上次消费的分区和本次消费的分区，自动剔出之前消费可是现在不归于顾客的分区的数据。
  2. 关于重复场景 2 – 自动 TTL：关于不同运转实例，使命上一次运转实例中止之后，就不会出产数据，这些数据在多久没更新之后，就能够被整理掉，现在运用的定时 TTL，后续能够优化成事情 TTL。TTL 还有其他用处：长周期搜集上报的目标，比方 10 分钟搜集一次这些目标，在这个 10 分钟期间是没有更新的，搜集是重复数据的搜集，是无效搜集，TTL 能够整理掉这种无效搜集，削减搜集数据量，可是 TTL 在服务端会有数据掉坑现象，咱们装备告警有进行优化，一同后续服务端也支撑掉坑数据的连线展现，而不是掉坑展现。
  3. 关于重复场景 3 – 后续看服务端是否能供给搜集目标的查询接口，查询 lag 目标，做到搜集，露出，WAL 整理的精准操控。

4.3.3 数据等级区分

为了应对不同的事务场景和实践运转场景，咱们把目标分成 4 个等级

  1. 不做任何确保
  2. 不能丢掉
  3. 不能重复
  4. 不能丢掉，不能重复

不同等级适用于不同场景的目标数据，运用不同的的机制来保证

  1. 不做任何确保等级：上报频率很快的目标，比方 flink 使命中的目标，默认 10 秒一次，即便这次丢掉了，下次还会快速弥补回来。
  2. 不能丢掉等级：长报周期数据，比方咱们搜集的 lag 数据，假如丢掉一次，需求在等一次搜集周期，一个搜集周期现在是 10 分钟，那丢掉一次，告警就推迟到 20 分钟。
  3. 不能重复等级 ：比方计算类型的目标，假如重复，计算目标意义就会有其他意义。
  4. 不能丢掉，不能重复等级：比方对账目标，假如其中一个目标丢掉或许重复，多个环节的数据对不齐全；现在的目标体系还不能完全支撑，因为目标在 flink 上报层面存在还没搜集使命就挂的场景，咱们运用 event 体系来支撑，今后会有介绍。

5 Metrics-alarm / Metrics-Display 完成解析

5.1 看板

货拉拉实时研发平台指标监控实践

针对不同的用户，供给多看板；关于普通用户：供给使命维度，使命分组维度，咱们定制的看板的原则是简化。

  1. 每个仪表盘每个使命只用一条曲线进行展现，这儿需求对一些原始的目标进行聚合，比方不展现到flink使命并发度细粒度的目标；
  2. 比率化；比方tm内存运用，原始目标是2个目标，used内存和max内存，可是这个内存关于设置不同内存大小的使命，max也是改变的，所以咱们进行一个内存运用率的转化；比方gc改变，原始目标是累计值，关于运转好久的使命，累计值便是很大，所以咱们进行一个改变率的转化；比方source动摇，原始的目标意义一般是qps，可是qps的改变关于不同使命，不同运转时刻段，不同运转环境下，都是因它而异的，所以咱们转化成动摇率，这样用户只需求装备一个浮动比率即可。
  3. 时刻化，关于一些原始目标，意义是数值，可是数值关于不同使命，不同运转时刻段，不同运转环境下，都是因它而异的；所以咱们把这些意义欠好确认的转化成用户好了解的时刻，用户只需求装备能够忍受的一个时刻，比方kakfa lag 需求康复的时刻。
  4. 即便咱们对目标进行了比率化，可是没有水位线+前史曲线，用户不知道什么状况需求处理，一个咱们有对应的告警，而是意义清晰的水位线和面板描述，削减了用户运用本钱。

关于办理员：供给体系维度，metrics-report搜集维度，咱们定制看板的原则是专业化和宏观化

货拉拉实时研发平台指标监控实践

货拉拉实时研发平台指标监控实践

货拉拉实时研发平台指标监控实践

5.2 告警品种

告警也是针对不同用户进行设计，现在分成 3 类，告警使命，告警搜集，告警体系

使命告警 metrics-report 告警 体系告警
飞流使命-使命重试次数告警 飞流搜集-topic 消费 QPS 慢告警 飞流体系-接连 lag 使命总数告警
飞流使命-失利告警 飞流搜集-待 monitor 搜集数量小告警 飞流体系-接连 cp 失利使命总数告警
飞流使命-Full GC 次数动摇反常 告警 飞流搜集-lala-monitor 搜集推迟高告警 飞流体系-失利总数高告警
飞流使命-checkpoint 无法触发 告警 飞流搜集-kafka lag 告警
飞流使命-使命重试次数改变率告警 飞流搜集-端到端搜集推迟告警
飞流使命-Doris 重试推迟告警 飞流搜集-搜集丢掉率高告警
飞流使命-failover 次数改变告警 飞流搜集-内存运用率高告警
飞流使命-反压告警 飞流搜集-心跳告警
飞流使命-接连 cp 失利告警 飞流搜集-搜集进程 GC 告警
飞流使命-topic 消费康复时刻告警
飞流使命-cp 大小骤变告警
飞流使命-水印时刻告警
飞流使命-Source qps 动摇率告警
飞流使命-consumer lag 动摇率告警
飞流使命-消费康复时刻动摇率告警
飞流使命-TM CPU 运用率低告警

5.2.1 告警原理

飞流运用 lala-monitor 和其他事务接入 lala-monitor 的一个区别是，飞流是一个使命办理体系，咱们的告警主要是给使命的办理员发送，一同飞流办理员也作为兜底接受告警。这在没有运用到服务端供给的api之前，咱们运用的新监控服务的动态订阅组功用。

动态订阅组：是能够把数据发送给一个指定的变量化的订阅组，假如订阅组不存在，对应的Appid订阅组会作为兜底，这个比较契合咱们的需求。假如只以单个使命担任人作为告警发送目标，会存在告警接受处理单点问题，一同使命担任人会有离任或许项目变化的场景，咱们现在以使命tag作为告警组的最小粒度，后续会添加项目信息进来一同维护。

tag是同类使命/同项目下的使命的交集，需求把tag 对应使命的担任人并集添加到订阅组。咱们装备了通用的告警装备，发送到torrenttag/torrent/system/x这个订阅组，只需依据使命装备了告警组，比方tag1/torrent/system/p2，就能接收到tag下使命的告警。假如觉得咱们装备的阈值的告警等级不合理，能够禁用{torrent_tag} / torrent / system / x 这个订阅组，只需依据使命装备了告警组，比方 tag1/torrent/system/p2，就能接收到tag 下使命的告警。假如觉得咱们装备的阈值的告警等级不合理，能够禁用{torrent_tag}/torrent/system/x 告警组，然后自己装备订阅组，比方${torrent_id}/torrent/custom/x +自己仿制咱们供给告警模版，或许自己装备，进行告警。依据告警组进行装备，仅仅咱们供给的通用处理计划，用户完全能够自行装备。

5.2.2 误告警/告警精确性/告警推迟等问题

  • 告警众多：1.比方一些告警在高峰期简单呈现告警，咱们设置退避告警距离；2.设置合理的阈值；3.同使命告警合并
  • 误告警：关于数据掉坑/数据高低峰/数据突发带来的误告警，运用平均值；
  • 告警推迟：监控端到端推迟在一定范围之内

6 布置 完成解析

  • metrics-report 归于无中心架构，能够横向拓宽
  • Kafka 分区能够添加分区，metrics-report 自动发现新分区，并从新分区最早数据消费
  • 能够添加 topic，用于阻隔和拓宽

7 建设成果

经过目标告警体系的建立，体系的处理了目标的存储展现以及告警装备问题。告警时效性从本来分钟等级 -> 10秒等级，且可装备；屡次发现了使命和体系的反常状况；辅佐进行使命资源本钱治理；依据使命告警，长途进行运维使命；完成告警数，告警康复时刻等计算。

8 规划

现在的目标监控告警体系，仅仅建立了一个框架和进行一些场景优化，在告警实时性和告警的有用率上还有提升的空间。对目标的一些深度使用，现在还缺失，比方结合使命日志和其他服务的告警，进行根因剖析，依据目标的自动运维和资源调优等，这些都是后续需求补齐的方向。

作者：王世涛，货拉拉大数据技术与产品部-数据渠道组-实时研制渠道担任人，担任flink实时研制渠道产品演进及迭代。