监控可观测性实战

分布式系统可观测性缺失的代价

当服务拆分成多个进程或容器后，一次用户请求可能横跨 HTTP、数据库、消息队列等多个边界。如果没有统一的追踪、指标和日志关联，排障只能依靠猜测：CPU 飙高到底是哪个函数引起的？某个请求变慢是因为下游服务延迟还是自身代码问题？错误日志散落在各个文件里，无法与特定 trace 关联，导致定位根因像在迷宫里打转。更糟的是，等到监控告警才发现问题时，用户体验已经受损。

如何通过标准化埋点构建可观测性

该技能的核心思路是将可观测性拆成三个支柱——日志、指标和追踪，并用 OpenTelemetry 作为统一标准。关键步骤包括：

• 初始化 OpenTelemetry SDK：利用自动插桩（auto-instrumentation）覆盖常见的 HTTP 客户端/服务器、数据库驱动和消息中间件，无需手动修改业务代码即可获得基础 trace。
• 补充自定义 Span：自动插桩只能记录框架层面的调用，对于关键业务操作（例如“生成推荐列表”“扣减库存”），需要手动创建 Span，将业务逻辑的耗时和上下文嵌入追踪。
• 定义有界的指标标签：通过 Prometheus 或 OTel Metrics API 暴露 Request Rate、Error Rate、Duration 等 RED 指标。务必控制标签基数，例如不要将 user_id 直接作为标签，否则会导致指标爆炸；改用 user_type 或分桶方式。
• 结构化日志：输出 JSON 格式的日志，并用 trace_id 字段与追踪关联。所有敏感字段（密码、令牌、个人身份信息）在写入日志前必须脱敏，推荐使用结构化字段而非字符串拼接。
• 基于 SLO 的告警：在定义服务等级目标（例如 99.9% 请求延迟 < 200ms）后，再配置告警规则。告警应该基于错误率、延迟分位数等 SLO 指标，而不是直接对 CPU 使用率等 sympt​om 报警，避免被噪声淹没。
• 仪表盘与反模式清单：为每个服务创建 RED 仪表盘，同时给出常见反模式，例如：未关联日志与追踪、使用字符串插值写日志、无限制标签基数、缺失 SLO 就建仪表盘等，便于自查。

适用边界与注意点

该技能适用于采用微服务或 Serverless 架构的团队，且技术栈支持 OpenTelemetry（多数现代语言已支持）。需要注意：

• 自动插桩可能无法覆盖自定义的网络库或旧版驱动，需要手动补充。
• 标签基数必须在设计阶段就规划好，事后修改指标定义可能引发数据不一致。
• 日志脱敏规则需要与安全团队对齐，避免漏网之鱼。
• 如果服务规模很小（例如单实例应用），完整的 SLO 体系可能显得过度设计，可以先从结构化日志和基础指标开始。

通过以上方式，团队可以逐步构建起可关联、可回溯、可告警的可观测性体系，而不是单纯地堆砌监控工具。