Crash日志分析：系统日志、应用日志、dmesg与journalctl使用归纳总结
遇到Crash，第一件事是什么？别急着翻代码，先看日志。我个人习惯先打开三个终端窗口，一个tail应用日志，一个dmesg -w，一个journalctl -f。为什么要这么干？因为不同日志藏在不同地方，漏掉一个可能就要多花半天时间。
系统日志——操作系统自己的“日记本”
系统日志记录的是内核、服务、硬件相关的消息。在传统Linux系统中，它通常放在 /var/log/messages 或 /var/log/syslog。我用得最多的是 tail -f /var/log/syslog，实时看系统出了什么幺蛾子。
核心命令速查
# 查看最后50行
tail -n 50 /var/log/syslog
# 实时追踪
tail -f /var/log/messages
# 过滤关键字
grep 'oom\|error\|panic' /var/log/syslog
# 按时间范围查看
journalctl --since "10 min ago" | grep -i error我在项目里遇到过这种情况：某服务深夜挂了，系统日志里只留下一条 Out of memory: Killed process。没有系统日志，你压根不知道是OOM killer干的。这时候除了加内存，还能快速定位是哪个进程吃太多——grep -i "killed" /var/log/syslog 直接出答案。
应用日志——程序自己写的“运行日记”
应用日志是程序主动打出来的，位置随应用自己定。常见的套路有：
/var/log/<应用名>/目录下- 应用配置文件里指定的路径
- 直接输出到标准输出，被systemd捕获
嗯，这里要注意：很多新手上来就翻系统日志，其实Crash的第一现场往往在应用日志里。我建议先查应用自有日志，因为打印的内容最直接，报错堆栈都在里面。
提示：如果应用日志没打开，可以用 lsof | grep /var/log 看哪些进程在写日志文件，或者查 /proc/<pid>/fd/1 看标准输出。
dmesg——内核级别的“急诊单”
dmesg其实是内核环形缓冲区的输出，专门记录硬件异常、驱动错误、内存错误这类低级问题。说它像急诊单，是因为它记录的都是“生死攸关”的消息。
避坑指南：我曾经因为一个内存ECC错误导致服务器间歇性Crash，翻应用日志全是无关信息。后来 dmesg | grep -i error 发现大量 EDAC: CE error on DIMM2。更换内存后问题消失。所以，硬件类Crash一定要看dmesg。
常用组合：
# 只看最后20条
dmesg | tail -20
# 实时监控
dmesg -w
# 留日志文件
dmesg -T > /tmp/dmesg_$(date +%s).logjournalctl——统一的“日志搜索器”
systemd带来了journalctl，它把系统日志、应用日志（只要服务是systemd管理的）都整合到一个二进制日志系统里。说真的，我后来基本都用journalctl替代了传统的syslog，因为它检索真的方便。
journalctl高阶用法
| 场景 | 命令 |
|---|---|
| 查看某单元所有日志 | journalctl -u nginx.service -n 50 |
| 只看错误级别 | journalctl -p err -b -0 |
| 按时间区间筛选 | journalctl --since "2025-01-01 00:00:00" --until "2025-01-02 00:00:00" |
| 实时跟踪指定单元 | journalctl -fu myservice |
你想想看，以前查问题要同时开三个tail窗口，现在一条journalctl命令就能把系统和应用日志混在一起过滤。不过要注意，如果Crash导致系统重启，默认 -b -0 只显示当前启动的日志，要看上一次启动加 -b -1。
四类日志对比
下面这张表总结了我平时判断先看哪类日志的决策逻辑。
| 日志类型 | 典型路径/命令 | 主要用途 | 我什么时候看 |
|---|---|---|---|
| 系统日志 | /var/log/syslog, tail -f | 服务状态、安全事件、内核消息 | Crash无明确应用报错时 |
| 应用日志 | 应用自定义路径 | 程序运行细节、报错堆栈 | 第一优先，看应用自身的异常 |
| dmesg | dmesg -T | 硬件异常、驱动错误、OOM | 怀疑硬件问题或内存溢出时 |
| journalctl | journalctl -u xxx -n 50 | 统一检索，支持索引和时间轴 | 需要跨服务联合排查时 |
我的习惯：先 journalctl -p err -b -0 --no-pager 看当前启动所有错误级消息，如果没发现，再查应用日志和dmesg。这样五分钟内就能判断Crash大致范围。
总结一下：日志分析没有银弹，但有套路。我的经验是——应用日志优先，系统日志兜底，dmesg查硬件，journalctl做粘合剂。下次遇到Crash，按这个流程走，半小时内应该能锁定方向。