毫不夸张地说,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 的指标类型(请注意与 Meter 区分),专门用于衡量一段时间内的指标数值。这包括了时间段内的平均值、最大值、最小值以及计数等。实际上,我们内部使用的许多指

本文详细介绍了 Flink 指标系统的重要性和工作原理,包括 Metric Reporters、Metric 类型、滴滴内部的实现及消费延迟指标的计算。Flink 指标对于实时任务监控和诊断至关重要,滴滴自研了 flink-metrics-kafka 实现,支持周期性推送指标数据。此外,文章还探讨了 Flink 的弹性设计,通过 SPI 加载 MetricReporterFactory 实现指标系统的灵活性。
最低0.47元/天 解锁文章
509

被折叠的 条评论
为什么被折叠?



