石墨：sumSeries() 不求和

Question

从今天早上 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

Answer 1

好像这两个系列没有按时间戳对齐，所以sum无法总结要点。这在以下图表中可见，其中选择了两个不同分钟内的时间高点（来自 grafana 的图表）。

我不知道为什么会这样。我重新启动了一些服务（此图表来自statsd for python 和bucky）。也许是其中一个人的错。

注意。现在这可行，但是，我想知道是否有人知道原因以及我如何解决它。

Answer 2

您需要确保的一件事是，向 Graphite 发送指标的服务以与您的最小保留期或您将呈现图表的期限相同的粒度执行此操作。如果图表中的数据点每 60 个秒，您需要每 60 秒从每个服务发送一次指标。如果图表将显示每小时的数据点，您可以每小时发送一次指标。在您的情况下，最小的周期是每 60 秒。

我在我们的系统中遇到了类似的问题——graphite 配置了最小的保留期10s:6h，但是我们有 7 个相同服务的实例生成大量指标并将它们配置为每 20 秒发送一次数据，以便避免超载我们的监控。这导致了几乎不可避免的错位，其中来自不同实例的系列将每 20 秒有一个数据点，但有些会在 10、30、50 有它，而另一些会在 0、20、40 有它。取决于有多少服务对齐后，我们会得到一个非常参差不齐的图形，看起来与您的相似。

对于以 10 秒为增量返回数据的时间段，我为解决此问题所做的工作是使用 keepLastValue 函数 -> keepLastValue(1)。我使用1 作为参数，因为我只想跳过 1 None 值，因为我知道我们的服务通过每 20 秒而不是每 10 秒发送一次来导致这种情况。这样，不同服务生成的系列永远不会有差距，所以总和更接近真实数字，并且图表不再具有锯齿状外观。我想这会在监控中引入一些额外的延迟，但这对于我们的用例来说是可以接受的。