Linux服务器磁盘空间管理与日志清理实战指南
1. 问题现象与紧急处理当Linux服务器磁盘空间被日志文件占满时系统会表现出明显的异常症状。最常见的就是在执行文件操作时收到No space left on device的错误提示这时候我们需要立即采取应急措施防止服务中断。1.1 快速诊断磁盘状态首先用df命令查看整体磁盘使用情况df -h这个命令会显示所有挂载点的空间使用率重点关注Use%列达到或接近100%的分区。典型的输出类似Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 39G 0 100% / /dev/vdb1 100G 80G 20G 80% /data注意如果发现某个分区使用率异常高不要立即执行删除操作先确认该分区是否包含重要数据1.2 定位大文件目录使用du命令快速找出占用空间最大的目录du -h --max-depth1 / | sort -h这个组合命令会扫描根目录下所有一级子目录的大小按人类可读格式(-h)显示按大小排序(sort -h)典型输出示例4.0K /lostfound 16M /opt 145M /boot 1.2G /home 3.8G /var 15G /data/logs1.3 临时应急处理当空间完全耗尽时可以先清理一些临时文件腾出空间# 清理系统日志轮转文件 sudo rm -f /var/log/*.gz /var/log/*.old # 清空不重要的日志文件 sudo truncate -s 0 /var/log/syslog sudo truncate -s 0 /var/log/kern.log # 删除临时目录文件 sudo rm -rf /tmp/*重要提示truncate命令比直接删除更安全它保留文件描述符但清空内容避免影响正在写入日志的服务2. 日志文件深度分析与处理2.1 识别问题日志文件使用组合命令查找大日志文件find /var/log -type f -name *.log -exec du -h {} | sort -h | tail -n 20这个命令会在/var/log目录下查找所有.log文件计算每个文件大小排序后显示最大的20个文件2.2 日志轮转配置优化大多数Linux系统使用logrotate管理日志检查配置文件cat /etc/logrotate.conf ls /etc/logrotate.d/典型的优化配置示例以nginx为例/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate /usr/sbin/nginx -s reload /dev/null 21 || true endscript }关键参数说明daily: 每天轮转rotate 14: 保留14个历史版本compress: 启用gzip压缩delaycompress: 延迟压缩前一个版本2.3 手动日志清理策略对于没有自动轮转的日志可以创建定时任务# 每天凌晨清理30天前的日志 0 0 * * * find /data/logs -type f -name *.log -mtime 30 -delete安全删除建议先确认日志是否重要可以先移动到临时目录观察几天使用shred安全删除敏感日志shred -u -z -n 3 sensitive.log3. 高级问题排查技巧3.1 已删除但未释放的空间有时候删除文件后空间并未释放可能是因为仍有进程在占用lsof | grep deleted处理方案重启持有文件句柄的服务或使用gdb工具释放gdb -p [PID] EOF call close([FD]) EOF3.2 Inode耗尽问题大量小文件可能耗尽inodedf -i解决方案合并小文件使用tar归档旧日志调整文件系统inode数量需重新格式化3.3 特殊文件系统问题Docker存储驱动可能占用大量空间docker system df清理命令docker system prune -a --volumes4. 长效预防措施4.1 监控与告警设置配置prometheus监控规则示例groups: - name: disk.rules rules: - alert: DiskSpaceRunningLow expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 85 for: 5m labels: severity: warning annotations: summary: Disk space low on {{ $labels.instance }} description: {{ $labels.mountpoint }} on {{ $labels.instance }} has only {{ printf %.2f $value }}% free space4.2 自动化清理脚本示例日志清理脚本#!/bin/bash LOG_DIR/data/logs RETENTION_DAYS30 MAX_USAGE80 current_usage$(df -h $LOG_DIR | awk NR2 {print $5} | tr -d %) if [ $current_usage -gt $MAX_USAGE ]; then echo $(date) - Current usage $current_usage% exceeds threshold $MAX_USAGE% find $LOG_DIR -type f -name *.log* -mtime $RETENTION_DAYS -delete systemctl reload rsyslog echo Cleanup completed else echo $(date) - Current usage $current_usage% is normal fi4.3 日志架构优化建议集中式日志方案ELK Stack (Elasticsearch Logstash Kibana)Loki Grafana商业方案如Splunk日志分级存储热数据本地SSD温数据网络存储冷数据对象存储无服务日志方案AWS CloudWatch LogsGoogle Cloud Logging阿里云SLS5. 实战案例解析5.1 Nginx日志爆炸案例问题现象/var分区2天内被占满主要占用者是/var/log/nginx/access.log根本原因未配置logrotate访问量突增到10万QPS解决方案紧急处理mv /var/log/nginx/access.log /tmp/nginx-access.bak kill -USR1 $(cat /run/nginx.pid)长期方案http { log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log main buffer32k flush1m; open_log_file_cache max1000 inactive20s valid1m min_uses2; }5.2 Java应用堆栈日志问题典型症状多线程应用产生GB级日志日志文件包含大量重复堆栈跟踪优化方案修改logback配置appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender fileapp.log/file rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePatternapp.%d{yyyy-MM-dd}.%i.log.gz/fileNamePattern maxFileSize100MB/maxFileSize maxHistory30/maxHistory totalSizeCap5GB/totalSizeCap /rollingPolicy encoder pattern%d{ISO8601} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder /appender添加异常日志过滤器turboFilter classch.qos.logback.classic.turbo.DuplicateMessageFilter allowedRepetitions3/allowedRepetitions cacheSize1000/cacheSize /turboFilter6. 专家级技巧与工具推荐6.1 高级分析工具ncdu - 交互式磁盘分析器ncdu /var/logdust - 更直观的du替代品dust -d 2 /varplog - 日志模式分析器plog -p %h %l %u %t %r %s %b access.log6.2 日志压缩技巧使用zstd高效压缩# 压缩 find /var/log -name *.log -type f -mtime 7 -exec zstd --rm {} # 解压查看 zstdcat logfile.log.zst | less6.3 日志分析最佳实践结构化日志JSON格式关键字段索引时间戳标准化采样策略高频日志随机采样错误日志全量保留调试日志按需开启日志分级ERROR: 必须立即处理WARN: 需要关注INFO: 业务流水账DEBUG: 开发调试用在实际运维中我发现很多磁盘空间问题都是由于缺乏预防性维护导致的。建议建立定期检查机制比如每周一次的磁盘健康检查每月一次的日志归档。对于关键系统可以考虑使用LVM等支持在线扩容的文件系统方案这样在空间不足时可以快速扩展而不用停机。