监控告诉你”坏了”，可观测性告诉你”为什么”
传统监控体系的核心逻辑是预设阈值——CPU 超过 80% 报警，接口延迟超过 500ms 报警。这套方法在单体应用时代行之有效，因为系统的故障模式是有限的、可枚举的。但在微服务架构下，一个请求可能经过十几个服务，故障的组合空间呈指数级增长，你无法为每种异常场景都预设一条告警规则。
可观测性的本质区别在于：它不要求你提前知道会出什么问题。通过高基数、高维度的遥测数据，你可以在事后对任意维度进行切片分析，定位那些从未预见过的故障模式。这不是工具的升级，而是认知方式的转变。
Metrics、Logs、Traces：三支柱的协同
业界常说的”可观测性三支柱”——指标、日志、链路追踪——并不是三个独立的系统，而是同一份遥测数据的三种视角。指标告诉你系统的宏观健康状况，链路追踪帮你定位具体哪个环节出了问题，日志则提供最细粒度的上下文信息。
OpenTelemetry 的出现让这三者的统一采集成为可能。我们在实践中发现，与其分别部署三套采集 Agent，不如统一使用 OTel Collector 作为遥测数据的网关。这样不仅降低了运维成本，更重要的是让 Trace ID 真正贯穿了指标和日志，实现了从告警到根因的一键下钻。
告警疲劳：可观测性建设中最容易被忽视的问题
很多团队投入大量精力建设了完善的监控大盘和告警规则，最终却发现 on-call 工程师每天收到上百条告警，真正有意义的不到 10%。告警疲劳是可观测性体系退化的最大杀手——当工程师开始习惯性忽略告警时，系统等于回到了”裸奔”状态。
治理告警疲劳需要建立告警的分级和收敛机制。我们的做法是将告警分为 P0 到 P3 四个等级，P0 和 P1 必须在 15 分钟内响应，P2 和 P3 则汇总为日报。同时引入告警聚合和抑制规则，确保同一根因只产生一条可操作的告警。可观测性的目标不是”看到更多”，而是”更快地看到关键信息”。
相关文章