识别高频故障需用journalctl聚焦重复异常模式：统计服务启动次数、扫描timeout/connection refused等高频错误词、检查内核taint/OOM killer记录，并对比多boot日志差异定位变更点。
识别高频故障，关键不是翻遍所有日志，而是用 journalctl 快速聚焦“反复出现的异常模式”。系统级稳定性问题往往藏在重复失败、周期性崩溃或服务反复重启的日志特征里，而不是单次报错。
查服务是否频繁重启
服务反复 start/stop 是典型稳定性隐患。journalctl 可直接统计单位时间内的启动次数：
- 看某服务最近 24 小时内启动了多少次：
journalctl -u nginx.service --since "24 hours ago" | grep "Started\|Starting" | wc -l - 结合时间戳排序，确认是否密集发生：
journalctl -u mysql.service --since "6 hours ago" --no-pager | grep -E "(Started|Stopping)" | head -20 - 若发现每分钟都 restart，大概率是配置错误、资源耗尽或依赖未就绪，需立即检查
systemctl status mysql.service中的 “Restart” 和 “TriggeredBy” 字段
抓重复性错误关键词
高频故障常伴随固定错误短语，比如 “timeout”、“connection refused”、“permission denied”、“cannot bind”、“OOM killed”。用 journalctl + grep 组合快速扫描：
- 过去一小时所有服务中出现最多的错误词：
journalctl --since "1 hour ago" -p 3 | grep -oE "(timeout|refused|denied|OOM|segfault)" | sort | uniq -c | sort -nr - 只查特定服务的高频失败原因：
journalctl -u php-fpm.service -p 3 --since "30 min ago" | grep -i "failed\|restart\|socket" - 注意：-p 3 表示只取 err 级别及以上，避免被 info 冲刷掉关键线索
定位内核级重复异常
硬件不稳定、驱动缺陷或内存问题会引发周期性内核警告或 panic，这类故障容易被忽略但危害极大：
- 查近期所有内核 taint 记录（污染标志）：
journalctl -k --since "7 days ago" | grep -i "tainted\|warn\|machine check" - 检查是否反复出现 OOM killer 日志：
journalctl -k | grep -i "killed process" | tail -15 - 确认当前内核是否已被污染：
cat /proc/sys/kernel/tainted；若返回值非 0，说明存在专有模块、强制加载或硬件异常等风险源
对比多次启动行为差异
某些故障只在特定条件下触发，比如某次更新后、某个负载高峰后。用不同启动会话做横向比对：
- 列出所有可查的启动记录：
journalctl --list-boots - 对比当前启动与上一次启动的关键服务状态：
journalctl -b -1 -u sshd.service | tail -5和journalctl -b -0 -u sshd.service | tail -5 - 若某服务在 -b -2 正常，但在 -b -1 和 -b 开始失败，重点排查中间发生的变更（如内核升级、配置修改、模块加载）
