石墨停止随机收集数据

我们有一个Graphite服务器，可以通过collected，statsd，JMXTrans收集数据。几天以来，我们的数据经常出现漏洞。挖掘我们仍然拥有的数据，我们可以看到碳缓存的大小有所增加（从50K增加到4M）。我们看不到收集的指标数量增加（metricsReceived稳定在30万左右）。我们的查询数量平均从1000个增加到1500个。

奇怪的是，当高速缓存大小增加时，cpuUsage从100％（我们有4个CPU）略微降低到50％。

再次奇怪的是，如果从磁盘读取八位位组，则数量会增加，而写入八位位组的数量会减少。

我们将carbon配置为大多数使用默认值：

• MAX_CACHE_SIZE = inf
• MAX_UPDATES_PER_SECOND = 5000
• MAX_CREATES_PER_MINUTE = 2000

显然，我们的系统已经发生了某些变化，但是我们不知道是什么，也不知道如何找到原因。

有什么帮助吗？

这不是石墨堆栈的错误，而是IO瓶颈，最有可能是因为您的存储没有足够高的IOPS。因此，队列不断建立，并在4M处溢出。到那时，您会丢失大量排队的数据，这些数据后来在图表中反映为随机的“间隙”，随后会反映出来。您的系统无法跟上接收指标的规模。它不断充满和溢出。

奇怪的是，当高速缓存大小增加时，cpuUsage从100％（我们有4个CPU）略微降低到50％。

这是因为您的系统开始交换，并且由于IO等待，CPU获得了很多“空闲时间”。

要添加上下文，我在系统上收到了500K IOPS，该系统上我收到了约40K度量。队列稳定在50K。

其他答复者提到磁盘I / O瓶颈。我将讨论网络瓶颈是造成此问题的另一个原因。

在我的环境中，我们运行前端UI服务器（httpd，memcached）集群；中间层中继的另一个集群（执行转发和聚合的碳-c-中继）；这些群集中的每个群集都由EC2中的多个实例组成，并且每分钟总共有1500万个度量标准。

我们遇到了一个问题，即我们看到聚合“和”函数生成的指标存在差距，并且聚合值也不正确（太低）。通过重启中间层的碳-c-继电器可以缓解该问题，但几个小时后间隙会再次出现。

我们在中间层和后端层都进行了聚合（后端层聚合了从中间层传递给它的聚合度量）。

中间层主机没有cpu绑定，没有磁盘绑定，并且没有内存限制。再加上问题仅在重新启动中继过程后几个小时才会出现，这意味着存在网络瓶颈。我们的解决方案只是将更多主机添加到中间层。立即执行此操作会导致聚合指标正确执行，并且没有出现差距。

网络堆栈中的确切瓶颈在哪里？我不能告诉你 它可能在linux主机上；它可能在亚马逊方面。