Масштабирование метриков DropWizard против таймеров

Я изучаю таблицу показателей DropWizard (ранее метрики Coda Hale), и я смущен, когда должен использовать Meters vs Timers. Согласно документам:

Метр: Счетчик измеряет скорость, с которой происходит множество событий

Таймер: Таймер - это в основном гистограмма продолжительности типа события и метр скорости его появления

Основываясь на этих определениях, я не могу различить их. Меня смущает то, что Timer не используется так, как я ожидал, что он будет использоваться. Для меня Timer - это просто: таймер; он должен измерять разницу времени между a start() и stop(). Но похоже, что Timers также фиксирует скорости, с которыми происходят события, которые чувствуют, что они наступают на Meters' toes.

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

Ответ 1

Вы немного сбиты с толку, потому что таймер DW Metrics IS, среди прочего, является метрическим метром DW.

A Meter относится исключительно к темпам, измеренным в Гц (события в секунду). Каждый измеритель приводит к публикации 4 (?) Отдельных метрик:

средняя (средняя) ставка с момента запуска Metrics
1, 5 и 15 минутные средние скорости прокатки

Вы используете счетчик, записывая значение в разных точках вашего кода. DW Metrics автоматически записывает время стены каждого вызова вместе со значением, которое вы ему дали, и использует их для расчета скорости, с которой это значение увеличение:

Meter getRequests = registry.meter("some-operation.operations")
getRequests.mark() //resets the value, e.g. sets it to 0
int numberOfOps = doSomeNumberOfOperations() //takes 10 seconds, returns 333
getRequests.mark(numberOfOps) //sets the value to number of ops.

Мы ожидаем, что наши тарифы составят 33,3 Гц, так как было проведено 333 операции, а время между двумя вызовами для отметки() составляло 10 секунд.

Таймер вычисляет эти выше 4 метрики (учитывая, что каждый Timer.Context является одним событием) и добавляет к ним ряд дополнительных показателей:

подсчет количества событий
минимальная, средняя и максимальная длительности, наблюдаемые с момента запуска показателей
стандартное отклонение
"гистограмма", записывающая продолжительность, распределенную на 50, 97, 98, 99 и 99,95 процентилях.

Для каждого таймера есть что-то вроде 15 общих показателей.

Короче: Таймеры сообщают о множестве показателей, и их может быть сложно понять, но как только вы это сделаете, это довольно мощный способ определить поведение spikey.

Фактически, просто сбор времени, проведенного между двумя точками, не является ужасно полезным показателем. Подумайте: у вас есть такой блок кода:

Timer timer = registry.timer("costly-operation.service-time")
Timer.Context context = timer.time()
costlyOperation() //service time 10 ms
context.stop()

Предположим, что costlyOperation() имеет постоянную стоимость, постоянную нагрузку и работает на одном потоке. В течение 1-минутного отчетного периода мы должны ожидать, что эта операция будет выполняться 6000 раз. Очевидно, что мы не будем сообщать о фактическом времени обслуживания по проводке 6000x - вместо этого нам нужно каким-то образом суммировать все эти операции, чтобы они соответствовали нашему желаемому отчетному окну. Таймер DW Metrics Timer делает это для нас автоматически, один раз в минуту (наш отчетный период). Через 5 минут наш реестр показателей будет сообщать:

скорость 100 (события в секунду)
средняя скорость в 1 минуту 100
5-минутная средняя скорость 100
количество 30000 (общее количество событий)
максимум 10 (мс)
минус 10
среднее значение 10
значение 50-го процентиля (p50) 10
значение 99.9-го процентиля (p999) 10

Теперь рассмотрим, что мы входим в период, когда время от времени наша операция полностью отключается от рельсов и блоков в течение длительного периода:

Timer timer = registry.timer("costly-operation.service-time")
Timer.Context context = timer.time()
costlyOperation() //takes 10 ms usually, but once every 1000 times spikes to 1000 ms
context.stop()

За 1-минутный период сбора данных мы теперь увидим менее 6000 исполнений, так как каждое 1000-е исполнение занимает больше времени. Работает до 5505. После первой минуты (6 минут всего системного времени) этого мы теперь увидим:

средняя скорость 98 (события в секунду)
средняя 1-минутная скорость 91,75
5-минутная средняя скорость 98,35
счет 35505 (общее количество событий)
максимальная длительность 1000 (мс)
минимальная продолжительность 10
средняя продолжительность 10.13
значение 50-го процентиля (p50) 10
значение 99.9-го процентиля (p999) 1000

Если вы рисуете это, вы увидите, что большинство запросов (p50, p75, p99 и т.д.) завершалось через 10 мс, но один запрос из 1000 (p99) завершался за 1 секунду. Это также можно было бы рассматривать как небольшое снижение средней скорости (около 2%) и значительное уменьшение 1-минутного среднего (почти 9%).

Если вы посмотрите только на время (или скорость или продолжительность), вы никогда не заметите эти всплески - они попадают в фоновый шум при усреднении с большим количеством успешных операций. Точно так же знание max не полезно, потому что оно не говорит вам, как часто происходит max. Вот почему гистограммы являются мощным инструментом отслеживания производительности и почему DW Metrics Timer публикует как скорость, так и гистограмму.