如何避免服务器磁盘被日志撑爆？

运维工程师最怕的深夜报警，往往不是什么复杂的系统故障，而是这种看似简单的”磁盘爆满”问题。说实话，日志文件这个”隐形杀手”已经让太多同行栽过跟头了。记得去年有个朋友的公司，就因为Nginx访问日志没做切割，导致支付接口完全不可用，损失惨重。这不禁让人思考：我们到底该如何避免这种”低级错误”演变成严重事故？

日志管理的三个致命误区

很多人以为日志管理很简单，结果往往踩坑。第一个误区是”日志越多越好”——实际上无节制的debug日志不仅占用空间，还会拖慢系统性能。我就见过一个API服务，把整个请求体都记录到日志里，结果日志文件比业务数据还大。第二个误区是”日志不用清理”，有些开发者天真地认为磁盘空间永远够用，殊不知一个失控的循环日志就能在几小时内塞满磁盘。第三个误区最可怕：把日志写在系统盘。你知道么？当系统盘100%占用时，连最简单的命令行都可能无法执行！

实战中的解决方案

经过多次”血泪教训”，我现在会给每台服务器配置这些防护措施：首先是用logrotate做日志轮转，这个Linux自带的小工具简直是个神器，可以按时间或大小切割日志，还能自动压缩旧日志。配置起来也很简单，比如针对Nginx日志：

/var/log/nginx/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

其次是给关键目录设置监控报警，我习惯用Prometheus+Alertmanager组合，当磁盘使用超过80%时就触发报警。最后也是最重要的：一定要建立日志分级制度。生产环境永远只记录WARNING及以上级别的日志，DEBUG日志只能在测试环境使用。

那些年踩过的坑

说来惭愧，我也不是一开始就懂得这些。记得刚入行时部署的一个Java应用，因为没配置GC日志轮转，结果三个月后运维同事惊慌失措地打电话说服务器连ssh都登不上了——32GB的GC日志把磁盘塞得满满当当。从那以后，我在所有Java应用的启动参数里都会加上这样的配置：

-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=20M

你看，日志管理就是这样，平时不显山露水，一旦出事就是大问题。但只要我们提前做好这些防护措施，至少能保证半夜不会被报警电话吵醒，你说对吧？