一个可观测后端的最小实现：日志、指标与追踪怎么取舍

先问要回答什么问题

可观测性建设常见的误区是先买工具再想用途。更有效的顺序是先列出真实问题：接口变慢时怎么定位、错误率上升时怎么归因、容量不足时怎么提前发现。问题清单决定了记录什么数据。

对多数中小规模服务而言，结构化日志能回答其中大部分问题，成本也低。把请求标识、用户标识、耗时、状态码、依赖调用结果写进同一行日志，排查时就能顺着一条链路看完整个请求。

指标用于发现，日志用于解释

指标的价值在于趋势与告警，采样成本低，适合长期保存。日志的价值在于细节，适合短期保存、按需检索。两者分工清楚，就不必把所有信息都塞进指标。

常见做法是给每个接口记录请求量、错误率与分位延迟，再给依赖调用单独记一组。分位延迟比平均值有用得多，平均值会把长尾掩盖掉。

追踪要解决上下文传递

分布式追踪的核心是把同一次请求的上下文带到每个服务。实现上通常依赖请求头传递标识，再在服务内部注入到日志与指标标签里。

落地时的难点是异步任务。消息队列消费、定时任务没有原始请求头，需要在消息体里携带标识，否则链路会在中间断掉。

从小处开始

一个可行的起步方案是：统一日志格式、加请求标识、给关键接口打点、给慢查询加埋点。这四件事做完，多数线上问题都能在十分钟内定位。

之后再考虑采样策略与长期存储。可观测性不是一次性工程，随着系统复杂度增长逐步补齐，比一开始铺得过大更容易维持。

一个具体的日志字段设计

建议至少包含：时间戳、请求标识、路由、方法、状态码、耗时、上游耗时、用户标识的哈希值、错误码。字段命名保持一致，便于聚合查询。

注意不要记录完整的请求体与身份信息。脱敏应该在写入日志之前完成，而不是在查询时处理。