После некоторых исследований документации и разговоров с другими я нашел проблему - и решение.
То, как разработан формат файла «шепот», предполагает, что вы (или ваше приложение) будете публиковать обновления не быстрее, чем минимальный интервал в вашем файле storage-schemas.conf. Этот файл используется для настройки степени хранения данных при разных разрешениях временного интервала.
Мой storage-schemas.conf файл был установлен с минимальным временем хранения 1 минута. Демон StatsD по умолчанию (от etsy) предназначен для обновления до carbon (графитового демона) каждые 10 секунд. Причина в том, что проблема заключается в том, что за 60-секундный период StatsD сообщает 6 раз, каждая запись перезаписывает последнюю (в этом 60-секундном интервале, потому что вы обновляете быстрее, чем раз в минуту). Это приводит к действительно странным результатам на вашем графике, потому что последние 10 секунд в минуту могут быть полностью мертвыми и сообщать 0 для активности в течение этого периода, что приводит к полному обнулению всех данных, которые вы записали за эту минуту.
Чтобы это исправить, мне пришлось перенастроить файл storage-schemas.conf для хранения данных с максимальным разрешением 10 секунд, чтобы каждое обновление из StatsD сохранялось в базе данных шепотом без перезаписи.
Etsy опубликовала конфигурацию storage-schemas.conf, которую они использовали для установки углерода, которая выглядит следующим образом:
[stats]
priority = 110
pattern = ^stats\..*
retentions = 10:2160,60:10080,600:262974
Это имеет минимальное время хранения 10 секунд и сохраняет их на 6 часов. Однако из-за моей следующей проблемы я значительно продлил сроки хранения.
Когда я позволил этим данным собираться в течение нескольких дней, я заметил, что они все еще выглядят непонятно (и находились в процессе отчетности). Это было связано с 2 проблемами.
StatsD (более старые версии) сообщал только о среднем количестве событий в секунду за каждый 10-секундный отчетный период. Это означает, что если вы увеличивали ключ 100 раз в 1 секунду и 0 раз в течение следующих 9 секунд, в конце 10-й секунды statsD сообщит 10 графиту вместо 100. (100/10 = 10). При этом не удалось сообщить общее количество событий за 10-секундный период (очевидно).
Более новые версии statsD решают эту проблему, поскольку они представили корзину stats_counts, которая регистрирует общее количество событий на показатель для каждого 10-секундного периода (таким образом, вместо отчета 10 в предыдущем примере, он сообщает 100).
После обновления StatsD я заметил, что данные за последние 6 часов выглядели великолепно, но когда я смотрел дальше последние 6 часов - все выглядело странно, и следующая причина:
Поскольку графит хранит данные, он перемещает данные из высокоточного хранения в более низкую точность хранения. Это означает, что на примере etsy storage-schemas.conf после 6 часов с точностью 10 секунд данные были перемещены с точностью до 60 секунд (1 минута). Чтобы переместить 6 точек данных с точностью от 10 с до 60 с, графит делает среднее из 6 точек данных. Таким образом, потребуется взять общее значение 6 самых старых точек данных и разделить его на 6. Это дает среднее количество событий за 10 секунд за этот 60-секундный период (а не общее количество событий, что нас волнует о конкретно).
Вот как устроен графит, и в некоторых случаях это может быть полезно, но в нашем случае это не то, что мы хотели. Чтобы «исправить» эту проблему, я увеличил время удержания точности 10 секунд до 60 дней. По истечении 60 дней я сохраняю точные и 10-минутные значения точности, но они, по сути, существуют без всякой причины, так как эти данные не так полезны для нас.
Я надеюсь, что это кому-то поможет, я знаю, что это раздражало меня на несколько дней - и я знаю, что нет огромного сообщества людей, которые используют этот стек программного обеспечения для этой цели, поэтому потребовалось немного исследований, чтобы действительно понять, что происходит и как получить желаемый результат.