6

我们正在尝试将 Graphite 用于（近）实时图形网络系统。然而，我们似乎无法让石墨的速度快于 1 秒的更新率。最终我们希望有 100 毫秒的更新

通过阅读常见问题解答，它听起来像石墨很快 - 但这要么非常误导，要么我不了解如何加速石墨

耳语的计时信息似乎使用 UNIX 时间戳

Graphite 的可扩展性如何？

从 CPU 的角度来看，Graphite 在前端和后端水平扩展，这意味着您可以简单地添加更多机器来获得更多吞吐量。它也是容错的，因为丢失后端机器会导致最小的数据丢失（无论该机器在内存中缓存了什么），并且如果您有足够的剩余容量来处理负载，则不会中断系统。

从 I/O 的角度来看，在负载下 Graphite 非常快速地对许多不同的文件执行大量微小的 I/O 操作。这是因为发送到 Graphite 的每个不同的指标都存储在自己的数据库文件中，类似于在 RRD 工作之上构建的工具（绘图、仙人掌、Centreon 等）的数量。事实上，Graphite 最初确实使用 RRD 进行存储，直到出现需要新存储引擎的基本限制。

大容量（每分钟更新几千个不同的指标）几乎需要一个好的 RAID 阵列。如果磁盘无法跟上发生的大量小写操作（每个数据点只有几个字节，但大多数磁盘每秒不能执行超过几千次 I/O 操作，即使它们很小）。当这种情况发生时，Graphite 的数据库引擎，whisper，允许 carbon 一次写入多个数据点，从而提高整体吞吐量，但代价是保持多余的数据缓存在内存中，直到可以写入。

图表的实时性如何？

非常。即使在重负载下，每个时间间隔的指标数量也远大于存储系统可以执行 I/O 操作的速率，并且大量数据点被缓存在存储管道中（请参阅上一个问题以了解解释)，Graphite 仍然绘制实时图形。诀窍在于，当 Graphite webapp 接收到绘制图形的请求时，它同时从磁盘和预存储缓存（如果您有多个后端服务器可能分布）中检索数据，并结合两个来源数据以创建实时图表。

他们也只显示秒，没有小数点：http: //graphite.readthedocs.org/en/latest/config-carbon.html 和 from and until must be a time specification conforming to the AT-STYLE time specification described这里： http: //oss.oetiker.ch/rrdtool/doc/rrdfetch.en .html。 http://graphite.wikidot.com/url-api-reference

那是什么？石墨快吗？或者它只是快速处理大型数据集 - 我们正在寻找一个简单易用的数据包数据网络接收器以直观地显示 - Graphite 似乎是一个很好的解决方案，但现在我们已经配置并运行了它，我猜我们只是浪费了一个很多时间

谢谢！

4

1 回答 1

7

Graphite 将在您的 storage-schemas.conf 中按照最精细定义的精度最多存储一个数据点（接收到的其他数据点将被丢弃）。 可能的最高精度是 1 秒。 例如保留 = 1s :6h,1min:7d,10min:5y

为了实现您的目标，您需要在 Graphite 前面放置一个聚合器。聚合器将接收所有指标并聚合数据，刷新到 Graphite 存储以匹配存储模式。聚合器将对指标执行计算（平均值、总和、平均值等）并将其发送。 例如，在最后一秒，您处理请求的平均时间为 14 毫秒，或者在最后 10 秒内，请求的总数为 4234。

因此，虽然您无法以比 1 秒更精细的粒度进行报告，但您可以使用聚合器来捕获 1 秒时间间隔内发生的事件的总和和平均值并进行报告。

两种常见的选择是StatsD和碳聚合器中提供的 Graphite。

** StatsD，IMO 是要走的路。它是一个网络守护程序，您可以单独运行并通过 UDP 发送给它。也就是说，您可以使用 carbon-aggregator.py 做很多相同的事情（例如 UDP）。

于 2013-10-03T03:05:24.823 回答