Linux 日志管理：journalctl 与 /var/log 怎么查怎么清理

当服务器出问题，日志是唯一不会撒谎的证人。服务为什么起不来？谁在半夜狂试你的 SSH 密码？磁盘怎么突然满了？答案都在日志里。但很多新手要么不知道去哪看，要么被满屏输出吓退。这篇文章把 journalctl 这套现代日志工具和传统的 /var/log 文本日志讲清楚，并教你用 logrotate 防止日志爆盘、用几行命令从 auth.log 里揪出暴力破解的来源 IP。

一、现代日志的两套体系

现在主流发行版都跑 systemd，日志由 systemd-journald 统一收集，二进制存在 /var/log/journal，必须用 journalctl 查看。同时，传统文本日志仍由 rsyslog 写入 /var/log（Ubuntu 默认写 /var/log/syslog，RHEL 默认只 journald 也可选装 rsyslog）。所以查日志有两把钥匙：journalctl 看 systemd 收集的，直接读 /var/log 下的文本文件看传统布局。两套并存，各有用武之地。

二、journalctl 最常用参数

journalctl 不带参数会倒出全部日志，空格翻页。日常最有用的几个：-n 50 看最近50条；-f 实时跟踪（像 tail -f）；-b 只看本次启动以来；--list-boots 列出历史启动；-u nginx.service 只看某个服务；-p err 只显示错误及以上级别；--since "1 hour ago" 看最近一小时。-x 还会附上错误解释，对新手极友好。掌握这几个，九成的日志查询都能应付。

journalctl -n 50
journalctl -f
journalctl -u nginx.service
journalctl -p err
journalctl --since "1 hour ago"

三、按时间、按服务精准过滤

日志太多时，精准过滤是关键。--since 和 --until 配合具体时间能锁定故障窗口，比如 --since "2026-08-01 00:00:00" --until "2026-08-02 00:00:00"。排查某服务启动失败，用 journalctl -u nginx.service -p err -b 专看本次启动的错误，再加 -x 看解释，定位快得多。还能按用户查：journalctl _UID=1000。过滤维度越准，噪音越少，你越容易看到真相。

journalctl -u nginx.service -p err -b
journalctl -u ssh.service --since "2026-08-06 00:00:00"

四、传统 /var/log 文本日志

如果发行版保留了 rsyslog，/var/log 下有一堆文本文件：Ubuntu 的 syslog（系统全局）、auth.log（认证/SSH/sudo）、kern.log（内核）；RHEL 对应 messages 和 secure。Nginx 这类服务还会在自己的子目录写 access.log / error.log。看实时滚动用 tail -f，翻最后一百行用 tail -n 100，搜错误用 grep -i error。文本日志的好处是你可以用熟悉的 grep/awk 任意加工。

sudo tail -f /var/log/syslog
sudo tail -n 100 /var/log/nginx/error.log
grep -i error /var/log/syslog

五、从 auth.log 揪出暴力破解 IP

SSH 暴破是常态。/var/log/auth.log（RHEL 是 /var/log/secure）记录每次登录尝试。grep "Failed password" 看失败记录，再用 awk 提取第11列（来源 IP）、sort、uniq -c、sort -nr，就能按次数排出最猖狂的攻击者。揪出来后直接 ufw deny from 该IP，或用 firewalld 的 rich-rule 拒绝。这招比装工具还快，是每个运维的必备肌肉记忆。

sudo grep "Failed password" /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head

六、日志也会吃光磁盘：journalctl 清理

journald 的日志会一直涨，不限制能撑爆磁盘。先用 journalctl --disk-usage 看占用，再用 --vacuum-size=500M 把总量压到 500M，或 --vacuum-time=2weeks 只留两周。想根治，改 /etc/systemd/journald.conf 的 SystemMaxUse=500M 等参数，然后重启 systemd-journald。别等磁盘 100% 报警才想起来——那是网站已经挂了的时刻。

journalctl --disk-usage
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=2weeks

七、logrotate：让日志自动轮转

日志不能只增不减，logrotate 按大小/时间轮转、压缩、删旧。全局配置在 /etc/logrotate.conf，各服务在 /etc/logrotate.d/。你看 nginx 的规则就知道它每天轮转、保留14份、压缩。改完用 logrotate -d 演练（dry-run）检查语法，再用 -f 强制执行一次。注意：轮转后服务若还写旧文件，需在 postrotate 里 reload，否则 fd 不释放、磁盘不释放。这套机制，是服务器长期稳定运行的隐形守护。

补充与延伸：日志是系统留给你的黑匣子

把日志当成"出事才看的东西"就亏了。成熟的团队会把日志当成系统的黑匣子——平时就盯着关键指标，在用户投诉之前先发现异常。journalctl 的 -f 实时跟踪、配合 -p err 只看错误，能在问题刚冒头时就告警；而把 /var/log/auth.log 的失败登录做成定时统计，能比 Fail2Ban 更早看出有人在对你撒网。日志真正的价值不是"事后诸葛亮"，而是"事中雷达"。养成定期扫一眼错误的习惯，你会比故障快半步。

另一个常被忽视的维度是"日志要能送出去"。一台机器磁盘满了、journald 自己也写不下时，本地日志就失灵了。所以稍微正式一点的架构，都会把日志转发到集中平台（rsyslog 推到远程、或 journald 的 ForwardToSyslog、或容器世界的 Loki/ELK）。这样哪怕单机崩了，过往日志还在远端，排障不丢线索。对个人 VPS 来说，至少把 auth.log 的关键告警邮件发给自己，成本极低却能在被攻破时保留证据链。

日志分析也有套路。别一上来就 cat 大文件，先用 grep -i error 缩小范围，再用 awk 抽取字段、sort | uniq -c 统计频次，定位"出现最多的错误"往往比看单条更有效。比如用 grep -c "timeout" access.log 看超时频率，用 awk 统计各状态码占比，异常一眼可见。这些小组合拳，是运维从"看日志"升级到"读日志"的分水岭。

最后提醒：日志里也有隐私和敏感信息。访问日志可能带 token、Cookie；应用日志可能打出了用户手机号。轮转压缩之外，要控制日志文件的权限（别让普通用户能读 auth.log 里的密码尝试细节），长期归档前做脱敏。日志管理是一套"收得全、留得住、看得懂、藏得住"的功夫，做到这四句，才算真正驾驭了它，也才对得起它每天默默记下的那些线索。

讲个实战技巧：用 journalctl 做"变更前后对比"。你刚改了某个配置、重启了服务，想确认有没有报错，用 journalctl -u 服务名 -p err -b 看本次启动以来的错误，再配合 --since "10 min ago" 锁定时间窗，比肉眼翻几千行快得多。排查的精髓就在于"给时间、给服务、给级别"三维同时收窄，噪音越小，真相越清楚。

再补充日志轮转的一个隐藏坑：有些程序（比如自己写的 Python 服务）用的是自己打开文件写日志，logrotate 把文件改名后，它还在写那个已经被移走的旧 inode，导致磁盘不释放、新文件却是空的。解决办法是在 logrotate 配置里加 copytruncate（先拷贝再截断原文件），或在 postrotate 里让服务重新打开日志（如 kill -HUP）。这点不理解，你的磁盘清理可能只是自欺欺人。

最后，日志量太大时也别硬扛。可以用 journald 的 RateLimitIntervalSec / RateLimitBurst 限制单条日志刷屏，避免一个死循环把磁盘写爆；也可以在应用层用采样、把 debug 日志按环境开关。日志的黄金法则是：该记的记全，不该记的别刷屏。平衡好了，日志才是资产，不是负担。

日志是机器和你之间的对话。你愿意花时间读它，它就把系统的秘密讲给你听；你只顾跑业务、从不看它，等它用"宕机"这种最激烈的方式开口时，往往已经晚了。把"定期翻日志"变成和"定期备份"一样自然的习惯，你的系统就有了自我报告的通道。一个会读日志的运维，和一个只会重启的运维，中间差的是一整个段位。

最后给个落地建议：把"看日志"也自动化一部分。比如写个脚本每天定时统计 auth.log 的失败登录 TOP10、nginx 的 5xx 数量，有异常就发你一条消息。你不必时刻盯着，但关键信息会主动找你。当日志从"被动查阅"变成"主动汇报"，你的运维就真正上了台阶，也更有余裕去琢磨业务本身。

把日志当作和机器长期的对话，而不是出事才翻的档案。你对它用心，它便在关键时刻替你说话。本文的命令不多，但每一条都能在深夜救你一次，值得存进自己的速查表，常看常新。

日志这件事，越早建立习惯，你半夜被叫醒的次数就越少。

sudo cat /etc/logrotate.d/nginx
sudo logrotate -d /etc/logrotate.d/nginx
sudo logrotate -f /etc/logrotate.d/nginx