![Graphite 停止随机收集数据](https://linux22.com/image/616817/Graphite%20%E5%81%9C%E6%AD%A2%E9%9A%8F%E6%9C%BA%E6%94%B6%E9%9B%86%E6%95%B0%E6%8D%AE.png)
我们有一个 Graphite 服务器,通过 collectd、statsd、JMXTrans 等收集数据……几天以来,我们的数据经常出现漏洞。深入研究我们仍然拥有的数据,我们可以看到 carbon 缓存大小有所增加(从 50K 增加到 4M)。我们没有看到收集的指标数量有所增加(metricsReceived 稳定在 300K 左右)。我们的查询数量平均从 1000 个增加到 1500 个。
奇怪的是,当缓存大小增加时,cpuUsage 会从 100%(我们有 4 个 CPU)略微下降到 50%。
奇怪的是,我们发现从磁盘读取的八位字节数量增加了,而写入的八位字节数量减少了。
我们的 carbon 配置大多采用默认值:
- MAX_CACHE_SIZE = inf
- 每秒最大更新次数 = 5000
- 每分钟最大创建数 = 2000
显然,我们的系统发生了一些变化,但我们不明白是什么变化,也不知道如何找到原因……
有什么帮助吗?
答案1
这不是 Graphite Stack 的 bug,而是 IO 瓶颈,很可能是因为您的存储没有足够高的 IOPS。因此,队列不断增加,并在 4M 时溢出。此时,您失去如此多的排队数据,稍后会反映为图表中的随机“间隙”。您的系统无法赶上接收指标的规模。它保持充满并溢出。
奇怪的是,当缓存大小增加时,cpuUsage 会从 100%(我们有 4 个 CPU)略微下降到 50%。
这是因为您的系统开始交换,并且由于 IO 等待,CPU 获得大量“空闲时间”。
为了补充上下文,我在 AWS 的系统上配置了 500 个 IOPS,我在该系统上收到了大约 40K 指标。队列稳定在 50K。
答案2
其他回答者提到了磁盘 I/O 瓶颈。我将讨论网络瓶颈,这是造成这种情况的另一个原因。
在我的环境中,我们运行一组前端 UI 服务器 (httpd、memcached);另一组中间层中继 (carbon-c-relay 执行转发和聚合);以及一个后端层 (httpd、memcached、carbon-c-relay 和 carbon-cache)。每个集群均由 EC2 中的多个实例组成,每分钟总共处理 1500 万个指标。
我们遇到了一个问题,即聚合“sum”函数生成的指标存在差距,而且聚合值不正确(太低)。通过重新启动中间层的 carbon-c-relay 可以缓解此问题,但几个小时后差距又会出现。
我们在中间层和后端层都进行了聚合(后端层聚合了从中间层传递给它的聚合指标)。
中间层主机不受 CPU 和磁盘的限制,也不受内存限制。再加上问题只会在重新启动中继进程几个小时后出现,这意味着存在网络瓶颈。我们的解决方案只是向中间层添加更多主机。这样做立即导致聚合指标正常运行并且不会出现差距。
网络堆栈中瓶颈的具体位置在哪里?我无法告诉你。它可能在 Linux 主机上;也可能在 Amazon 端。