Linux 系统日志与故障排查

大家好，我是你们的老朋友，今天想跟你们聊聊 Linux 系统日志和故障排查的那点事儿。日志是我们排查问题的第一手资料，也是系统运行的“黑匣子”。如果你刚接触 Linux，或者已经在生产环境里摸爬滚打，这篇文章都能帮你把日志用得更顺手。咱们不搞那些高大上的理论，直接上干货，结合实际案例，让你看完就能动手。

1. Linux 日志体系到底是怎么回事？

Linux 的日志并不是一个单一的文件，而是一套完整的体系。常见的日志存放位置有：

- /var/log/syslog 或 /var/log/messages：系统整体日志，很多发行版会把内核、启动、服务等全部丢到这里。

- /var/log/auth.log（Debian/Ubuntu）或 /var/log/secure（RHEL/CentOS）：登录、sudo、ssh 等认证相关的记录。

- /var/log/kern.log：内核日志，尤其在硬件驱动、电源管理出问题时会很有价值。

- /var/log/dmesg：系统启动时的硬件检测信息，等价于 dmesg 命令的输出。

- /var/log/nginx/、/var/log/apache2/：Web 服务器的业务日志。

- 应用自行管理的日志：比如 MySQL 的 error.log、slow.log，Docker 的 container.log 等。

日志的生成主要靠 syslog（现在的 rsyslog 或 syslog-ng）收集统一写入。系统服务会调用 syslog() 把消息发送到 syslog 守护进程，然后再根据 /etc/rsyslog.conf 或 /etc/syslog-ng/syslog-ng.conf 的规则把不同优先级、不同设施的日志写到对应文件。了解这套机制后，你就能知道：为什么有些日志在 messages 里找不到，却在 auth.log 里出现——因为它们的设施（facility）不同。

2. 常用日志命令与技巧

2.1 查看日志的基本姿势

# 实时滚动查看系统日志（类似 tail -f）
tail -f /var/log/syslog

查看最近 50 行的认证日志
tail -n 50 /var/log/auth.log

按关键字过滤，只显示包含 "failed" 的行
grep "failed" /var/log/auth.log

支持正则表达式，查找 192.168.1.100 相关的登录尝试
grep -E "Failed password for.*192\.168\.1\.100" /var/log/auth.log

2.2 进阶组合：多文件聚合 + 时间范围

如果你需要同时查看多个日志文件，或者只看某一段时间的记录，可以结合 awk、sed、journalctl：

# 使用 journalctl 按时间范围过滤（CentOS 7+、Debian 9+）
journalctl --since "2025-12-01 08:00" --until "2025-12-01 12:00" -u nginx

合并两个日志文件并按时间排序
cat /var/log/syslog /var/log/auth.log | sort -t' ' -k1,2 -k3

2.3 实时监控异常

生产环境里最怕的就是突发故障。下面两条命令可以帮助你实时捕捉异常：

# 监控内核日志，发现 OOM、硬件错误等
dmesg -w

监控所有服务的错误日志（journalctl）
journalctl -p err --since "1 hour ago"

3. 常见故障排查案例

3.1 SSH 登录失败

经常有同事反馈“密码对了却登不进去”。先看 auth.log（或 secure）：

grep "Failed password" /var/log/auth.log | tail -20

常见错误：

- “Failed password for root from 10.0.0.5 port 22 ssh2”：说明 root 用户被禁止登录（很多发行版默认禁止），解决方案是改用普通用户或修改 /etc/ssh/sshd_config 的 PermitRootLogin。

- “Authentication failure”：可能是 PAM（可插入认证模块）报错，检查 /etc/pam.d/sshd 或 /var/log/secure 是否有 “pam_unix(sshd:auth): authentication failure” 的线索。

3.2 服务启动不了

比如 Nginx 启动失败，先检查它的错误日志：

nginx -t          # 先做语法检查
systemctl status nginx
journalctl -u nginx --no-pager -n 50

常见原因：

- 端口冲突：nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)，使用 ss -tlnp | grep :80 查谁占用了端口。

- 权限不足：nginx: [emerg] open() "/run/nginx.pid" failed (13: Permission denied)，确认 Nginx 以正确用户运行，或者目录权限是否被误改。

3.3 磁盘空间不足导致系统异常

日志本身也会占空间，一旦 /var/log 爆满，系统会出现各种诡异问题。先用 df -h 检查分区使用率：

df -h /var
du -sh /var/log/*

如果发现某个日志文件（比如 syslog）已经十几 GB，可以使用 logrotate 自动轮转。检查 /etc/logrotate.d/ 下的配置，确保有 compress、rotate 7、size 100M 等参数。

4. 日志分析与监控工具

如果你不想天天手动敲命令，可以考虑下面几款开源工具：

| 工具 | 特点 | 适用场景 |

|------|------|----------|

| ELK（Elasticsearch + Logstash + Kibana） | 强大的全文检索、可视化 | 大规模分布式系统 |

| Grafana + Loki | 与 Prometheus 生态兼容，查询语言简单 | 容器化、云原生环境 |

| rsyslog + LogAnalyzer | 轻量级，直接写入 MySQL/PostgreSQL | 中小企业内部日志收集 |

| journalctl + systemd | 系统自带，无需额外安装 | 快速定位本地系统问题 |

对于个人开发者或小团队，我推荐先从 journalctl 入手，再配合 Grafana+Loki，因为部署门槛低，查询语言（LogQL）和 Prometheus 类似，上手快。

5. 最佳实践与日常小技巧

1. 日志轮转一定要开：不要等磁盘爆了才想起来。/etc/logrotate.conf 和 /etc/logrotate.d/ 里的配置要定期审计。

2. 关键日志加入告警：比如 auth.log 出现 “Failed password” 超过 5 次/分钟，就触发邮件或 Slack 报警。可以用 fail2ban 或者自写脚本配合 journalctl。

3. 日志保留时间要合规：不同业务对日志保留时间有法律或内部规定，通常安全日志保留 6 个月，业务日志保留 30 天。务必在 logrotate 配置里明确 rotate N。

4. 日志敏感信息脱敏：如果日志里出现密码、身份证号等，需要在收集或存储前做脱敏处理，避免泄露风险。

5. 做好日志归档：使用 tar + gzip 定期把历史日志打包，移到冷存（如对象存储），既节省空间，又方便以后审计。

结语

日志是排查问题的第一把钥匙，也是系统运行状态的镜子。本文从日志体系、常用命令、故障案例、监控工具到最佳实践，给大家梳理了一条完整的思路。希望你在日常运维或开发中，能够快速定位问题，不再因为“找不到日志”而抓狂。

如果觉得有帮助，记得点个赞，转发给需要的小伙伴。有什么疑问或想聊的具体场景，欢迎在评论区留言，我们下期再见！祝你们的系统永远稳如泰山，日志永远清晰可读。