滴滴 Flink 指标系统的架构设计与实践

毫不夸张地说，Flink 指标是洞察 Flink 任务健康状况的关键工具，它们如同 Flink 任务的眼睛一般至关重要。简而言之，这些指标可以被理解为滴滴数据开发平台实时运维系统的数据图谱。在实时计算领域，Flink 指标扮演着举足轻重的角色，例如，实时任务的消费延迟和检查点失败的警报都是基于对 Flink 报告的指标进行监控而触发的；同时，许多实时任务智能诊断的关键决策点也是依 Flink 指标来制定的。

鉴于 Flink 指标系统的重要性，深入理解其工作原理显得尤为必要，这是灵活运用 Flink 指标系统的前提。作为一名平台工程师，我尝试对 Flink 的原理进行一次剖析，如果存在任何不准确之处，敬请各位指正。

Flink 指标系统的核心概念

接下来我们将探讨一些核心概念，它们是理解 Flink 指标系统不可或缺的基础。

Metric Reporters

Metric Reporter 是 Flink 用于导出指标数据的接口，通过 flink-conf.yaml 文件可以轻松配置所需的 MetricReporter。Flink 提供了多种 MetricReporter 的实现，包括 Prometheus、Datadog 等，以满足不同的监控需求。

值得注意的是，尽管 Flink 提供了众多 MetricReporter 的实现，但它如何根据需要动态加载这些实现呢？我们将在后文关于弹性设计的讨论中深入分析这一机制，现在先留个悬念。

MetricReporter 支持两种指标上报方式：Push 和 Pull。具体不赘述了，我们直接引用官方文档中的描述：

Metrics are exported either via pushes or pulls.

Push-based reporters usually implement the Scheduled interface and periodically send a summary of current metrics to an external system.

Pull-based reporters are queried from an external system instead.

滴滴内部的Metric Reporters

滴滴内部没有采用社区的MetricReporter，而是根据滴滴内部实际情况，自研了flink-metrics-kafka。简单来讲，采用push的方式，

滴滴并未使用社区提供的 MetricReporter，而是根据自身需求自主研发了 flink-metrics-kafka。简单来说，该系统采用推送 Push 方式，周期性将 Flink 计算的指标推送到 kafka topic 当中。下文中的实现原理，也是基于 flink-metrics-kafka 介绍的。

Metrics type

Flink 社区对指标进行了高度抽象，定义了四种主要的指标类型：Counter、Gauge、Histogram 和 Meter。

• Counter：这是一种简单的计数器，用于记录事件的数量。

• Gauge：这种指标非常灵活，可以返回任意类型的统计数据。Gauge 可以看作是 Counter 的泛化版本。

• Histogram：正如其名，Histogram 表示的是一系列长整型数值的分布情况，常用于绘制直方图。

• Meter：这种指标用于度量平均吞吐量，适用于评估系统的处理能力。

滴滴内部的 Metered

在滴滴内部，我们独创了一种名为 Metered 的指标类型（请注意与 Mete