我们使用石墨来追踪磁盘利用率的历史。 我们的警报系统会查看石墨的数据，以便在空闲空间低于一定数量的区块时提醒我们。
我想得到更聪明的警报 – 我真正关心的是“在我必须做些关于可用空间的事情之前，我有多less时间？”，例如，如果趋势显示在7天内我将用尽磁盘空间然后提出一个警告，如果它less于2天然后提出一个错误。
石墨的标准仪表板界面可以非常聪明的衍生品和霍尔特Winters信心乐队，但到目前为止我还没有find一种方法来将其转换为可操作的指标。 我用其他方式处理数字也很好（只需从石墨中提取原始数据并运行脚本即可）。
一个复杂因素是graphics不平滑 – 文件被添加和删除，但随着时间的推移总体趋势是磁盘空间的使用增加，所以也许有必要看看局部最小值（如果看“无磁盘”度量）并在低谷之间画出一个趋势。
有没有人做过这个？
说实话，“天到天日”实际上是一个糟糕的衡量标准 – 文件系统在100％的利用率时，会变得非常愚蠢。
我真的build议使用传统的85％，90％，95％的门槛（警告，警报，和重要的你真的需要修复，这个NOW），这应该会给你现代磁盘上的很多警告时间（假设1TB的驱动器：85％的TB仍然留下很多空间，但是你意识到了一个潜在的问题，90％你应该计划一个磁盘扩展或者其他缓解措施，在95％的TB你还剩50GB，应该修好运动）。
这也确保了你的文件系统或多或less的优化：它有足够的空间来处理创build/修改/移动大文件。
如果你的磁盘不是现代的（或者你的使用模式涉及大量的数据被扔到磁盘上），你可以很容易地调整阈值。
如果您仍然使用“天数到满”度量标准，则可以从石墨中提取数据并对其进行一些计算。 IBM的监控工具可以实现几天或者全天的指标 ，可以让您了解如何实施它，但是基本上，您正在考虑历史上两点之间的变化率。
为了您的理智，您可以使用来自Graphite的衍生产品（它会给你随时间的变化率）和项目，但如果你真的想要“更聪明”的警报，我build议使用每日和每周的变化率（计算根据当天/周的高峰使用情况）。
您使用的具体投影（最小变化率，最大变化率，平均变化率，加权平均值等）取决于您的环境。 IBM的工具提供了许多不同的观点，因为确定一个通用的模式是非常困难的。
最终没有什么algorithm能够很好地进行你想要的计算。 磁盘利用率是由用户驱动的，用户是Rational Actor模型的对立面：所有的预测都可以从窗口中走出来，一个疯狂的人决定今天是他们将要执行完整的系统内存转储主目录。 只因为。
我们最近推出了一个使用线性回归的自定义解决scheme。
在我们的系统中，磁盘耗尽的主要来源是没有被旋转的杂散日志文件。
由于这些增长非常可预测，我们可以对磁盘利用率进行线性回归（例如z = numpy.polyfit(times, utilization, 1) ），然后根据线性模型计算100％标记（例如(100 - z[1]) / z[0] ）
部署的实现看起来像这样使用ruby和GSL，虽然numpy工作得很好。
以90分钟的时间间隔（112分）提供一周的平均利用率数据，能够挑出可能的磁盘耗尽候选者，而没有太多的噪音。
要点中的类被封装在一个从侦察器中提取数据的类，警报松弛，并发送一些运行时遥测到statsd。 因为它是特定于我们的基础设施的，所以我会留下这一点。