【运维发布】磁盘水位：日志盘的预警与自动清理

实战应用：用在哪里

游戏服务器每天产生 20GB 的日志文件，一周即可写满 500GB 的日志盘，磁盘写满导致服务端无法写入新的日志甚至影响数据库落盘。磁盘水位管理设置两道预警：使用率 80% 触发日志压缩归档、使用率 90% 触发自动清理旧日志并告警运维扩容。

水位监控与分级处置

定时器每小时检查一次磁盘使用率，超过 80% 触发日志压缩、超过 90% 自动删除 7 天前的旧日志并告警运维扩容。

setontimerex(231, 3600)
function ontimer231()
    local usage = getDiskUsage("/var/log")
    if usage >= 90 then
        callscript("cleanup_old_logs", 7)
        sendmail("#运维老张", 960, "磁盘空间紧急",
            "日志盘使用率 " .. usage .. "%，已清理 7 天前日志", "")
    elseif usage >= 80 then
        callscript("compress_logs")
        sendmail("#值班老张", 961, "磁盘空间预警",
            "日志盘使用率 " .. usage .. "%，已压缩归档", "")
    end
end

日志轮转与清理策略

日志文件按天切割并压缩归档，压缩后的归档日志保留 30 天后自动删除，活跃日志文件按大小超过 500MB 时轮转。

local LOG_RETENTION_DAYS = 30
local MAX_LOG_SIZE = 500
local function rotateIfNeeded(currentSize)
    if currentSize > MAX_LOG_SIZE then
        callscript("rotate_log")
        callscript("compress_log")
    end
end

验证与监控

水位监控验证使用率 79%、81%、89%、91% 四个边界的分档触发；日志轮转验证轮转后的文件名带日期后缀可追溯；压缩归档的日志文件可正常解压读取。监控磁盘使用率的小时曲线与日志增量速率，增速异常说明有异常日志输出源。

踩坑记录

日志压缩用 gzip 单线程执行，压缩 20GB 日志耗时 30 分钟导致压缩期间磁盘 IO 被占满，改用并行压缩后耗时缩短。日志清理按修改时间判断但文件被 touch 过修改时间更新了，清理逻辑改为按文件名中的日期后缀判断。磁盘使用率通过 df 命令获取但 df 在 NFS 挂载点上返回不准确，改为直接读 /proc/mounts 中的信息。清理脚本误删了当前正在写入的活跃日志文件，清理逻辑排除最近 1 小时内修改过的文件。

快照保留策略要区分全量与增量：全量快照保留十四天已够回档使用，增量快照三天一清理。清理脚本必须走白名单目录，曾有通配符写得太宽，把同盘位的导表缓存一并删掉，次日开服加载明显变慢，排查了半天时间才定位到删除清单，此后清理逻辑都要求先打印清单再执行。