容量故障往往不是突然发生，而是余量持续被消耗，直到磁盘写满或连接池无法分配。只在使用率超过某个比例时通知，可能来不及完成排查、扩展、数据整理和验证。趋势分析需要回答：资源按什么速度变化、增长来自哪里、预计何时耗尽，以及行动至少需要多少时间。容量余量应和行动周期一起评估，而非脱离运维流程单看百分比。🧭
按挂载点监控总空间、可用字节、净增长速率、inode余量和文件数量。整机平均使用率可能掩盖日志卷先满、数据库卷增长过快或临时目录耗尽。进一步按目录类型观察日志、数据库文件、对象缓存、备份和临时文件，确定增长是业务数据、未轮转日志还是异常重复产物。文件系统空间充足但inode耗尽，同样会导致新文件创建失败。
对平稳区间可估算time_to_full = free_bytes / net_growth_per_second，单位需一致。净增长应从可用空间的变化计算，并排除压缩、轮转、快照回收造成的周期性波动。除近期平均斜率外，还应观察高峰日或批处理窗口斜率；若增长明显非线性，简单线性外推只适合作为下界参考。📦
数据库连接、应用池连接、文件描述符和下游客户端连接都有各自上限。需要同时看已用、空闲、等待者、拒绝数、连接创建速率及持有时间。连接数随请求率同步上升且峰后回落，可能是正常并发；流量平稳但连接数持续阶梯增长，可能是关闭路径遗漏、长事务或池中对象未归还。
数据库当前连接未满并不代表应用没有连接瓶颈：请求可能排在本地池外，尚未建立数据库会话。应用池等待者增加而数据库空闲连接仍多，可能是池配置、连接验证或路由分片问题。对照请求并发、请求时长、长事务和pool_waiters，判断瓶颈是在资源上限还是资源回收。⚙️
短窗口用于识别突发，长窗口用于看到日周期、周周期和业务活动。比较工作日与周末、备份时段与非备份时段，避免把周期性峰值误判为持续增长，也避免长周期平均抹平近期加速。可以分别计算近期净增长、高峰净增长和已知业务计划下的需求，再选择合理保守的预测期限。行动点应早于预计耗尽日期，并覆盖负责人响应、决策、执行和回归验证时间。
容量扩展并非总能即时完成。存储扩容可能涉及文件系统扩展和应用验证；连接上限增加也可能把压力转移到数据库CPU、锁竞争或内存。预测应与扩展方案的前置条件结合，不能假设提高硬上限就能解决资源瓶颈。🔍
空间曲线突然下降可能来自挂载切换或采集断点，并非清理成功；连接曲线下降也可能是应用无法建连。先核对卷身份、采集完整性、池指标定义和实例数量，再解读趋势。为每个关键卷和连接池设定安全余量、预测窗口和行动负责人。验收时检查告警能指出资源对象、当前可用量、近期斜率、估计耗尽时间及所需行动期限；在测试环境模拟轮转周期或峰值写入，确认模型不会把短时波动当成永久趋势。定期比较预测与实际，记录误差原因并调整窗口或增长分类，容量管理才形成闭环。✅
