Linux 日志排查：从一条报错到定位根因的日常思路

线上服务出问题时，日志往往是第一现场。很多人一上来就重启服务，结果问题暂时消失，根因却还在，下一次换个时间又会回来。本文分享一套日常可用的 Linux 日志排查思路：先定范围，再找证据，最后才动手改。

第一步：先确认三件事

看到报错不要急着翻日志，先问清楚：什么时候开始的？影响了哪些用户或接口？最近有没有发布、改配置、扩缩容？把这三点写下来，能避免在无关日志里浪费半小时。如果是刚发布后出问题，先对比变更内容；如果是凌晨定时出现，就要留意定时任务和日志轮转。

第二步：找对日志，而不是到处翻

系统服务优先看 journalctl，例如查看某个服务最近的日志并按时间过滤；传统服务则在 /var/log 下找对应的 messages、secure 或应用专属日志。应用自己的日志更重要：先确认日志级别、输出路径和轮转策略，再看有没有把关键信息打到标准输出却没有落盘。容器环境里，要区分宿主机日志、容器日志和应用日志，不要只看其中一层就下结论。

journalctl -u nginx --since "2026-11-01 05:00" --until "2026-11-01 06:00"
tail -n 200 /var/log/nginx/error.log
grep -n "ERROR" /var/log/app/app.log | tail -n 100

第三步：按时间线还原，而不是只看最后一行

报错的最后一行常常只是结果。正确做法是把故障时间点前后几分钟的日志拉出来，按时间排序，找出第一次异常。可以用 grep 过滤关键字，再用上下文参数看前后几行；也可以先用 tail 观察实时日志，确认问题是否还在复现。注意时区和时间格式不一致的问题：有的日志用 UTC，有的用本地时间，对不齐时间线就容易把两件无关的事拼成因果。

第四步：区分表象和根因

举个常见例子：应用日志报数据库连接失败，第一反应可能是数据库挂了，但往前翻可能发现磁盘满了，数据库无法写入；再往前看，可能是某个定时任务产生了大量临时文件。只重启应用，磁盘还是满的，问题很快会复发。再如连接池耗尽，表面是超时，根因可能是慢查询占住了连接，或者下游接口变慢导致连接迟迟不释放。这时要结合系统指标一起看：CPU、内存、磁盘、连接数和慢查询，日志给线索，指标给佐证。

一份可复用的排查清单

1. 确认故障时间、影响范围和最近变更；2. 找到对应服务的系统日志和应用日志；3. 按时间线定位第一次异常，而不是最后一次报错；4. 用关键词和上下文缩小范围，必要时实时跟随日志；5. 结合磁盘、内存、连接数等指标验证猜测；6. 修复后观察一段时间，确认异常不再出现；7. 把过程和结论记下来，下次同类问题可以直接复用。

结尾：好习惯比命令更重要

日志排查拼的不是谁记得的命令多，而是思路是否稳定：先定范围，再找证据，再验证，最后修复并复盘。平时可以把常用命令整理成自己的速查表，给关键服务加上日志级别说明和告警阈值，故障时就不用临时翻文档。把每一次排查都当成一次积累，日志就会从一堆看不懂的文字，变成定位问题最可靠的线索。