耳语/石墨的磁盘容量规划

14

有没有人有任何公式，或者他们环境中的一些样本数据可以帮助我估计每个数据点石墨将使用多少磁盘空间？

monitoring graphite

2

确保您也正确地计划了磁盘I / O，而不仅仅是磁盘容量。多年来，rrdtool积累了许多微优化功能，使其写入速度比Graphite的Whisper数据库格式快得多（快2倍？）。如果您打算将所有数据保存在适当的SSD上，那将为您提供大部分帮助，但是我不打算在旋转磁盘上保留整吨的Whisper DB。从规模上讲，Graphite抛出的磁盘I / O级别只是不划算。

— jgoldschrafe 2013年

7

whisper-info.py 让您深入了解每个文件的聚合方式和聚合方式，包括文件的大小。

但是，它仅对现有的耳语文件有用。

如果希望在将模式放置到位之前看到其预测大小，请尝试使用耳语计算器，例如https://gist.github.com/jjmaestro/5774063上可用的计算器。

编辑：

当被问到一个例子...

storage_schema：

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

看我的档案applied-in-last-hour.wsp，ls -l产量

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

和whisper-info.py ./applied-in-last-hour.wsp产量

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

因此，基本上，您将每个统计信息的每个保留匹配项，每个保留期限段的主机相结合，再乘以您也打算应用此系统的系统因子，再乘以要跟踪的新统计信息的数量。然后，您需要使用任何数量的存储空间，至少要加倍（因为我们要购买存储空间，并且我们知道我们会使用它...）

— 沃尔多
source

您有机会从中获得一些样品编号（与保留设置配对）。现在，我正在考虑磁盘使用情况方面的不同时间序列数据存储-因此，为此而活着的石墨有点困难。

— 凯尔·勃兰特

@KyleBrandt答案已更新。

— gWaldo 2013年

谢谢你因此，对于文件大小，是在一小时的数据收集后会是什么，还是文件大小几乎总是会是？那么4415092代表5年数据的保留价值，还是代表一小时一分钟的数据？另外，是字节还是位？

— 凯尔·勃兰特

这是该公司的一项新实施，我无法使用旧的。由于顶级文件大小结果与结果匹配，ls -l因此我将其作为字节。当我将.wsp文件中的档案大小加起来（由所报告whisper-info.py）时，它们接近.wsp文件的整体大小（其余的我认为是元数据等。这应该是所有文件的大小）时间的推移，数据下降到较低的数据分辨率，并且旧的数据点都被丢弃。

— gWaldo

好的，使用此保留设置。大致来说：ServerCount * MetricCount * 4.5MBytes

— 凯尔·勃兰特

2

在statsd 的文档中，它们提供了数据保留策略的示例。

保留10s:6h,1min:7d,10min:5y为2160 + 10080 + 262800 = 275040个数据点，存档大小为3.2 MiB。

假设线性关系，则每个数据点大约为12.2字节。

— 安德烈·克雷
source

ops-school.readthedocs.org/en/latest/monitoring_201.html （时间戳，值）对存储为长整型和双精度值，每对消耗12个字节。0.2 diff可能是由于文件元数据信息的开销？

— user27465

1

没有使用Graphite的直接经验，但是我想可以使用与用于Cacti或其他任何RRD或时间翻转驱动的逻辑相同的逻辑（Graphite不再在内部使用RRD，但存储逻辑似乎具有可比性。）

快速的答案是“可能没有您认为需要的空间那么多”。

长答案涉及一些特定于站点的数学。对于我们的监视系统（InterMapper），我确定了保留期限，分辨率和数据点大小，进行了乘法运算，并增加了开销。

例如，我将使用磁盘空间-我们以5分钟的精度存储30天的数据，以15分钟的精度存储另外60天的数据，然后以小时的精度存储另外300天的数据，而我们使用的是64位（8字节）整数存储它：

总共21600个样本，细分为：
- 30天5分钟精度的8640个样本
- 60天15分钟精度的5760个样本
- 300天1小时精度的7200个样本

每个样本8个字节，大约173KB，加上用于存储索引的正常开销等，一个分区的磁盘使用情况数据将其增加到大约200KB（任何错误都可能导致高估）。

根据基本指标，我可以算出平均的“每台计算机”大小（10个磁盘分区，交换空间，RAM，平均负载，网络传输以及其他一些东西）-每台计算机大约5MB。

我还要在最终数字的基础上再加上一个10％的值，然后进行四舍五入，因此我将每台机器的大小调整为6MB。

然后，我查看一下用于存储用于绘制图表的指标数据的1TB空间，然后说：“是的，除非我们大量增长，否则我一生可能不会用光存储空间！” :-)

— voretaq7
source

1

从实际的实践中得出一些数据，包括我的生产保留策略（5分钟为9个月；每小时为1年；每天为5年），以及大约20台机器，每台机器具有约20个8字节度量标准，以及警告/警报/ critical /停机事件历史5年，我正在使用1.5G磁盘空间。这是InterMapper将所有内容插入Postgres数据库的过程。再次如此-快速的答案是“可能没有您认为需要的空间那么多” :-)

— voretaq7 2013年

是的，数学很简单，我实际上只是在研究Graphite如何存储数据-可以在规模上产生重大变化。我发现的唯一一件事是，根据文档，它的空间使用效率不是很高（可能是因为它依靠相当积极的汇总）。

— 凯尔·勃兰特

Whisper（用于存储后端Graphite的后端）具有一些内置的空间节省项-您可能已经看到了该页面。关于“归档重叠时间段”的部分对我来说很突出，因为这意味着归档比我上面的示例更大，因为它们都可以追溯到时间的开始（60天的归档实际上是90天； 300天的归档是390天）。Whisper还与每个需要添加的数据点一起保留一个时间戳（4或8个字节）。不过看起来并不棘手，只是肿了：）

— voretaq7 2013年

0

我有70个节点，它们生成大量数据。使用Carbon / Whisper，一个节点仅创建了91k个文件（该节点生成多个模式，每个模式具有多个计数器和变量字段，这些字段需要可选，例如：（nodename）。（schema）。（counter）。（subcounter）。（etc ）....等等）。

这提供了绘制所需图形所需的粒度。运行脚本以填充其余69个节点后，我的磁盘上有1.3TB的数据。而且，每个节点仅需要6个小时的数据。让我得到的是6个小时数据的实际平面csv文件约为230Mb /节点。70个节点约为16Gb的数据。我的存储模式为120s：365d。

我是数据库的新手，所以我可能做错了事，但是我猜想这是每个样本的全部开销。

因此，这是一个有趣的实验，但我认为对我存储的数据使用耳语是没有道理的。MongoDB似乎是一个更好的解决方案，但是我需要弄清楚如何将其用作Grafana的后端。

— musca999
source