为什么需要日志监控
很多运维事故看起来像“服务器挂了”，但真正的根因往往是日志没有被看见。网站访问变慢、接口报错、登录异常、流量突增，这些现象都会在日志里留下痕迹。日志不是一个“事后整理的附件”，而是排障的第一手资料。
一个典型场景是：凌晨 3 点，业务方说“首页突然很慢”。如果你手里只有一张截图，判断会很慢；但如果能先看 Nginx 的访问日志和 PHP/FastCGI 的报错日志，就能迅速判断是数据库慢、后端 500、还是某个第三方接口超时。
Linux 系统日志：先认清常见文件
| 日志文件 | 用途 | 查看命令 |
|---|---|---|
/var/log/syslog |
系统综合日志（Ubuntu/Debian） | tail -f /var/log/syslog |
/var/log/messages |
系统综合日志（CentOS/RHEL） | tail -f /var/log/messages |
/var/log/auth.log |
认证和登录日志 | tail -f /var/log/auth.log |
/var/log/nginx/access.log |
Nginx 访问日志 | tail -f /var/log/nginx/access.log |
/var/log/nginx/error.log |
Nginx 错误日志 | tail -f /var/log/nginx/error.log |
/var/log/mysql/error.log |
MySQL 错误日志 | tail -f /var/log/mysql/error.log |
/var/log/dpkg.log |
软件包安装日志 | less /var/log/dpkg.log |
使用 journalctl
现代 Linux 系统大多使用 systemd-journald 管理日志。它的好处是可以跨服务统一查看、按时间过滤，并且便于与 systemctl 结合使用。
# 查看所有日志
journalctl
# 查看最近 30 分钟的日志
journalctl --since "30 min ago"
# 查看某个服务的日志
journalctl -u nginx
journalctl -u ssh
journalctl -u docker
# 实时追踪日志
journalctl -f
# 查看错误级别以上的日志
journalctl -p err
# 查看昨天的日志
journalctl --since yesterday --until today
实时日志监控：从“看日志”到“看趋势”
tail 命令
# 实时查看 Nginx 访问日志
tail -f /var/log/nginx/access.log
# 显示最后 100 行并追踪
tail -100f /var/log/nginx/error.log
# 查看多个日志文件
tail -f /var/log/nginx/access.log /var/log/nginx/error.log
日志过滤与统计
# 统计 5xx 错误数量
grep 'HTTP/1.1" [5]..' /var/log/nginx/access.log | wc -l
# 查找访问量最大的 IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# 查找请求最多的 URL
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# 查找特定时间段的日志
awk '/12\/Jul\/2026:14:00/,/12\/Jul\/2026:15:00/' /var/log/nginx/access.log
一个简单的报错告警脚本
#!/bin/bash
# monitor-errors.sh — 实时监控错误并通知
ALERT_EMAIL="[email protected]"
ERROR_PATTERNS="(PHP Fatal error|ERROR|FATAL|Out of memory)"
tail -f /var/log/nginx/error.log | while read line; do
if echo "$line" | grep -qE "$ERROR_PATTERNS"; then
echo "$line" | mail -s "Server Error Alert" $ALERT_EMAIL
echo "[ALERT] $line"
fi
done
这种脚本并不适合做大型生产监控，但足够帮助你在早期阶段把“异常日志”变成“可见的告警”。如果你的服务器规模上升到多台实例，建议再接入 Prometheus、Grafana 或 ELK 之类的集中日志平台。
日志轮转（Log Rotation）
日志文件不可能无限增长，尤其是高流量站点。配置轮转可以避免磁盘被日志写满，也便于保留最近一段时间的排障线索。
logrotate 配置
# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
手动执行
# 强制轮转
sudo logrotate -f /etc/logrotate.d/nginx
# 测试配置
sudo logrotate -d /etc/logrotate.d/nginx
日志分析工具
| 工具 | 类型 | 用途 |
|---|---|---|
grep / awk / sed |
命令行 | 快速过滤和分析 |
goaccess |
终端/Web | Nginx 日志实时分析 |
lnav |
终端 | 增强型日志查看器 |
ngxtop |
终端 | Nginx 访问统计 |
| ELK Stack | 服务 | 企业级日志分析和搜索 |
安全注意事项
- 日志中包含敏感信息（IP、路径、可能的数据），注意访问权限；
- 日志文件设置为
640权限，只允许所有者和管理员读取； - 定期备份重要日志；
- 配置日志轮转防止磁盘写满；
- 考虑集中式日志管理（多台服务器时）。
监控体系的下一步：告警与可视化
单纯看日志能解决临时问题，但真正高效的运维流程还需要把“看见异常”变成“及时提醒”。一个简单的实践是：把 5xx 错误率、接口超时率和登录失败次数做成告警阈值，超过阈值时自动发邮件或推送到团队群。这样你不会在事故已经扩大后才发现问题，而是在异常刚刚出现时就能收到通知。
如果你的站点已经有多台服务器或多个服务实例，再往前走一步，建议把日志与监控面板绑定起来。Prometheus、Grafana 或 ELK 这类工具不会替代你手动查看日志，但能让你把“某个时间段的错误爆发”和“某个服务的资源压力”放在同一个视图里，判断问题的来源会更快。
典型故障与日志线索对照
| 问题现象 | 先看哪类日志 | 常见线索 |
|---|---|---|
| 页面大量 502/503 | Nginx error log | upstream 超时、后端连接数耗尽 |
| 登录异常增多 | auth log / application log | 密码错误、IP 封禁、Token 失效 |
| 页面变慢但不报错 | access log / slow query log | 请求耗时上升、数据库慢查询增多 |
| 磁盘被写满 | syslog / journalctl | 日志轮转失效、文件不断膨胀 |
很多初学者把日志监控理解成“盯着一个终端看”，但真正好的做法是把问题从“偶发现象”升级成“可追踪的流程”。这意味着你要在排障时知道，某类异常应该去哪一份日志里找，哪种告警应该在什么时候触发，哪些现象已经超出正常波动范围。
维护日志文化，而不只是维护日志文件
真正成熟的团队不会把日志监控当成“临时救火工具”。他们会把日志视为一部分长期运行资产：谁负责看告警、谁负责确认恢复、哪些异常需要记录到故障单、哪些日志要保留到审计时间窗口。这样一来，事故处理不再是靠记忆和口头传达，而是能形成一套可复用的流程。对于小团队来说，这一点尤其重要，因为一个人兼顾开发、运维和客服时，标准化的排障顺序能节省大量时间。
参考：systemd journalctl 文档 https://www.freedesktop.org/software/systemd/man/journalctl.html；Nginx 日志文档 https://nginx.org/en/docs/http/ngx_http_log_module.html
维护一个网站时，日志不是“额外工作”，而是最能帮助你快速判断问题走向的基础设施。