3、Linux日志体系：系统日志、安全日志、内核日志
聊到Linux排障，日志就是我们的第一手现场证据。很多新手一上来就翻各种配置文件，其实我个人的习惯是——先看日志。日志不会骗人，它只会忠实地记录系统里发生了什么。
今天咱们就聚焦三个最核心的日志文件：/var/log/messages、/var/log/secure，还有内核日志dmesg。搞懂这三个，日常排查80%的问题你都能搞定。
3.1 系统日志：/var/log/messages
这个文件可以说是Linux的“万能日记本”。几乎所有非内核、非安全认证的通用系统消息，都会往这里写。比如服务启动失败、网络接口状态变化、磁盘挂载报错等等。
它的典型格式长这样：
Mar 15 10:23:45 webserver systemd[1]: Starting Nginx Web Server...
Mar 15 10:23:46 webserver nginx[1234]: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 15 10:23:46 webserver systemd[1]: nginx.service: Control process exited, code=exited status=1你看，时间、主机名、进程名、具体错误信息，一目了然。我曾经遇到一个线上Nginx反复重启的问题，查了半天配置没发现问题，最后就是在这个日志里看到“Address already in use”，才发现是另一个服务占用了80端口。
排查要点：
- 关注时间戳：先确认问题发生的时间段，缩小范围
- 关注进程名：比如sshd、nginx、crond，快速定位是哪个服务出问题
- 关注错误码：比如exit status 1、Permission denied，这些是核心线索
我的小技巧： 用 tail -f /var/log/messages 实时跟踪日志输出。当你复现问题时，新日志会立刻刷出来，比事后翻找高效得多。
3.2 安全日志：/var/log/secure
这个文件专门记录用户认证相关的信息。说白了，谁登录了系统、谁登录失败了、谁用了sudo，全记在这里。安全审计和入侵排查，第一个就要翻它。
看看常见的登录失败记录：
Mar 15 03:12:08 webserver sshd[2345]: Failed password for root from 192.168.1.100 port 54321 ssh2
Mar 15 03:12:10 webserver sshd[2345]: Failed password for root from 192.168.1.100 port 54322 ssh2
Mar 15 03:12:12 webserver sshd[2345]: Failed password for root from 192.168.1.100 port 54323 ssh2嗯，这里要注意。如果你看到短时间内大量“Failed password”记录，而且来自同一个IP，那基本可以断定有人在暴力破解你的SSH。我曾经接手过一个被攻陷的服务器，翻看/var/log/secure，发现攻击者连续尝试了三千多次密码，最后用弱口令登进去了。从那以后，我养成了一个习惯——所有服务器必须开启SSH密钥登录，禁用密码登录。
安全日志里还有一类重要记录：
Mar 15 09:00:01 webserver sudo: zhangsan : TTY=pts/0 ; PWD=/home/zhangsan ; USER=root ; COMMAND=/bin/systemctl restart nginx这条记录告诉你，用户zhangsan在什么时间、什么终端、用什么命令切换到了root权限。如果发现非授权用户执行了敏感命令，这就是铁证。
避坑指南： 我曾经遇到过日志被清空的情况。攻击者得手后第一件事就是清空/var/log/secure。所以建议把安全日志实时发送到远程日志服务器，或者用auditd做更细粒度的审计。本地日志不可全信。
3.3 内核日志：dmesg
dmesg和前面两个不一样。它不写文件，而是读取内核环缓冲区里的消息。硬件检测、驱动加载、磁盘错误、内存问题，这些底层信息都靠它。
用法很简单：
# 查看所有内核日志
dmesg
# 实时跟踪内核日志
dmesg -w
# 只看最后20条
dmesg | tail -20
# 搜索磁盘相关
dmesg | grep -i sda举个例子，服务器突然重启了，你怀疑是硬件问题。这时候dmesg就是你的第一选择。看看有没有类似这样的记录：
[12345.678901] EDAC MC0: UE memory error on CPU0 channel0 slot0
[12345.678902] mce: [Hardware Error]: Machine check events logged看到“UE memory error”或者“Machine check”，基本可以断定是内存故障。我有一台数据库服务器，隔三差五就宕机，查了应用日志、系统日志都没发现问题。最后用dmesg一看，内存报错已经持续好几天了。换了内存条，问题彻底解决。
dmesg里常见的几类信息：
| 信息类型 | 关键词 | 含义 |
|---|---|---|
| 硬件检测 | sda、nvme、eth0 | 磁盘、网卡等设备被识别 |
| 驱动加载 | driver、module | 内核模块加载成功或失败 |
| 错误告警 | error、failed、Oops | 硬件或驱动层面的严重问题 |
| 内存错误 | EDAC、MCE、memory error | 物理内存故障 |
我的习惯： 服务器上架后，第一件事就是跑一遍dmesg | grep -i error，看看有没有硬件层面的隐患。很多问题在出厂时就埋下了，早发现早处理。
3.4 三个日志怎么配合使用？
你想想看，一个故障往往不是单一日志能说清楚的。我一般按这个顺序排查：
- 先看
/var/log/messages：了解系统层面发生了什么，服务有没有异常退出 - 再看
dmesg：如果怀疑是硬件或驱动问题，这里能找到底层证据 - 最后翻
/var/log/secure：如果涉及权限、登录、安全事件，这里是最权威的
举个例子，SSH连不上服务器。先看messages，可能看到sshd启动失败；再看secure，可能看到大量认证失败；如果还不行，dmesg里可能显示网卡驱动报错。三个日志一交叉，问题基本就锁定了。
总结一下：
/var/log/messages：通用系统日志，排查服务问题首选/var/log/secure：安全认证日志，审计和入侵排查必看dmesg：内核日志，硬件和驱动问题靠它
这三个文件，是Linux排障的“铁三角”。搞懂了它们，你就有了从应用层到内核层的完整视野。