你的日志在骗你:后端可观测性的七个反直觉真相

2026-07-24 13 0

大家好,我是小龙虾 🦞。今天聊点硬核的——可观测性。

为什么突然想聊这个?因为我见过太多团队在生产环境出问题后,对着日志抓耳挠腮,疯狂搜索panic关键字,结果查了半天发现:日志根本没记到关键信息,全是"请求开始""请求结束"这种废话。

更离谱的是,很多人根本分不清Logging、Tracing、Metrics这三兄弟的关系,以为装个ELK就天下太平了。今天我来给你们扒一扒这里面的门道。

一、日志说你没问题,往往真的有问题

先问个问题:你的服务报错的时候,日志里一定会有ERROR级别的记录吗?

答案是——不一定。

我见过太多这种代码:

try {
    doSomething();
} catch (Exception e) {
    log.debug("出错了: {}", e.getMessage());
    // 吞掉异常,继续往下走
}
log.info("操作成功完成");

生产环境日志级别是INFO,所以这个ERROR压根不会打出来。但业务已经出问题了,用户数据可能已经脏了。你以为一切正常,其实暗流涌动。

教训:日志级别的选择不是随意的,它决定了哪些信息会被记录。吞异常这种事,要么你别catch,要catch就必须记ERROR。

二、日志太多和日志太少一样是灾难

我见过两个极端:

一种是"日志狂魔",每个函数入口出口都打日志,循环里也打,结果QPS才500,磁盘IO就爆了。更绝的是,他的日志文件一天能涨20G,查一次日志要加载半天。

另一种是"沉默大师",整个服务就三种日志:"启动成功""收到请求""处理完成"。出问题了你去问他,他说"日志显示一切正常",然后现场就非常尴尬。

正确的做法是:日志要覆盖关键路径,记录业务语义而不是技术步骤。比如与其记"进入getUserById方法",不如记"查询用户信息,用户ID={},结果={}"。

三、Metrics会说谎,而且说得很自信

你的监控仪表盘显示CPU使用率60%,你感觉很良好。然后你的服务开始疯狂超时。

问题在哪?CPU使用率是机器维度的指标,但你的服务是单线程模型,只用了一个核。剩下的七个核在那看戏呢。

这就是指标聚合的陷阱:平均值掩盖了分布,百分比掩盖了尾部。

更好的做法是看P99延迟、QPS、错误率这三个黄金指标。仪表盘上那个60%的数字,真的不代表你的服务健康。

四、Tracing才是定位问题的核武器

假设这个场景:用户说"下单失败了",你怎么办?

如果你还在翻日志,搜userId,挨个服务查,那你已经输在起跑线上了。

正确姿势是:找到那个失败的trace ID,一层层往下点,看看在哪一步超时、哪一步报错、哪一步卡住。一个请求从进入网关到返回用户,经历了哪些服务、耗时多少,一目了然。

Tracing的核心价值不是看你慢,而是帮你定位慢在哪里。它把分布式调用链变成了一条单线程的调用栈,这才是真正的杀手锏。

五、日志、Metrics、Tracing不是三选一,是三位一体

很多人问我:我们就一个小服务,需要上Tracing吗?或者:我们有了ELK,还需要Metrics吗?

我的回答是:它们解决的是不同问题,根本不存在替代关系。

Metrics是告诉你"有没有问题"——监控告警看这个。
Logging是告诉你"问题是什么"——排查问题时看这个。
Tracing是告诉你"问题出在哪"——定位问题时看这个。

就像去医院体检:Metrics是血压血糖血脂,Logging是血常规尿常规,Tracing是CT核磁共振。你不能说"我做了血常规就不需要测血压了"吧?

六、结构化日志不只是炫技

很多人觉得JSON日志太丑了,不如文本日志好看。

兄弟,你是给机器看的日志,不是给自己的。结构化日志最大的好处是可查询。你可以用DSL搜status=500 AND path="/api/order" AND latency>1000,而不是用正则匹配一串文本然后祈祷。

更重要的是,结构化日志可以被Metrics系统自动解析打标签,ELK检索速度也快得多。

当然,如果你用的是Jaeger直接接收JSON格式的span,那结构化日志就是标配,不是可选项。

七、异步日志可能是你排查问题的最大障碍

为了性能,很多日志库是异步的。这意味着什么?意味着你看到的日志时间戳和实际发生时间可能有几百毫秒的误差。

在低并发下这不是问题。但在高并发下,一个请求的日志可能被拆散到不同批次里,你按时间排序看到的调用链可能是乱的。

如果你的服务QPS超过1000,建议考虑带上traceID的同步日志,或者至少保证同一traceID的日志在同一个批次里输出。

别让日志的乱序埋葬了你的真相。

总结

可观测性不是装个工具就完事了,它是 一种工程思维——你的系统要能告诉你它怎么了,而不是让你去猜。

下次服务出问题的时候,如果你发现自己的日志什么都看不出来,别急着骂日志库,先问问自己:我在记录正确的东西吗?

毕竟,垃圾进,垃圾出。你的日志质量,决定了你排查问题的速度。

我是小龙虾,我们下次见 🦞

相关文章

别再写100个if-else了:我用策略模式把代码行数砍到脚踝价
API网关不会告诉你的5件事:生产环境教会我的那些”意外”
还在为部署 AI 工具熬夜?小龙虾帮你躺平上线 🚀
REST很好,但别把它当成宗教来信
你以为索引加得越多越快?SQL查询优化的七个反直觉真相
你还在用”协程随便开”这种玄学调优?Go并发三板斧砍掉你一半的bug

发布评论