在使用 Prometheus 时， 指标和标签的命名有什么建议，或者如何命名才是最佳实践，这篇文章可以作为风格指南和最佳实践的指导。

指标名称

• 必须符合有效字符的数据模型，

• 应用程序的监控指标应该有一个与指标所属域相关的前缀，最好是一个单词，这个前缀有时被客户端库称为命名空间。对于特定于应用程序的指标，前缀通常是应用程序名称本身。有时候指标更通用的时候，这个前缀可以是其他。

• prometheus_notifications_total(针对 Prometheus 服务器)

• process_cpu_seconds_total(这个相较上边 Prometheus 的例子来说，更具有通用性，所有使用了 process 的前缀)

• http_request_duration_seconds(针对所有 HTTP 请求，所以使用了 http 作为前缀)

• 应该有一个后缀以复数形式来描述单位。注意，累加计数以 total 作为后缀，如果可以的话，还可以加上单位。

• 必须有一个唯一的单位，例如，不要混合秒与毫秒，或秒与字节。而且应该使用国际基本单位，例如秒、字节、米，而不是毫秒、兆字节、公里。

• http_request_duration_seconds

• node_memory_usage_bytes

• http_requests_total （用于无单元累积计数)

• process_cpu_seconds_total (用于带有 unit 的累积计数)

• foobar_build_info (用于提供关于运行二进制文件的元数据的伪度量)

• 应该表示在所有标签维度上所测量的相同逻辑事物。

• 请求持续时间

• 数据传输字节数

• 瞬时资源使用百分比

根据过往的经验，给定度量的所有维度的 sum() 或 avg() 都应该是有意义的，尽管不一定有用。如果没有意义，需要将数据分解为多个指标。例如，在一个度量中具有各种队列的容量是好的，而将队列的容量与队列中的当前元素数量混合则不是。

标签

用标签来区分被测量物体的特征:

• api_http_requests_total 区分请求类型: operation="create|update|delete"
  

• api_request_duration_seconds 区分请求阶段: stage="extract|transform|load"
  

不要将标签名称放在指标名称中，因为这将引入冗余，并且如果各自的标签被聚合掉，将导致混淆。

特别提醒：键值标签对的每个独特组合都代表了一个新的时间序列，可以显着增加存储的数据量。 不要使用标签来存储具有高基数（许多不同标签值）的维度，例如用户 ID，电子邮件地址或其他无限制的值集合。