Метрики: количества, скорость и распределения

§1Измерение и метрика

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

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

Из тысячи измерений длительности получаются разные метрики: количество запросов, суммарное время, среднее, доля медленных. Какая нужна, зависит от вопроса. Поэтому к названию метрики всегда прилагают описание: что измеряли, в какой точке, в каких единицах.

Метрики сервиса стенда называются lab_http_requests_total и lab_http_request_duration_seconds. Имена построены по соглашениям Prometheus, поэтому читаются без документации.

Первоисточник: Prometheus · Metric and label naming ↗

Метрики различаются по тому, как ведёт себя число. Следующий раздел называет три вида.

§2Три вида числовых данных

Числа в метриках ведут себя по-разному, и от этого зависит, какие вычисления с ними допустимы. В Prometheus и большинстве других систем различают три основных вида.

Счётчик (counter) только растёт, а при перезапуске процесса начинается с нуля. Так считают запросы, ошибки, отправленные байты. Мгновенное значение (gauge) растёт и уменьшается. Так показывают длину очереди, занятую память, активные соединения. Распределение (histogram) — это набор счётчиков по диапазонам значений. Так хранят длительность запросов и размер ответов.

Вид выбирают по тому, что измеряют. События считают счётчиком: число запросов может только расти. Состояние в момент измерения показывают мгновенным значением: очередь то растёт, то убывает. Если важно, сколько запросов быстрые и сколько медленные, берут гистограмму.

Первоисточник: Prometheus · Metric types ↗

Первый из трёх видов — счётчик. С него начинается подробный разбор.

§3Счётчик и скорость

Счётчик (counter) — метрика, которая хранит накопленное количество событий с момента запуска процесса. Значение только увеличивается, а при перезапуске процесса начинается с нуля.

Само значение счётчика почти ничего не говорит. Число 15 000 означает, что с момента запуска процесс обработал 15 000 запросов. Процесс мог работать минуту или месяц, так что о текущей нагрузке по этому числу судить нельзя.

Пользу даёт изменение счётчика: берут два значения с интервалом 10 секунд и делят прирост на интервал.

before = 15000   # значение счётчика в 12:00:00
after = 15240    # значение счётчика в 12:00:10
seconds = 10

print((after - before) / seconds, "запроса/с")

24.0 запроса/с

Это средняя скорость за 10 секунд. Внутри интервала запросы могли приходить неравномерно: 200 в первую секунду и 40 за остальные девять. Счётчик этого не покажет, но и не потеряет ни одного события: сколько бы запросов ни пришло между чтениями, прирост их учтёт.

На дашборде Grafana в главе 1.8 две верхние панели показывают счётчики с запуска, а панель «Поток запросов» — скорость, посчитанную из того же счётчика. Метрика одна, а вопросы разные: «сколько всего» и «сколько в секунду сейчас».

Счётчик считает события. Для состояний нужен второй вид метрики.

§4Мгновенное значение

Мгновенное значение (gauge) — метрика, которая показывает текущее состояние в момент измерения. Значение может и расти, и уменьшаться.

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

Обращаться с мгновенным значением как со счётчиком нельзя. В 12:00 в очереди 40 заданий, в 12:01 — 35. Разница −5 не означает, что за минуту обработали пять заданий: могло прийти 100 новых и выполниться 105. Мгновенное значение показывает только остаток, а сколько заданий прошло через очередь, по нему не узнать.

Второе отличие: мгновенное значение фиксирует состояние только в момент измерения. Если очередь выросла до 5000 и опустела между двумя измерениями, пика на графике не будет. У счётчика такой проблемы нет, поэтому события считают счётчиком, а мгновенное значение оставляют для состояний.

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

§5Двадцать запросов к стенду

Теперь измерения со стенда. Скрипт experiment.py из архива отправляет двадцать запросов подряд и сохраняет длительность каждого. Сценарии заданы заранее: запросы 7 и 17 медленные, запрос 13 завершается ошибкой, остальные семнадцать быстрые. Это управляемый опыт: настоящий трафик он не представляет, но его можно повторить и проверять на нём расчёты.

Исходные данные можно проверить самим: requests.csv ↓ содержит все двадцать строк, summary.json ↓ — итоговый расчёт. Времени в таблице два. client_ms измерил скрипт-клиент, handler_ms — сам сервис внутри обработчика. Все расчёты ниже сделаны по времени клиента: его ждёт пользователь.

import csv
import math
import statistics

with open("results/requests.csv", newline="") as file:
    durations = sorted(float(row["client_ms"]) for row in csv.DictReader(file))

n = len(durations)
print("запросов:", n)
print("среднее:", round(statistics.mean(durations), 3), "мс")
print("медиана:", round(statistics.median(durations), 3), "мс")
print("p95:", durations[math.ceil(0.95 * n) - 1], "мс")

запросов: 20
среднее: 379.47 мс
медиана: 85.739 мс
p95: 3024.239 мс

Программа читает CSV модулем csv: DictReader превращает каждую строку в словарь с ключами из заголовка. Генератор берёт из каждой строки client_ms и переводит в число, а sorted упорядочивает длительности по возрастанию. Функции statistics.mean и statistics.median считают среднее и медиану. Как устроена последняя строка с p95, разобрано ниже.

В итогах прогона среднее в четыре раза больше медианы. Следующий раздел объясняет, откуда такая разница.

§6Почему среднее скрывает редкие задержки

Восемнадцать запросов из двадцати заняли от 78 до 94 мс. Два запроса длились около 3 секунд. Среднее получилось 379 мс, хотя ни одного запроса такой длительности в прогоне нет.

Так получается потому, что среднее складывает все значения. Два запроса по 3000 мс добавляют к сумме около 6000 мс, и после деления на 20 каждый обычный запрос как будто стал медленнее на 300 мс. Без этих двух запросов среднее оставшихся восемнадцати — около 85 мс.

Медиана — значение, которое делит упорядоченный набор пополам: половина значений меньше медианы, половина больше. При чётном числе значений медиана равна среднему двух центральных.

Медиана прогона — 85,739 мс, и она хорошо описывает типичный запрос. Но у неё обратный недостаток: медленные запросы она не замечает совсем. Если бы медленным стал не каждый десятый, а каждый третий запрос, медиана осталась бы около 86 мс.

Среднее всё же нужно. Чтобы оценить, сколько процессорного времени сервис тратит на запросы, считают сумму или среднее. А для вопроса «насколько долго ждут пользователи» одного среднего мало.

В таблице есть третий показатель, p95. Он описывает медленную часть запросов, и ему посвящён следующий раздел.

§7Перцентиль

Перцентиль — значение, ниже которого лежит заданный процент упорядоченных наблюдений. p95 — такая длительность, что 95% запросов выполнились не дольше неё, а 5% — дольше.

p95 читается как «95-й перцентиль». Часто используют p50 (это медиана), p90, p95 и p99. Чем больше число, тем более редкие медленные запросы описывает перцентиль.

Посчитать перцентиль можно разными методами. Здесь используется метод ближайшего ранга: он проще остальных.

Ниже те же двадцать запросов. Сначала столбцы стоят в порядке отправки. Переключите на «По длительности»: столбцы выстроятся по возрастанию, и 19-й столбец окажется p95.

В порядке отправки медленные запросы 7 и 17 стоят в середине. После сортировки они оказываются последними, а ошибочный запрос 13 — первым: ошибка вернулась быстрее всех, за 78 мс. Ошибочные запросы в выборке длительности тянут показатели вниз, и сбой может выглядеть как ускорение.

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

Перцентиль посчитан по списку из двадцати значений. Следующий раздел показывает, как его получают, когда значений миллионы.

§8Гистограмма: как хранят распределение

На стенде перцентиль посчитан по списку всех длительностей. Сервис с тысячей запросов в секунду так делать не может: список всех значений занял бы слишком много места. Нужно сохранить форму распределения в нескольких числах.

Гистограмма (histogram) — метрика, которая делит возможные значения на диапазоны и считает, сколько наблюдений попало в каждый. Диапазоны называют корзинами (buckets).

Сервис отдаёт гистограмму длительности по адресу /metrics. Так выглядит ответ в браузере после нескольких сотен запросов.

123456

# HELP — описание метрики для человека, # TYPE — её вид: counter или histogram. Первые две строки данных — счётчик запросов с разбивкой по статусу: 254 успешных и 11 ошибочных.

Дальше идёт гистограмма. Строки _bucket — счётчики корзин. Метка le означает less or equal, «меньше или равно». Корзина le="0.1" хранит число запросов длительностью не больше 0,1 секунды. Корзины накопительные: каждая включает все предыдущие, поэтому числа сверху вниз только растут.

Последние две строки — _sum и _count: сумма всех длительностей в секундах и общее число наблюдений. Из них получается среднее: 77,73 / 265 ≈ 0,293 с, или 293 мс. Так построена панель «Средняя длительность» в Grafana.

Точность перцентилей из гистограммы задают границы корзин. Границы делают гуще там, где важна точность. Если обещанная длительность ответа 300 мс, нужны корзины 0,2, 0,3 и 0,4 с: одной корзины от 0,25 до 0,5 недостаточно. Функция histogram_quantile в Prometheus выполняет ту же линейную оценку.

Первоисточник: Prometheus · Histograms and summaries ↗

Гистограмма хранит распределение одного экземпляра. Следующий раздел показывает, как объединять данные нескольких экземпляров.

§9Почему перцентили нельзя усреднять

У сервиса три экземпляра, каждый считает свой p95, а на общей панели нужен p95 всего сервиса. Взять среднее от трёх значений — неверный расчёт.

Правильно сначала объединить распределения, а потом посчитать перцентиль. Гистограммы объединяются сложением: корзины с одинаковыми границами складывают по всем экземплярам и получают гистограмму сервиса. Это ещё одна причина хранить длительности гистограммой: готовые перцентили объединить нельзя.

Метрики сжимают события в числа. Последний раздел подводит итог: что при этом сохраняется и что теряется.

§10Что теряется при агрегации

Метрика сжимает много событий в несколько чисел, и подробности при этом теряются. Сравнение ниже показывает, что остаётся и что теряется.

Для левой колонки метрики подходят лучше других сигналов: они занимают мало места и быстро считаются даже за месяцы. Для правой нужны другие сигналы: текст исключения хранится в логах, этапы запроса — в трассах. Метрика показывает, что и насколько изменилось, а дальше расследование переходит к подробным данным.

§11Частые ошибки

§12Проверьте себя

§13Шпаргалка