我们使用石墨来跟踪一段时间内的磁盘使用历史。我们的警报系统会查看来自石墨的数据，以在可用空间低于一定数量的块时提醒我们。
我想获得更智能的警报——我真正关心的是“我需要多长时间才能对可用空间进行处理？”，例如，如果趋势显示 7 天后我将用完磁盘空间然后引发警告，如果少于 2 天则引发错误。
Graphite 的标准仪表板界面可以非常智能地使用衍生工具和 Holt Winters 信心带，但到目前为止我还没有找到将其转换为可操作指标的方法。我也很擅长以其他方式处理数字（只需从石墨中提取原始数字并运行脚本即可）。
一个复杂的问题是图表不平滑 - 文件被添加和删除，但随着时间的推移，总体趋势是磁盘空间使用量增加，因此可能需要查看本地最小值（如果查看“无磁盘”指标) 并在波谷之间绘制趋势。
有人做过吗？
老实说，“天数到满”无论如何都是一个糟糕的指标——文件系统在接近 100% 利用率时变得非常愚蠢。
我真的建议使用传统的 85%、90%、95% 阈值（分别是警告、警报和关键您真的需要修复此问题） - 这应该会给您在现代磁盘上的大量警告时间（假设一个 1TB 的驱动器：85% 的 TB 仍然留给您大量空间，但您知道潜在的问题，90% 的您应该计划磁盘扩展或其他一些缓解措施，95% 的 TB你还剩下 50GB 空间，应该好好修复一下）。
这也确保了您的文件系统或多或少地以最佳方式运行：它有足够的可用空间来处理创建/修改/移动大文件。
如果您的磁盘不是现代的（或者您的使用模式涉及将大量数据扔到磁盘上），您可以轻松调整阈值。
如果您仍然使用“距离满天”指标，您可以从石墨中提取数据并对其进行一些数学运算。 IBM 的监控工具实施了几天前的完整指标，这可以让您了解如何实施它，但基本上您是在计算历史上两点之间的变化率。
为了您的理智，您可以使用 Graphite 的衍生物（它将为您提供随时间变化的速率）并使用它进行项目，但如果您真的想要“更智能”的警报，我建议使用每日和每周的变化率（计算基于一天/一周的峰值使用量）。
您使用的具体预测（最小变化率、最大变化率、平均变化率、加权平均值等）取决于您的环境。IBM 的工具提供了如此多不同的视图，因为很难确定一种万能的模式。
最终，没有算法会非常擅长进行您想要的计算。磁盘利用率是由用户驱动的，而用户是 Rational Actor 模型的对立面：你的所有预测都可能会因为一个疯狂的人决定今天是他们将执行完整的系统内存转储到他们的主目录。只是因为。
我们最近推出了使用线性回归的自定义解决方案。
在我们的系统中，磁盘耗尽的主要来源是未轮换的杂散日志文件。
由于这些增长非常可预测，我们可以对磁盘利用率执行线性回归（例如，
z = numpy.polyfit(times, utilization, 1)），然后在给定线性模型的情况下计算 100% 标记（例如，(100 - z[1]) / z[0]）使用 ruby 和 GSL部署的实现看起来像这样，尽管 numpy 也工作得很好。
以 90 分钟的间隔（112 点）提供一周的平均利用率数据，到目前为止，已经能够在没有太多噪音的情况下挑选出可能的磁盘耗尽候选者。
gist 中的类被包装在一个类中，该类从 scout 中提取数据，向 slack 发出警报并将一些运行时遥测数据发送到 statsd。我会忽略这一点，因为它特定于我们的基础架构。
为此，我们使用统计趋势及其标准偏差在简单的静态阈值上添加更智能（不那么愚蠢）的逻辑，为此目的保留“平均时间到满”或“平均失败时间”指标。
最简单的警报：只是一个任意阈值。不考虑与实际磁盘空间使用有任何关系。
简单的TTF：更聪明一点。计算未使用百分比减去缓冲区并除以零保护率。在统计上不是很可靠，但是当我的用户上传他们的猫视频语料库（真实故事）时，我已经救了我几次。
更好的 TTF：但我想避免在 99% 时对静态只读卷发出警报（除非它们有任何更改），并且我希望更主动地通知嘈杂的卷，并检测具有非托管磁盘空间足迹的应用程序。哦，Simple TTF 中偶尔出现的负值让我很困扰。
我仍然保持 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)更安静的驱动器可以提供非常流畅的警报。
更长的范围甚至可以驯服最嘈杂的公共音量。