Prometheus 监控告警实战 2026：PromQL、Alertmanager 与 SLO 驱动的可观测性

DevOps运维

为什么 Prometheus 仍是云原生监控的事实标准

在 OpenTelemetry 蓬勃发展的 2026 年，Prometheus 依然主导指标（Metrics）领域。它以拉取模型（Pull） + 多维数据模型 + 强大 PromQL 著称，配合 Alertmanager 形成闭环告警。理解它的设计取舍，是搭建可靠可观测性的第一步。

维度 Prometheus 推模型（Push）方案
采集 主动拉取 /metrics 客户端主动推送
查询 PromQL 多维灵活 依赖外部存储查询
服务发现 原生支持 K8s/Consul 需自行实现
适用 机器/服务指标 短生命周期任务（配 Pushgateway）

架构与核心组件

  • Prometheus Server：抓取、存储（本地 TSDB）、执行 PromQL。
  • Exporter：把第三方系统指标暴露为 /metrics（node_exporter、blackbox_exporter 等）。
  • Alertmanager：去重、分组、路由、静默告警。
  • Pushgateway：承接批处理/短任务的推送指标。
# prometheus.yml 最小配置
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["node-1:9100", "node-2:9100"]
  - job_name: "api"
    kubernetes_sd_configs:
      - role: endpoints
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_name]
        regex: "order-api"
        action: keep

排障抓取失败时，可用 HTTP 状态码 工具对照 Exporter 返回的响应码（如 200/503），快速定位是采集端还是暴露端问题。

PromQL 核心函数

rate / irate：计算速率

# 每秒 HTTP 请求数（5m 窗口，自动去毛刺）
rate(http_requests_total[5m])

# 瞬时速率（最近两个样本），更灵敏但更易抖
irate(http_requests_total[5m])

histogram_quantile：分位延迟

http_request_duration_seconds_bucket 是直方图指标，用分位函数看 P99 延迟：

# P99 请求延迟
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

标签聚合

# 按服务与状态码汇总 QPS
sum by (service, code) (rate(http_requests_total[5m]))

记录规则（Recording Rules）：预计算降本

把高频、昂贵的查询预计算为新时间序列，仪表盘直接读结果。

# rules/recording.yml
groups:
  - name: http_slo
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))
      - record: job:request_latency:p99
        expr: |
          histogram_quantile(0.99,
            sum by (job, le) (rate(http_request_duration_seconds_bucket[5m])))

告警规则与 Alertmanager

告警规则

# rules/alerts.yml
groups:
  - name: availability
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{code=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m                 # 持续 10 分钟才触发，避免抖动
        labels:
          severity: critical
        annotations:
          summary: "错误率超过 5%"
          description: "服务 {{ $labels.job }} 5xx 错误率 {{ $value | humanizePercentage }}"

Alertmanager 路由与分组

# alertmanager.yml
route:
  receiver: "slack-default"
  group_by: ["alertname", "job"]
  group_wait: 30s          # 同组首次等待，聚合多条
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: ["severity=critical"]
      receiver: "pagerduty"
      continue: true
    - matchers: ["job=~"batch.*"]
      receiver: "slack-batch"

receivers:
  - name: "slack-default"
    slack_configs:
      - api_url: ${SLACK_URL}
        channel: "#alerts"

抑制（Inhibition）与静默（Silence）

  • 抑制：当「主机宕机」告警存在时，抑制该机上「服务不可用」告警，避免噪音。
  • 静默：维护窗口（如发版）临时屏蔽特定告警，可用 Cron 说明 工具规划维护时段。

SLO 与错误预算燃烧率

用 SLO（服务等级目标）替代「拍脑袋阈值」，是现代告警的核心。以 99.9% 可用性为例：

# 30 天窗口内的合规比（good / total）
(
  sum(rate(http_requests_total{code!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) > 0.999

燃烧率（Burn Rate）告警在错误预算快速消耗时提前报警：

- alert: ErrorBudgetBurnFast
  expr: |
    (
      sum(rate(http_requests_total{code=~"5.."}[1h]))
      / sum(rate(http_requests_total[1h]))
    ) > (14.4 * (1 - 0.999))   # 1h 内烧光 30d 预算的 14.4 倍速率
  for: 5m
  labels: { severity: critical }

应用埋点：别只靠 Exporter

业务指标需要主动埋点。以 Python 为例：

from prometheus_client import Counter, Histogram, start_http_server

REQUESTS = Counter("http_requests_total", "总请求数", ["method", "code"])
LATENCY = Histogram("http_request_duration_seconds", "请求耗时")

start_http_server(8000)   # 暴露 /metrics

@LATENCY.time()
def handle(req):
    REQUESTS.labels(req.method, "200").inc()
    return "ok"

前端或网关侧，可把结构化指标先经 JSON 格式化 工具校验，再写入监控管线，避免脏数据污染查询。

生产最佳实践清单

  1. 合理设 for：避免瞬时抖动产生告警风暴。
  2. Cardinality 控制：高基数列（如 user_id）不要做标签，会撑爆 TSDB。
  3. 分层告警：Warning 进群，Critical 进值班（Pager）。
  4. 记录规则前置：仪表盘查询走预计算。
  5. 长期存储：本地 TSDB 配 Thanos / Mimir 做远程写，突破单机保留上限。

常见问题 FAQ

Q1：rate 和 irate 怎么选？

看趋势用 rate（平滑稳）；看瞬时尖刺用 irate（灵敏）。仪表盘一般用 rate。

Q2：直方图还是摘要（Summary）？

需要跨实例聚合分位（如全局 P99）用直方图；单实例且无法预知分位用 Summary。直方图更灵活，推荐默认。

Q3：告警一直抖动怎么办？

给告警规则加 for: 10m，或对指标做更长的 rate 窗口，吸收短时波动。

Q4：label 太多会怎样？

每个唯一 label 组合都是一条时间序列。滥用高基数列会导致内存与写入爆炸，是 Prometheus 最常见的性能坑。

Q5：Prometheus 能替代日志和链路吗？

不能。Metrics 看「总量与趋势」，Logs 看「单条细节」，Traces 看「调用路径」。三者互补，构成完整可观测性。

工具推荐

在 Prometheus 运维中，以下 工具库 能帮上忙：

Prometheus 的威力不在「能画图」，而在「用 PromQL 把业务健康翻译成可量化的 SLO，再用 Alertmanager 把噪音过滤成可行动的告警」。把指标、告警、SLO 三层串起来，监控才真正有价值。

本站提供浏览器本地工具，免注册即可试用 →

#Prometheus#监控告警#可观测性#PromQL#SLO#DevOps