磁盘写满往往是运维中最让人被动的一类告警：服务仍在运行，日志仍在写入，但可用的字节数已经所剩无几。1Panel 提供了主机监控与告警能力，可以在磁盘使用率达到阈值时推送通知，但告警本身不会释放任何容量。要把“收到告警”变成“容量自动回落”，需要在告警之外补上一层可执行的归档与清理逻辑。

为什么告警之后容量依然在涨

常见的日志增长场景有三类：应用自身按天或按小时滚动写日志；Nginx、MySQL、容器运行时等中间件持续追加写入；容器标准输出被持久化到宿主机目录。这些文件的特点是持续写入、单文件不大但数量多、历史文件长期不清理。监控面板上看到的是一条上扬的曲线，而真正占用空间的往往是几个月前的归档文件。

因此只配置告警阈值，结果通常是：运维收到通知，登录服务器，手工删几个文件，容量暂时回落，两周后同样的问题再发生一次。

整体设计：告警负责发现，计划任务负责处置

比较稳妥的做法是把职责拆成三层：监控告警负责发现异常并通知人；1Panel 的计划任务负责按固定周期执行归档脚本；脚本自身负责压缩、迁出、保留与限流。这样即使告警渠道暂时不可用，常规归档仍会按时运行。

第一步：把告警阈值分出层级

建议至少设置两个层级，例如使用率到达 80% 预警、90% 紧急（具体数值应按业务写入速度自行设定）。预警层用于触发常规归档与人工确认，紧急层用于触发更激进的清理动作并同时通知值班人员。分层的好处是避免“一刀切”删除，给排查留出缓冲时间。

第二步：用计划任务承载归档动作

在 1Panel 中创建一个 Shell 类型的计划任务，按小时或每天固定时间执行。脚本应尽量幂等：无论执行多少次，结果都应该是把超过保留期的日志压缩归档、把超出容量上限的归档删除，而不是每次重复搬运。

第三步：归档而不是直接删除

直接 rm 日志文件在多数场景下是下策：一旦后续需要排查问题，证据已经消失。更合理的顺序是“先压缩、再迁出、最后删除”。压缩可使用 gzip 或 zstd，文本日志的压缩比通常很高，这一步就能回收可观的空间。

迁出目标优先选择与业务盘不同的位置：独立数据盘、挂载的网络存储，或对象存储。把归档包写回同一个已满的磁盘没有意义，反而会加剧写入压力。如果服务器只有单块盘，可以保留少量高压缩比的归档包，并为其设置明确的容量上限，超出后按最旧优先删除。

第四步：设置保留周期与容量双上限

只在脚本里写“保留 30 天”并不够。如果某天日志量突然放大十倍，30 天的量依然可能撑爆磁盘。建议同时约束两个维度：

• 时间维度：原始日志保留 N 天，压缩归档保留 M 天。
• 容量维度：归档目录占用不得超过设定上限，超限时按文件修改时间从旧到新删除。

两个条件任一触发即执行清理，才能覆盖突发流量场景。

第五步：验证与闭环

脚本上线后需要验证三件事：归档文件是否可正常解压读取；删除动作是否只作用于归档目录；磁盘使用率是否在告警后的一两个执行周期内回落。可在脚本末尾追加一条通知或日志记录，把本次释放的空间量写入系统日志，便于事后回溯执行效果。

容易踩坑的细节

• 句柄未释放：正在被进程写入的日志文件被删除后，磁盘空间不会立即释放。这类情况应先切割日志并让进程重新打开文件，或使用 truncate 将文件截断为空，而不是直接删除。
• 忽略容器日志：容器运行时与容器内应用的输出往往单独存放，归档策略需要覆盖到这些目录，否则清理效果会被抵消。
• 清理范围过大：脚本中的查找路径必须尽量精确，避免误删业务数据目录或配置文件。
• 并发执行：任务间隔过短时可能与前一次执行重叠，建议加入简单的执行锁。
• 只通知不处理：告警渠道（如邮件、企业微信、钉钉、飞书、Webhook，以实际版本支持的渠道为准）应配置到人，但不要把处置动作完全寄托在人工响应上。

落地检查清单

1. 确认磁盘监控项已开启，并设置分级阈值与通知渠道。
2. 梳理需要归档的日志目录清单，明确哪些属于可清理范围。
3. 编写归档脚本，包含压缩、迁出、保留策略与容量上限。
4. 在 1Panel 中创建计划任务，设置合理的执行周期。
5. 先用测试目录试跑，确认解压可用、删除范围正确。
6. 观察一到两周，根据实际释放量与业务写入速度调整阈值与保留天数。

磁盘告警的价值不在于“提醒你磁盘满了”，而在于为自动化处置争取时间窗口。把归档策略交给计划任务定时执行，把告警留给真正需要人判断的异常，容量管理才能从反复救火转向稳定运行。