Prometheus Metrics 设计的最佳实践和应用实例，看这篇够了！

Prometheus 是一个开源的监控解决方案，部署简单易使用，难点在于如何设计符合特定需求的 Metrics 去全面高效地反映系统实时状态，以助力故障问题的发现与定位。本文即基于最佳实践的 Metrics 设计方法，结合具体的场景实例——TKE 的网络组件 IPAMD 的内部监控，以我的实践经验谈一谈如何设计和实现适合的、可以更好反映系统实时状态的监控指标（Metrics）。该篇内容适于 Prometheus 或相关监控系统的初学者(可无任何基础了解)，以及近期有 Prometheus 监控方案搭建和维护需求的系统开发管理者。经过这篇文章，能够加深对 Prometheus Metrics 的理解，并能针对实际的监控场景提出更好的指标（Metrics）设计。

1 引言

Prometheus 是一个开源的监控解决方案，它可以提供监控指标数据的采集、存储、查询以及监控告警等功能。做为云原生基金会(CNCF)的毕业项目，Prometheus 已经在云原生领域获得了大范围的应用，并逐渐成为了业界最流行的监控解决方案之一。

Prometheus 的部署和使用能够说是简单易上手，可是如何针对实际的问题和需求设计适宜的 Metrics 却并非那么直接可行，反而须要优先解决暴露出来的诸多不肯定问题，好比什么时候选用 Vector，如何设计适宜的 buckets，Summary 和 Histogram 指标类型的取舍等。然而，要想有效助力故障及问题的发现与定位，必需要有一个合理有效的 Metrics 去全面高效地反映系统实时状态。

本文将介绍基于最佳实践的 Metrics 设计方法，并结合具体的场景实例——TKE 的网络组件 IPAMD 的内部监控，以我的实践经验谈一谈如何设计和实现适合的、可以更好反映系统实时状态的监控指标(Metrics)。

本文以后的第 2 节将对 Prometheus 的 Metrics 作简单的介绍，对此已有了解的读者可跳过。以后第 3 节将介绍 Metrics 设计的最佳实践。第 4 节将结合具体的实例应用相关设计方法。第 5 节将介绍 Golang 上指标收集的实现方案。

2 Prometheus Metrics Type 简介

Prometheus Metrics 是整个监控系统的核心，全部的监控指标数据都由其记录。Prometheus 中，全部 Metrics 皆为时序数据，并以名字做区分，即每一个指标收集到的样本数据包含至少三个维度的信息：名字、时刻和数值。

而 Prometheus Metrics 有四种基本的 type：

• Counter: 只增不减的单变量
• Gauge：可增可减的单变量
• Histogram：多桶统计的多变量
• Summary：聚合统计的多变量

此外，Prometheus Metrics 中有一种将样本数据以标签（Label）为维度做切分的数据类型，称为向量(Vector)。四种基本类型也都有其 Vector 类型：

• CounterVec
• GaugeVec
• HistogramVec
• SummaryVec

Vector 至关于一组同名同类型的 Metrics，以 Label 作区分。Label 能够有多个，Prometheus 实际会为每一个 Label 组合建立一个 Metric。Vector 类型记录数据时需先打 Label 才能调用 Metrics 的方法记录数据。

如对于 HTTP 请求延迟这一指标，因为 HTTP 请求可在多个地域的服务器处理，且具备不一样的方法，因而，可定义名为 http_request_latency_seconds 的 SummaryVec，标签有region和method，以此表示不一样地域服务器的不一样请求方法的请求延迟。

如下将对每一个类型作详细的介绍。

2.1 Counter

• 定义：是单调递增的计数器，重启时重置为0，其他时候只能增长。

• 方法：

  type Counter interface {  Metric  Collector  // 自增1  Inc()  // 把给定值加入到计数器中. 若值小于 0 会 panic  Add(float64)}

• 常测量对象：

• • 请求的数量
  • 任务完成的数量
  • 函数调用次数
  • 错误发生次数
  • ...

2.2 Gauge

• 定义：表示一个可增可减的数字变量，初值为0

• 方法：

  type Gauge interface {  Metric  Collector  Set(float64)    // 直接设置成给定值  Inc()   // 自增1  Dec()   // 自减1  Add(float64)     // 增长给定值，可为负  Sub(float64)    // 减小给定值，可为负  // SetToCurrentTime 将 Gauge 设置成当前的 Unix 时间戳  SetToCurrentTime()}

• 常测量对象：

• • 温度
  • 内存用量
  • 并发请求数
  • ...

2.3 Histogram

• 定义：Histogram 会对观测数据取样，而后将观测数据放入有数值上界的桶中，并记录各桶中数据的个数，全部数据的个数和数据数值总和。

• 方法：

  type Histogram interface {  Metric  Collector  // Observe 将一个观测到的样本数据加入 Histogram 中，并更新相关信息  Observe(float64)}

• 常测量对象：

• • 请求时延
  • 回复长度
  • ...各类有样本数据

• 具体实现：Histogram 会根据观测的样本生成以下数据：

  inf 表无穷值，a1,a2,...是单调递增的数值序列。

• • [basename]_count: 数据的个数，类型为 counter
  • [basename]_sum: 数据的加和，类型为 counter
  • [basename]_bucket{le=a1}: 处于[-inf,a1]的数值个数
  • [basename]_bucket{le=a2}: 处于[-inf,a2]的数值个数
  • ...
  • [basename]_bucket{le=<+inf>}：处于[-inf,+inf]的数值个数，prometheus默认额外生成，无需用户定义
• Histogram 能够计算样本数据的百分位数，其计算原理为：经过找特定的百分位数值在哪一个桶中，而后再经过插值获得结果。好比目前有两个桶，分别存储了[-inf, 1]和[-inf, 2]的数据。而后如今有20%的数据在[-inf, 1]的桶，100%的数据在[-inf, 2]的桶。那么，50%分位数就应该在[1, 2]的区间中，且处于(50%-20%) / (100%-20%) = 30% / 80% = 37.5% 的位置处。Prometheus计算时假设区间中数据是均匀分布，所以直接经过线性插值能够获得 (2-1)*3/8+1 = 1.375.

2.4 Summary

• 定义：Summary 与 Histogram 相似，会对观测数据进行取样，获得数据的个数和总和。此外，还会取一个滑动窗口，计算窗口内样本数据的分位数。

• 方法：

  type Summary interface {  Metric  Collector  // Observe 将一个观测到的样本数据加入 Summary 中，并更新相关信息  Observe(float64)}

• 常测量对象：

• • 请求时延
  • 回复长度
  • ...各类有样本数据

• 具体实现：Summary 彻底是在client端聚合数据，每次调用 obeserve 会计算出以下数据：

• • [basename]_count: 数据的个数，类型为 counter
  • [basename]_sum: 数据的加和，类型为 counter
  • [basename]{quantile=0.5}: 滑动窗口内 50% 分位数值
  • [basename]{quantile=0.9}: 滑动窗口内 90% 分位数值
  • [basename]{quantile=0.99}: 滑动窗口内 99% 分位数值
  • ...

实际分位数值可根据需求制定，且是对每个 Label 组合作聚合。

2.5 Histogram 和 Summary 简单对比

能够看出，Histogram 和 Summary 类型测量的对象是比较接近的，但根据其实现方式和其自己的特色，在性能耗费、适用场景等方面具备必定差异，本文总结以下：

3 Metrics 设计的最佳实践

3.1 如何肯定须要测量的对象

在具体设计 Metrics 以前，首先须要明确须要测量的对象。须要测量的对象应该依据具体的问题背景、需求和需监控的系统自己来肯定。

思路1：从需求出发

Google 针对大量分布式监控的经验总结出四个监控的黄金指标，这四个指标对于通常性的监控测量对象都具备较好的参考意义。这四个指标分别为：

• 延迟：服务请求的时间。
• 通信量：监控当前系统的流量，用于衡量服务的容量需求。
• 错误：监控当前系统全部发生的错误请求，衡量当前系统错误发生的速率。
• 饱和度：衡量当前服务的饱和度。主要强调最能影响服务状态的受限制的资源。例如，若是系统主要受内存影响，那就主要关注系统的内存状态。

而笔者认为，以上四种指标，实际上是为了知足四个监控需求：

• 反映用户体验，衡量系统核心性能。如：在线系统的时延，做业计算系统的做业完成时间等。
• 反映系统的服务量。如：请求数，发出和接收的网络包大小等。
• 帮助发现和定位故障和问题。如：错误计数、调用失败率等。
• 反映系统的饱和度和负载。如：系统占用的内存、做业队列的长度等。

除了以上常规需求，还可根据具体的问题场景，为了排除和发现之前出现过或可能出现的问题，肯定相应的测量对象。好比，系统须要常常调用的一个库的接口可能耗时较长，或偶有失败，可制定 Metrics 以测量这个接口的时延和失败数。

思路2：从需监控的系统出发

另外一方面，为了知足相应的需求，不一样系统须要观测的测量对象也是不一样的。在 官方文档 的最佳实践中，将须要监控的应用分为了三类：

• 线上服务系统（Online-serving systems）：需对请求作即时的响应，请求发起者会等待响应。如 web 服务器。
• 线下计算系统（Offline processing）：请求发起者不会等待响应，请求的做业一般会耗时较长。如批处理计算框架 Spark 等。
• 批处理做业（Batch jobs）：这类应用一般为一次性的，不会一直运行，运行完成后便会结束运行。如数据分析的 MapReduce 做业。

对于每一类应用其一般状况下测量的对象是不太同样的。其总结以下：

• 线上服务系统：主要有请求、出错的数量，请求的时延等。
• 线下计算系统：最后开始处理做业的时间，目前正在处理做业的数量，发出了多少 items， 做业队列的长度等。
• 批处理做业：最后成功执行的时刻，每一个主要 stage 的执行时间，总的耗时，处理的记录数量等。

除了系统自己，有时还需监控子系统：

• 使用的库（Libraries）: 调用次数，成功数，出错数，调用的时延。
• 日志（Logging）：计数每一条写入的日志，从而可找到每条日志发生的频率和时间。
• Failures: 错误计数。
• 线程池：排队的请求数，正在使用的线程数，总线程数，耗时，正在处理的任务数等。
• 缓存：请求数，命中数，总时延等。
• ...

最后的测量对象的肯定应结合以上两点思路肯定。

3.2 如何选用 Vector

选用 Vec 的原则：

• 数据类型相似但资源类型、收集地点等不一样
• Vec 内数据单位统一

例子：

• 不一样资源对象的请求延迟
• 不一样地域服务器的请求延迟
• 不一样 http 请求错误的计数
• ...

此外，官方文档 中建议，对于一个资源对象的不一样操做，如 Read/Write、Send/Receive， 应采用不一样的 Metric 去记录，而不要放在一个 Metric 里。缘由是监控时通常不会对这二者作聚合，而是分别去观测。

不过对于 request 的测量，一般是以 Label 作区分不一样的 action。

3.3 如何肯定 Label

根据3.2，常见 Label 的选择有：

• resource
• region
• type
• ...

肯定 Label 的一个重要原则是：同一维度 Label 的数据是可平均和可加和的，也即单位要统一。如风扇的风速和电压就不能放在一个 Label 里。

此外，不建议下列作法：

my_metric{label=a} 1my_metric{label=b} 6my_metric{label=total} 7

即在 Label 中同时统计了分和总的数据，建议采用 PromQL 在服务器端聚合获得总和的结果。或者用另外的 Metric 去测量总的数据。

3.4 如何命名 Metrics 和 Label

好的命名可以见名知义，所以命名也是良好设计的一环。

Metric 的命名：

• 须要符合 pattern: [a-zA-Z:][a-zA-Z0-9:]*

• 应该包含一个单词做为前缀，代表这个 Metric 所属的域。如：

• • prometheus_notifications_total
  • process_cpu_seconds_total
  • ipamd_request_latency

• 应该包含一个单位的单位做为后缀，代表这个 Metric 的单位。如：

• • http_request_duration_seconds
  • node_memory_usage_bytes
  • http_requests_total (for a unit-less accumulating count)

• 逻辑上与被测量的变量含义相同。

• 尽可能使用基本单位，如 seconds，bytes。而不是 Milliseconds, megabytes。

Label 的命名：

• 依据选择的维度命名，如：

• • region: shenzhen/guangzhou/beijing
  • owner: user1/user2/user3
  • stage: extract/transform/load

3.5 如何设计适宜的 Buckets

根据前述 histogram 的统计原理可知，适宜的 buckets 能使 histogram 的百分位数计算更加准确。

理想状况下，桶会使得数据分布呈阶梯状，即各桶区间内数据个数大体相同。如图1所示，是本人在实际场景下配置的buckets 数据直方图，y 轴为 buckets 内的数据个数，x 轴是各 buckets，能够看出其近似成阶梯状。这种状况下，当前桶个数下对数据的分辨率最大，各百分位数计算的准确率较高。

图1 较为理想的桶数据分布

而根据笔者实践经验，为了达成以上目标，buckets 的设计可听从以下经验：

• 须要知道数据的大体分布，若事先不知道可先用默认桶 （{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}）或 2 倍数桶（{1,2,4,8...}）观察数据分布再调整 buckets。
• 数据分布较密处桶间隔制定的较窄一些，分布稀疏处可制定的较宽一些。
• 对于多数时延数据，通常具备长尾的特性，较适宜用指数形式的桶（ExponentialBuckets）。
• 初始桶上界通常覆盖10%左右的数据，若不关注头部数据也可让初始上界更大一些。
• 若为了更准确计算特定百分位数，如90%，可在90%的数据处加密分布桶，即减小桶的间隔。

4 实例：TKE-ENI-IPAMD Metrics 设计与规划

4.1 组件简介

该组件用于支持腾讯云 TKE 的策略路由网络方案。在这一网络方案中，每一个 pod 的 IP 都是 VPC 子网的一个IP，且绑定到了所在节点的弹性网卡上，经过策略路由连通网络，而且使得容器能够支持腾讯云的 VPC 的全部特性。

其中，在 2.0.0 版本之前，tke-eni-ipamd 组件是一个 IP 分配管理的 GRPC Server，其主要职责为:

• cni IP 真正分配/删除的 GRPC Server，分配/释放 IP 会调用腾讯云弹性网卡接口执行相应的 IP 绑定/解绑操做
• Node 控制器（用于给 Node 绑定/解绑弹性网卡）
• Stateulfset 控制器（用于给 Statefulset 预留 IP 资源）

其工做原理和流程如图 2 所示：

图2 tke-eni-ipamd(v2.0.0-) 工做原理和流程

4.2 IPAMD 的使用场景和咱们的要求

背景：

• ip 分配/释放对时延比较敏感，为了方便肯定 ip 分配/释放过程当中性能瓶颈是由咱们自身代码形成的仍是底层模块形成的（如 ipamd 调用的 vpc 接口等）。同时也方便对咱们的代码和推动底层模块的性能优化。
• ipamd 运行过程当中可能会出现故障等问题，为了及时发现故障，定位问题，也须要有内部监控。

需求：

• 须要可以统计 ip 分配和释放各个阶段的时延，以肯定性能瓶颈
• 须要知道当前的并发请求数，以肯定 IPAMD 负载
• vpc 接口 ip分配/释放，弹性网卡建立/绑定/解绑/释放耗时比较长，而且常常有失败状况。须要可以统计这些接口的时延和调用成功率，以定位性能瓶颈。
• node controller，statefulset controller 进行 sync 阶段会有一系列流程，但愿能清楚主要流程耗时，方便定位瓶颈
• 弹性网卡的建立/删除等过程当中容易产生脏数据，须要可以统计脏数据的个数，以发现脏数据问题。
• 须要有较强的实时性，可以清楚的看到最近（~分钟级别）系统的运行状态

咱们的场景：

• ipamd 是部署在每一个用户集群中的一个组件
• 每一个用户集群内有 prometheus server 作聚合，而后每一个 region 也有 server 去拉取数据

4.3 整体设计

所以，须要如下几类 Metric：

• ip alloc/free 各阶段时延
• 基本运行信息：请求并发数、内存用量、goroutine 数，线程数
• vpc 接口时延
• vpc 接口调用成功率
• controller sync 时延
• 脏数据计数

4.4 Histogram vs. Summary

时延可选择 Histogram 或 Summary 进行测量，如何选择？

基于 2.5 节的二者对比，有以下分析：

Summary:

• 优势：

• 1. 可以很是准确的计算百分位数
  2. 不须要提早知道数据的分布

• 缺点：

• 1. 灵活性不足，实时性须要经过 maxAge 来保证，写死了后灵活性就不太够（好比想知道更长维度的百分位数）
  2. 在 client 端已经作了聚合，即在各个用户集群的 ipamd 中已经聚合了，咱们若是须要观察所有 user 下的百分位数数据是不行的（只能看均值）
  3. 用户集群的 ipamd 的调用频率可能很低（如小集群或者稳定集群），这种状况下 client 端聚合计算百分位数值失去意义（数据太少不稳定），若是把 maxAge 增大则失去实时性

Histogram:

• 优势：

• 1. 兼具灵活性和实时性
  2. 能够灵活的聚合数据，观察各个尺度和维度下的数据

• 缺点：

• 1. 须要提早知道数据的大体分布，并以此设计出合适而准确的桶序列
  2. 难以经过 Label 串联多种 Metrics，由于各个 Metrics 的数据分布可能差别较大，若是都只用一种桶序列的话会致使百分位数计算差别较大

Summary 的缺点过于致命，难以回避。Histogram 的缺点能够经过增长工做量（即经过测试环境中的实验来肯定各 Metrics 的大体分布）和增长 Metrics（不用 Label 区分）来较好解决。

因此倾向于使用 Histogram。

4.5 Metrics 规划示例

详细的 Metrics 规划内容较多，这里选取了一些表明性的样例，列举以下：

注1：DefBuckets指默认桶 （{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}）。

注2：以上 buckets 持续微调中。

5 指标收集的 Golang 实现方案

5.1 整体实现思路

• 利用 prometheus 的 golang client 实现自定义的 exporter（包括自定义的 Metrics ），并嵌入到 ipamd 代码中，以收集数据
• 全部的 Metrics 做为 Metrics 包的外部变量可供其余包使用，调用测量方法
• 自定义 exporter 参考 prometheus client golang example
• 将收集到的数据经过 http server 暴露出来

5.2 Metrics 收集方案

方案1：非侵入式装饰器模式

样例: kubelet/kuberuntime/instrumented_services.go

type instrumentedRuntimeService struct {    service internalapi.RuntimeService}func recordOperation(operation string, start time.Time) {    metrics.RuntimeOperations.WithLabelValues(operation).Inc()    metrics.DeprecatedRuntimeOperations.WithLabelValues(operation).Inc()    metrics.RuntimeOperationsDuration.WithLabelValues(operation).Observe(metrics.SinceInSeconds(start))    metrics.DeprecatedRuntimeOperationsLatency.WithLabelValues(operation).Observe(metrics.SinceInMicroseconds(start))}func (in instrumentedRuntimeService) Status() (*runtimeapi.RuntimeStatus, error) {    const operation = "status"    defer recordOperation(operation, time.Now())    out, err := in.service.Status()    recordError(operation, err)    return out, err}

优势：

• 上层调用函数处几乎不用修改，只需修改调用的实例
• 抽象较好，非侵入式设计，代码耦合度低

缺点：

• 需单独封装每一个调用函数，复用度低
• 没法封装内部函数，只能适用于测量对外服务函数的数据

方案2：defer 函数收集

样例：

func test() (retErr error){    defer func(){        metrics.LatencySeconds.Observe(...)    }()    ...    func body    ...}

优势：

• 上层调用函数处彻底不用修改
• 适用于全部函数的测量

缺点：

• 有点滥用 defer
• 侵入式设计，具备必定的耦合度

5.3 目前 IPAMD 的指标收集实现方案

• 时延统计：经过 golang 的 time 模块计时，在函数中嵌入 time.Now 和并在其后 defer time.Since 来统计。
• 调用成功率统计：调用次数在接口函数里直接用 counter 进行统计，失败次数在defer里获取命名返回值统计，最后在 prometheus server 端聚合的时候经过 PromQL 利用这两个数据计算出调用成功率。
• 并发请求数的统计：在最外层的 AddPodIP 和 DelPodIP 中，在函数中和 defer func 中分别调用Inc和Dec。

6 总结

本文介绍了 Prometheus Metrics 及最佳实践的 Metrics 设计和收集实现方法，并在具体的监控场景—— TKE 的网络组件 IPAMD 的内部监控中应用了相关方法。

具体而言，本文基于最佳实践，回答了 Prometheus Metrics 设计过程当中的若干问题：

• 如何肯定须要测量的对象：依据需求(反映用户体验、服务量、饱和度和帮助发现问题等)和需监控的具体系统。
• 什么时候选用 Vec：数据类型相似但资源类型、收集地点等不一样，数据单位统一。
• 如何肯定 Label：可平均和可加和的，单位要统一；总和数据另外计。
• 如何命名 Metrics 和 Label：见名知义，应包含监控的系统名/模块名，指标名，单位等信息。
• 如何设计适宜的 Buckets：依据数据分布制定，密集部分桶区间较窄，整体桶分布尽可能接近阶梯状。
• 如何取舍 Histogram 和 Summary：Histogram 计算偏差大，但灵活性较强，适用客户端监控、或组件在系统中较多、或不太关心精确的百分位数值的场景；Summary 计算精确，但灵活性较差，适用服务端监控、或组件在系统中惟一或只有个位数、或须要知道较准确的百分位数值(如性能优化场景)的场景。

此外，Metrics 设计并非一蹴而就的，需依据具体的需求的变化进行反复迭代。好比需新增 Metrics 去发现定位可能出现的新问题和故障，再好比 Buckets 的设计也须要变化来适应测量数据分布发生的变化，从而得到更精确的百分位数测量值。

参考资料

1. Prometheus 官方文档 ：https://prometheus.io/docs/introduction/overview/Prometheus
2. Go client library：https://github.com/prometheus/client_golang