4. Linux 系统日志分析：核心日志解读

系统日志，说白了就是 Linux 的「黑匣子」。

服务器出问题，第一反应是什么？我个人的习惯是——先看日志。不看日志就动手排查，那叫瞎蒙。你想想看，网络断了、服务挂了、内核 panic 了，这些信息全都写在日志里。关键是你得知道去哪看，怎么看。

这一章，咱们就盯住三个最核心的日志文件：/var/log/messages、/var/log/secure 和 dmesg。把这几个吃透了，80% 的故障你都能找到线索。

4.1 /var/log/messages：系统通用日志

这是 Linux 系统里最「杂」的日志文件。几乎所有非内核、非安全认证的通用信息都会往这里写。包括系统启动信息、服务启停、网络接口状态变化、文件系统挂载等等。

一句话总结：不知道看哪个日志的时候，先看 messages 准没错。

4.1.1 典型内容长什么样？

用 tail 或者 less 打开，每一行大概长这样：

Feb 27 10:15:32 web01 systemd[1]: Starting Nginx web server...
Feb 27 10:15:33 web01 nginx[1234]: nginx started successfully
Feb 27 10:16:01 web01 dhclient[5678]: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Feb 27 10:16:01 web01 dhclient[5678]: DHCPACK from 192.168.1.1
Feb 27 10:16:02 web01 kernel: eth0: link up, 1000Mbps, full-duplex

格式很固定：时间戳 + 主机名 + 进程名[PID] + 消息内容。我刚开始做运维那会儿，经常盯着这玩意儿看半天，后来发现只要抓住「时间」和「进程名」这两个关键字段，排查效率能翻倍。

4.1.2 什么时候必须看它？

  • 服务启动失败：比如 Nginx 起不来，messages 里通常会告诉你为什么——端口被占、配置文件语法错误、依赖服务没启动。
  • 网络接口抖动：像上面例子里的 link up、link down 信息，就是网卡物理链路出问题的直接证据。
  • DHCP 获取 IP 异常：如果服务器拿不到 IP，messages 里会记录 DHCP 请求和响应的全过程。

我的一个小技巧：排查网络问题时，先用 grep -i "link\|dhcp\|network" /var/log/messages 过滤一下，能快速定位到网卡和 IP 相关的异常。

4.1.3 避坑指南

我曾经踩过一个坑：messages 日志默认会被 logrotate 轮转。如果你发现 messages 文件特别小，甚至只有几行，别慌——看看同目录下有没有 messages-20250227 或者 messages.1.gz 这样的历史文件。轮转后的日志通常保留 4 周，用 zless 或者 zgrep 去查压缩包里的内容。

4.2 /var/log/secure：安全审计日志

这个文件，我建议你把它当成「服务器的大门监控」。所有跟用户认证、权限切换、远程登录相关的事件，都会记录在这里。

说白了，谁在什么时候、从哪个 IP、用什么账号、登录成功了还是失败了，secure 日志里一清二楚。

4.2.1 典型内容长什么样？

Feb 27 09:00:01 web01 sshd[2345]: Accepted password for root from 192.168.1.100 port 22
Feb 27 09:05:23 web01 sshd[2346]: Failed password for invalid user admin from 10.0.0.50 port 22
Feb 27 09:05:24 web01 sshd[2347]: Failed password for root from 10.0.0.50 port 22
Feb 27 09:10:00 web01 sudo: root : TTY=pts/0 ; PWD=/root ; USER=nginx ; COMMAND=/bin/systemctl restart nginx

4.2.2 什么时候必须看它？

  • SSH 登录失败：密码输错了、密钥不对、被防火墙拦截了，secure 里都会给出具体原因。
  • 暴力破解检测：如果某个 IP 在短时间内出现大量 Failed password 记录，基本可以断定是在扫你的服务器。
  • 权限提升审计：谁用了 sudo、执行了什么命令，全都有记录。这在排查「谁乱改了配置」时特别好用。

实战经验：有一次客户说服务器被黑了，我第一件事就是查 secure 日志。结果发现某个弱口令账号被爆破成功，攻击者用那个账号登录后执行了挖矿程序。顺着 secure 里的 IP 和时间线，半小时就把入侵路径还原出来了。

4.2.3 快速分析命令

场景 命令
查看最近 10 条登录失败记录 tail -10 /var/log/secure | grep "Failed password"
统计暴力破解 IP 排行 grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr
查看所有 sudo 操作 grep "sudo" /var/log/secure

注意：如果 secure 日志里出现大量 Connection closed by authenticating user 的记录，别以为只是「连接关闭」这么简单。这往往是攻击者在尝试 SSH 握手阶段就断开了连接，用来绕过某些入侵检测系统。嗯，遇到这种情况，建议直接封掉源 IP。

4.3 dmesg：内核环缓冲区日志

dmesg 跟上面两个日志不太一样。它不是文件，而是内核环缓冲区的内容。说白了，就是内核自己记的「小本本」，专门记录硬件检测、驱动加载、文件系统挂载、内存错误等底层信息。

为什么单独讲它？因为很多网络故障的根因，其实出在硬件层面。比如网卡驱动崩溃、内存校验错误、磁盘 I/O 超时——这些在 messages 里可能只提一句，但在 dmesg 里会有详细的上下文。

4.3.1 典型内容长什么样？

[    0.000000] Linux version 5.10.0-28-amd64 (debian-kernel@lists.debian.org)
[    1.234567] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex
[    2.345678] EXT4-fs (sda1): mounted filesystem with ordered data mode
[ 1234.567890] e1000e 0000:02:00.0 eth0: Detected Hardware Unit Hang:
                 TDH <3c> TDT <3d> next_to_use <3d> next_to_clean <3c>
                 buffer_info: <3c> <3d>
[ 1234.567891] e1000e 0000:02:00.0 eth0: Reset adapter unexpectedly

4.3.2 什么时候必须看它？

  • 网卡频繁断连：如果 messages 里出现 link up / link down 反复切换，去 dmesg 里看看有没有 Hardware Unit Hang 或者 Reset adapter 的记录。有的话，基本可以判定是网卡硬件故障或者驱动 bug。
  • 服务器突然重启：dmesg 的最后几条记录会告诉你重启前发生了什么——可能是 Kernel panic，也可能是 Out of memory。
  • 新硬件不识别：插了张新网卡或者新硬盘，系统没认出来。用 dmesg | grep -i "error\|fail\|warn" 扫一遍，通常能找到原因。

我个人习惯：排查网络问题时，一定会先跑一遍 dmesg -T | grep -i "eth\|net\|link\|error"。-T 参数能把内核时间戳转换成人类可读的时间，方便跟 messages 日志对照。

4.3.3 跟 messages 的区别

对比项 dmesg /var/log/messages
信息来源 内核环缓冲区（内存） 系统日志服务（rsyslog）
记录范围 硬件、驱动、内核模块 服务、应用、网络、用户态
持久性 重启后清空 写入磁盘，持久保存
典型用途 排查硬件故障、内核崩溃 排查服务异常、网络配置

注意：dmesg 的内容在服务器重启后就会丢失。如果你怀疑是内核级别的故障，建议在重启前先用 dmesg > /root/dmesg_before_reboot.log 保存一份。我曾经因为没保存，重启后丢失了关键的内核 panic 信息，排查了整整两天才找到根因——嗯，吃一堑长一智。

4.4 三份日志的协同排查思路

实际工作中，很少只靠一份日志就能定位问题。我的排查流程通常是这样的：

  1. 先看 messages：了解故障发生的时间点、涉及的服务和进程。
  2. 再看 secure：确认是不是认证或权限问题导致的。
  3. 最后查 dmesg：如果前两步没找到明确原因，就去 dmesg 里挖硬件层面的线索。

举个例子：用户反馈网站打不开。messages 里看到 Nginx 在 10:30 报 connect() failed (111: Connection refused)，说明后端服务挂了。secure 里没有异常登录记录，排除人为破坏。dmesg 里发现 Out of memory: Kill process，原来是内存耗尽导致后端进程被 OOM killer 干掉了。你看，三份日志串起来，根因就浮出水面了。

日志协同排查流程 故障触发 第一步：messages 服务状态 / 网络事件 找到线索？ 是 第二步：secure 认证 / 权限审计 否 第三步：dmesg 硬件 / 内核 / 驱动 定位根因 → 修复验证 三份日志交叉验证 避免单一信息误判

4.5 本章小结

三份日志，各有侧重：

  • messages 是「全景图」，告诉你发生了什么。
  • secure 是「安检门」，告诉你谁进来了。
  • dmesg 是「体检报告」，告诉你硬件有没有毛病。

排查的时候，别只盯着一份看。交叉验证，才能避免被假象误导。嗯，记住一句话：日志不会骗人，但只看一半的日志会。

← 上一章 📖 返回目录 下一章 →