应先确认系统发行版，再查对应日志：rhel/centos看/var/log/messages和/var/log/secure，ubuntu/debian看/var/log/syslog和/var/log/auth.log；journald接管后需用journalctl补充；关键问题优先查dmesg、journalctl和安全日志。
查系统出问题，先看 /var/log/messages 还是 /var/log/syslog
CentOS/RHEL 系统认 /var/log/messages，Ubuntu/Debian 系统用 /var/log/syslog —— 不是选错，是根本不存在另一个文件。硬去 cat 不存在的路径只会报 No such file or directory，别怀疑权限，先 ls /var/log/{messages,syslog} 看哪个真有。
- 用
lsb_release -is或cat /etc/os-release | grep ID快速确认发行版 -
/var/log/messages在 RHEL 8+ 默认被journald接管，内容可能比以前少；若需完整日志，得用journalctl -u systemd补充 - 别直接
tail -f /var/log/messages就开始盯屏：它不记录内核启动瞬间的硬件报错，那种得翻/var/log/dmesg或dmesg -T
排查登录异常，/var/log/secure 和 /var/log/auth.log 别混用
SSH 登录失败、sudo 权限拒绝、PAM 认证失败，全在安全日志里，但路径因系统而异：RHEL/CentOS 写进 /var/log/secure，Debian/Ubuntu 走 /var/log/auth.log。两者内容结构一致，但日志轮转配置、默认权限略有不同。
- 暴力破解痕迹：用
grep "Failed password" /var/log/secure | tail -20查最近失败尝试，注意匹配invalid user（扫用户名）和for root（专盯 root） -
/var/log/btmp是二进制格式，不能直接 cat；想看所有失败登录记录，必须用lastb -i（-i 显示 IP），否则全是乱码 - 如果
/var/log/secure突然不写新日志，先检查rsyslog是否运行：systemctl status rsyslog；停了就起不来，journalctl -u rsyslog会告诉你配置哪行写错了
/var/log/boot.log 看起来有用，但多数时候是“假线索”
这个文件只记录 init.d 或 systemd service 启动脚本 stdout/stderr 的输出，不是系统启动全过程。服务没报错但没起来？它可能一片空白；内核卡在 USB 初始化？它压根不提。
- 真正反映启动瓶颈的是
systemd-analyze blame（用户态）和dmesg -T | head -50（内核态） -
/var/log/boot.log在 CentOS 7+ 默认关闭，除非手动开启systemd的stdout捕获，否则就是空文件 - 想确认某服务是否成功启动过，别依赖它，改用
systemctl status nginx或journalctl -u nginx --since "2026-02-14"
日志太多撑爆磁盘？重点盯 /var/log/journal 和轮转配置
/var/log/journal 是 journald 的二进制存储目录，不像文本日志能用 logrotate 直接切，它自己管大小。默认不限制，跑几个月就占几个 GB，而 /var/log/messages 可能才几十 MB。
- 查占用：
journalctl --disk-usage；清旧日志：journalctl --vacuum-time=2weeks（保留两周）或--vacuum-size=500M - 永久限制：编辑
/etc/systemd/journald.conf，取消注释SystemMaxUse=和SystemMaxFileSize=，改完必须systemctl restart systemd-journald -
logrotate对/var/log/*.log有效，但对/var/log/journal完全无效——轮转脚本里加它，纯属白配
最常被忽略的其实是时间精度：dmesg 默认用 boot time，journalctl 默认用 monotonic，而 /var/log/messages 是 wall-clock。三者时间对不上时别急着怀疑日志丢数据，先统一用 -T 或 --since 对齐时间基准。
