很多网站出现磁盘告警时，排查方向会先落到数据库、附件目录或备份文件。但在真实运维里，日志往往是更容易被低估的一类文件：它每天都在增长，出问题时又必须保留足够线索。如果日志没有按规则轮转，轻则磁盘被写满，重则服务无法写入新日志，故障现场反而被覆盖或丢失。
日志为什么会越积越多
Web 服务、数据库、应用程序、安全组件都会持续写日志。访问量不高的网站，也可能因为爬虫扫描、错误重试、接口异常、慢查询或调试日志未关闭，产生远超预期的日志量。尤其是 access log、error log、PHP-FPM 日志、应用框架日志和数据库慢日志，一旦没有限制单文件大小和保存周期，就会长期堆在服务器上。
日志增长还有一个特点：它不是一次性占用，而是每天一点点吞掉空间。等到监控报警时，管理员看到的往往已经是几十 GB 的历史文件，很难立刻判断哪些可以删、哪些还要留作排障依据。
轮转不只是删除旧文件
日志轮转的核心不是“清理磁盘”，而是按时间或大小把日志切分、压缩、保留和淘汰。常见策略包括每天切一次、文件超过指定大小后切分、保留最近 7 到 30 天、旧日志压缩存档、超过周期后自动删除。这样既能控制磁盘占用，也能让排障时快速定位某一天或某一小时的日志。
以 Linux 上常见的 logrotate 为例，它通常会配合 cron 或 systemd timer 周期执行。配置里可以指定日志路径、轮转频率、保留份数、压缩方式，以及切分后是否通知服务重新打开日志文件。Nginx、Apache、PHP-FPM、MySQL、Redis 等服务都可能需要类似处理。
磁盘写满后影响会连锁放大
日志占满磁盘并不只是“少一点空间”的问题。系统分区满了以后，服务可能无法写入临时文件，数据库可能无法落盘，缓存可能异常，证书续期、备份任务和上传功能也可能失败。更麻烦的是，有些程序在无法写日志时不会立刻报出清晰错误，只表现为接口变慢、后台卡顿或偶发 500。
如果网站部署在单盘云服务器上，系统、程序、数据库、日志和备份都挤在同一块磁盘，风险会更集中。日常可以给日志、备份、数据库分别设置更清晰的目录和保留规则；业务增长后，也可以考虑把关键数据和日志拆到独立磁盘或对象存储。
排障时日志要留得住也找得到
日志保留太短，故障发生后可能已经被自动清掉；保留太久，又会增加磁盘压力。比较实用的做法是根据业务节奏设定分层保留：近期日志保留明文便于 grep，较早日志压缩存档，超过合规或排障需要的周期再删除。对于电商、后台系统、接口服务等关键业务，还要单独保留错误日志、访问高峰日志和安全审计日志。
如果业务跑在云服务器上，选型时不要只看 CPU 和内存，也要评估磁盘容量、快照策略和后续扩容是否方便。例如部署企业官网、后台管理系统或轻量 API 服务时，可以根据访问量选择合适配置的 速维云云服务器，再配合系统层日志轮转和定期备份，避免小问题拖成整站不可用。
建议先检查这几项
第一，看磁盘使用率和 inode 是否紧张，常用命令包括 df -h、df -i、du -sh /var/log/*。第二，确认 Nginx、PHP-FPM、数据库和应用目录里的日志是否都有轮转规则。第三，检查轮转任务是否真的在执行，不要只看配置文件存在。第四，确认切分后服务是否重新打开了新日志文件，否则可能出现文件已删除但进程仍占用空间的情况。
最后，不建议在故障现场直接粗暴删除整目录日志。更稳妥的方式是先确认最大文件、时间范围和服务占用情况，把明显过期的压缩日志转移或清理，再补上轮转规则和监控告警。日志管理做得好，磁盘更稳，排障也更有底气。
