日志管理与查看：journald、logrotate、集中日志

服务器出问题时，日志是第一手线索。现代 Ubuntu/Debian 系统里日志分两套：systemd 的 journald（结构化、按服务查）和传统的 /var/log 文本文件。学会查、学会控制体积，是运维你自己 VPS 的基本功。

用 journalctl 查 systemd 日志

journald 收集所有由 systemd 管理的服务输出。最常用的几种查法：

# 查某个服务的日志（-u 指定 unit）
journalctl -u nginx

# 实时跟随（类似 tail -f），排错时最常用
journalctl -u nginx -f

# 按时间过滤
journalctl -u nginx --since "2026-07-14 09:00" --until "2026-07-14 10:00"
journalctl --since "1 hour ago"
journalctl --since today

# 只看错误级别及以上
journalctl -p err -b

# 本次开机以来的全部日志（-b = boot）
journalctl -b

几个实用参数：-n 100 只看最后 100 行，-r 倒序（最新在前），-o short-iso 用标准时间戳，-k 只看内核消息。组合使用，例如 journalctl -u ssh -f -p warning。

传统 /var/log 与 logrotate

很多服务（Nginx、应用自身）仍直接写文本文件到 /var/log，比如 /var/log/nginx/access.log、/var/log/syslog。直接查看：

tail -f /var/log/nginx/error.log
grep "500" /var/log/nginx/access.log

这类文件会一直增长，不处理就可能把磁盘写满导致服务崩溃。logrotate 负责定期切割、压缩、删除旧日志。配置放在 /etc/logrotate.d/ 下，每个服务一个文件：

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

含义：每天轮转、保留 14 份、旧文件 gzip 压缩、文件不存在不报错、空文件跳过。改完可以手动测试：

# 演练，不真正执行，检查配置
logrotate -d /etc/logrotate.d/myapp
# 强制立即执行一次
sudo logrotate -f /etc/logrotate.d/myapp

> 提示：copytruncate 适用于不会重新打开日志文件句柄的程序；若程序支持 reload，用 postrotate 脚本发信号更干净。

给 journald 设置大小上限

journald 自己也会占磁盘。查看当前占用和清理：

journalctl --disk-usage
sudo journalctl --vacuum-size=500M   # 只保留最近 500M
sudo journalctl --vacuum-time=14d    # 只保留最近 14 天

想永久限制，编辑 /etc/systemd/journald.conf：

[Journal]
SystemMaxUse=500M
MaxRetentionSec=2week

改后执行 sudo systemctl restart systemd-journald 生效。

什么时候需要集中日志

单台服务器上述方法足够。但当你有多台机器、或希望日志跨重启/跨容器长期留存、需要全文检索和告警时，就该考虑集中日志方案：

• ELK / Elastic Stack：Elasticsearch 存储 + Logstash/Filebeat 采集 + Kibana 可视化，功能强但吃资源。
• Grafana Loki：轻量、按标签索引、和 Prometheus/Grafana 生态契合，小团队更省心。

它们的共同思路：在每台机器跑一个采集 agent，把日志推到中心存储统一查询。单台 VPS 通常不必上，等规模上来再引入。

小结

日常排错先用 journalctl -u <服务> -f 和 --since；传统文本日志靠 logrotate 定期切割压缩防止撑爆磁盘；用 SystemMaxUse 给 journald 设上限。多机或需长期检索时，再考虑 ELK 或 Loki 这类集中日志。先把单机这套练熟，绝大多数问题都能就地定位。