监控、日志与告警

监控的目标不是「装一堆看板」，而是在故障发生前发现异常、发生时快速定位、发生后复盘改进。本页讲体系怎么搭、指标怎么选、告警怎么不「狼来了」。示例语境：Prometheus + Grafana + Loki/ELK，组件命令需在真实环境验证。

可观测性三支柱与黄金信号

支柱	回答	工具形态
Metrics 指标	系统现在是否异常（数值化、聚合）	Prometheus、CloudWatch
Logs 日志	为什么异常（逐条记录、可检索）	ELK、Loki
Traces 链路	请求在哪里慢/失败（跨服务时序）	Jaeger、Tempo、Zipkin

四个黄金信号（Google SRE 书）建议至少覆盖三个：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。对应到方法：容器/服务用 RED（Rate 请求率 / Errors 错误 / Duration 延迟），基础设施用 USE（Utilization 利用率 / Saturation 饱和度 / Errors 错误）。

分层监控：从下到上，别只盯一层

基础设施：CPU、内存、磁盘、网络、节点存活（node_exporter）；
容器与编排：Pod 状态、重启次数、资源用量、HPA 扩缩（kube-state-metrics + cAdvisor）；
应用：RED 三指标 + 业务指标（下单量、支付成功率）——业务指标才是最终裁判；
依赖：数据库、消息队列、外部 API 的健康与延迟。

常见误区：只盯基础设施，业务已经挂了看板还是绿的——把「用户能完成的业务动作」作为顶层指标。

Prometheus：拉取式指标体系

Prometheus 是**拉取（pull）**模型：定期按配置抓取目标暴露的 /metrics；应用侧通过 SDK 暴露指标（counter/gauge/histogram/summary 四种类型），服务发现决定「抓谁」。

yaml

# prometheus.yml（片段）
scrape_configs:
  - job_name: 'api'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: api
        action: keep

yaml

# 告警规则片段：错误率 5 分钟高于 1%
- alert: ApiHighErrorRate
  expr: |
    sum(rate(http_requests_total{code=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])) > 0.01
  for: 5m            # 持续 5 分钟才触发，防毛刺
  labels:
    severity: page
  annotations:
    summary: '{{ $labels.job }} 错误率过高'

for 字段能滤掉瞬时抖动，避免「狼来了」；
Alertmanager 负责路由与发送（邮件/IM/电话），支持分组、抑制与静默——同类告警合并成一条，别一个实例刷一屏。

日志：采集、集中、检索

容器日志默认 stdout，由采集器（Fluent Bit / Filebeat）打标签后送集中端：ELK（Elasticsearch 检索 + Kibana）或 Loki（便宜、与 Grafana 一体、按标签索引而非全文）；
结构化日志（JSON）优于一行行拼字符串：字段可直接检索与聚合，别把信息塞进 message 里靠人眼；
日志要分层保留：热数据短保留高可用，冷数据归档满足审计；敏感信息（密码、token、身份证）脱敏后再落盘，日志是数据泄露高发口。

告警设计：SLO 比「拍脑袋阈值」可靠

SLI：可量化的指标（如「可用请求占比」）；SLO：目标值（如「月度可用性 ≥ 99.9%」）；
告警应问「用户会不会受影响、要不要现在处理」：error budget（SLO 允许的故障额度）耗尽前提醒，比「CPU>80% 就报警」更有业务意义；
每条告警配 runbook：什么现象 → 先看什么面板/日志 → 常见处理步骤 → 升级路径。没有 runbook 的告警会变成半夜接电话后瞎猜；
分三级：page（立即处理，真故障）/ ticket（工作时间内处理）/ info（只记录）。一级告警越少越可信。

事故管理与复盘

事故分级（SEV 1-4）事先定义：影响范围 + 是否涉及资金/数据 + 用户可见度，别临时拍；
复盘会只问系统和流程问题，不追责个人：时间线 → 影响范围 → 根因 → 缓解动作 → 改进项（每项要有负责人与截止日）；
复盘产出要落成可执行改进（补监控、加测试、改发布门禁），不是「记一笔」——指标：同一类事故不再重复发生。

常见坑速查

坑	现象	解法
只监控基础设施	业务挂了看板是绿的	加应用层 RED 与业务指标
告警轰炸	值班脱敏/忽略真告警	`for` 去毛刺、合并同类、分级 review
阈值拍脑袋	该报不报、不该报狂报	围绕 SLO/error budget 设计
指标没留存	事故复盘无数据	长周期存储（如 Thanos）保历史
日志含敏感信息	泄露 + 合规风险	落盘前脱敏、访问审计
没有 runbook	半夜值班瞎查	每条告警配处理手册
复盘会追责	大家隐瞒真实原因	只问系统与流程，改进项闭环
单点监控组件	监控自己先挂了	监控组件高可用 + 外部拨测兜底

检查清单

[ ] 有从基础设施到业务的完整指标分层，关键业务动作有顶层指标；
[ ] 告警围绕 SLO 设计并分级，每条都有 runbook，无明显「狼来了」；
[ ] 日志结构化、标签化，敏感信息脱敏，保留策略与审计要求一致；
[ ] 关键链路（网关→服务→存储）有 trace 串联可定位；
[ ] 事故分级、复盘流程落地，改进项闭环并追踪；
[ ] 监控体系自身具备高可用，并有外部拨测兜底验证。

监控、日志与告警 ​

可观测性三支柱与黄金信号 ​

分层监控：从下到上，别只盯一层 ​

Prometheus：拉取式指标体系 ​

日志：采集、集中、检索 ​

告警设计：SLO 比「拍脑袋阈值」可靠 ​

事故管理与复盘 ​

常见坑速查 ​

检查清单 ​