illegalCreed

中文

English

中文

English

Appearance

入门：Pull 模型、指标类型与告警流水线 ​

基于 Prometheus 3.x · 核于 2026-08

速查 ​

  • 是什么：Prometheus 是开源时序指标监控系统（CNCF 第二个毕业项目，仅次于 Kubernetes），用 Pull 模型主动从应用暴露的 /metrics 端点抓取时序数据，存进内置 TSDB，用 PromQL 查询与告警，由 Alertmanager 路由告警，Grafana 做可视化。
  • 数据模型：一条时序 = metric name（http_requests_total）+ 任意多 labels（{method="GET",code="200"}）+ (timestamp, float64 value)。labels 是多维度的「身份证」，所有聚合都靠 labels 切片。
  • 四大指标类型：①**Counter（计数器）单调递增（请求数、错误数，只能 rate）；②Gauge（瞬时值）可增可减（CPU/内存/温度，直接读）；③Histogram（直方图）分桶累计（延迟分布，算分位数 P50/P95/P99）；④Summary（摘要）**客户端预计算分位数（不可聚合，少用）。
  • Pull vs Push：Prometheus 主动去拉应用 /metrics（默认 15s 一次），应用被动暴露文本格式指标——好处是监控端可控（知抓取成功与否）、易调试（curl 即可看）、无应用发不出去的风险；短任务（Cron/批处理）来不及被拉，用 Pushgateway 中转。
  • PromQL 三类查询：①即时查询返回当前值（node_memory_MemAvailable_bytes）；②范围查询返回一段时间序列（rate(...[5m])，用于画图）；③标量/字符串做计算。rate/irate/histogram_quantile 是最高频函数。
  • 告警流水线：在 Prometheus 写 Alerting Rule（FOR 5m 持续时长 + 条件）→ 触发后推送给 Alertmanager → Alertmanager 按 route 分组/去重/抑制/静默 → 路由到邮件/钉钉/Slack/PagerDuty。
  • Service Discovery：动态发现抓取目标——K8s 模式自动列出所有 Pod、Consul 模式查服务注册表、DNS 模式解析 SRV 记录——配合 relabel（抓取前重写标签）做过滤与改写。
  • 存储：本地 TSDB 按 2 小时分块（chunk）存压缩数据，默认保留 15 天；长期存储/高可用靠远程读写（remote_write/remote_read）转发到 Thanos/Mimir/Cortex/VictoriaMetrics。
  • 生态位置：Prometheus = 采集 + 存储 + 查询；可视化交 Grafana；告警交 Alertmanager；日志交 ELK/Loki；追踪交 Jaeger/Tempo——只做指标这一件事，做好。

一、Prometheus 是什么：监控的 Pull 革命 ​

传统监控（statsd/Zabbix/Nagios）多是 Push 模型——应用主动把指标发到 collector。Prometheus 反其道而行：**监控端主动拉（Pull）**应用暴露的 /metrics HTTP 端点。这带来根本性的差异：

传统 Push 模型                     Prometheus Pull 模型
应用 ──主动推指标──> collector       应用 ──暴露 /metrics──> HTTP 端点
                                                    ▲
                                    Prometheus ──定时拉─┘ (默认 15s)
  • 为什么选 Pull：①监控端全知——它知道哪些目标在抓、抓取是否成功（up=0 即抓失败），Push 模型下某个应用不发指标你都不知道它消失了；②易调试——curl http://app:8080/metrics 就能看到原始指标，无需起 collector；③应用解耦——应用只需暴露文本端点，不知道有谁在监控、有几个 Prometheus；④自然的服务发现——拉取列表来自 SD（K8s/Consul），新 Pod 上线自动加入抓取。
  • Pull 的弱点：短任务（Cron/批处理 Lambda）跑几秒就退出，Prometheus 抓不到——用 Pushgateway 做中转：任务把指标推给 Pushgateway，Prometheus 持久地从 Pushgateway 拉。注意 Pushgateway 不是通用 Push 方案，只用于短任务，且要手动清理过期指标。
  • 拉取格式：应用暴露文本格式（ exposition format），如 http_requests_total{method="GET",code="200"} 1234。一行一个样本，# HELP/# TYPE 是注释。客户端库（prom-client、micrometer、prometheus_client）自动生成。

二、四大指标类型：counter/gauge/histogram/summary ​

所有 Prometheus 指标分四类，理解类型才能选对 PromQL 函数：

类型行为典型指标怎么用
Counter（计数器）单调递增（重启归零）请求总数、错误总数、字节发送必须 rate()/increase() 算速率，不能直接读（一直涨没意义）
Gauge（瞬时值）可增可减CPU%、内存、温度、队列长度直接读，或 avg_over_time/max_over_time
Histogram（直方图）分桶累计计数请求延迟分布、响应体大小histogram_quantile(0.99, rate(..._bucket[5m])) 算分位数
Summary（摘要）客户端预算分位数延迟分位数直接读 _quantile，不可跨实例聚合，少用
  • Counter 的 rate 哲学：http_requests_total 这个数字本身（如 100 万次）没意义——它在涨是正常的。有意义的是每秒速率 rate(http_requests_total[5m])（如 50 req/s）。increase(...[1h]) 算「过去 1 小时新增多少」。
  • Histogram vs Summary：算延迟 P99 都能算，但 Histogram 在服务端用桶聚合（le="0.1" 表示「≤100ms 的累计请求数」），可跨实例/跨时间聚合；Summary 在客户端预算好分位数，不能跨实例聚合（两个实例的 P99 不能合并成总 P99）。生产几乎只用 Histogram——它聚合灵活，桶边界可调。
  • Histogram 的桶设计：默认桶 [0.005, 0.01, 0.025, ..., 10, +Inf] 秒。要监控 SLO（如 P99 < 300ms），务必保证 0.3 这个桶存在，否则分位数不准。桶太多（高基数）吃内存，要权衡。

三、PromQL 入门：监控的「SQL」 ​

PromQL 是 Prometheus 的查询语言，写面板和告警都靠它。三类最常用模式：

promql
// ① 即时查询：当前可用内存（所有实例）
node_memory_MemAvailable_bytes

// ② 范围查询 + rate：过去 5 分钟每秒 QPS，按 method 分组
sum by (method) (rate(http_requests_total[5m]))

// ③ 算 P99 延迟（Histogram）
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

// ④ 告警条件：错误率 > 1% 持续 5 分钟
(sum(rate(http_requests_total{code=~"5.."}[5m])) by (service))
  / (sum(rate(http_requests_total[5m])) by (service)) > 0.01
  • 即时 vs 范围：metric（无 []）返回最新一个点的即时向量；metric[5m] 返回过去 5 分钟的范围向量（一系列点，画图用，不能直接输出）。
  • rate vs irate：rate 在窗口内线性回归算平均速率（平滑）；irate 只看最后两个点（灵敏但有抖动）。告警用 rate（稳），实时大屏用 irate（灵）。
  • 向量匹配：两个向量做除法（如错误率），要靠 labels 对齐。ignoring(code) 忽略某些 label 匹配，on(service) 只按某些 label 匹配——和 SQL JOIN 类似。
  • 聚合：sum/avg/max/min/count + by/without 分组，等价 SQL 的 GROUP BY。

四、告警流水线：Rule + Alertmanager ​

Prometheus 告警分两段，职责清晰：

┌─ Prometheus ────────────┐    ┌─ Alertmanager ────────────────┐
│ Alerting Rule           │    │ route（按 label 路由）         │
│   condition + FOR 5m    │───>│ grouping（分组聚合）          │──> 邮件/钉钉/PagerDuty
│ 触发 → firing 状态      │    │ inhibit（抑制：A 响应则屏蔽 B）│
└─────────────────────────┘    │ silence（手动静默）           │
                               └───────────────────────────────┘
  • Alerting Rule（写 Prometheus 配置）：alert: HighErrorRate + expr: ... > 0.01 + for: 5m（持续 5 分钟才触发，避免抖动）+ labels/annotations（带到 Alertmanager）。
  • Alertmanager 做路由与去重：同一条告警可能被多个 Prometheus 实例触发，Alertmanager 按 group_by（如 [alertname, service]）去重合并；按 route.receiver 路由到不同渠道（P0 → PagerDuty，P2 → 邮件）。
  • 抑制（inhibit）：定义「集群宕机」时抑制「单节点宕机」（前者已涵盖后者），避免告警风暴。
  • 静默（silence）：维护窗口临时屏蔽告警（带 matcher + 过期时间）。

五、Service Discovery：自动发现抓取目标 ​

云原生环境目标动态变化（Pod 频繁创建/销毁），不能写死 IP。Prometheus 的 Service Discovery 自动维护抓取列表：

  • Kubernetes SD：列出所有 Pod/Service/Node/Endpoint，自动发现带 prometheus.io/scrape: "true" 注解的 Pod——K8s 监控的事实标准。
  • Consul/DNS/Eureka SD：服务注册表模式，新增实例自动加入。
  • relabel（抓取前重写）：SD 给的标签可能不规范，用 relabel_configs 在抓取前过滤（action: keep/drop）或改写（action: replace）__address__/job/instance 标签——把 K8s 的元标签（__meta_kubernetes_pod_name）转成业务标签（pod）。
  • metric_relabel（抓取后重写）：抓到的样本标签也能改写/丢弃（action: labeldrop 删高基数标签如 user_id）。

六、生态定位：只做指标，做好 ​

Prometheus 故意不做日志/追踪——日志给 ELK/Loki，追踪给 Jaeger/Tempo。它专注指标监控，把可视化交给 Grafana，长期存储交给 Thanos/Mimir。这种「Unix 哲学」让它在指标领域成为事实标准：CNCF 生态、K8s、Istio、所有主流语言客户端都原生支持 Prometheus 格式。理解了它的 Pull 模型与 PromQL，后续 Grafana 大盘、Alertmanager 告警、OpenTelemetry 指标导出都顺理成章。

下一步 ​

理解了 Prometheus 的 Pull 模型与四大指标类型后，下一步深入两个核心维度——指标与 PromQL（counter/gauge/histogram/summary 详解 + PromQL 函数 + Alertmanager 路由）与架构与服务发现（TSDB 存储 + Service Discovery + 远程读写 + Grafana 集成）。