遇到bug如何抓取日志

凌晨两点，日志我盯着屏幕上那个红得刺眼的日志报错，心里只有一个念头：这bug到底干了啥？日志

日志就是案发现场。抓不到日志，日志你就是日志在对着空气破案。别急着改代码，日志先想清楚怎么把现场完整地搬出来。日志

最直接的日志办法——看控制台。本地调试时，日志F12打开开发者工具，日志Console和Network两个面板能告诉你八成真相。日志但线上环境呢？日志用户说“页面白屏了”，你总不能让他按F12吧。日志这时候你得主动埋点，日志把关键操作、日志接口返回、异常堆栈全部console.log出来，再通过前端监控工具（比如Sentry）自动上报。别偷懒，日志打得多，排查时你就少掉几根头发。

后端更麻烦。Java的logback、Python的logging、Node的winston——配置好日志级别，INFO、DEBUG、ERROR别一股脑全开，生产环境开INFO就够了，DEBUG刷屏会拖垮性能。关键业务节点必须打日志：参数进来了、数据库查到了、外部接口返回了、异常被捕获了，每个环节留个脚印。我见过太多人只在catch块里打日志，结果异常前的数据全丢了，那等于只看到尸体没看到作案过程。

有个细节容易被忽略：日志别光打错误信息，要把上下文带出来。比如“用户ID为12345的订单支付失败”，比“支付失败”有用一百倍。带上请求ID、用户ID、操作时间、具体参数——这些才是破案的关键线索。我们团队现在强制要求，所有日志必须包含traceId，一条请求从网关到数据库，全程串联起来，排查效率翻倍。

真遇到疑难杂症，日志文件可能不够用。线上系统挂了，你得实时看日志——tail -f 命令盯着滚动的输出，配合grep过滤关键字。但日志文件轮转了怎么办？logrotate配置好，保留最近7天的备份。更狠一点，直接把日志推到ELK（Elasticsearch + Logstash + Kibana），全链路搜索，几秒钟就能从几千万条记录里捞出一句话。别嫌搭这套东西麻烦，等你在几十个服务器上找一条报错时，就知道什么叫“悔不当初”。

还有一个土办法，但特别管用——复现。让用户重现操作步骤，你这边开着debug模式盯着日志输出。实在不行，临时在可疑代码段加几行System.out.println，跑完再删。虽然丑，但能救命。

最后说个真实案例。上个月我们线上订单系统偶发超时，错误率不到1%，根本抓不到规律。后来把日志级别临时调到DEBUG，专门加了接口耗时统计，跑了一天后发现，超时都发生在某个特定数据库连接池被占满的时候——原来是慢查询拖垮了连接。如果当时没打那几行耗时日志，这bug可能永远是个谜。

抓日志不是技术活，是习惯。养成“代码跑起来就顺手打日志”的习惯，比任何调试工具都管用。下次再遇到bug，先别慌，问自己一句：日志抓全了吗？

很赞哦!（7938）