1. 从一次磁盘告警说起/var/log 为何总是“吃”满空间那天下午监控系统突然弹出一条刺眼的告警“服务器磁盘使用率超过90%”。我第一反应是哪个业务的数据目录又爆了结果df -h一看根目录/快满了。用du -sh /*快速定位发现/var目录占了大头再深入/var/log好家伙几十个G的日志文件静静地躺在那里其中几个syslog、kern.log、messages文件体积大得惊人。这场景对于任何一个运维过 Linux 服务器的朋友来说都再熟悉不过了。/var/log这个目录就像系统的“日记本”记录着内核、系统服务、应用程序的点点滴滴但如果不加管理它就会变成一个无限膨胀的“貔貅”只进不出最终吞噬掉宝贵的磁盘空间轻则导致新日志无法写入服务报错重则系统完全无法创建新文件或进程直接宕机。所以清理/var/log下的日志文件绝不是简单的rm -rf。它是一项需要理解日志机制、掌握正确工具、并建立长期策略的系统性工作。盲目删除可能让你在关键时刻丢失重要的排错线索而粗暴的rm命令如果指向了错误的目标比如rm -rf /var/log/后面多打了个空格更是灾难性的。今天我就结合多年踩坑经验系统性地梳理一下面对/var/log日志文件太大的问题时我们到底有哪些安全、有效且可持续的清理方式。2. 理解日志系统谁在写写了什么为何会大在动手清理之前我们必须先搞清楚日志是怎么来的。现代 Linux 系统主要依赖两个核心组件来管理日志rsyslog或更早的syslogd和journald。2.1 传统派rsyslog 与它的文本日志文件rsyslog是大多数发行版默认的系统日志守护进程。它负责接收来自系统内核、各种服务如 SSH、Cron、Apache以及任何通过syslogAPI 发送消息的应用程序的日志。它的配置决定了这些日志的去向最常见的就是写入/var/log/下的各个文本文件。/var/log/syslog或/var/log/messages 通常包含除认证、邮件等特定类别外的大部分系统级日志。/var/log/auth.log或/var/log/secure 专门记录认证相关的日志如用户登录、sudo 提权。/var/log/kern.log 内核产生的日志。/var/log/cron 定时任务cron的日志。/var/log/nginx/,/var/log/apache2/ Web 服务的访问日志和错误日志。这些文件是纯文本的会随着时间推移不断追加内容。如果没有外部干预它们会一直增长下去。这就是为什么你经常会看到几个G甚至几十G的syslog文件。2.2 现代派systemd-journald 与它的二进制日志使用systemd作为初始化系统的发行版如 CentOS 7/8, Rocky Linux, Ubuntu 16.04还拥有journald。它同样收集内核、系统服务、应用程序的日志但默认不写入文本文件而是以一种高效的、带索引的二进制格式journal存储通常位于/run/log/journal/内存中重启丢失或/var/log/journal/持久化到磁盘。journald的日志虽然也占空间但它自身具备日志轮转和大小限制的配置。问题往往出在很多服务既通过journald记录又配置了rsyslog将日志转发到文本文件造成了“双重记录”这是磁盘空间被快速消耗的一个常见原因。2.3 日志变大的元凶失控的应用与缺失的轮转除了系统日志第三方应用程序是更大的“空间杀手”。一个典型的例子是数据库如 MySQL、PostgreSQL在调试时开启的详细查询日志或者一个 Java 应用配置了DEBUG级别且未设置日志回滚策略。这些应用日志的生成速度可能远超系统日志几天内就能产生数百GB的数据。另一个关键因素是“日志轮转”log rotation的缺失或配置不当。健康的日志管理不是等文件大了再删而是定期将当前日志文件归档、压缩并只保留一定数量的历史文件。下一章我们就从最核心的轮转工具讲起。3. 治本之策配置 logrotate 实现自动化轮转logrotate是 Linux 系统自带的日志轮转工具它是解决日志膨胀问题的首选和根本方案。它通过周期性的计划任务通常由cron每日执行根据预定义的规则对日志文件进行重命名、压缩、删除旧文件等操作。3.1 logrotate 是如何工作的它的核心是一个个配置文件通常位于/etc/logrotate.conf主配置和/etc/logrotate.d/各个服务或应用的独立配置。我们来看一个经典的syslog配置例如/etc/logrotate.d/rsyslog/var/log/syslog { rotate 7 daily missingok notifempty delaycompress compress postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }让我逐条解释这个配置的意图和背后的逻辑rotate 7 保留7份归档日志。这是空间与可追溯性之间的权衡。保留太少可能查不到一周前的故障保留太多占用磁盘。对于核心系统日志7-30天是常见范围。daily 每天轮转一次。对于高流量的访问日志你可能需要hourly甚至size触发如size 100M。missingok 如果日志文件不存在也不报错继续执行。避免因临时文件缺失导致整个轮转任务失败。notifempty 如果日志文件是空的就不进行轮转。节省不必要的操作。delaycompress 延迟压缩。将上一次轮转的归档文件进行压缩而不是最新的那个。这样做是为了让一些还需要读取最新归档日志的工具如日志监控 agent能有时间处理。compress 使用 gzip 压缩旧日志。这是节省空间的利器文本日志的压缩比通常很高。postrotate ... endscript 轮转后执行的脚本。这里通常是向rsyslog服务发送信号HUP通知它关闭旧的文件句柄并重新打开新文件。这是最关键的一步如果没有这个操作rsyslog进程会继续向已经被重命名如syslog.1的文件里写日志导致轮转失效。对于不同的服务这个信号可能不同如nginx -s reload,kill -USR1 pid。3.2 为自定义应用配置 logrotate假设你的应用/opt/myapp/logs/app.log增长很快你需要为其添加配置。只需在/etc/logrotate.d/下创建一个新文件比如myapp/opt/myapp/logs/*.log { daily rotate 30 compress delaycompress missingok notifempty create 644 appuser appgroup postrotate # 如果你的应用支持重载日志在这里发送信号 # kill -USR1 cat /var/run/myapp.pid # 如果应用不支持可能需要重启服务但这会影响业务需谨慎。 endscript }这里多了个create选项它指定轮转后新创建的空白日志文件的权限、所有者和所属组。确保和原文件一致避免应用因权限问题无法写入。3.3 手动触发与调试配置好后不需要等到明天。你可以用logrotate -f /etc/logrotate.d/myapp强制立即执行一次轮转测试配置是否正确。更安全的调试方式是使用-d调试模式logrotate -d /etc/logrotate.d/myapp它会模拟执行并输出详细过程但不做任何实际修改。实操心得 检查postrotate脚本是否适合你的服务至关重要。对于像nginx或自定义的守护进程如果它不支持通过信号重载日志那么轮转后日志会继续写入旧文件。一个变通方法是使用copytruncate选项它会复制原文件后清空原文件而非移动但这存在日志丢失一小段的风险在复制和清空的瞬间仅作为备选方案。4. 紧急清理当磁盘已满时的安全操作指南当磁盘使用率超过95%甚至系统开始报“No space left on device”时我们需要立刻释放空间但这时的每一步操作都必须格外小心。4.1 第一步精准定位找出“罪魁祸首”切忌盲目进入/var/log就开始rm。先用组合命令快速定位df -h确认是哪个分区满了。du -sh /var/log/* | sort -rh | head -20这个命令组合非常强大du计算大小sort -rh按人类可读的数字逆序排序head显示前20个。瞬间你就能看到是哪个目录或文件最大。如果怀疑是某个特定的大文件可以用ls -lhS /var/log/ | head -10按文件大小排序列出。4.2 第二步区分对待安全清理根据定位结果采取不同策略对于已轮转并压缩的旧日志如syslog.2.gz,nginx.access.log.3.gz 这些是logrotate已经处理过的历史文件直接删除通常是安全的。你可以用rm删除最老的几个rm /var/log/syslog.7.gz /var/log/syslog.6.gz。或者如果你想保留最近N天的可以结合find命令find /var/log -name *.gz -mtime 30 -delete删除30天前的所有.gz文件。务必先确认这些归档文件里没有你需要调查的近期故障日志。对于当前正在写入的日志文件如syslog,kern.log绝对不要直接rm或 file因为运行中的进程如rsyslogd持有这个文件的描述符你删除的只是目录项磁盘空间并不会立即释放直到进程关闭文件句柄通常需要重启服务。在此期间文件看似消失了但空间仍被占用du命令可能查不出来而df显示空间未释放这会让你非常困惑。正确做法是清空truncatetruncate -s 0 /var/log/syslog或: /var/log/syslog。这个操作将文件大小截断为0但进程的文件句柄仍然指向同一个 inode可以继续写入。空间会立刻释放。这是应急时最常用的方法。通知服务重载 清空后最好通知日志服务如systemctl restart rsyslog或发送HUP信号让它知道文件已被重置。对于 journald 日志 如果/var/log/journal过大可以使用journalctl命令来管理。查看日志占用的总空间journalctl --disk-usage。清理指定时间之前的日志journalctl --vacuum-time2weeks保留最近2周。清理日志直到占用空间低于指定大小journalctl --vacuum-size500M保留最多500M。这些命令是安全的journald会自行维护其索引和文件。4.3 第三步处理“幽灵”空间与特殊文件有时你会发现du和df的结果对不上df显示空间已用满但du统计所有文件加起来却没那么多。这通常是因为有文件被删除但进程仍持有句柄即上述的rm错误操作遗留问题。使用lsof | grep deleted命令可以列出所有已被删除但仍有进程打开的文件。找到对应的进程ID重启该进程或发送信号让其关闭文件空间才会真正释放。另一个可能是磁盘上存在大量非常小的文件du命令因为块大小的原因统计有偏差或者有隐藏的.*文件。可以用find /var/log -type f | wc -l看看文件总数是否异常多。踩坑实录 我曾遇到一个生产环境问题/var/log下某个应用的日志目录里生成了数百万个微小日志文件每个几KB原因是日志配置错误每次请求都创建一个新文件。du -sh看起来不大但df显示 inode 用尽了df -i导致系统无法创建新文件。解决方案是先修改应用配置然后用一个脚本分批删除这些海量小文件find /path/to/logs -name *.log -delete一次性删除太多可能卡住可以分日期或分批处理。5. 进阶管理与长效预防策略清理只是补救建立预防机制才能一劳永逸。5.1 调整 rsyslog 和 journald 的默认配置rsyslog 编辑/etc/rsyslog.conf可以限制某些日志设施的级别减少不必要的日志。例如将*.info;mail.none;authpriv.none;cron.none调整为*.warn;mail.none;authpriv.none;cron.none可以减少syslog中info级别的大量信息。journald 编辑/etc/systemd/journald.conf。设置SystemMaxUse来限制持久化日志的最大磁盘使用量如SystemMaxUse1G。设置MaxRetentionSec来限制日志保留时间。修改后需重启服务systemctl restart systemd-journald。5.2 为高流量日志设计更激进的轮转策略对于像 Nginx 访问日志这样增长极快的文件仅靠daily轮转可能不够。可以配置按大小轮转/var/log/nginx/access.log { size 100M rotate 10 compress delaycompress missingok notifempty create 640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }size 100M表示文件达到100MB就触发轮转。sharedscripts表示postrotate脚本在所有日志如error.log都轮转完后只运行一次。5.3 使用日志收集与集中化方案对于重要的业务日志最治本的方法是不在本地长期存储。搭建一个集中的日志管理平台如 ELK StackElasticsearch, Logstash, Kibana或 Grafana Loki通过rsyslog、Filebeat、Fluentd等工具将服务器上的日志实时转发到中心存储。本地只需保留最近几小时或几天的日志用于临时排查logrotate配置可以非常激进如rotate 2。这样既解放了服务器磁盘又实现了日志的聚合、搜索和可视化分析提升了运维效率。5.4 建立监控与告警不要等到磁盘满了才处理。将磁盘使用率特别是/var分区、关键日志文件的大小、logrotate是否成功执行纳入监控体系如 Zabbix, Prometheus。设置合理的告警阈值如80%警告90%严重这样你就有充足的时间在问题发生前介入处理从容调整配置或清理策略。最后关于那个危险的rm命令。在/var/log下操作时请养成条件反射般的习惯在执行rm前先按Tab键补全路径仔细核对对于批量删除优先使用find -delete并先不加-delete选项运行一次看结果写脚本时对路径变量加引号防止空格导致的误删。磁盘空间很重要但数据的安全和可追溯性更重要。管理日志本质上是在管理系统的记忆和运维的主动权。