Prometheus 监控体系：从零搭建生产级

为什么单跑一个 Prometheus 不够

很多团队的 Prometheus 是这样用的：装上、开端口、配个 exporter、用 Grafana 看图。这套小循环能工作，但生产中很快遇到这些障碍：

• 本地存储天数不够（默认 15 天）。
• 告警规则散落各处，没人维护。
• 多个集群没有统一视图。
• 长期存储成本飙升。
• 与告警系统 / IM / oncall 工作流不通。

本期我们要把 Prometheus 当作「整套监控体系的核心」，而不是「一个开源工具」。

基础架构：三层视角

我把监控体系拆成三层：

层级	责任	常见组件
采集	从被监控对象 pull/push	Prometheus, exporter, agent
存储与查询	时序数据库	Prometheus, Thanos, Cortex, Mimir
告警与面板	规则引擎 + 通知 + UI	Alertmanager, Grafana, 内部 IM

把三层分别做扎实，监控体系才有「可演进性」。

采集：exporter 与 service discovery

Prometheus 的采集模型是「pull 模式」。每个被监控对象暴露一个 /metrics 端点。常见采集方式：

• node_exporter：Linux 主机指标。
• blackbox_exporter：黑盒探针（HTTP/TCP/ICMP）。
• 应用 SDK：Go / Python / Java 各有官方或社区 client。

在动态基础设施（K8s）下，手动注册不现实，需要服务发现：

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: 'true'

存储：单点扛不住，那就分区

Prometheus 的本地存储对中小规模足够。规模上来后的两种主流扩展：

1. Thanos：将多个 Prometheus 实例的对象存储（S3/GCS）统一，提供全局查询。
2. Mimir：每个租户的全局 scale 模式，写入 TSDB 即查询。

我们最终选择 Thanos，因为它的「上传到对象存储 + Querier / Compactor」结构对运维友好。

保留策略：让数据不再「无边」增长

时序数据的保留窗口与采样精度联动：

精度	保留
15s 原始	15 天
1m 平均	90 天
5m 平均	1 年
1h 平均	3 年

这些数字的设置要和下游的「数据复用」对齐。一旦定好，对象存储成本 = 上面的窗口数。

告警：把规则写成代码

我见过太多团队的告警规则散落各处，最后没人知道「为什么不告警」。我们的建议：

1. 用 Git 管理告警规则。
2. 用 promtool check rules 做语法 / 语义校验。
3. 让规则附带「runbook 链接」字段。
4. 把规则按「服务 / 业务 / 集群」组织。

groups:
  - name: api-errors
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m
        labels:
          severity: critical
          team: shop
        annotations:
          summary: "API 错误率超 5%"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

Alertmanager：路由与降噪

Alertmanager 是 Prometheus 团队的告警中心。它的核心概念：

• Route：按 label 把告警分发到不同 receiver。
• Group：把多个同类告警合并通知。
• Inhibit：上游故障时抑制下游告警。
• Silence：在维护期屏蔽告警。

长期存储成本的工程

监控数据增长大致是「业务规模 × 指标维度」。控制成本的几条原则：

• 高基数指标（按用户 ID）慎用。
• Histogram 用桶数控制（推荐 5–7 个）。
• 采样 + 聚合 + 归档分层。

在我们的生产里，监控成本通常占总基础设施 3–5%。但如果不做控制，会涨到 15% 以上。

面板设计：让人愿意看

Grafana 面板的好坏直接影响值班效率。我的经验：

• 每个核心服务一个「主面板」，包括 SLO、QPS、错误率、依赖、容量五块。
• 面板按业务模块切分，不堆在一个 dashboard。
• 颜色与阈值人为约定（绿黄红，5% 警戒）。
• 面板要可分享、可下载截图（事故复盘必备）。

与 on-call 协作：减少告警疲劳

• 每个值班周期只处理「有效告警」+「事故报告」。
• 周会复盘：被叫醒的告警是否有必要？要不要改规则？
• 把告警按业务影响分 P0 / P1 / P2。
• 维护窗口静默，但要有审计日志。

未来方向：OpenTelemetry + TSDB

未来 2 年的趋势：

• 采集层从 Prometheus exporter 转向 OTLP 标准。
• 存储端仍然是 TSDB，但云厂商方案越来越多。
• eBPF 数据直接进指标体系。

给团队的几条具体建议

• 把 Prometheus 当作「核心」而非「工具」。
• 告警规则严格 Git 化。
• 面板与告警同步更新。
• 年度成本回顾。
• 把指标、Trace、Log 三者联动。

监控系统从不是装上 Prometheus 就完事。它需要持续运营、规则治理、成本控制。把这些当作日常工作做扎实，团队的「能见度」会一直提升，事故相应减少。