首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >计算直到磁盘满的天数

计算直到磁盘满的天数
EN

Server Fault用户
提问于 2013-08-07 11:01:39
回答 3查看 6.5K关注 0票数 10

随着时间的推移,我们使用石墨来追踪磁盘的使用历史。我们的警报系统通过查看石墨的数据来提醒我们,当自由空间落在一定数量的块以下时。

我想得到更智能的提醒--我真正关心的是“我还有多长时间才能对空闲空间做点什么?”,例如,如果趋势显示,7天内我将耗尽磁盘空间,然后提出警告,如果不足2天,那么就会出现错误。

石墨的标准仪表板界面可以非常聪明的衍生品和霍尔特温特斯信心带,但到目前为止,我还没有找到一种方法来把这个可操作的衡量标准。我还可以用其他方式处理数字(只需从石墨中提取原始数字并运行脚本即可)。

一个复杂的问题是,图形不是平滑的--文件被添加和删除,但是随着时间的推移,总的趋势是磁盘空间使用量增加,所以也许需要查看本地最小值(如果查看“磁盘自由”度量),并在凹槽之间绘制一个趋势。

有人做过这个吗?

EN

回答 3

Server Fault用户

回答已采纳

发布于 2020-06-13 00:00:22

为此,我们保留了一个“平均完成时间”或“平均失败时间”度量,使用统计趋势及其标准偏差,在一个简单的静态阈值上添加更聪明(不那么愚蠢)的逻辑。

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

  • 示例:当前%> 90%

简单的TTF:有点聪明。计算未使用百分比减去缓冲区,再除以受保护的零比率。

更好的TTF:但我想避免对静态只读卷发出99%的警告(除非它们有任何变化),而且我想要更积极地通知噪音卷,并检测带有非管理磁盘空间足迹的应用程序。哦,简单的TTF中偶尔出现的负值让我很困扰。

  • 例如:最大值(100%- 1% -stdev(当前%)-电流%,0) /最大值(速率(当前%),0.001%)

我仍然保持1%的静态缓冲。非正常使用模式的标准差和消费率都会增加,有时会过度补偿。在graphana或警报管理器中,您将得到一些非常昂贵的子查询。但我确实得到了更流畅的时刻表,也得到了更少噪音的提醒。

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

更安静的驱动器可以发出非常平滑的警报。

更长的范围甚至可以驯服最喧闹的公共书籍。

票数 3
EN

Server Fault用户

发布于 2013-08-08 16:21:19

老实说,“天到满”实际上是一个糟糕的度量标准--文件系统在接近100%的利用率时变得非常愚蠢。

我真的建议使用传统的85%,90%,95%的阈值(警告、报警和批评你-现在就需要修复)--这应该会给你在现代磁盘上大量的警告时间(比方说1TB驱动器: 85%的to驱动器仍然给你留下很大的空间,但是你意识到了一个潜在的问题,到90%的时候,你应该计划一个磁盘扩展或其他一些缓解措施,而在95%的to上,你剩下了50 in的内存,并且应该很好地进行修复)。

这也确保了您的文件系统或多或少地优化了功能:它有足够的空闲空间来处理创建/修改/移动大型文件的问题。

如果您的磁盘不是现代的(或者您的使用模式涉及更大数量的数据被抛到磁盘上),那么您可以很容易地调整阈值。

如果你还在使用“天到满”的度量标准,你可以从石墨中提取数据,并对其做一些计算。IBM的监控工具实现了几天前的完整度量.,它可以给你一个如何实现它的想法,但基本上你是在历史上两个点之间的变化率。

为了您的理智,您可以使用Graphite的派生程序(这将给出随时间变化的速率)并使用它进行项目,但是如果您真的想要“更智能”的警报,我建议您使用每日和每周的变化速率(根据日/周的峰值使用率计算)。

您使用的特定预测(最小变化率、最大变化率、平均变化率、加权平均值等)取决于你的环境。IBM的工具提供了这么多不同的视图,因为很难确定一个一刀切的模式。

最终,没有一个算法能够很好地完成你想要的计算。磁盘利用率是由用户驱动的,用户是Rational模型的对立面:所有的预测都可以从窗口中消失,一个疯狂的人决定,今天他们将对自己的主目录执行完整的系统内存转储。就因为。

票数 9
EN

Server Fault用户

发布于 2015-11-29 21:58:20

我们最近推出了一个使用线性回归的自定义解决方案。

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

由于它们的增长非常可预测,我们可以对磁盘利用率(例如,z = numpy.polyfit(times, utilization, 1))进行线性回归,然后在给定线性模型(例如,(100 - z[1]) / z[0])的情况下计算100%的标记。

部署的实现看起来像使用ruby和GSL的,尽管numpy也运行得很好。

按照每周90分钟(112个点)提供的平均利用率数据,到目前为止,已经能够在没有太多噪音的情况下挑选出磁盘耗尽的可能人选。

gist中的类被包装在一个类中,该类从scout中提取数据,警告为松弛,并向statsd发送一些运行时遥测。因为这是我们的基础设施特有的,所以我就不提这一点了。

票数 3
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/529288

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档