Prometheus 与 Grafana

核心设计选择:Prometheus 的 Pull 模型

先理解一个让许多人感到意外的设计决策.监控数据从服务到监控系统有两种传输方向:

Push 模型:  你的服务 ──主动推送──▶ 监控系统
              (服务需知道监控系统地址,定时发送数据)

Pull 模型:  监控系统 ──主动抓取──▶ 你的服务的 /metrics 端点
              (Prometheus 知道有哪些服务,定时去"拉取")

Prometheus 选择了 Pull 模型:服务只需暴露一个 HTTP 端点(约定路径为 /metrics),将当前指标以纯文本形式输出;Prometheus 按配置的间隔(如每 15 秒)主动发起抓取.一个 /metrics 端点的输出内容示例如下:

# HELP http_requests_total Total HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 8954
http_requests_total{method="POST",status="500"} 12
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 8800
http_request_duration_seconds_bucket{le="0.5"} 8950
http_request_duration_seconds_bucket{le="+Inf"} 8966

第 02 篇中的 Counter 和 Histogram 正是以这种纯文本格式对外暴露.Pull 模型在动态的 Kubernetes 环境中尤具优势:

数据模型:指标名 + 标签

Prometheus 的数据模型是其能力的根基.每条时间序列由**指标名(Metric Name)和一组标签(Label)**唯一确定:

http_requests_total{method="POST", status="500", service="order"}
└────────┬────────┘ └──────────────────┬──────────────────────┘
     指标名                         标签(键值对)

标签是维度.同一指标名下,标签的不同组合对应不同的时间序列.这使得可以从任意维度切片分析:"按 status 查看错误""按 service 查看流量""只关注 POST 请求"--全依赖标签的过滤与聚合能力.

PromQL:将第 02 篇的设计转化为查询

PromQL 是 Prometheus 的查询语言.不需要掌握全部语法,但有几个模式是日常排障的核心,恰好对应第 02 篇的指标设计.

使用 rate() 将 Counter 转换为速率

回顾第 02 篇的原则--Counter 的绝对值没有意义,速率才有.rate() 即用于此目的:

# 过去 5 分钟内每秒请求数(QPS)-- 这即 RED 中的 R(Rate)
rate(http_requests_total[5m])

# 按服务聚合 QPS(sum 将不同实例的值相加)
sum(rate(http_requests_total[5m])) by (service)

错误率:RED 中的 E

# 错误请求速率 / 总请求速率 = 错误占比
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# status=~"5.." 是正则匹配,匹配所有 5xx 状态码

P99 延迟:RED 中的 D

第 02 篇指出延迟应看百分位,应使用 Histogram.PromQL 通过 histogram_quantile 从 Histogram 的桶数据中计算百分位:

# 计算 P99 延迟 -- 0.99 表示 99 百分位
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)
# le 是 Histogram 的"桶上界"标签,by (le) 保留该标签才能计算分位

至此,第 01 篇凌晨那条"下单 P99 超过 2 秒"的告警背后的 PromQL 逻辑已经清晰.RED 的三个指标对应三条查询,一一对应.

存储架构:Prometheus 内置存储的定位与局限

Prometheus 内置一个时序数据库(TSDB,Time Series Database),专为"大量数值 + 时间戳"场景优化,写入和查询性能均很高.但它刻意设计为本地,单机存储,由此带来两个限制:

• 不适合长期存储:默认保留约 15 天,本地磁盘无法承载数年数据量
• 非天然高可用:单机存储,该 Prometheus 实例故障则数据中断

这是刻意为之的设计选择:Prometheus 追求保持简单可靠的核心,将"长期存储,跨集群聚合,高可用"等需求交由专门的方案处理--Thanos 或 Mimir(将数据下沉至对象存储如 S3,实现近乎无限期,可水平扩展的存储;Mimir 采用 remote write 模型,Thanos 经典模式则通过 sidecar 将本地数据块上传至对象存储).

Grafana:统一可视化层

Prometheus 自带的界面功能较为基础.Grafana 是事实标准的可视化平台:它连接 Prometheus(以及后续将介绍的 Loki,Tempo)作为数据源,使用 PromQL 查询数据,将结果呈现为丰富的看板(Dashboard).

关键认知:Grafana 自身不存储数据,它仅是一个"查询 + 展示"的前端层.一张图表 = 一条 PromQL + 一种图形类型.第 02 篇的 RED 看板,即是将上述三条 PromQL 各配置一张图表组合而成.

告警:从被动查看到主动通知

看板是"主动查看"模式,但没有人能 7x24 小时盯屏幕.告警(Alerting)负责在异常发生时主动通知相关人员.Prometheus 的告警体系分两个步骤,职责分离清晰:

[Prometheus<br/>根据告警规则(PromQL)<br/>持续评估] → [Alertmanager<br/>去重 / 分组 / 静默 / 路由] → [通知渠道<br/>钉钉 / Slack / PagerDuty / 邮件]

• Prometheus 负责"判断":告警规则的本质是一条 PromQL + 阈值 + 持续时间.条件成立则生成告警事件.
• Alertmanager 负责"处理通知":对告警进行去重(同一问题不重复发送),分组(相关告警合并为一条通知),按值班表路由,支持静默(维护期间暂停通知).

下面是一条将第 02 篇 SLO 落地的告警规则:

groups:
  - name: slo-alerts
    rules:
      - alert: HighErrorRate
        # 错误率 > 1%(即 SLO 99% 的反面)
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m])) > 0.01
        for: 5m                      # ← 持续 5 分钟才触发告警,避免瞬时抖动导致误报
        labels:
          severity: critical
        annotations:
          summary: "服务 {{ $labels.service }} 错误率超过 1%"

Kubernetes 中的服务发现:Pull 模型自动化的关键

最后回应一个之前埋下的伏笔:Kubernetes 中 Pod 频繁增删与漂移(回顾 Kubernetes 笔记中的相关内容),Prometheus 如何知道该抓取哪些目标?答案是服务发现(Service Discovery)--Prometheus 直接对接 Kubernetes API,自动发现带有特定注解的 Pod/Service,动态将其加入抓取目标列表.Pod 启动即自动开始监控,Pod 终止即自动移除,全程无需手动修改配置.这正是 Pull 模型在动态环境中的核心优势.生产环境中通常使用 Prometheus Operator(配合 ServiceMonitor 资源)以声明式方式管理这一切--又是声明式思想(参见 GitOps 系列)的延伸.