拓冰建站拓冰建站
首页 / 资讯中心 / 正文

日志与监控:后端排查问题的两大关键工具

日志与监控听起来像是后端工程师最基础的工具但越是基础的东西越容易在关键时刻掉链子。我见过太多团队线上出了问题第一反应是打开日志文件对着几十个G的文本用grep反复搜搜不到就抓瞎另一类团队则盯着监控面板看着满屏的红点却不知道从哪下手。说白了日志和监控不是拿来“看”的而是拿来“问”的。如果你不知道怎么向它们提问它们就只是两堆数据垃圾。很多人把日志和监控混为一谈觉得都是记录系统状态的东西。可实际上日志是“事后解剖”的工具而监控是“事前预警”的哨兵。日志告诉你刚才发生了什么监控告诉你现在正在发生什么。排查问题的时候你几乎总是先被监控吵醒然后顺着日志的线索去定位根因。这两者不是上下游的关系而是两套完全不同的思维模式——日志面向细节监控面向趋势。先聊聊日志。日志的本质是什么是事件流。每一次请求、每一次数据库调用、每一次缓存击穿都在日志里留下痕迹。但很多人对日志有个致命误解觉得只要日志够多就一定能找到线索。于是他们把所有的东西都打出来接口入参、出参、SQL语句、中间件告警全塞进同一个文件。结果呢等真要排查问题时打开一个日志文件里面全是噪音。日志的颗粒度如果不对记录得越多掩盖真相的能力越强。我记得有个项目线上偶发超时排查了一个星期都没头绪。后来我们把日志级别从INFO调成DEBUG才发现是某个第三方服务的连接池被耗尽而连接池的监控指标根本没人看。问题其实一直都没有藏起来只是日志打得不够细监控维度不够全导致谁也看不见。这件事给我的教训是日志不是给机器写的而是给未来的自己写的。如果你觉得某条日志“现在没用”那就别打。十年后你会在凌晨三点感谢自己当初的克制。那怎么定义一条“有用”的日志标准很简单它能独立回答“发生了什么、影响范围多大、怎么复现”。比如一个支付回调失败好的日志应该包含回调来源IP、请求头、原始报文、解析后的关键字段、失败原因、当前重试次数以及一个全局唯一的traceId。缺了任何一项这条日志就只是半条日志。半条日志比没有日志更可怕因为它会给你一种“我在查”的错觉却把你引向更深的深渊。可现实是很多团队连半条日志都保证不了。微服务架构下一个请求经过四五个服务每个服务往自己的日志文件里写没有串联标记排查问题全靠肉眼匹配时间戳。这时候你需要的其实不叫日志叫“罪案现场”。没有traceId的微服务日志就像把一本推理小说的每一页撕下来随机发给十个人看然后问谁是凶手。所以现在但凡比较成熟的后端框架都会在入口生成一个traceId穿透到所有下游调用。你如果还没这么做建议把这条当成接下来三个月最重要的技术债。说完日志再来看监控。监控的本质是“测量”。它测量的对象很广CPU、内存、QPS、延迟、错误率、队列积压量、GC暂停时间……但测量本身不是目的测量是为了回答一个问题当前系统的行为偏离了预期吗如果你连“预期”都没定义清楚监控就只是画一堆漂亮的曲线图每次开会时拿出来当背景板。我见过很多团队给监控设定告警阈值时拍脑袋比如“CPU使用率超过80%就报警”结果生产环境每天白天都要响几十次晚上又安静得像坟墓。这种告警的本质是狼来了——第一天大家还看两眼第二个星期就点了免打扰真正出事时反而误了窗口期。告警的粒度设计得比监控本身更需要智慧。一个成熟的告警策略应当是“减少噪音保留余音”宁可错杀一两次也绝不能让每个人都对报警信息麻木。另外监控指标之间存在因果关系但很多人只看单一指标。比如一个服务QPS突然下降可能不是服务本身变慢而是上游调用方在降级。如果你只盯着这个服务的监控就会发现CPU、内存都正常日志里也没有报错像极了“灵异事件”。监控真正的威力来自于交叉视图而不是单张仪表盘。把请求量、成功率、响应时间放在同一张图上你会看到它们之间隐藏的关联——比如响应时间涨起来的前三秒GC曲线突然拉高。那是JVM在帮你说话只不过你没听懂。可即便你日志打得规范监控指标也全面依然可能出现一个很尴尬的局面系统每天都在报小错但业务没受影响你正想优化又担心改动风险太大。于是这些“小错”就像鞋里的沙子一直磨着你的精力。这时候你需要的不是更好的工具而是“分级意识”。日志和监控要解决的问题不是把所有异常都消灭而是把所有异常都归类。比如你可以把异常分成三类等级一业务已兜底无需人工介入等级二需要看一眼但不用立即处理等级三必须马上处理否则钱和口碑都会流失。对不同等级分配不同的日志记录量、不同的监控告警渠道。高等级用声音和电话低等级用邮件和工单。这样你的注意力才能集中在真正值得的地方。在实际排查问题的过程中日志和监控还扮演着另一种角色它们在构建一种“现场感觉”。很多后端工程师调了好几年BUG其实没有感觉。看到一个报错脑子里没有任何画面不知道这个异常是从哪一层抛出来的也不知道它会往哪些方向扩散。这就是缺乏“现场感”。而每天花一点时间读日志、看监控曲线就是在培养这种直觉。你不可能靠搜索解决所有问题但你一定可以靠熟悉感最快地定位问题。我从工作第三年开始每天上班第一件事不是看邮件而是打开监控面板把主要服务的核心指标看一遍。这个东西坚持几年效果非常明显哪个服务今天比昨天慢了十毫秒哪个队列积压量总在午休时抬升你会像熟悉自己队友的习惯一样熟悉这些数字。等真正出故障时你不用比谁都先慌你甚至能在告警发出来之前就预感哪里不对。监控的最高境界是你不需要打开监控面板也知道它一定在说些什么。然而技术和工具始终是辅助排查问题真正的抓手始终是人。我见过一个团队用了最豪华的技术栈日志系统是ELK监控是Prometheus加Grafana告警走了PagerDuty可每次线上出问题依然是几个核心人员拉群每个人开着各自的终端连不上同一个上下文。原因很简单他们从来没约定过“什么才算一次完整的排查”也从没演练过“如果日志和监控互相矛盾我该信谁”。日志和监控互相矛盾的情况真的会发生。比如监控显示成功率百分之百日志里却有一堆超时异常。多数人第一反应是“监控出问题了”然后盯着监控调半天。但如果你冷静想想会意识到可能只是日志的记录点和监控的统计口径不一致——日志打的是入口的调用结果监控采集的是出口的流量采样。口径不统一会导致你在同一座山上看到完全不同的两幅风景而你永远不知道哪幅是真实的。所以现在很多团队都在推行“一次请求一个日志流水”把入口日志、业务日志、出口日志通过traceId串成完整链路与此同时监控系统要能基于同一条链路计算延迟和错误率。也就是说日志和监控正在从“两套体系”走向“一张视图”。真正的大规模系统从来不需要你人肉去关联日志和监控它需要的是把两者无缝缝合起来的可观测性平台。可观测性这个词这两年特别火。它不同于传统监控的地方在于监控告诉你哪个组件出问题了而可观测性告诉你系统内正在发生什么为什么正在发生。换句话说日志是事实监控是视图可观测性是故事。一个完整的故事需要时间线、人物关系和因果链。对应到系统里就是时间戳、traceId和异常传播路径。不过别指望一套平台买回来就能解决所有问题。日志和监控的价值70%靠的是你如何定义它们而不是它们能记录什么。这就像同一把手术刀在实习生手里和外科主任手里命运完全不同。我开始带团队之后每次做技术规划都要为日志和监控留出至少10%的工时。很多人觉得这是浪费时间可线上出了事故熬一个通宵查日志那才是真正的浪费时间。如果你问我什么才是后端排查问题的核心能力我会说是“否定的能力”。日志和监控的最大价值不是帮你找到原因而是帮你排除原因。系统报错了你一个个去看监控显示内存没有异常日志显示网络没有超时数据库连接池指标健康……到这一步你其实已经把问题缩小到了一个非常窄的范围内。懂得果断说“不是这个原因”的人比什么都能查的人更值得信赖。最后我想给刚入行的后端工程师一点建议不要盲目追逐那些炫酷的可观测性平台先把你手头的日志收集好监控指标定义好。能在十台机器上千行日志里找到问题用的是基本功能在一千个服务几万条调用链里找到问题才是平台的本事。但平台再好也只是延伸你的感官替代不了你的判断。工具改变速度思考决定方向。日志和监控是两把钥匙但需要它们打开的那扇门叫“对系统深刻的理解”。
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门