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