计算直到磁盘已满的天数

我们使用石墨来跟踪一段时间内磁盘利用率的历史记录。我们的警报系统会查看石墨中的数据，以在可用空间低于一定数量的块时向我们发出警报。

我想获得更智能的警报-我真正关心的是“我必须花多长时间才能对可用空间做些什么？”，例如，如果趋势表明在7天内我将用完磁盘空格，然后发出警告，如果少于2天，则引发错误。

使用衍生工具和Holt Winters Confidence乐队，Graphite的标准仪表板界面可以非常智能，但是到目前为止，我还没有找到将其转换为可操作指标的方法。我也可以通过其他方式处理数字（只需从石墨中提取原始数字并运行脚本即可）。

一个复杂的问题是，该图并不平滑-添加和删除文件，但是随着时间的推移，总体趋势是磁盘空间使用量增加，因此也许需要查看本地最小值（如果查看“无磁盘”指标） ）并在槽之间绘制趋势。

有人这样做吗？

老实说，“直到满天数”确实是一个糟糕的指标-文件系统在达到100％利用率时会变得非常愚蠢。
我真的建议您使用传统的85％，90％，95％阈值（分别需要警告，警报和严重的“您确实需要解决此问题”）-这应该为您在现代磁盘上提供很多警告时间（假设有一个1TB的驱动器：TB的85％仍为您留出了很多空间，但是您知道了潜在的问题，到90％时您应该计划进行磁盘扩展或其他缓解措施，而TB的95％您还有50GB的存储空间，应该进行修复）。

这也确保文件系统或多或少地发挥最佳性能：它具有足够的可用空间来处理创建/修改/移动大文件。

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

如果您仍然使用“直到满的天数”度量标准，则可以从石墨中提取数据并对其进行一些数学运算。 IBM的监视工具实施了几天到完整的度量标准，这些度量标准可以使您了解如何实施它，但是基本上，您需要掌握历史两点之间的变化率。

为了您的理智，您可以使用Graphite的派生工具（它将为您提供随时间变化的速率），并使用该值进行投影，但是如果您确实想要“更智能”的警报，建议您使用每日和每周变化率（计算得出） （根据当天/每周的高峰使用量）。

您使用的具体预测（最小变化率，最大变化率，平均变化率，加权平均值等）取决于您的环境。IBM的工具提供了许多不同的观点，因为很难确定一种“一刀切”的模式。

最终，没有一种算法会非常擅长进行所需的计算。磁盘利用率是由用户驱动的，用户是Rational Actor模型的对立面：您的所有预测都可能被一个疯狂的人忽略，认为今天是他们要对其进行完整的系统内存转储的日子。主目录。只是因为。

我们最近使用线性回归为此推出了定制解决方案。

在我们的系统中，磁盘耗尽的主要来源是没有旋转的杂散日志文件。

由于这些增长非常可预测，因此我们可以对磁盘利用率（例如z = numpy.polyfit(times, utilization, 1)）执行线性回归，然后在给出线性模型（例如(100 - z[1]) / z[0]）的情况下计算100％的标记

尽管numpy也可以很好地运行，但是使用ruby和GSL 部署的实现看起来像这样。

以90分钟为间隔（112点）提供一周的平均利用率数据，到目前为止，已经能够选择可能的磁盘耗尽候选对象而没有太多的噪音。

要点中的类包装在一个类中，该类从侦察兵中提取数据，向松懈警报并向statsd发送一些运行时遥测。由于它是特定于我们的基础结构的，因此我将省略。