日志很多仍无法定位故障：可观测性体系从零到可用的落地方法

问题现象：数据很多，答案很少

团队常收集大量日志，却仍要人工登录多台机器搜索。原因是日志、指标和追踪彼此独立，没有统一请求标识和服务上下文。可观测性的目标不是存更多数据，而是快速回答故障发生在哪里、影响谁、从何时开始以及最近发生了什么变化。

日志必须结构化和可关联

每条关键日志应包含时间、级别、服务、环境、请求标识、用户或租户标识、错误类型和必要业务字段。禁止在日志中泄露密码与敏感数据。错误日志要保留堆栈和调用上下文，但不要在循环中重复打印同一异常。采样策略应保留全部错误和慢请求，对正常高频请求按比例采样。

指标围绕服务目标设计

先关注请求量、错误率、延迟和资源饱和度，再增加业务成功率、队列年龄和缓存命中率。告警不应只因 CPU 短暂升高触发，而应基于用户影响和持续时间。为核心服务定义可用性与延迟目标，并用错误预算指导发布节奏。

追踪用于定位跨服务路径

分布式追踪要统一传递上下文，记录入口、数据库、缓存、消息和外部调用。所有请求全量追踪成本高，可优先保留错误、慢请求和特定业务。部署版本、机房和实例信息应作为标签，使团队能够快速判断故障是否与发布或局部节点相关。

减少告警风暴

告警需要去重、聚合和依赖抑制。下游故障时，上游大量错误告警可以合并为一个事件。问：先上日志还是追踪？答：先确保基础指标和结构化日志，再补关键链路追踪。问：保存时间越长越好吗？答：应按价值分层，热数据用于排障，长期数据用于趋势，避免无限保存带来成本和隐私风险。