Отслеживание показателей с использованием статистикиD (через etsy) и графита, графитовый график, похоже, не является графическим отображением всех данных

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

Итак, уклонившись от этой догадки, мы вложили update.log углерода и обнаружили, что действие произошло более 4 тысяч раз сегодня (используя grep и wc), но согласно интегральному результату графика он возвращал только 220ish.

Что может быть причиной этого? Данные сообщаются в statsd, используя библиотеку php statsd, и вызывая statsd::increment('metric');, и, как указано выше, журнал подтверждает, что сегодня произошло 4 000 + обновлений этого ключа.

Мы используем:

графит 0.9.6 со статами D (etsy)

Ответ 1

После публикации моего комментария выше я обнаружил, что Graphite 0.9.9 имеет (новый?) конфигурационный файл, storage-aggregation.conf, в котором можно управлять методом агрегации для каждого шаблона. Доступными параметрами являются средние, суммарные, минимальные, максимальные и последние.

http://readthedocs.org/docs/graphite/en/latest/config-carbon.html#storage-aggregation-conf

Ответ 2

После некоторых исследований в документации и некоторых разговоров с другими, я нашел проблему - и решение.

Как формируется формат файла шепота, он ожидает, что вы (или ваше приложение) опубликуете обновления не быстрее минимального интервала в вашем файле storage-schemas.conf. Этот файл используется для настройки того, сколько удержания данных у вас есть при разных разрешениях временного интервала.

Мой storage-schemas.conf файл был установлен с минимальным временем удерживания 1 минута. Демон statD по умолчанию (от etsy) предназначен для обновления до углерода (графитового демона) каждые 10 секунд. Причина в том, что это проблема: за 60 секундный период StatsD сообщает 6 раз, каждая запись перезаписывает последнюю (в этот 60-секундный интервал, потому что вы обновляетесь быстрее, чем один раз в минуту). Это приводит к действительно странным результатам на вашем графике, потому что последние 10 секунд в минуту могут быть полностью мертвы и сообщать 0 для активности за этот период, что приводит к полному уничтожению всех данных, которые вы написали за эту минуту.

Чтобы исправить это, мне пришлось повторно настроить мой файл storage-schemas.conf для хранения данных с максимальным разрешением 10 секунд, поэтому каждое обновление от StatD будет сохранено в базе данных шепота без перезаписывания.

Etsy опубликовала конфигурацию storage-schemas.conf, которую они использовали для их установки углерода, которая выглядит следующим образом:

[stats]
priority = 110
pattern = ^stats\..*
retentions = 10:2160,60:10080,600:262974

Это имеет минимальное время удерживания 10 секунд и сохраняет их на 6 часов. Однако из-за моей следующей проблемы я значительно увеличил сроки хранения.

Как я позволяю этим данным собираться в течение нескольких дней, я заметил, что он все еще смотрел (и был под отчет). Это было связано с двумя проблемами.

StatsD (более старые версии) сообщает только о среднем количестве событий в секунду за каждый 10-секундный отчетный период. Это означает, что если вы увеличили ключ 100 раз в 1 секунду и 0 раз в течение следующих 9 секунд, то в конце 10-й секунды статистика D сообщила бы 10 на графит вместо 100. (100/10 = 10). Это не удалось сообщить об общем количестве событий за 10 секунд (очевидно).

Новые версии statsD исправляют эту проблему, поскольку они ввели ведро stats_counts, которое регистрирует общее количество событий на метрику за каждый 10-секундный период (поэтому вместо того, чтобы сообщать 10 в предыдущем примере, он сообщает 100).

После обновления StatD я заметил, что последние 6 часов данных выглядели великолепно, но поскольку я смотрел за пределы последние 6 часов - все выглядело странно, и следующая причина заключается в следующем:
Как графит хранит данные, он перемещает данные с высокой точностью удерживания на более низкую точность хранения. Это означает, что, используя пример etsy storage-schemas.conf, после 6 часов с точностью до 10 секунд данные были перенесены на 60 секунд (1 минута). Чтобы переместить 6 точек данных с точностью от 10 с до 60 с, графит выполняет среднее из 6 точек данных. Таким образом, это займет общую стоимость самых старых 6 точек данных и разделит ее на 6. Это дает среднее количество событий за 10 секунд за этот 60-секундный период (а не общее количество событий, что нам очень важно о конкретном).

Именно так графит разработан, и в некоторых случаях это может быть полезно, но в нашем случае это не то, что мы хотели. Чтобы "исправить" эту проблему, я увеличил время задержки на 10 секунд до 60 дней. За 60 дней я хранил мелкие и 10-тичные исправления, но они по существу там без причины, поскольку эти данные не так полезны для нас.

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