遇到bug时如何抓取日志

程序崩了，何抓第一反应不该是取日打开搜索引擎。先去看日志。何抓90%的取日bug，日志里写得清清楚楚，何抓只是取日很多人不知道去哪找、怎么看。何抓

日志到底藏在哪

不同语言、取日不同框架，何抓日志位置完全不一样。取日没有万能路径，何抓但有几条通用线索。取日

Python应用，何抓如果用了logging模块，取日默认输出到stderr。何抓跑在终端里就直接打在屏幕上，跑在systemd里就进了journalctl。Django项目通常在项目根目录的logs/下，Flask看你怎么配，有人写文件有人只打控制台。

Java这边，Logback和Log4j2是主流。Spring Boot默认打控制台，但生产环境一般会配滚动文件，路径写在application.properties或者logback-spring.xml里。翻一下配置文件，搜“file”或者“fileNamePattern”就能找到。

Node.js更散。winston、pino、bunyan各有各的玩法。pino默认输出JSON到stdout，如果你用pm2托管，得先pm2 logs才看得到。Docker容器里的应用，日志被Docker接管了，得用docker logs <container_id>，或者去/var/lib/docker/containers/下面翻。

最坑的是K8s环境。Pod重启一次，之前的日志就没了。kubectl logs只能看到当前容器的输出，加--previous才能拿到上一个挂掉的实例的日志。这个参数很多人不知道，白白丢掉关键线索。

抓到日志之后看什么

日志文件动辄几百兆，从头翻到尾不现实。先定位时间窗口——bug是什么时候出现的，就聚焦那个时间段。grep加时间戳过滤，比肉眼扫快一百倍。

然后找异常栈。Java的堆栈从“Caused by”往下读，最底层那个往往是根因。Python的Traceback从最后一行往上看，最后一行是错误类型，往上是调用链。别被中间那些框架层的调用迷惑，直接跳到你自己写的代码那一帧。

有个真实案例。之前线上一个接口间歇性500，日志里全是ConnectionTimeoutException。看着像数据库连接池不够，但调大连接数没效果。后来仔细翻日志，发现每次超时前都有一条“GC pause”的警告。真正的问题是JVM内存分配不合理导致频繁Full GC，连接池只是背锅的。如果只看异常类型，永远找不到这个根因。

日志级别别乱设

生产环境开DEBUG，磁盘两天就满。开ERROR，又漏掉关键上下文。INFO是大多数场景的合理选择，但有些地方需要单独调。

比如支付回调、第三方接口调用，这些环节出问题概率高，值得单独开DEBUG。logback支持按包名设级别，Python的logging可以按logger名字控制。别一刀切，把最吵的那个模块压到WARN，把最关键的模块提到DEBUG。

还有个细节：日志里一定要带traceId。微服务架构下，一个请求穿过五六个服务，没有traceId根本串不起来。用MDC（Mapped Diagnostic Context）往每条日志里塞一个唯一标识，排查效率翻倍。这个投入十分钟就能搞定，但很多人等到出事了才想起来加。

实在没日志怎么办

有些老系统就是没打日志，或者日志被清掉了。这时候只能动态加。Java用Arthas的watch命令，可以在不重启的情况下观察方法入参和返回值。Python用py-spy dump看当前调用栈，或者pdb挂上去。Node.js用node --inspect配合Chrome DevTools。

这些手段是兜底的，别当成常规操作。最好的策略永远是：写代码的时候就把日志当回事。关键分支打日志，异常捕获打日志，外部调用打日志。多写几行logging.info，比出事后熬夜翻日志强得多。

日志不是给机器看的，是给人看的。写的时候想一下：三个月后的自己，凌晨两点看到这行输出，能不能立刻明白发生了什么。想不清楚，就重写。