Graphite：sumSeries() 不求和
Graphite: sumSeries() does not sum
从今天早上 6 点开始，我遇到了石墨的一种奇怪行为。
我们有两台机器可以收集有关接听电话的日期，我绘制了图表，还绘制了这两个图表的总和。
单机图还行，求和就不行了
这是 graphtite 和 grafana 的截图，展示了如何4+5=5（我的数学老师会为此而死）
这个错误的总和也发生在其他指标上。我不明白为什么。
storage-scheams.conf
# Schema definitions for whisper files. Entries are scanned in order,
# and first match wins.
#
# [name]
# pattern = regex
# retentions = timePerPoint:timeToStore, timePerPoint:timeToStore, ...
[default_1min_for_1day]
pattern = .*
retentions = 60s:1d,1h:7d,1d:1y,7d:5y
storage-aggregations.conf
# Schema definitions for whisper files. Entries are scanned in order,
# and first match wins.
#
# [name]
# pattern = regex
# retentions = timePerPoint:timeToStore, timePerPoint:timeToStore, ...
[time_data]
pattern = ^stats\.timers.*
xFilesFactor = 0.5
aggregationMethod = average
[storage_space]
pattern = \.postgresql\..*
xFilesFactor = 0.1
aggregationMethod = average
[default_1min_for_1day]
pattern = .*
xFilesFactor = 0
aggregationMethod = sum
aggregation-rules.conf 这可能是原因，但它在早上 6 点之前工作。但无论如何，我没有看到 stats_count.all 指标。
stats_counts.all.rest.req (60) = sum stats_counts.srv_*_*.rest.req
stats_counts.all.rest.res (60) = sum stats_counts.srv_*_*.rest.res
好像两个系列没有按照时间戳对齐，所以sum没法总结出要点。这在下图中可见，其中选择了两个不同分钟的时间高点（来自 grafana 的图表）。
我不知道为什么会这样。我重新启动了一些服务（此图表来自 statsd for python 和 bucky）。也许是其中之一的错。
注意。现在这有效了，但是，我想知道是否有人知道原因以及我该如何解决它。
您需要确保的一件事是，向 Graphite 发送指标的服务以与您的最小保留期或您将在其中呈现图表的时间段相同的粒度进行发送。如果图表中的数据点将是每 60 秒，您需要每 60 秒从每个服务发送一次指标。如果图表每小时显示一个数据点，您可以每小时发送一次指标。在您的情况下，最小周期是每 60 秒一次。
我在我们的系统中遇到了类似的问题 - 石墨被配置为最小保留期 10s:6h，但我们有 7 个相同服务的实例生成大量指标并将它们配置为每 20 次发送一次数据秒以避免我们的监控超载。这导致了几乎不可避免的错位，其中来自不同实例的系列每 20 秒会有一个数据点，但有些会在 10、30、50，而其他人会在 0、20、40。取决于有多少服务对齐，我们会得到一个非常参差不齐的图表，看起来和你的很相似。
我为以 10 秒为增量返回数据的时间段解决此问题的方法是使用 keepLastValue 函数 -> keepLastValue(1)。我使用 1 作为参数，因为我只想跳过 1 个 None 值，因为我知道我们的服务通过每 20 秒而不是每 10 秒发送一次来导致这个。这样不同服务生成的系列从来没有差距，所以总和更接近实数，图表不再有锯齿状。我想这在监控中引入了一些额外的滞后，但这对于我们的用例来说是可以接受的。
从今天早上 6 点开始，我遇到了石墨的一种奇怪行为。
我们有两台机器可以收集有关接听电话的日期，我绘制了图表，还绘制了这两个图表的总和。
单机图还行，求和就不行了
这是 graphtite 和 grafana 的截图，展示了如何4+5=5（我的数学老师会为此而死）
这个错误的总和也发生在其他指标上。我不明白为什么。
storage-scheams.conf
# Schema definitions for whisper files. Entries are scanned in order,
# and first match wins.
#
# [name]
# pattern = regex
# retentions = timePerPoint:timeToStore, timePerPoint:timeToStore, ...
[default_1min_for_1day]
pattern = .*
retentions = 60s:1d,1h:7d,1d:1y,7d:5y
storage-aggregations.conf
# Schema definitions for whisper files. Entries are scanned in order,
# and first match wins.
#
# [name]
# pattern = regex
# retentions = timePerPoint:timeToStore, timePerPoint:timeToStore, ...
[time_data]
pattern = ^stats\.timers.*
xFilesFactor = 0.5
aggregationMethod = average
[storage_space]
pattern = \.postgresql\..*
xFilesFactor = 0.1
aggregationMethod = average
[default_1min_for_1day]
pattern = .*
xFilesFactor = 0
aggregationMethod = sum
aggregation-rules.conf 这可能是原因，但它在早上 6 点之前工作。但无论如何，我没有看到 stats_count.all 指标。
stats_counts.all.rest.req (60) = sum stats_counts.srv_*_*.rest.req
stats_counts.all.rest.res (60) = sum stats_counts.srv_*_*.rest.res
好像两个系列没有按照时间戳对齐，所以sum没法总结出要点。这在下图中可见，其中选择了两个不同分钟的时间高点（来自 grafana 的图表）。
我不知道为什么会这样。我重新启动了一些服务（此图表来自 statsd for python 和 bucky）。也许是其中之一的错。
注意。现在这有效了，但是，我想知道是否有人知道原因以及我该如何解决它。
您需要确保的一件事是，向 Graphite 发送指标的服务以与您的最小保留期或您将在其中呈现图表的时间段相同的粒度进行发送。如果图表中的数据点将是每 60 秒，您需要每 60 秒从每个服务发送一次指标。如果图表每小时显示一个数据点，您可以每小时发送一次指标。在您的情况下，最小周期是每 60 秒一次。
我在我们的系统中遇到了类似的问题 - 石墨被配置为最小保留期 10s:6h，但我们有 7 个相同服务的实例生成大量指标并将它们配置为每 20 次发送一次数据秒以避免我们的监控超载。这导致了几乎不可避免的错位，其中来自不同实例的系列每 20 秒会有一个数据点，但有些会在 10、30、50，而其他人会在 0、20、40。取决于有多少服务对齐，我们会得到一个非常参差不齐的图表，看起来和你的很相似。
我为以 10 秒为增量返回数据的时间段解决此问题的方法是使用 keepLastValue 函数 -> keepLastValue(1)。我使用 1 作为参数，因为我只想跳过 1 个 None 值，因为我知道我们的服务通过每 20 秒而不是每 10 秒发送一次来导致这个。这样不同服务生成的系列从来没有差距，所以总和更接近实数，图表不再有锯齿状。我想这在监控中引入了一些额外的滞后，但这对于我们的用例来说是可以接受的。