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

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

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

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

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

графит 0.9.6 с statsD (etsy)

Источник

2 ответа

Решение

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

http://readthedocs.org/docs/graphite/en/latest/config-carbon.html

Источник

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

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

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

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

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

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

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

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

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

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

    После того, как я обновил StatsD, я заметил, что данные за последние 6 часов выглядели великолепно, но когда я смотрел за пределы последних 6 часов - все выглядело странно, и следующая причина:

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

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

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

Источник
Другие вопросы по тегам