/var/log/messages是rhel/centos系统记录硬件初始化、驱动异常、电源中断等核心事件的日志文件，由rsyslog写入、logrotate按size或时间轮转、cron每日触发，需确保rsyslog活跃、规则正确、postrotate重载服务，并配合dmesg -w与关键词过滤实现硬件报错实时监控。
/var/log/messages 是 RHEL/CentOS 系统中记录系统级事件（含硬件初始化、驱动异常、电源中断、PCIe 错误等）的核心文本日志。它本身不“实时轮转”，而是由 rsyslog + logrotate + cron 协同完成“准实时”轮转与监控——关键在于确保日志能持续写入、及时切割、不丢失硬件报错，并便于快速发现。
确认 messages 是否在被 rsyslog 正确写入
硬件报错（如磁盘 SMART 告警、内存 ECC 错误、网卡 link down）首先进入内核 ring buffer，再经 rsyslog 过滤写入 /var/log/messages。若该文件长期无更新或为空，说明源头已断：
- 运行
systemctl status rsyslog，确保服务 active（running）； - 检查
/etc/rsyslog.conf或/etc/rsyslog.d/50-default.conf，确认有类似*.info;mail.none;authpriv.none;cron.none /var/log/messages的规则； - 执行
logger "test hardware alert"，再tail -n1 /var/log/messages，看是否立即出现——验证写入链路通畅。
让轮转不丢硬件报错：关键配置要点
默认 daily 轮转可能错过凌晨突发故障。需兼顾“及时性”和“可追溯性”：
-
改用 size 触发轮转：在
/etc/logrotate.d/syslog（或 rsyslog）中，将daily替换为size 10M，避免等待整点而堆积大量报错； -
保留足够旧日志：
rotate 30（保留30份），硬件问题常具周期性（如某块硬盘每天凌晨报错），需回溯多天； -
必须 reload rsyslog：确保
postrotate中包含systemctl kill -s HUP rsyslog.service，否则 rsyslog 仍向旧文件句柄写入，新日志实际没生成； - 禁用 delaycompress：硬件报错需立即压缩归档，避免解压延迟影响排查；
-
加 create 权限：如
create 0644 root root，防止新日志因权限问题无法写入。
真正“实时监控”硬件报错的实用组合
单靠 tail -f /var/log/messages 不够——它只显示新行，但硬件错误常以“burst”方式集中爆发（如 RAID 卡掉盘瞬间刷屏），容易漏看。推荐以下组合：
-
过滤关键词+循环提醒：运行
tail -f /var/log/messages | grep -i -E "(error|fail|warn|offline|reset|ecc|smart)"，终端一有匹配就高亮输出； -
配合 dmesg -w：内核硬件事件最先出现在 dmesg，
dmesg -w实时流式输出，比 messages 更早几秒，且含更底层信息（如nvme 0000:01:00.0: controller is down）； -
定时扫描归档日志：用 cron 每10分钟跑一次脚本，检查最新 rotated 日志（如
/var/log/messages-20260720）是否有新增硬件关键字，邮件告警； -
查状态文件定位轮转时间：
cat /var/lib/logrotate/status | grep messages可看到上次轮转确切时间，确认是否按预期触发（比如 size 达标后是否真切了）。
当 messages 突然停止记录硬件错误时，优先排查这些
不是配置失效，而是常见“静默中断”场景：
- rsyslog 配置语法错误导致服务自动退出（
journalctl -u rsyslog -n 50查启动失败原因）； - 磁盘空间满或 inodes 耗尽（
df -h /var/log和df -i /var/log）； - SELinux 拒绝 rsyslog 写入（
ausearch -m avc -ts recent | grep rsyslog）； - RHEL 8+ 默认启用 journald，messages 内容变少——此时必须
journalctl -k -p err..alert补充查看内核硬件错误。
