Почему statsd часто не создает все варианты, когда меры создаются в графите

Я считаю, что это должно быть как-то вызвано тем, как я настроил statsd/graphite, однако я не могу понять:

Часто, когда новая мера создается путем отправки значений таймера для разных метрик в быстрой последовательности, statsd, кажется, отправляет в graphite только некоторые из вариантов, которые он должен создать для каждого таймера, например. если я сделаю следующее и позволю ему создать несколько показателей:

while true;do echo "test$RANDOM:38|ms" | nc -w 1 -u localhost 8125;done

У меня получается что-то вроде следующего, т.е. data-файлы созданы только для некоторых метрик, а некоторые отсутствуют и не отображаются даже спустя какое-то время.

$ cd /opt/graphite/storage/whisper/stats/timers
$ ls test9304/
count.wsp  lower.wsp  mean_90.wsp  std.wsp  sum.wsp  upper.wsp
$ ls test31877/
count_ps.wsp  count.wsp  lower.wsp  mean_90.wsp  mean.wsp  std.wsp  sum_90.wsp  sum.wsp  upper_90.wsp  upper.wsp

Кажется, что эти недостающие появляются после того, как мера снова отправляется иногда позже, но это как-то недетерминировано, какие из них когда создаются.

Так есть ли причина для этого? Какая-то внутренняя оптимизация или кеширование, которое сбрасывает данные только через более длительный период, чем заявленные 10 секунд?


udp measurement graphite statsd
person centic    schedule 20.02.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Ответ о конфигурации углерода был в правильном направлении, однако он не объяснял, почему эти вещи никогда не отображались, даже не в браузере Graphite, который должен учитывать кэшированные данные.

Фактическая причина была другой, после просмотра файлов конфигурации я обнаружил следующее, что, вероятно, больше связано с моей проблемой:

> # Softly limits the number of whisper files that get created each minute.                                               
> # Setting this value low (like at 50) is a good way to ensure your graphite                                             
> # system will not be adversely impacted when a bunch of new metrics are                                                 
> # sent to it. The trade off is that it will take much longer for those metrics'                                         
> # database files to all get created and thus longer until the data becomes usable.                                      
> # Setting this value high (like "inf" for infinity) will cause graphite to create                                       
> # the files quickly but at the risk of slowing I/O down considerably for a while.                                       
> MAX_CREATES_PER_MINUTE = 50

Это на самом деле объясняет, почему отправка большого количества новых мер в statsd создала только некоторые, но в случайном порядке... Фактические создание новых мер зависело от минутного переключения.

person centic    schedule 21.02.2014

arrow_upward
1
arrow_downward

Да, carbon-cache (это уже в названии) выполняет такое кэширование, чтобы не исчерпывать пропускную способность ввода-вывода и записывать несколько метрик вместе, а графитовое веб-приложение использует как файлы на диске, так и данные в ОЗУ. Вы даже можете настроить это поведение углеродного кеша, например. сколько точек данных (по всем показателям) он собирает перед очисткой.

person cmur2    schedule 21.02.2014