1. 项目概述当服务器日志成为“硬盘杀手”做运维或者自己折腾服务器的朋友肯定对/var/log这个目录又爱又恨。爱的是当系统或应用出问题时它是我们第一个要去翻找的“案发现场”那些密密麻麻的日志记录着系统运行的每一个细节。恨的是如果你长时间不管它这个目录会像一只贪吃的仓鼠悄无声息地把你宝贵的磁盘空间啃食殆尽。我遇到过不止一次线上服务突然卡死或无法写入一查才发现根分区被/var/log下的几个巨型日志文件给塞满了其中syslog、kern.log、auth.log以及各种应用日志比如nginx、mysql的日志是常见的“元凶”。这不仅仅是磁盘空间的问题。一个持续高速写入的日志文件如果体积过大会严重影响后续的写入性能甚至导致日志轮转logrotate失败。更麻烦的是当你想去排查一个历史问题时面对一个动辄几十GB的纯文本日志文件用grep、tail、less这些工具都会变得异常缓慢和笨重分析效率极低。因此掌握一套有效、安全且自动化的日志清理策略是每个系统管理员必须精通的“生存技能”。今天我就结合自己踩过的坑和总结的经验详细拆解一下 Linux 下/var/log日志文件的清理之道从手动应急到自动预防让你彻底告别“磁盘空间不足”的警报。2. 核心思路不是简单删除而是科学管理面对庞大的日志文件新手最容易犯的错误就是直接rm -f。这非常危险很多应用程序在运行时会持续向日志文件写入直接删除文件并不会释放磁盘空间因为文件描述符还被进程占用着。空间会被占用到进程重启或显式清空文件为止。更优雅、更安全的做法是遵循一套层次化的管理思路应急处理当磁盘空间告急需要立即释放空间时如何安全、快速地清理现有大文件。常规轮转如何配置系统工具如logrotate让日志文件自动按时间或大小进行切割、压缩和删除防患于未然。源头治理如何调整应用程序和系统服务的日志级别、输出格式和目的地避免生成过多无用日志。集中与归档对于重要的历史日志如何将其转移到其他存储或归档系统既释放本地空间又满足审计或排查需求。接下来我们就按照这个思路一步步展开。2.1 手动清理与应急处理实战当收到磁盘使用率超过90%的告警或者df -h命令显示/var分区飘红时第一步是快速定位“罪魁祸首”。2.1.1 快速定位大日志文件使用du和find命令组合可以迅速找到目标# 查看/var/log目录下各子目录和文件的大小按人类可读格式排序 sudo du -sh /var/log/* # 或者更精确地找到最大的几个文件 sudo find /var/log -type f -name *.log -exec du -h {} | sort -rh | head -20一个更直观的命令是ncduNCurses Disk Usage它提供了一个交互式界面来浏览磁盘使用情况但可能需要单独安装。找到具体的巨型文件后比如/var/log/syslog.1或/var/log/nginx/access.log我们开始清理。2.1.2 安全清空正在写入的日志文件绝对不要直接rm正确的方法是清空文件内容。有两种主流方式使用truncate命令推荐这个命令将文件大小直接截断为指定值效率极高。# 将文件大小截断为0字节但保留文件inode进程可继续写入 sudo truncate -s 0 /var/log/bigfile.log执行后ls -lh会看到文件大小瞬间变为0磁盘空间立即释放。正在写入的应用程序不受影响。使用:或cat /dev/null 这是更传统的做法。sudo : /var/log/bigfile.log # 或 sudo cat /dev/null /var/log/bigfile.log其效果与truncate -s 0类似。重要提示清空前如果该日志还有分析价值可以先备份一下。cp /var/log/bigfile.log /tmp/bigfile.log.bak。清空操作是不可逆的。2.1.3 处理已轮转的旧日志/var/log下经常会有很多类似syslog.2.gz、auth.log.3.gz这样的压缩文件它们是logrotate轮转后压缩的旧日志。直接删除这些文件通常是安全的因为它们不再被进程使用。# 删除所有 .gz 的压缩日志文件 sudo find /var/log -name *.gz -type f -delete # 删除7天前的所有轮转日志非压缩 sudo find /var/log -name *.[0-9] -type f -mtime 7 -delete # 删除特定应用如nginx的旧访问日志 sudo find /var/log/nginx -name access.log.* -type f -mtime 30 -delete使用-mtime N参数可以按时间筛选7表示7天以前。这是应急时快速释放空间的有效手段。2.2 配置自动化轮转logrotate 深度解析手动清理是治标配置logrotate才是治本。它是 Linux 系统自带的日志管理工具通过 cron 任务每日自动运行。2.2.1 logrotate 工作原理与核心配置它的主配置文件是/etc/logrotate.conf但更常见的做法是在/etc/logrotate.d/目录下为每个服务创建独立的配置文件。我们以管理 Nginx 日志为例看看一个典型的配置/etc/logrotate.d/nginx/var/log/nginx/*.log { # 匹配的日志文件路径 daily # 轮转周期每天 missingok # 如果日志文件丢失不报错继续处理下一个 rotate 14 # 保留14份轮转后的文件如access.log.1, .2, ..., .14 compress # 轮转后使用gzip压缩旧日志生成.gz文件 delaycompress # 延迟压缩本次轮转的文件在下一次轮转时才压缩 notifempty # 如果日志文件为空则不进行轮转 create 0640 nginx adm # 轮转后创建的新日志文件权限和属主属组 sharedscripts # 在所有日志轮转后统一执行一次postrotate脚本 postrotate # 轮转后需要执行的命令 [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }轮转周期除了daily还有weekly、monthly、size如size 100M达到100MB就轮转。压缩相关compress开启压缩delaycompress常用于需要进程重新打开文件的场景如上面的Nginx避免进程还在写一个已压缩的文件。create指定新日志文件的属性确保应用有权限写入。postrotate/endscript这是最关键的部分。轮转后必须通知应用程序重新打开日志文件。对于Nginx是发送USR1信号对于Apache (httpd)可能是graceful重启对于rsyslog可能需要kill -HUP。如果这个信号发送不正确或遗漏应用程序会继续向已被轮转重命名的旧文件如access.log.1写入导致日志丢失或混乱。2.2.2 系统关键日志的轮转配置系统核心日志如syslog、auth.log、kern.log通常由rsyslog生成其轮转配置一般在/etc/logrotate.d/rsyslog。配置项与上述类似但postrotate脚本通常是重启rsyslog服务postrotate /usr/lib/rsyslog/rsyslog-rotate endscript这个脚本内部就是向rsyslog主进程发送HUP信号。2.2.3 测试与调试 logrotate 配置在将配置应用到生产环境前务必测试# 调试模式运行显示详细执行过程但不真正轮转 sudo logrotate -d /etc/logrotate.d/nginx # 强制立即执行一次轮转即使未到周期 sudo logrotate -vf /etc/logrotate.d/nginx-v是 verbose 输出-f是 force 强制。通过调试输出你可以清楚地看到它会处理哪些文件、执行什么操作、以及是否会调用postrotate脚本。2.3 进阶策略从源头控制日志体积即使有logrotate如果应用程序本身日志级别太低如 DEBUG或者访问量巨大仍然会产生海量日志。这时需要从源头控制。2.3.1 调整系统日志级别对于rsyslog可以编辑/etc/rsyslog.conf或/etc/rsyslog.d/*.conf文件控制哪些级别的日志被记录。例如将某设施的日志级别从*.*所有级别调整为*.info仅记录 info 及以上级别忽略 debug。# 示例将 mail 相关的调试日志忽略 # mail.* -/var/log/mail.log # 注释掉或修改级别 mail.info -/var/log/mail.log # 只记录 info 及以上2.3.2 调整应用日志配置以 Nginx 为例可以在nginx.conf的http或server块中调整访问日志格式减少不必要的字段或者为某些静态资源请求关闭日志记录。http { log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent; # 一个相对精简的格式 access_log /var/log/nginx/access.log main buffer32k; # 使用缓冲区提升性能 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { access_log off; # 静态资源不记录访问日志 expires 30d; } }对于 MySQL可以检查my.cnf中的general_log和slow_query_log是否被不必要地开启。生产环境通常关闭通用查询日志只根据需要开启慢查询日志。2.3.3 使用 systemd-journald 的持久化日志现代 Linux 发行版如 CentOS 7/Ubuntu 16.04使用systemd其日志由journald管理。默认情况下日志只保存在内存/run/log/journal中重启即消失。你可以配置持久化存储并限制其大小。 编辑/etc/systemd/journald.conf[Journal] Storagepersistent # 改为持久化存储 #SystemMaxUse10% # 限制日志最多占用文件系统的10% SystemMaxUse1G # 或直接指定最大容量如1GB MaxRetentionSec1month # 最大保留时间修改后运行sudo systemctl restart systemd-journald生效。持久化日志位于/var/log/journal。2.4 日志的集中管理与长期归档对于需要长期保存日志以满足合规性或深度分析需求的场景本地清理和轮转就不够了。2.4.1 使用 rsyslog 转发到中央日志服务器你可以配置rsyslog将重要的日志实时转发到一台专用的中央日志服务器如 ELK Stack 中的 Logstash或另一台rsyslog服务器。这样本地只需保留近期日志历史日志在中央服务器上被统一存储、索引和分析。 在/etc/rsyslog.conf中添加*.* 192.168.1.100:514 # 通过UDP将所有日志转发到192.168.1.100的514端口 # 或 *.* 192.168.1.100:514 # 使用TCP传输更可靠2.4.2 定期归档到对象存储对于非实时分析的历史日志可以编写脚本定期将logrotate生成的.gz压缩文件上传到云存储如 AWS S3、阿里云 OSS或内部的文件服务器上。这可以通过cron任务配合s3cmd、rclone等工具实现。# 示例cron任务每月1号凌晨2点归档上个月的nginx日志 0 2 1 * * /usr/bin/find /var/log/nginx -name *.gz -mtime 30 -exec /usr/local/bin/rclone move {} remote:bucket/nginx-logs/ \;3. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种“坑”。下面是我总结的一些典型问题及解决方法。3.1 清空日志文件后磁盘空间未释放这是最常见的问题。原因和解决方法如下进程未重启文件描述符未关闭你用truncate或:清空了文件但写入该文件的进程如nginx、java应用还在运行并且仍然持有该文件的描述符。在 Linux 中文件描述符指向的是文件的 inode。你清空的是文件内容但 inode 还被进程占用着磁盘空间不会释放给系统直到进程关闭该文件句柄。排查使用lsof命令查找正在使用该文件的进程。sudo lsof /var/log/bigfile.log sudo lsof | grep deleted # 查找已被删除但还被进程占用的文件状态为‘deleted’解决最干净的方法是重启持有该文件句柄的进程。如果无法重启对于rsyslog、nginx这类服务可以发送信号让其重新打开日志文件如kill -USR1或systemctl reload。文件系统有延迟有时释放空间后df命令显示有延迟。可以尝试运行sync命令强制写入磁盘或者检查是否有其他进程如备份、监控正在读取这个大文件导致空间释放缓慢。3.2 logrotate 执行失败报错“权限被拒绝”这通常发生在postrotate脚本执行或者create指令创建新文件时。权限问题logrotate通常以root身份运行但create指令指定的用户/组可能没有对应目录的写权限。检查目标日志目录如/var/log/nginx的权限和属主确保create指定的用户如nginx有权限在该目录创建文件。sudo ls -ld /var/log/nginx/ sudo chown nginx:adm /var/log/nginx/ # 如果需要修正属主属组 sudo chmod 755 /var/log/nginx/ # 确保目录有执行权限SELinux 上下文在启用了 SELinux 的系统如 CentOS/RHEL上即使权限正确也可能因安全上下文不对而失败。检查并修正sudo ls -Z /var/log/nginx/ # 如果上下文不对恢复默认 sudo restorecon -Rv /var/log/nginx/3.3 日志轮转后应用不再写入新日志这几乎总是因为postrotate脚本配置错误或未生效。应用没有收到重新打开日志文件的信号所以还在向旧的已被重命名文件描述符写入。检查配置确认/etc/logrotate.d/下对应应用的配置文件中postrotate脚本的命令是正确的。对于不确定的信号最粗暴但不一定优雅的测试方法是直接重启服务。手动测试信号你可以手动模拟logrotate的过程来测试。先重命名当前日志文件sudo mv /var/log/nginx/access.log /var/log/nginx/access.log.old创建新文件sudo touch /var/log/nginx/access.log修改权限属主如果需要sudo chown nginx:adm /var/log/nginx/access.log向应用进程发送重载信号sudo kill -USR1或sudo systemctl reload nginx检查应用是否开始向新的access.log写入。3.4 如何清理 journald 的持久化日志如果journald配置了持久化存储它的日志位于/var/log/journal/目录下。清理方法如下# 查看当前日志占用的磁盘空间 sudo journalctl --disk-usage # 清理指定时间之前的日志例如清理7天前的 sudo journalctl --vacuum-time7d # 清理日志使总大小不超过指定值例如保留最多500MB sudo journalctl --vacuum-size500M # 清理日志只保留最近一定数量的文件 sudo journalctl --vacuum-files5也可以设置SystemMaxUse等在/etc/systemd/journald.conf中的参数让其自动管理。3.5 面对海量小日志文件怎么办有时不是单个文件大而是文件数量极多例如某个微服务为每个请求生成一个日志文件。这会导致inode耗尽用df -i查看同样使系统异常。策略调整修改应用配置避免生成海量小文件改为写入单个文件或按天/小时轮转的单个文件。批量清理使用find命令结合-mtime和-delete进行批量删除但需格外小心最好先-ls列出确认。# 危险先ls确认再执行delete sudo find /path/to/logs -type f -name *.log -mtime 30 -ls sudo find /path/to/logs -type f -name *.log -mtime 30 -delete使用 logrotate 通配符在logrotate配置中使用通配符匹配这些文件并进行统一的压缩和删除管理。日志管理是一个持续的过程没有一劳永逸的方案。核心在于理解你的系统日志产生规律结合logrotate配置自动化轮转并从应用层面控制日志输出粒度。定期检查/var/log目录的大小和logrotate的运行状态/var/lib/logrotate/status文件记录了上次轮转的时间将其纳入日常监控体系这样才能确保你的服务器磁盘空间永远“游刃有余”。