参考：指标类型、PromQL 函数与易错点
基于 Prometheus 3.x · 核于 2026-08
速查
- 四大指标类型：Counter（单调递增，
rate）/ Gauge（瞬时值，直接读）/ Histogram（分桶，服务端聚合分位数）/ Summary（客户端预算分位数，不可聚合）。 - PromQL 三查询：即时向量（无
[]）/ 范围向量（[5m]，需套函数）/ 标量。 - 三大速率函数：
rate（平均，告警用）/irate（末两点，大屏用）/increase（窗口总增量）。 - 聚合顺序：先
rate后sum；histogram_quantile先sum by (le)后quantile。 - 告警流水线：Alerting Rule（
for: 5m）→ Alertmanager（group_by 分组 / inhibit 抑制 / route 路由）。 - Service Discovery：K8s SD（role: pod/service/node/endpoint）+ relabel（keep/drop/replace）。
- relabel 两阶段：
relabel_configs（抓取前，目标层）/metric_relabel_configs（抓取后，样本层，删高基数 label）。 - 存储：本地 TSDB（2h chunk，默认 15 天）；长期/HA 靠 remote_write 到 Thanos/Mimir/Cortex/VictoriaMetrics。
- 高可用：跑两实例 + Alertmanager 集群去重；存储层去重靠 Thanos/Mimir。
一、四大指标类型速查
| 类型 | 行为 | 典型指标 | 怎么查 | 关键函数 |
|---|---|---|---|---|
| Counter | 单调递增（重启归零） | 请求数、错误数、字节发送 | rate/increase 算速率 | rate/irate/increase/resets/changes |
| Gauge | 可增可减 | CPU%、内存、温度、队列长度 | 直接读或滑动窗口 | avg_over_time/max_over_time/min_over_time/changes/deriv |
| Histogram | 分桶累计 | 延迟分布、响应体大小 | histogram_quantile 算分位数 | histogram_quantile/rate(_bucket) |
| Summary | 客户端预算分位数 | 延迟分位数（单实例） | 直接读 _quantile | 无（不可聚合） |
二、PromQL 函数清单
速率类（用于 Counter）
| 函数 | 含义 | 用途 |
|---|---|---|
rate(v[5m]) | 窗口内每秒平均速率 | 告警、稳态监控 |
irate(v[5m]) | 最后两点每秒速率 | 实时大屏（灵敏） |
increase(v[1h]) | 窗口内总增量 | 「过去 1h 新增多少」 |
resets(v[5m]) | 窗口内 counter 重置次数 | 诊断重启 |
changes(v[5m]) | 窗口内值变化次数 | Gauge 变化频率 |
滑动窗口类（用于 Gauge）
| 函数 | 含义 |
|---|---|
avg_over_time(v[5m]) | 窗口平均值 |
max_over_time(v[5m]) | 窗口最大值 |
min_over_time(v[5m]) | 窗口最小值 |
sum_over_time(v[5m]) | 窗口求和 |
quantile_over_time(0.99, v[5m]) | 窗口分位数（要小心成本） |
stddev_over_time(v[5m]) | 窗口标准差 |
predict_linear(v[1h], 3600) | 线性预测 1h 后的值（磁盘满预警） |
聚合类
| 函数 | 含义 |
|---|---|
sum/avg/min/max | 求和/平均/最小/最大 |
count | 时序条数 |
count_values("label", v) | 按 value 计数并打 label |
topk(3, v)/bottomk(3, v) | 取 Top/Bottom N |
quantile(0.99, v) | 即时分位数（注意：和 histogram_quantile 不同，作用于即时向量） |
by/without | 分组维度（保留/排除某些 label） |
数学与时间类
| 函数 | 含义 |
|---|---|
abs/ceil/floor/round | 取整 |
clamp_min(v, 0)/clamp_max(v, 100) | 限幅 |
time()/timestamp(v) | 当前时间戳 / 样本时间戳 |
vector(0) | 标量转向量（凑数用） |
scalar(v) | 向量转标量 |
Histogram 专用
promql
histogram_quantile(0.99, sum by (le) (rate(http_duration_bucket[5m])))
// 注意：先 rate（每桶速率）→ sum by le（跨实例合并桶计数）→ histogram_quantile（算分位数）三、告警规则模板
yaml
groups:
- name: service-alerts
interval: 30s
rules:
# ① 服务可用性：up == 0 持续 1 分钟
- alert: ServiceDown
expr: up == 0
for: 1m
labels: { severity: critical }
annotations:
summary: "{{ $labels.job }} 在 {{ $labels.instance }} 不可达"
# ② 高错误率：5xx 占比 > 1% 持续 5 分钟
- alert: HighErrorRate
expr: |
sum by (service) (rate(http_requests_total{code=~"5.."}[5m]))
/ sum by (service) (rate(http_requests_total[5m])) > 0.01
for: 5m
labels: { severity: warning }
annotations:
summary: "{{ $labels.service }} 错误率 {{ $value | humanizePercentage }}"
# ③ P99 延迟：> 500ms 持续 10 分钟
- alert: HighLatencyP99
expr: |
histogram_quantile(0.99,
sum by (le, service) (rate(http_duration_seconds_bucket[5m]))
) > 0.5
for: 10m
labels: { severity: warning }
# ④ 资源预警：磁盘 4h 后将满
- alert: DiskWillFill
expr: predict_linear(node_filesystem_avail_bytes[1h], 4*3600) < 0
for: 5m
labels: { severity: critical }四、scrape_configs 常见配置
yaml
scrape_configs:
# 静态目标
- job_name: node
static_configs:
- targets: ['node1:9100', 'node2:9100']
# K8s Pod 自动发现 + relabel
- job_name: k8s-pods
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: "true"
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
target_label: __address__
regex: (.+):(?:\d+);(\d+)
replacement: $1:$2
metric_relabel_configs:
- regex: 'user_id|trace_id'
action: labeldrop # 删高基数 label
# 短任务经 Pushgateway
- job_name: pushgateway
honor_labels: true # 保留 Pushgateway 上的 job/instance 标签
static_configs:
- targets: ['pushgateway:9091']五、易错点清单
- 「Counter 直接读有意义」：错。counter 一直涨，必须
rate/increase。http_requests_total读出来 100 万没信息量，rate(...[5m])才有意义。 - 「rate 和 irate 没区别」：错。
rate是窗口平均（稳，告警用），irate是末两点（灵但抖，大屏用）。流量突降时 irate 易误报。 - 「Histogram 和 Summary 等价」：错。Histogram 服务端聚合（可跨实例合并 P99），Summary 客户端预算（不可跨实例合并）——生产几乎只用 Histogram。
- 「先 sum 后 rate」：错。聚合速率要先
rate后sum（每条时序先算速率再求和）；反过来把 counter 加和再 rate 语义错乱。 - 「histogram_quantile 先 quantile 后 sum」：错。必须先
sum by (le)后histogram_quantile——先把各实例的桶计数加起来再算分位数，否则得到「P99 的 P99」错误结果。 - 「Prometheus 做日志/追踪」：错。Prometheus 只做指标。日志归 ELK/Loki，追踪归 Jaeger/Tempo。
- 「把 user_id 做 label」：错。高基数 label 会让时序数爆炸，吃光 TSDB 内存——user_id/session_id/trace_id 这些归日志/追踪，绝不做 label。
- 「Pull 适合短任务」：错。短任务（Cron/Lambda）跑几秒就退出，Prometheus 抓不到——用 Pushgateway 中转，且只用于短任务。
- 「原版 Prometheus 高可用」：错。原版单节点无副本去重——跑两实例 + Alertmanager 集群去重，存储层去重靠 Thanos/Mimir。
- 「Summary 比 Histogram 准」：错。两者精度都取决于桶/分位配置；Summary 不能跨实例聚合是硬伤，集群场景一律 Histogram。
- 「promQL 里用 SQL」：错。PromQL 是独立语言，没有 JOIN/ORDER BY，向量匹配用
on/ignoring，分组用by/without。 - 「远程读写是 Push 模型」：理解偏差。remote_write 是 Prometheus 主动转发样本到远端（采集仍为 Pull），远端只做存储/查询，不影响 Pull 哲学。