从“收集日志”到
“发现信号”

很多可观测性建设的第一步，是把所有日志接进一个平台。几周之后，存储费用上来了，真正排障时却仍然要靠经验逐台查找。问题通常不在日志平台，而在于我们没有先定义“什么变化值得被看见”。

可观测性的目标不是收集更多数据，而是缩短从异常发生到做出正确判断的时间。

一、先从用户影响倒推

对在线服务来说，可以先回答三个朴素问题：请求是否成功、响应是否足够快、系统是否还有余量。它们分别对应错误率、延迟和饱和度。相比从 CPU、内存等机器指标开始，这组信号更接近用户真实体验。

接着为关键路径设定服务目标。例如，不说“延迟要低”，而说“过去 30 天内，99.9% 的读取请求在 300ms 内成功返回”。可量化的目标会自然带出需要观察的指标，也能避免告警阈值完全依赖直觉。

二、让三类数据各司其职

• 指标负责快速发现趋势：某个时间窗内发生了什么。
• 追踪负责定位链路：时间究竟花在了哪个环节。
• 日志负责补充上下文：当时的输入、状态和错误细节是什么。

不要要求任意一种数据解决全部问题。一个实用的串联方式，是给请求生成统一的 request_id，将它写入访问日志、应用日志和追踪上下文。告警从聚合指标触发，值班人员沿追踪找到异常节点，再用同一个标识检索必要日志。

三、只为“需要行动”而告警

告警是否有价值，可以用一个标准检验：收到它的人能否采取明确行动。单次错误、短暂 CPU 峰值和已自动恢复的抖动，通常更适合进入看板或事件记录，而不是半夜叫醒值班人员。

在小团队里，最小可行的告警集合往往只有几项：核心入口的成功率和高分位延迟、队列积压、数据库连接耗尽，以及证书或容量等确定会到期的资源。

四、把观测成本作为设计变量

高基数字段会放大指标成本，完整追踪会增加网络与存储压力，过量日志也可能带来敏感信息风险。比较稳妥的做法是：指标控制标签维度；追踪按错误、延迟和比例采样；日志默认结构化，并对敏感字段做白名单式保留。

最后，定期从真实故障复盘观测体系：哪些信号最早暴露问题，哪些数据从未被使用，哪一步判断耗时最长。删除无效数据与新增信号同样重要。