监控与可观测性

解决什么问题

当服务规模从单机扩展到多节点、多语言之后，排查故障往往要在日志、指标、链路三类数据之间来回切换：报警说 CPU 高，但不知道是哪个请求慢；日志里有异常堆栈，却无法定位是哪条链路触发的；仪表盘堆了几十个面板，却没有人说得清每个数字对应的 SLO。根因定位变成一场跨系统拼图游戏。

核心能力

这个技能围绕可观测性三大支柱给出可执行的实践清单：

• 链路追踪：基于 OpenTelemetry 初始化 SDK，自动为 HTTP、数据库、消息队列注入 instrumentation，并为关键业务操作补充自定义 span
• 指标采集：使用 Prometheus 暴露指标，标签设计遵循有界基数原则，避免把 user ID 这类高基数字段直接作为 label
• 结构化日志：输出 JSON 格式日志，支持敏感信息脱敏，替代字符串拼接的日志写法，并通过共享 trace ID 与链路数据关联
• 告警与仪表盘：在定义 SLO 之后再搭建告警规则和仪表盘，按服务展示 RED 指标（Rate、Errors、Duration），告警基于错误率与延迟分位数而非 CPU 这类症状

适用边界

技能内的检查清单（Checklist）适合作为接入后的验收标准，但它默认你已经选择了 OpenTelemetry + Prometheus 这一套技术栈。如果你使用 Jaeger 或 StatsD 等替代方案，清单中的具体配置需要相应替换。此外，告警规则和 SLO 的制定与业务目标紧密相关，技能提供的是原则而非现成的阈值数值。