3、核心日志文件解读：/var/log/messages、/var/log/syslog、/var/log/boot.log、dmesg
日志文件是系统的黑匣子。我干了这么多年运维，每次排查问题，第一反应就是去翻这几个文件。它们记录了系统从开机到运行的全过程，说白了就是系统的「病历本」。今天咱们就把这几个核心日志文件掰开揉碎了讲清楚。
3.1 /var/log/messages 与 /var/log/syslog：通用系统日志
这两个文件是大多数 Linux 发行版最核心的日志文件。它们记录了系统运行过程中的各种消息，包括内核信息、应用程序日志、服务状态变化等。
核心区别：
- /var/log/messages：Red Hat 系（RHEL、CentOS、Fedora）的通用日志文件
- /var/log/syslog：Debian 系（Ubuntu、Debian）的通用日志文件
我个人习惯，登录一台新服务器，第一件事就是先看看这两个文件的大小。如果发现某个文件已经几百兆甚至上 G，那就要小心了——要么是日志轮转没配好，要么是某个程序在疯狂刷日志。
我曾经遇到过一个案例，某台 Web 服务器突然响应变慢，查了半天发现 /var/log/messages 已经 2.3GB 了。为什么？因为有个 PHP 进程一直在报连接数据库超时，每秒钟刷几十条日志，把磁盘 IO 都吃满了。清理日志、修复数据库连接后，系统立刻恢复正常。
日志格式解读
一条典型的日志长这样：
Feb 15 14:23:45 web01 kernel: [12345.678901] Out of memory: Killed process 1234 (nginx)拆开来看：
| 字段 | 示例值 | 说明 |
|---|---|---|
| 时间戳 | Feb 15 14:23:45 | 日志产生的时间 |
| 主机名 | web01 | 产生日志的机器名 |
| 进程/服务 | kernel | 产生日志的进程或内核模块 |
| 消息内容 | Out of memory: Killed process 1234 (nginx) | 具体的日志信息 |
小技巧：用 tail -f /var/log/messages 可以实时监控日志输出。我排查线上问题时经常开两个终端，一个看日志，一个操作命令，效率很高。
3.2 /var/log/boot.log：系统启动日志
这个文件记录了系统从开机到登录提示符出现之间的所有信息。说白了，就是系统「起床」的过程记录。
为什么这个文件重要？你想想看，如果服务器重启后连不上 SSH 了，或者某个服务没自动启动，你该去哪查？/var/log/boot.log 就是第一站。
Starting Network Manager...
[ OK ] Started Network Manager.
Starting httpd...
[FAILED] Failed to start httpd.service: Unit not found.看到 [FAILED] 了吗？这就是问题所在。我曾经帮一个同事排查问题，他的服务器重启后 Nginx 没起来，查了 boot.log 发现是配置文件里写错了路径，导致服务启动失败。修复后重启服务，问题解决。
注意：有些发行版（特别是使用 systemd 的现代系统）的启动日志可能分散在 journalctl 中。可以用 journalctl -b 查看本次启动的所有日志，效果类似。
3.3 dmesg：内核环缓冲区日志
dmesg 不是文件，而是一个命令。它读取的是内核环缓冲区（kernel ring buffer）中的消息。这些消息主要来自内核和硬件驱动，记录了系统启动过程中的硬件检测、驱动加载、设备识别等信息。
我个人觉得，dmesg 是排查硬件问题最直接的武器。比如：
- 新加的硬盘没识别？查 dmesg
- 网卡驱动报错？查 dmesg
- 内存条有问题？查 dmesg
举个例子，你插了一块新硬盘，但系统里看不到：
$ dmesg | grep -i sda
[ 2.345678] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks
[ 2.345679] sd 0:0:0:0: [sda] Write Protect is off
[ 2.345680] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2.345681] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled如果没看到类似输出，说明系统根本没识别到这块盘。这时候就该检查物理连接或者驱动了。
实用命令：
dmesg | tail -20：查看最近 20 条内核消息dmesg | grep -i error：快速定位错误信息dmesg -T：以人类可读的时间格式显示（部分系统支持）
3.4 四个日志文件的对比与选择
这四个日志来源各有侧重，我整理了一张表，方便你快速对照：
| 日志来源 | 主要记录内容 | 适用场景 | 查看方式 |
|---|---|---|---|
| /var/log/messages | 通用系统消息、应用日志 | 日常运维、服务异常排查 | cat / tail / less |
| /var/log/syslog | 同上（Debian 系） | Ubuntu/Debian 系统运维 | cat / tail / less |
| /var/log/boot.log | 系统启动过程 | 启动失败、服务未自动启动 | cat / less |
| dmesg | 内核与硬件消息 | 硬件故障、驱动问题、设备识别 | dmesg 命令 |
嗯，这里要注意一点：dmesg 的内容也会出现在 /var/log/messages 或 syslog 中，但 dmesg 更聚焦于内核层面，而且能看到更早的启动信息（因为 messages 可能会被日志轮转覆盖）。
3.5 核心日志文件知识体系
下面这张图帮你理清这几个日志文件的关系和定位：
3.6 实战：快速定位问题的日志分析流程
说了这么多理论，咱们来点实际的。假设现在服务器出问题了，你该怎么用这几个日志文件快速定位？
- 先看 dmesg：检查有没有硬件层面的错误，比如磁盘 I/O 错误、内存故障、网卡断开等。命令：
dmesg | grep -iE "error|fail|warn" - 再看 boot.log：如果是启动相关的问题，看看哪个服务启动失败了。命令：
grep -i "failed" /var/log/boot.log - 最后翻 messages/syslog：根据问题发生的时间段，用
grep或sed提取相关日志。命令：grep "Feb 15 14:2[0-9]" /var/log/messages
避坑指南：我曾经犯过一个错误——只看 messages 不看 dmesg。那次是磁盘阵列卡报错，messages 里只记录了「I/O error」，但 dmesg 里明确写了「SCSI disk timeout」。如果早看 dmesg，能省下半天排查时间。所以我的建议是：硬件问题先查 dmesg，软件问题先查 messages。
好了，这一章的内容就到这里。这几个日志文件是系统排障的基石，多翻翻、多看看，慢慢你就能从日志里读出系统的「心事」了。