小团队有必要搭完整的 Prometheus + Grafana 吗？

有必要，但不需要一开始就追求"完整"。小团队可以先从最简单的方案起步：Node Exporter（机器指标）+ Prometheus（存 + 查）+ Grafana（看板）+ Alertmanager（告警），一台 2C4G 的服务器就能跑起来，运维成本很低。等规模大了再逐步加入日志（Loki）和链路追踪（Tempo）。

告警收敛到底怎么做？

核心是三层抑制：① 依赖抑制——下层挂了自动屏蔽上层告警（如 DB 挂了就不报 API 延迟）；② 分组聚合——同样告警 5 分钟内只发一条，而不是每 15 秒刷一次；③ 静默窗口——已知的维护窗口自动静默。Alertmanager 的 inhibit_rules + group_by + time_intervals 可以实现这三层。

SLO 和传统监控指标有什么区别？

传统监控看"这台机器怎么了"（CPU 高、磁盘满），SLO 看"用户体感怎么样"（API 响应时间 99% ≤ 200ms）。前者是基础设施视角，后者是用户视角。建议先做 SLO——定义 3-5 个用户可见的指标（API 可用率、响应时间、错误率），用这些 SLO 决定告警优先级，而不是盯着 CPU 告警修机器。

收到告警后第一件事应该做什么？

先确认告警的真实性和影响范围——不要直接开始修。标准流程：① 查看对应仪表盘（Grafana Dashboard），确认指标确实异常 ② 判断影响范围（多少个用户 / 服务受影响） ③ 评估紧急程度（P0 立刻响应 / P1 30 分钟内 / P2 工作日处理） ④ 根据 Runbook 执行操作。这个流程应该写成文档，每次告警都是演练。

监控告警体系设计：从指标采集到告警收敛的完整链路

监控告警最典型的困境是"要么被告警淹没，要么关键告警被噪声淹没"。本文从 Prometheus + Grafana 这一标准组合出发，梳理监控体系的四层架构：采集层 → 聚合存储层 → 可视化层 → 告警收敛层，重点解决告警风暴和疲劳问题。

先说结论：先建 SLO，再搭监控，最后配告警

监控体系最常犯的错误是倒过来做——先搭了一堆指标采集，配了一堆告警规则，然后发现每天收到几百条告警，真正需要关注的反而被淹没了。

正确的顺序：

定义 SLO（Service Level Objective）——用户可见的关键指标和阈值
搭采集合存储——采集需要的指标，不多采
搭可视化——让 SLO 一目了然
配告警收敛——只有 SLO 违反才告警，且做好噪声抑制

一、SLO 先行：你应该告警的信号

不是所有异常都值得告警。只对「用户能感知的异常」告警。

不需要告警的信号（做成 Grafana 看板即可）

指标	为什么不告警
CPU 使用率 > 80%	不是用户能感知的问题，做好扩容水位监控即可
磁盘使用率 > 85%	日常运维项，写定时脚本清理或自动扩容
单次 5xx	看错误率而不是绝对值，1/10000 的 5xx 在正常范围内
单个 Pod 重启	看重启频率，偶发重启不影响整体可用性

二、采集层：Prometheus + Exporters

架构图

应用服务（/metrics）──→ Prometheus Server ──→ Grafana
Node Exporter        ──→ Prometheus Server ──→ Alertmanager
PostgreSQL Exporter  ──→ Prometheus Server     ↓
                                           通知（钉钉/邮件/企业微信）

关键配置示例

# prometheus.yml
global:
  scrape_interval: 15s       # 采集间隔
  evaluation_interval: 15s   # 规则评估间隔

rule_files:
  - 'alerts/*.yml'           # 告警规则

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']   # Node Exporter

  - job_name: 'app'
    static_configs:
      - targets: ['localhost:3000']   # 应用 /metrics 端点

原则：采集间隔不要短于 15 秒。 更短的间隔除了增加存储成本和网络压力，对你的告警精度几乎没有任何帮助。

三、告警收敛：Alertmanager 三层抑制

第一层：依赖抑制

# alertmanager.yml
inhibit_rules:
  - source_match:            # 当 DB 不可用
      severity: 'critical'
      alertname: 'InstanceDown'
    target_match:            # 抑制所有依赖 DB 的服务告警
      severity: 'warning'
    equal: ['instance']

  - source_match:
      alertname: 'PostgresDown'
    target_match:
      alertname: 'APIHighLatency'   # DB 挂了，API 延迟高是必然的
    equal: ['cluster']

第二层：分组聚合

route:
  group_by: ['alertname', 'severity']   # 按告警名+级别分组
  group_wait: 30s           # 同类告警等待 30s，聚合成一条发
  group_interval: 5m        # 已聚合的组，每 5 分钟重发一次
  repeat_interval: 4h       # 确认的告警每 4 小时重发一次

第三层：静默窗口

time_intervals:
  - name: 'business_hours'
    time_intervals:
      - weekdays: ['monday:friday']
        times:
          - start_time: '09:00'
            end_time: '19:00'

四、Grafana 看板设计原则

一个好的 Grafana 看板遵循”三秒法则”——运维人员打开看板后 3 秒内能判断系统是否健康。

看板布局

┌─────────────────────────────────────┐
│ 行 1：SLO 概览（红/黄/绿大数字）      │
│  API 可用率 │ P99 延迟 │ 错误率      │
├─────────────────────────────────────┤
│ 行 2：核心服务状态（各服务小卡片）     │
│  auth │ orders │ payment │ notify    │
├─────────────────────────────────────┤
│ 行 3-4：详细指标（按需展开）          │
│  CPU/内存/磁盘/网络 │ SQL 慢查询     │
└─────────────────────────────────────┘

只看红色：如果 SLO 概览行全是绿色，说明系统健康，不需要往下看。这是看板设计最容易被忽视的原则。

五、推荐工具组合（按团队规模）

规模	推荐方案	月运营成本
个人/小团队	Prometheus + Grafana + Alertmanager	一台 2C4G 服务器
中型团队	+ Loki（日志）+ Tempo（追踪）	2-3 台服务器
大规模	VictoriaMetrics + Grafana OnCall + PagerDuty	取决于数据量

检查清单

上线前：

SLO 已定义且团队达成共识（不超过 5 个指标）
关键服务已暴露 /metrics 端点
Prometheus 目标可达，scrape 成功
告警规则已配置依赖抑制（防止告警风暴）
Runbook 已写完——收到告警后第一步做什么
Grafana 看板满足”三秒法则”

日常运维：

每周检查 Grafana 看板（5 分钟即可）
每月 review 告警规则——去掉不必要的告警
每季度做一次告警演练（模拟 P0 故障，验证响应流程）