只给磁盘设置“使用率超过90%”告警，并不能可靠保护日本服务器上的业务：大容量文件系统可能还有充足余量，小容量文件系统却可能来不及处理；大量小文件还可能在空间未满时先耗尽inode。

可将磁盘空间和inode使用率的80%设为预警起点、90%设为严重告警起点，再叠加“最低剩余量”和“预计耗尽时间”判断。这些数字是便于落地的初始配置，不是通用安全线。真正的阈值应保证：从收到告警到完成处置期间，剩余容量仍能承受业务写入。服务器部署在日本，并不会改变这个判断原则。

先明确监控目标：在写入失败前留出处理时间

本文以Linux服务器、本地可写文件系统为主要适用环境。配置前需要确认实际挂载点、文件系统类型，以及业务数据、日志、临时文件分别写到哪里。不同目录如果属于同一个文件系统，应共享容量告警，不能将目录当成独立磁盘。

监控至少要覆盖两类资源：

inode用于记录文件对象的元数据，普通文件、目录等都会消耗它。对于inode数量通常在创建文件系统时确定的ext4，大量小文件尤其值得关注；XFS等支持动态分配inode的文件系统，不能把某一时刻上报的总量简单理解成固定文件数量上限，应结合其分配机制、剩余空间和实际错误判断。

此外，容量告警不是磁盘性能告警。空间接近耗尽不能单独证明读写变慢，磁盘使用率较低也不能证明I/O正常。这里的目标是避免空间或inode不足导致写入、建文件失败，而不是用容量比例代替性能测试。

统一指标口径，再设置三级阈值

空间使用率应关注业务真正可用的容量

Linux文件系统可能保留部分块供特定用途使用，因此“空闲空间”不一定等于普通业务进程能够使用的空间。监控时应优先关注面向普通进程的可用空间，例如监控采集器中的avail类指标，而不是只看free。

可以统一采用以下告警口径：

空间不可用占比 = (1 - 业务可用空间 / 文件系统总空间) × 100%
inode使用率 = (1 - 可用inode / inode总量) × 100%

第一项包含已使用空间及普通业务无法使用的保留部分，不应未经核对就标成与df完全一致的“已用比例”。GNU df的Use%通常根据已用空间和可用空间计算，存在保留块时，与上述公式可能不同。

监控面板、告警表达式和人工核验必须采用一致口径。否则会出现面板已报警、登录服务器却看到另一个百分比的情况。

用初始阈值建立分级，而不是直接认定危险程度

以下配置适合尚未积累完整容量历史、需要先建立基础告警的场景；空间和inode应分别计算、分别触发。

表中的比例和时间都是建议起点，用于建立分级，不代表经过业务验证的安全标准。增长特别快的临时目录可能需要更低阈值；增长缓慢的大容量归档文件系统，则应结合绝对余量调整通知级别。

空间和inode应采用“任意一项满足即触发”，不能要求两者同时超过阈值。inode耗尽时，即便还有大量可用空间，也可能无法创建新文件。

用剩余量和增长趋势修正百分比

剩余量应覆盖处置窗口

更贴近业务的设置方法，是先确定处理所需时间，再计算最低余量：

最低空间余量 = 设计净写入速率 × 处置窗口 + 突发空间储备
最低inode余量 = 设计inode净消耗速率 × 处置窗口 + 突发inode储备

这里的处置窗口包括发现、确认、审批以及完成清理或扩容的时间，不能只计算执行操作的时间。设计速率应来自实际监控中具有代表性的高负载时段，不宜直接采用全天平均值。

例如，假设某业务高负载期间净增加空间为每小时4 GiB，完成处理需要3小时，则仅覆盖这一窗口就需要12 GiB，尚未计入突发储备。这个计算只说明最低余量的确定方法，不能证明12 GiB适合其他服务器；若集中写入强度更高，阈值必须上调。

对inode采用同样思路，但应观察“已用inode的净增长”，而不是只统计应用创建文件的总次数。文件删除会释放inode，临时文件快速创建又删除时，总创建量不等于净消耗量。

预计耗尽时间用于识别快速恶化

当剩余资源持续下降时，可以估算：

预计空间耗尽时间 = 当前可用空间 / 空间净消耗速率
预计inode耗尽时间 = 当前可用inode / inode净消耗速率

若预计耗尽时间短于实际处置窗口，即使使用率还没有达到80%，也应升级告警。反过来，使用率较高但长期平稳的文件系统，可以保留容量预警，并减少重复通知。

趋势告警需要满足边界条件：

• 采样连续，不能将数据缺失解释成容量不变。
• 净消耗速率为正；资源正在释放时，不应强行给出耗尽时间。
• 短窗口用于捕捉突发，较长窗口用于确认趋势，不能用单次跳变外推。
• 对日志轮转、批处理、缓存回收等周期行为，应覆盖完整周期观察。
• 周期性清理“即将执行”不能视为资源已经释放，应以采集结果为准。

线性预测适合持续增长负载，对阶跃式写入、批量文件落盘只能提供辅助判断。此时最低剩余量通常比单一预测值更可靠。

在服务器上核验：从只读检查到告警演练

以下命令适用于常见GNU/Linux环境。findmnt通常由util-linux提供，df通常由GNU coreutils提供；先确认工具已安装。将示例中的/var替换为实际业务路径。

findmnt -T /var
df -hT /var
df -i /var
df -B1 --output=source,size,used,avail,pcent,target /var

这些操作只读取状态，不会修改业务文件：

• findmnt确认路径对应哪个挂载点，避免监控了错误文件系统。
• df -hT查看空间、类型及挂载位置。
• df -i核对inode使用情况。
• 最后一条以字节查看空间，便于与监控原始值比较，减少单位和取整差异。

如果inode总量显示为零、不可用或不符合预期，应先检查文件系统与采集器是否支持该指标，不能直接套用除法公式。

只有确认某个挂载点异常后，再缩小范围检查目录占用：

du -x -h --max-depth=1 /var

该命令不删除文件，但会遍历目录，文件数量多时可能增加I/O和元数据访问负担，宜在低负载时执行。权限不足会造成统计不完整；不要为每次告警自动扫描整棵目录树。

如果df显示占用较高，而du明显偏低，可以进一步检查已删除但仍被进程打开的文件：

lsof +L1

该命令需要安装lsof，查看其他用户进程可能需要管理员权限；进程和打开文件很多时也有额外开销。此类文件可能仍占用空间和inode，但这不是差异的唯一原因，权限、挂载覆盖及文件系统元数据也可能影响结果。发现进程后应交由对应服务的变更流程处理，不宜直接终止进程。

告警验证不应通过写满生产磁盘完成。可以使用监控系统的规则测试能力输入模拟指标，检查阈值、持续时间、通知路由和恢复消息；如临时修改测试规则，应保留原配置并在验证后恢复。

降噪之后，还要保留真正的故障前兆

告警应以“实例＋文件系统或挂载点”为主要归属，同一资源的预警、严重、紧急状态做升级与抑制，避免三个级别同时反复通知。但通知中仍要注明触发的是空间还是inode，不能将两个原因合并成一个含糊的“磁盘异常”。

恢复条件可加入迟滞。例如预警在80%触发，可先尝试设置为降至75%以下并持续一段时间后恢复，减少阈值附近的反复开关。这同样是可调整的示例；若余量和耗尽时间条件仍然成立，就不能仅凭比例下降宣布恢复。

监控范围也要明确：伪文件系统、只读挂载及重复采集的同一底层文件系统通常不适合直接套用普通数据盘规则；业务实际使用的临时文件系统则不能一概排除。关键挂载点消失、变为只读或指标失联，应单独报警，不能当成容量恢复。

更值得提前关注的信号包括：日志轮转后空间没有按历史规律回落、inode增长明显加快、剩余量连续下降，以及应用出现“设备上没有剩余空间”等写入错误。如果整盘指标正常而业务仍无法写入，还需核对用户或项目配额，整盘剩余容量不能代表该业务拥有可用额度。

最终应在日本服务器经历业务高峰、批处理、日志轮转或文件保留策略变更后复测阈值。合格的告警不是“在90%时响过”，而是能在资源耗尽之前，给实际处置留下足够时间，并在资源真正恢复后可靠关闭。