1. 为什么需要清理Linux系统日志刚接手一台Linux服务器时我经常遇到一个头疼的问题系统运行一段时间后各种服务开始报错新进程无法创建甚至SSH都连不上。后来才发现是日志文件把磁盘空间占满了。这种情况在长期运行的服务器上特别常见特别是那些没有配置自动日志轮转的服务。日志文件本质上就是系统和服务运行的黑匣子记录着各种事件信息。但如果不加控制这些文件会像滚雪球一样越来越大。我曾经见过一个Nginx的access.log文件长到50GB直接把/var分区塞满。更糟的是某些服务在磁盘写满时会直接崩溃而不是优雅地降级。清理日志不只是简单的删除文件。你需要考虑哪些日志可以安全删除如何保留必要的调试信息怎样建立长期有效的管理机制2. 手动清理快速释放空间的应急方案2.1 定位磁盘空间占用元凶当磁盘告急时首先要找出罪魁祸首。我最常用的组合拳是# 查看各分区使用情况 df -h # 查看/var目录下各子目录大小 du -sh /var/* | sort -h # 找出大于100MB的日志文件 find /var/log -type f -name *.log -size 100M -exec ls -lh {} \;这几个命令能快速锁定目标。有一次我用这个方法发现是docker容器的json日志占了80%空间单个文件就有20GB。2.2 安全删除日志的三种姿势直接rm删除虽然简单但有些服务需要特殊处理清空正在写入的日志文件# 对于仍在被进程打开的文件 truncate -s 0 /var/log/syslog按时间清理旧日志# 删除30天前的nginx日志 find /var/log/nginx -name *.log -mtime 30 -delete按大小轮转日志# 使用logrotate立即执行轮转 logrotate -f /etc/logrotate.d/nginx特别注意删除日志前如果可能有排查需要的记录建议先压缩备份gzip /var/log/syslog.13. 自动化清理配置logrotate实现智能管理3.1 logrotate核心配置详解logrotate是Linux自带的日志管理神器它的配置文件通常位于主配置/etc/logrotate.conf服务专用配置/etc/logrotate.d/一个完整的配置示例以nginx为例/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate /usr/lib/nginx/modules/ngx_http_log_module.so endscript }关键参数说明rotate 14保留14个历史版本compress使用gzip压缩旧日志delaycompress延迟一次再压缩方便排查最近问题size 100M达到100MB就轮转可与daily同时使用3.2 实战中的坑与解决方案我在生产环境遇到过几个典型问题权限问题新创建的日志文件权限不对导致服务无法写入。解决方法是在配置中添加create指令指定权限。磁盘空间不足压缩大日志时可能临时需要双倍空间。可以设置nocompress禁用压缩或者先手动清理。日志不轮转检查是否配置了size/daily等触发条件以及日志文件是否匹配配置中的路径。4. 系统级日志管理策略4.1 journalctl管理systemd日志对于使用systemd的系统journal日志会默认存储在/run/log/journal重启后消失。要持久化存储# 创建存储目录 mkdir /var/log/journal systemctl restart systemd-journald清理旧日志的命令# 保留最近500MB日志 journalctl --vacuum-size500M # 保留最近2周日志 journalctl --vacuum-time2weeks4.2 rsyslog的高级配置技巧rsyslog的配置文件位于/etc/rsyslog.conf。可以通过模板定义日志分割规则# 按日期和程序名分割日志 $template DailyPerHostLogs,/var/log/%programname%-%$YEAR%%$MONTH%%$DAY%.log *.* ?DailyPerHostLogs限制日志大小的经典方法# 当日志超过100MB时重新开始 $outchannel log_rotation,/var/log/mylog.log,104857600,/opt/scripts/rotate.sh5. 容器环境的日志处理方案5.1 Docker日志驱动配置Docker默认的json-file驱动会无限增长日志推荐修改daemon.json{ log-driver: json-file, log-opts: { max-size: 100m, max-file: 3 } }对于已经运行的容器可以临时清理日志truncate -s 0 $(docker inspect --format{{.LogPath}} 容器名)5.2 Kubernetes集群日志管理在K8s环境中推荐以下方案节点级日志代理部署Fluentd或Filebeat收集日志Sidecar模式在Pod中运行日志处理容器应用直接输出程序直接写入ES等中央日志系统一个实用的kubectl日志清理命令# 清理所有pod的旧日志 kubectl get pods | awk {print $1} | xargs -I{} kubectl logs --tail100 {}6. 预防为主的日志治理体系建立完整的日志生命周期管理分级存储热数据近期日志存本地温数据存NAS冷数据归档到对象存储日志采样对DEBUG等低级别日志按比例采样集中化管理使用ELK或Loki统一收集分析告警机制监控关键日志的增长速度一个简单的磁盘空间监控脚本#!/bin/bash THRESHOLD90 CURRENT$(df / | grep / | awk { print $5} | sed s/%//g) if [ $CURRENT -gt $THRESHOLD ]; then logger -t disk_alert 磁盘使用率超过阈值: $CURRENT% # 这里可以添加邮件或webhook告警 fi日志管理不是一劳永逸的工作需要根据业务特点持续优化。我建议每月检查一次日志配置每季度做一次归档清理。记住好的日志系统应该像优秀的管家——既不会让垃圾堆积也不会丢掉重要物品。