监控、日志与可观测性
一、可观测性三支柱：指标、日志、追踪
可观测性依赖系统「吐出来」的数据来回答「发生了什么、为什么」。常见归纳为三支柱：指标（Metrics）——数值型、可聚合、随时间采样，如 QPS、延迟、错误率、CPU 使用率；适合看趋势、设阈值、做告警。日志（Logs）——离散事件与文本，带时间戳与上下文；适合排查「某次请求发生了什么」、错误堆栈与业务记录。追踪（Traces）——请求在多个服务/组件间的调用链，每个 span 有耗时与父子关系；适合分析延迟分布、定位慢在哪个环节。三者互补：指标发现「有问题」、日志和追踪帮助「找原因」。
二、监控指标与告警策略
监控要选对指标：黄金信号常包括延迟（请求耗时）、流量（QPS、连接数）、错误率、饱和度（CPU、内存、队列深度）。业务侧可加转化率、关键接口成功率等。告警策略要合理：设阈值（如 P99 延迟 > 500ms、错误率 > 1%）与持续时间（避免偶发毛刺就告警）；分级（P0 立即处理、P1 当日、P2 次日）；收敛与降噪（同一根因只告一次、夜间可合并或降级）；告警要有可执行动作（谁处理、怎么处理、文档或 runbook 链接）。避免告警疲劳：太多无效告警会导致真告警被忽略。
告警策略要点
- 阈值 + 持续时间，减少毛刺误报
- 分级（P0/P1/P2）与升级路径
- 收敛：同一根因合并、抑制重复
- 告警带 runbook 或处理指引，可执行
三、日志级别、聚合与检索
日志级别（如 DEBUG、INFO、WARN、ERROR）用于过滤与采样：生产通常只保留 INFO 及以上，或按采样率留 DEBUG；问题排查时可临时提高级别。聚合：日志集中到统一存储（如 ELK、Loki、云日志服务），便于跨节点检索。检索：按时间、级别、服务、关键词、TraceID 等查询；结构化日志（JSON、带固定字段）更易检索与统计。注意：日志量要控制，避免打爆存储；敏感信息脱敏、不写密码与完整卡号。
四、分布式追踪入门
在微服务或多组件架构下，一个请求会经过多个服务；分布式追踪为每次请求分配一个 TraceID，在各服务内记录 Span（操作名、开始/结束时间、父子关系），最终聚合成一条调用链。这样可以看到「请求从网关 → A 服务 → B 服务 → 数据库」的完整路径与各段耗时，快速定位「慢在 B 服务」或「某次调用超时」。常见实现有 OpenTelemetry、Jaeger、Zipkin；接入方式为在框架或中间件中注入 Trace 上下文并上报 Span。与日志结合：日志中带上 TraceID，告警或查日志时可通过 TraceID 跳到对应追踪视图。
五、On-call 与故障响应
On-call指轮流值班，在告警触发时第一时间响应：确认是否真实故障、按严重程度升级、按 runbook 处理或召集更多人。要点：值班表明确（谁何时 on-call）、告警能触达（电话、短信、值班工具）、有 runbook 与权限（常见故障的处理步骤、生产访问权限）、事后复盘（根因、改进项、文档更新）。故障响应流程可简化为：发现 → 确认 → 止损（回滚、限流、降级）→ 修复 → 恢复 → 复盘。把「谁在什么时候做了什么」记下来，便于改进与追责边界。
On-call 与故障响应要点
- 值班表清晰，告警能触达值班人
- Runbook 与权限就绪，常见问题有步骤可跟
- 故障流程：发现 → 确认 → 止损 → 修复 → 恢复 → 复盘
- 事后复盘写进文档，改进监控与预案
一句话： 可观测性三支柱：指标看趋势与告警、日志看事件与排查、追踪看调用链与延迟。告警要设阈值与持续时间、分级与收敛、带 runbook。日志分级、聚合与检索，敏感脱敏。分布式追踪用 TraceID 串起多服务 Span，定位慢点。On-call与故障响应：值班明确、告警触达、runbook 与复盘。
六、小结
可观测性三支柱：指标（趋势、告警）、日志（事件、排查）、追踪（调用链、延迟）。监控与告警：选对指标、设阈值与持续时间、分级与收敛、带 runbook。日志：级别、聚合、检索、敏感脱敏。分布式追踪：TraceID、Span、与日志关联。On-call：值班表、告警触达、runbook、故障流程与复盘。下一章讲发布策略与回滚，把蓝绿、金丝雀、功能开关与回滚预案说细。