DropWizard Metrics Счетчики и таймеры

Вы частично сбиты с толку, потому что таймер DW Metrics ЯВЛЯЕТСЯ, среди прочего, счетчиком DW Metrics.

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

• средняя (средняя) ставка с момента запуска Метрики
• 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 операции, а время между двумя вызовами mark() составляло 10 секунд.

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

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

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

Короче говоря: таймеры сообщают о МНОЖЕСТВЕ метрик, и их может быть сложно понять, но как только вы это сделаете, они станут довольно мощным способом обнаружения скачкообразного поведения.

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

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 делает это за нас автоматически раз в минуту (наш отчетный период). Через 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%).

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