四种指标类型
Prometheus 客户端库把指标分为四类：Counter 只增不减，进程重启后归零；Gauge 可增可减；Histogram 在客户端按桶累计，服务端可聚合出分位；Summary 在客户端直接算好分位。类型既决定能用哪些函数，也决定数据能否跨实例聚合，选错会让查询结果失去意义。
基本信息
| Counter | 单调递增的累计量，如请求总数、发送字节数 |
|---|---|
| Gauge | 可增可减的瞬时量，如队列长度、可用内存 |
| Histogram | 按 le 分桶累计，附带 _sum 与 _count |
| Summary | 客户端算分位，附带 _sum 与 _count |
| 命名惯例 | 计数以 _total 结尾，耗时用 _seconds，大小用 _bytes |
典型使用场景
- 请求计数：用 Counter 记录请求总数，查询时经 rate 转成速率
- 资源水位：用 Gauge 记录内存可用量、队列积压，直接看数值或变化率
- 耗时分布：用 Histogram 记录请求耗时，在查询端按需算 P95、P99
- 客户端精确分位：客户端能承担计算开销且不需要跨实例聚合时用 Summary
- 容量与配额：用 Gauge 记录配额余量与连接池占用，配阈值告警
四种类型
| 类型 | 变化方向 | 典型用途 | 示例 |
|---|---|---|---|
| Counter | 只增（重启归零） | 累计请求数、处理字节数 | http_requests_total |
| Gauge | 可增可减 | 队列长度、可用内存、温度 | node_memory_MemAvailable_bytes |
| Histogram | 分桶累计加总和与计数 | 请求耗时、响应体大小 | http_request_duration_seconds_bucket |
| Summary | 客户端分位加总和与计数 | 客户端直接算分位的耗时 | rpc_duration_seconds{quantile="0.99"} |
类型与函数对应
| 类型 | 常用函数 | 慎用或无效 |
|---|---|---|
| Counter | rate、irate、increase、resets | 直接求平均无意义 |
| Gauge | delta、deriv、avg_over_time、predict_linear | rate 会得到错误结论 |
| Histogram | histogram_quantile、bucket 计数相减 | 对 _sum 做分位无意义 |
| Summary | 直接读取 quantile 标签值 | 分位不能跨实例聚合 |
exposition 格式示例
exposition 格式示例
# HELP http_requests_total Total HTTP requests.
# TYPE http_requests_total counter
http_requests_total{code="200"} 1027
# TYPE node_load1 gauge
node_load1 0.85
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 24054
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423.0
http_request_duration_seconds_count 144320先确认类型再选函数：对 Gauge 使用 rate、对 Counter 手工做差值，都会得到无意义或错误的结果。
Histogram 会自动生成 _bucket、_sum、_count 三条序列，做聚合或告警时要明确用哪一条，混用会让口径不一致。
选型建议
请求次数与字节量用 Counter；水位、状态、余量用 Gauge；只要关心耗时或大小的分位，就优先用 Histogram，因为它能在查询端跨实例聚合；只有客户端必须自己算分位、且明确不需要合并多实例结果时才用 Summary。多数服务实际需要打交道的只有 Counter 与 Histogram 两种。
如何确认线上指标类型
两种确认方式：查看目标端点的原始输出，读 HELP 与 TYPE 注释行；或在表达式浏览器里查看指标的元信息。类型没弄清就套用函数，是新手最常见的一类误用，症状通常是曲线形状与预期完全不符。
从需求反推类型
| 需求 | 推荐类型 | 原因 |
|---|---|---|
| 统计一段时间发生了多少次 | Counter | 天然单调，rate 与 increase 直接可用 |
| 记录当前还剩多少 | Gauge | 需要双向变化，直接取值即可 |
| 算 P95、P99 且要按实例聚合 | Histogram | 桶可跨实例求和后再算分位 |
| 客户端自算分位且不聚合 | Summary | 节省服务端计算，但分位不可合并 |
类型误用的典型症状
- 曲线锯齿状周期性归零：对 Counter 直接取值，没有经过 rate
- 数值明明在涨、图表却是平的：对 Gauge 使用 rate 后被平滑成常数
- 分位曲线出现不可能的台阶：Histogram 桶太少，样本集中在少数桶
- 多实例聚合后数值反常变小：把 Summary 的分位直接做了平均
- 重启后出现负值尖峰：用手工差值代替 rate 计算 Counter 速率
同一个含义只保留一种类型与一个名字：把同一份耗时同时暴露成 Histogram 与 Summary，会让看板与告警的取数长期分叉。
类型一旦发布就很难更改：改类型意味着改指标名，看板与告警都要同步调整。埋点评审时把类型与命名一起定下来，比事后迁移省事得多。