宝塔日志频繁写入导致磁盘告急,我怎么处理的

2025.6.23 杂七杂八 1533
33BLOG智能摘要
上周五晚上,服务器磁盘使用率飙升至99%,排查发现/va/log目录占用了37G空间,主要由宝塔默认开启的登录日志、SSH日志等文件积攒导致。由于日志未轮转,三个月累计占用大量存储。通过清空日志、安装logrotate工具并配置自动轮转、关闭非必要日志,紧急释放空间。后续增加了磁盘报警监控、优化宝塔配置及定期清理超期日志的脚本。此次事件警示,忽视日志管理可能导致严重后果。
— 此摘要由33BLOG基于AI分析文章内容生成,仅供参考。

记一次宝塔日志爆盘的惊魂夜:我是如何从 99% 磁盘占用中抢救服务器的

宝塔日志频繁写入导致磁盘告急,我怎么处理的

上周五晚上十点半,我正瘫在沙发上刷短视频,突然企业微信连续弹出三条告警——服务器磁盘使用率超过95%!作为运维老鸟,我太清楚这意味着什么:再晚半小时处理,网站可能就要集体扑街了。赶紧一个鲤鱼打挺冲到电脑前,开始了这场与日志文件的深夜搏斗…

一、故障现场:/var/log 成了磁盘黑洞

连上服务器第一件事就是 df -h,果然 / 分区红了:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   48G     0 99% /

du -sh /* | sort -rh 快速定位,发现 /var/log 目录居然占了 37G!其中 btmpsecure 两个日志文件各占 15G+,好家伙,这俩文件比我去年写的年终总结都大。

二、真相大白:宝塔的”贴心”日志服务

仔细检查发现,宝塔默认开启了以下日志服务:

  • 系统登录日志(/var/log/btmp
  • SSH 登录日志(/var/log/secure
  • Nginx/Apache 访问日志
  • MySQL 慢查询日志

最坑的是——这些日志全都没有自动轮转!我的服务器每天被爬虫光顾几百次,每次扫描都会在 secure 日志里留下记录,三个月下来可不就积少成多了。

三、急救三板斧:清淤+限流+监控

第一步:紧急释放空间
先用 truncate -s 0 /var/log/btmp 清空文件(注意不能用 rm,会引发进程报错),然后安装 logrotate 工具:

yum install -y logrotate
cp /etc/logrotate.conf /etc/logrotate.conf.bak

第二步:配置日志轮转
/etc/logrotate.d/ 下新建 bt-panel 文件:

/var/log/btmp {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0600 root utmp
}

/var/log/secure {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

第三步:关闭非必要日志
在宝塔面板「安全」页面,关闭「登录日志」和「SSH 登录日志」。对于 Nginx 日志,我保留了访问日志但修改了格式,去掉了不用的字段。

四、长效预防:三个血泪经验

  1. 日志监控要前置:现在我在 Prometheus 加了磁盘预测报警,用量超过80%就触发
  2. 新装宝塔必做三件事:关登录日志、设 logrotate、改 Nginx 日志格式
  3. 定期检查 /var/log:写了个每周运行的脚本,用 find 清理超过30天的日志

折腾到凌晨一点,看着 df -h 显示可用空间回升到 15G,终于长舒一口气。这次事故给我上了生动的一课:所有不设上限的”贴心服务”,最终都会变成埋雷现场。下次再看到宝塔默认配置,我一定要多问一句:这玩意儿会自己长大吗?

评论

  • 同款经历!上次半夜被报警吵醒处理日志问题,现在看到宝塔就PTSD了

  • 学到了👍 原来可以用truncate清空日志文件,之前都是直接rm -rf莽过去

  • 宝塔这个默认配置真的坑,新装完不处理迟早要炸