计算磁盘满前的天数

Question

我们使用石墨来跟踪磁盘使用历史。当可用空间低于一定数量的块时，我们的警报系统会查看来自石墨的数据以提醒我们。

我想获得更智能的警报 - 我真正想要的是关心的是“在我必须对可用空间做一些事情之前我还有多长时间？”，例如，如果趋势表明在 7 天内我将用完磁盘空间然后引发警告，如果不到 2 天，则引发错误。

Graphite 的标准仪表板界面对于衍生品和 Holt Winters 置信度带非常智能，但到目前为止我还没有找到将其转换为可操作指标的方法。我也可以用其他方式处理数字（只需从石墨中提取原始数字并运行脚本来执行此操作）。

一个复杂的问题是图形不平滑 - 文件被添加和删除，但随着时间的推移，总体趋势是磁盘空间使用量增加，因此可能需要查看局部最小值（如果查看“磁盘空闲”指标） ) 并在低谷之间绘制趋势。

有没有人做过这个？

Answer 1

老实说，无论如何“天数”确实是一个糟糕的指标——文件系统在接近 100% 的利用率时变得非常愚蠢。
我真的建议使用传统的 85%、90%、95% 阈值（警告、警报和严重的你真的需要立即修复这个）——这应该会给你很多现代磁盘上的警告时间（假设一个 1TB 驱动器：85% 的 TB 仍然为您留下大量空间，但您知道一个潜在的问题，90% 的您应该计划磁盘扩展或其他一些缓解措施，而 95% 的 TB你还有 50GB 的空间，应该能很好地修复它）。

这也确保您的文件系统或多或少地以最佳方式运行：它有足够的可用空间来处理创建/修改/移动大文件。

如果您的磁盘不是现代磁盘（或者您的使用模式涉及将大量数据扔到磁盘上），您可以轻松调整阈值。

如果您仍然使用“天数直到满”指标，您可以从石墨中提取数据并对其进行一些数学计算。 IBM 的监控工具实施了几天直到完整指标，这可以让您了解如何实施它，但基本上您正在获取历史上两点之间的变化率。

为了您的理智，您可以使用 Graphite 的衍生物（它会为您提供随时间的变化率）并使用它进行项目，但如果您真的想要“更智能”的警报，我建议使用每日和每周的变化率（计算基于一天/一周的高峰使用量）。

您使用的具体预测（最小变化率、最大变化率、平均变化率、加权平均等......）取决于您的环境。IBM 的工具提供了如此多的不同视图，因为很难确定一种通用的模式。

最终没有算法会非常擅长做你想要的那种计算。磁盘利用率是由用户驱动的，而用户是 Rational Actor 模型的对立面：当一个疯子决定今天是他们将执行完整的系统内存转储到他们的主目录。只是因为。

Answer 2

为此，我们保留“平均充满时间”或“平均故障时间”指标，使用统计趋势及其标准差在简单的静态阈值上添加更智能（不太愚蠢）的逻辑。

最简单的警报：只是一个任意阈值。不考虑与实际磁盘空间使用情况有任何关系。

• 示例：当前% > 90%

简单 TTF：更聪明一点。计算未使用的百分比减去缓冲区，然后除以零保护率。统计上不是很可靠，但当我的用户上传他们的猫视频语料库（真实的故事）时，已经救了我好几次了。

• 示例：(100% - 5% - 当前%) / MAX(比率(当前%), 0.001%)

更好的 TTF：但我希望避免对 99% 的静态只读卷发出警报（除非它们有任何更改），并且我希望对嘈杂的卷进行更主动的通知，并检测具有非托管磁盘空间占用的应用程序。哦，简单 TTF 中偶尔出现的负值让我很烦恼。

• 示例：MAX(100% - 1% - stdev(当前%) - 当前%, 0) / MAX(速率(当前%), 0.001%)

我仍然保持 1% 的静态缓冲区。异常使用模式下的标准偏差和消耗率都会增加，有时会过度补偿。在 graphana 或alertmanager 中，你最终会得到一些相当昂贵的子查询。但我确实得到了我所寻求的更平滑的时间序列和更少噪音的警报。

• 例子：clamp_min((100 - 1 - stddev_over_time(usedPct{}[12h:]) - max_over_time(usedPct{}[6h:])) / clamp_min(deriv(usedPct{}[12:]),0.00001), 0)

更安静的驱动器可以实现非常顺畅的警报。

更长的范围甚至可以抑制最吵闹的公共音量。