1

碳储存计划 

[default]  
pattern = .*  
retentions = 5m:15d,15m:1y,1h:10y,1d:100y

存储聚合： 

[all_sum]  
pattern = .*  
xFilesFactor = 0.1  
aggregationMethod = sum

现在，我将条目输入为：

echo "rec.test 25 $(date --date="-6 minute" +%s)" | nc localhost 2003  
echo "rec.test 50 $(date --date="-3 minute" +%s)" | nc localhost 2003  
echo "rec.test 100 $(date +%s)" | nc localhost 2003  
echo "rec.test 1 $(date --date="-1 year" +%s)" | nc localhost 2003  
echo "rec.test 4 $(date --date="-1 year minute" +%s)" | nc localhost 2003  
echo "rec.test 6 $(date --date="-1 year -1 minute" +%s)" | nc localhost 2003  
echo "rec.test 8 $(date --date="-1 year -2 minute" +%s)" | nc localhost 2003

在 grafana 图上，我可以看到最近输入值的聚合（总和值）。但 1 年前的值没有汇总。实际上，仅显示一个值（1 小时窗口的最新条目）8 而不是 4+6+8=18。

配置中可能缺少什么？

4

2 回答 2

1

carbon-aggregator 中有一个缓冲机制，用于存储在最佳保留期内收到的值并发出聚合值。

在您的示例中，5m:15d意味着缓冲区将存储过去 5 分钟内收到的所有点，并经常为 carbon-cache 发出它们的总和（这将写入耳语文件）。

这就解释了石墨中点的正常工作流程。

例子：

  Metrics received:
  hello.world 42  1427615689 (15 minutes ago)
  hello.world 1   1427615869 (12 minutes ago)
  hello.world 1   1427615929 (11 minutes ago)
  hello.world 314 1427616049 (9 minutes ago)
  hello.world 1   1427616051(~9 minutes ago)

将在耳语文件中写入 2 点：

1427615689 44 (42+1+1)
1427615989 315 (314+1)

但是，当缓冲区的第一个点早于给定的阈值时，将丢弃缓冲区。

阈值的计算方式允许聚合迟到的点（如果点在 5 分钟的正常窗口之后几秒钟出现），但这必须在某个地方停止（否则所有点都应该永远存储在 carbon-aggregator 的内存中）。这个阈值默认为 5 resolution * settings['MAX_AGGREGATION_INTERVALS']。MAX_AGGREGATION_INTERVALS

在您的情况下，在它们携带的时间戳后 25 分钟收到的所有点都会找到一个已删除的缓冲区。在这种情况下，石墨将创建一个新缓冲区并发出“聚合”值以耳语，覆盖正确的值。

在前面的示例中，如果您发送一个点：

hello.world 100  1427615690 (~15 minutes ago)

发射时间后 25 分钟，它将覆盖耳语。你会得到：

1427615689 100 (100)
1427615989 315 (314+1)

延迟点是 grahite 缓冲区设计（以及大多数时间序列数据库）的一个极端案例。如果您知道某些点可能会迟到，您可以尝试增加MAX_AGGREGATION_INTERVALS设置，但我建议先将它们存储在其他地方，然后将它们与存储在石墨中的内容离线重新协调。

于 2015-03-29T08:19:31.650 回答
0

同样的问题，由于 prod 环境，无法访问石墨/耳语设置。您可以在外部聚合数据，然后将其发送到石墨数据端口。 https://github.com/floringavrila/graphite-feeder

于 2019-10-14T22:34:02.820 回答