Получение точных графитов stats_counts

У нас работает приложение etsy/statsd node, которое сбрасывает статистику на углерод/шепот каждые 10 секунд. Если вы отправляете 100 приращений (отсчетов), в первые 10 секунд графит отображает их правильно, например:

Однако, через 10 секунд, и это число падает до 0, null и /33.3. В конце концов он опускается со значением 1/6 от начального числа приращений, в этом случае 16.6.

Я хотел бы получить точные подсчеты, графит усредняет данные по 60-секундным окнам, а не суммирует их, возможно? Используя интегральную функцию, через какое-то время, очевидно, дает:

Ответы

Ответ 1

Графическое хранилище данных

Графит управляет сохранением данных, используя комбинацию настроек, хранящихся в storage-schemas.conf и storage-aggregation.conf. Я вижу, что ваша политика хранения (фрагмент из вашего хранилища-schemas.conf) сообщает Graphite хранить только одну точку данных для ее максимального разрешения (например, 10s:10m) и что она должна управлять агрегацией этих точек данных в качестве данных возрастает и переходит в более ранние интервалы (с более низким разрешением - например, 1m:1d). В вашем случае данные пересекаются в следующий интервал хранения в 10 минут, и через 10 минут данные свернутся в соответствии с настройками в памяти-aggregation.conf.

Агрегация/понижающая дискретизация

Агрегация/понижающая дискретизация происходит, когда данные возрастают и попадают в промежуток времени, который имеет более низкое разрешение. В вашем случае вы будете хранить 1 точку данных для каждого 10-секундного интервала, но как только эти данные составят более 10 минут, графит теперь сохранит данные как 1 точку данных в течение 1-минутного интервала. Это означает, что вы должны сказать графиту, как он должен принимать 10-секундные точки данных (из которых у вас есть 6 на минуту) и суммировать их в 1 точку данных в течение всей минуты. Должно ли оно среднее? Должен ли он суммировать? В зависимости от типа данных (например, времени, счетчика) это может иметь большое значение, о чем вы намекали в своем сообщении.

По умолчанию графит будет усреднять данные, поскольку он объединяется в данные с более низким разрешением. Использование среднего значения для выполнения агрегации имеет смысл при применении к данным таймера (и даже калибровки). Тем не менее, вы имеете дело со счетчиками, чтобы вы могли рассчитывать.

Например, в файле storage-aggregation.conf:

[count]
pattern = \.count$
xFilesFactor = 0
aggregationMethod = sum

агрегация/понижающая дискретизация UI (и сырых данных)

Также важно понять, как представлены агрегированные/пониженные данные при просмотре графика или просмотре необработанных (json) данных для разных периодов времени, поскольку пороги схемы хранения данных напрямую влияют на графики. В вашем случае вы запрашиваете render?from=-20min, который пересекает границу 10: 10 м.

Графит будет отображать (и выполнять в реальном времени понижающую дискретизацию) данные в соответствии с определенной точностью с низким разрешением. Иными словами, это означает, что если вы нарисуете данные, которые охватывают один или несколько интервалов хранения, вы получите соответственно накопительные данные. Пример поможет (при условии сохранения: retentions = 10s: 10m, 1m: 1d, 15m: 30d)

Любой граф с данными, не старше 10 минут, будет отображать 10-секундные агрегации. Когда вы переходите через 10-минутный порог, вы начнете просматривать данные счета в 1 минуту, свернутые в соответствии с политикой, установленной в файле storage-aggregation.conf.

Резюме /TL;DR;

Поскольку вы выполняете графику/запрос на 20-минутные данные (например, render?from=-20min), вы определенно попадаете в настройки с более низкой точностью (например, 10 с: 10 м, 1 м: 1д, 15 м: 30d), что означает, что агрегация происходит в соответствии с вашей политикой агрегирования. Вы должны подтвердить, что используете sum для правильного шаблона в файле storage-aggregation.conf. Кроме того, вы можете сократить диапазон времени графика/запроса до менее 10 минут, чтобы избежать динамического свернуть.