3. Prometheus 基础架构回顾：Pull 模型、ServiceMonitor、PromQL、Alertmanager
在深入滚动升级与 Prometheus 监控联动的故障排查之前，必须牢固掌握 Prometheus 的核心基础架构。本章将系统回顾四个关键组件：Pull 模型、ServiceMonitor、PromQL 和 Alertmanager，为后续实战打下坚实的理论基础。
3.1 Pull 模型：主动拉取 vs 被动推送
Prometheus 采用独特的 Pull（拉取）模型，即 Prometheus Server 主动向目标端点（Target）的 /metrics 接口发起 HTTP 请求，获取监控指标数据。这与传统的 Push（推送）模型（如 Zabbix、Graphite）形成鲜明对比。
| 特性 | Pull 模型（Prometheus） | Push 模型（传统） |
|---|---|---|
| 数据采集方向 | 监控系统主动拉取 | 被监控对象主动推送 |
| 网络依赖 | 监控系统可访问目标 | 目标可访问监控系统 |
| 健康检查 | 拉取失败即视为目标异常 | 需额外心跳机制 |
| 配置变更 | 修改 Prometheus 配置或服务发现 | 修改推送端配置 |
| 适用场景 | Kubernetes、云原生、微服务 | 传统网络设备、批处理任务 |
3.2 ServiceMonitor：Kubernetes 中的自动发现
在 Kubernetes 环境中，手动维护 Target 列表是不现实的。ServiceMonitor 是 Prometheus Operator 引入的 CRD（Custom Resource Definition），用于声明式地定义 Prometheus 应监控哪些 Service 及其 Endpoints。
ServiceMonitor 通过 标签选择器（Label Selector） 匹配 Service，并自动发现所有关联的 Pod 作为 Target。其核心字段包括：
selector：匹配 Service 的标签。endpoints：定义端口、路径、协议等采集参数。namespaceSelector：限定监控的命名空间范围。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: example-app
namespace: monitoring
spec:
selector:
matchLabels:
app: example-app
endpoints:
- port: http
path: /metrics
interval: 15s
namespaceSelector:
matchNames:
- productionnamespaceSelector 与 Prometheus 自身的 serviceMonitorNamespaceSelector 必须同时匹配，否则 ServiceMonitor 不会被 Prometheus 发现。排查时请检查两个选择器的交集。
3.3 PromQL：指标查询与聚合
PromQL（Prometheus Query Language） 是 Prometheus 的查询语言，用于实时分析和聚合时序数据。在滚动升级故障排查中，PromQL 是定位问题的核心工具。
以下是在滚动升级场景中常用的 PromQL 查询模式：
| 查询目标 | PromQL 示例 | 说明 |
|---|---|---|
| Pod 状态 | kube_pod_status_phase{phase="Running"} |
查看当前 Running 状态的 Pod 数量 |
| 请求错误率 | rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) |
计算 5 分钟内 5xx 错误率 |
| Pod 重启次数 | increase(kube_pod_container_status_restarts_total[5m]) |
5 分钟内 Pod 重启增量 |
| 升级进度 | count(kube_deployment_status_replicas_available) by (deployment) |
按 Deployment 统计可用副本数 |
rate() 用于计算每秒平均增长率，适合请求量、错误数等计数器；increase() 用于计算指定时间范围内的增量，适合重启次数等离散事件。
3.4 Alertmanager：告警路由与通知
Alertmanager 负责处理 Prometheus 发送的告警，执行去重、分组、静默、抑制，并最终通过邮件、Slack、PagerDuty 等渠道发送通知。
告警的生命周期如下：
- Prometheus 规则评估：Prometheus 根据
rules文件中的告警规则，定期评估表达式，当条件满足时生成告警。 - 发送至 Alertmanager：Prometheus 将告警推送到 Alertmanager 的 API。
- 分组与抑制：Alertmanager 根据配置对告警进行分组（避免告警风暴），并应用抑制规则（如已触发“节点宕机”则抑制该节点上的所有 Pod 告警）。
- 路由与通知：根据
route配置将告警发送到对应的接收器（Receiver）。
route:
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'slack-critical'
routes:
- match:
severity: critical
receiver: 'pagerduty-critical'
receivers:
- name: 'slack-critical'
slack_configs:
- channel: '#alerts-critical'
send_resolved: truegroup_wait: 10s 和 repeat_interval: 1m，以便在升级过程中快速发现异常，同时避免告警风暴淹没 SRE 团队。
3.5 架构总览：四者如何协同工作
下图展示了 Pull 模型、ServiceMonitor、PromQL 和 Alertmanager 在 Kubernetes 监控体系中的完整协作流程：
在滚动升级过程中，这四个组件形成完整的监控闭环：
- ServiceMonitor 确保新版本 Pod 自动被纳入监控范围。
- Pull 模型 实时检测 Pod 的健康状态和指标可用性。
- PromQL 提供即时查询能力，快速定位错误率飙升或 Pod 重启等异常。
- Alertmanager 在指标异常时及时通知 SRE 团队，触发回滚或人工介入。