25 Prometheus 最佳实践原则

在 Prometheus 官网中对如何更好地使用该监控系统做了充分的说明，包括指标和标签命名、控制台和仪表盘、测量仪表、直方图和摘要、告警、用好 PushGateway 等。

1.指标与标签的命名指标命名必须符合数据模型的有效字符。应该有一个与度量所属的域相关的应用程序前缀（客户端库函数有时将前缀称为命名空间），特定应用程序前缀通常是应用程序名称本身。在所有标签维度上测量的逻辑内容要相同，包括请求持续时间、数据传输字节数、即时资源使用率（百分比）等。标签是用来区分正在测量的事物的特征，不要将标签名称放在度量名称中，这会导致冗余，将显著增加存储的数据量。Prometheus 中没有任何单位是硬编码的，但为了更好地兼容，应该使用国际基本单位。

2.控制台和仪表盘不要试图在控制台展示每一种数据，而是要考虑最可能的故障模式以及如何区分。与其在单个大仪表盘上显示每个服务的信息，不如为每个服务构建单独的仪表盘，包括每个服务的延迟和错误。然后可以从顶部开始，一直钻取到有问题的服务。我们发现：控制台上的图形不超过 5 个；每个图表上的图（线）不超过 5 个；使用控制台模板展示时，在右侧表格中数据项不要超过 30 个。

3.测量仪表在使用同一个文件中创建的实例化度量类，在跟踪错误时，容易做到警报从控制台到代码进行切换。出于不同的监控目的，服务通常可以分为在线服务、离线处理和批处理作业三种类型。此外系统还有库接口、日志信息、失效、线程池、高速缓存、采集器等部分，这些也需要被监控。

4.直方图和摘要是更复杂的度量类型，要准确地使用这些度量类型难度很大。直方图和摘要两个样本的观测结果，通常是请求持续时间或响应大小，跟踪观测的数量和观测值的总和，然后计算观测的平均值。请注意，观测的数量本质上是一个计数器（它只会增加）。观测值之和也是计数器，如请求持续时间或响应大小从不为负数。原则上，可以使用摘要和直方图来观测负值（例如摄氏温度）。在这种情况下，观察值的总和会下降，这时不能再对其应用 rate 函数。

有两条经验法则：

• 如果需要聚合，请选择直方图。

• 如果知道将要观察的值的范围和分布，请选择一个直方图；如果需要精确的分位数，不论值的范围和分布，请选择摘要。

5.告警确保警报的简单，准确发出告警，拥有良好的控制台，便于查明原因。发出警报时确保 Prometheus 服务、警报管理器、推送网关和其他监控基础设施是正常运行的。可以对根因发出警报，这有助于减少噪声。例如从 Pushgateway 到 Prometheus 再到 Alertmanager 最后到 email 的黑盒测试，比单个警报都要好。将 Prometheus 的白盒监控与外部黑盒监控相结合，可以捕捉到难以觉察的问题，并在内部系统完全失效的情况下作为备用手段。

6.使用 PushGatewayPushgateway 是一种中介服务，它允许你从无法抓取的作业中推送度量。建议在某些有情况下使用 Pushgateway，当使用 Pushgateway 而不是 Prometheus 通常的 Pull 模型时，有几个陷阱需要注意：

• 当通过一个 Pushgateway 监视多个实例时，Pushgateway 既可以成为单一故障点，又可能成为潜在的瓶颈。

• Prometheus 实时采集 Up 状态度量来做健康监控会失效。

• Pushgateway 将信息永远暴露给 Prometheus，除非手动删除信息。