后端项目面试里，很多人被问线上排查时会说“看日志”。这句话太轻了。真实系统里，日志只是可观测性的一部分。一个请求从网关进入，经过应用、缓存、数据库、消息队列和外部服务，任何一段慢了或错了，都需要证据把链路串起来。
可观测性的核心不是记录更多文字，而是让系统在出问题时能回答三个问题：哪里出问题，影响多大，为什么发生。
日志要能串起一次请求
日志最基本的要求，是同一次请求有统一的 traceId 或 requestId。没有这个标识，日志再多也只是碎片。用户说某个操作失败时，你应该能从入口日志找到请求，再一路看到调用了哪些服务、查了哪些下游、在哪一步返回了错误。
日志内容也要有层次。入口日志记录用户、接口、参数摘要和耗时；业务日志记录关键状态变化；错误日志记录异常类型、错误码和上下文。不要把完整敏感参数都打出来，也不要只打印一个“失败了”。
指标告诉你影响范围
日志适合看单个请求，指标适合看整体趋势。接口 QPS、错误率、响应时间、下游耗时、线程池队列、连接池使用率、缓存命中率，这些指标能帮助你判断是单点问题还是系统性问题。
比如用户反馈慢，如果 P99 延迟升高但平均值没变，说明少量请求被拖慢；如果错误率突然上升，可能是下游或发布引入问题；如果连接池等待数上升，方向就应该转向数据库或 HTTP 客户端资源。
链路追踪让排查少靠猜
分布式系统里，一个接口慢可能不是当前服务慢，而是下游慢、重试多、序列化慢或网关排队。链路追踪的价值，是把每一段调用耗时拆开。你能看到请求在服务 A 花了 20 毫秒，在服务 B 花了 800 毫秒，在数据库花了 600 毫秒。
面试里可以说：我不会只看单服务日志，而会结合链路耗时、错误率和下游状态判断瓶颈。如果没有链路追踪，也至少要在关键边界打分段耗时日志，先把猜测变成证据。
告警要有行动意义
告警太少会漏问题，太多会没人看。一个有用的告警应该能指向行动：哪个接口、哪个依赖、哪个指标异常，影响持续多久，是否需要降级或回滚。单纯“CPU 高”不一定有用，结合接口错误率和线程状态才更有判断价值。
可观测性答得好，不是因为你会报很多工具名，而是因为你知道每类证据解决什么问题。日志定位个体，指标判断范围，链路追踪拆分路径，告警推动行动。面试官听到这里，会更容易相信你处理过真实线上问题。
还有一个面试里很容易加分的点：可观测性要和业务标识结合。只知道某个接口 500 次失败没有太大意义，如果能继续知道失败集中在哪个租户、哪个业务类型、哪个下游渠道，排查就会快很多。但业务标识也不能随便打全量敏感数据，通常只保存 ID、类型、状态和必要摘要。
真正成熟的系统会在设计接口时就考虑观测字段，而不是线上出问题后再补日志。因为故障发生时，过去没有记录的证据已经拿不回来了。