Можно ли использовать Graphite с очень редкими счетчиками?

Используя statsd, настроенный с помощью flushInterval: 1000 и взаимодействующий с углеродным кешем графита. Хотел бы я видеть очень редкие счетчики.

У меня есть следующая конфигурация для углерода:

storage-schemas.conf:

[carbon]
pattern = ^carbon\.
retentions = 60:90d

[default_30s_for_1day]
pattern = .*
retentions = 30s:1d

Отправка уникального счетчика таким образом:

$ echo "foobar:1|c" > /dev/udp/127.0.0.1/8125

Я вижу пакет, полученный statsd:

9 Jul 14:43:05 - DEBUG: foobar:1|c

а также данные, отправленные в углеродный кеш (экстракт tcpdump):

stats.foobar 1 1404909785

В графите, глядя на данные для «foobar», я вижу, что что-то произошло в этот момент (тонкая линия, см. красный кружок на картинке), но результат всегда «0»:

введите здесь описание изображения

Я что-то упускаю?

Если есть гораздо более частые результаты, то я вижу цифры, которые выглядят правильно.

Существует ли минимальное количество статистики, которую необходимо отправить для учета? Это настраивается?

Примечание: возможно, для таких случайных данных StatsD / Graphite не стоит, но, поскольку есть другие очень часто собираемые данные для того же проекта, они все равно будут использоваться, и мы надеемся, что можно будет использовать одно уникальное решение, даже для редких счетчиков.< /сильный>


graphite statsd
person Patrick Allaert    schedule 09.07.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Проблема в моей настройке заключалась в том, что flushInterval (1 сек.) было ниже моего наименьшего удержания (30 сек.).

Каждые (мой случай: 30 сек.) carbon-cache сохраняет результат, однако если, например, на секунде «10» для моего ключа foobar будет отправлено значение «1», statsd отправит считать "0" каждую секунду (точнее, каждый flushInterval) после. Это означает, что в секунду "30" последнее значение для foobar равно "0". Единственный шанс, что значение «1» будет принято во внимание, - это если оно было отправлено в самый последний момент, непосредственно перед секундой «30».

Меня можно обвинить в том, что я не использовал настройки statsd deleteIdleStats или deleteCounters, чтобы не отправлять "0". Но при этом, дважды установив счетчик на «1» за те же 30 секунд. слот пропустит первый счетчик, в результате чего будет зарегистрировано значение «1» вместо «2».

Настоящее решение состоит в том, чтобы привести статистику flushInterval в соответствие с минимальным удержанием углерода:

статистика config.js:

flushInterval: 10000

storage-schemas.conf углерода:

retentions = 10s:1d,1m:30d,5m:90d
person Patrick Allaert    schedule 09.07.2014