Метрики и Prometheus: типы и кардинальность

Кто к кому ходит

Prometheus не ждёт, пока приложение что-то пришлёт. Он сам по расписанию (у меня раз в 5 секунд) ходит на адрес приложения и забирает текущие значения. Это называют моделью опроса, и у неё есть приятный побочный эффект: сам факт удачного опроса - уже метрика. Она называется up и равна единице, если опрос прошёл.

Проверил, что бывает при падении цели. Пока приложение живо, up равна 1. Я остановил контейнер - через несколько секунд up стала 0, и это готовый сигнал «сервис недоступен», который не надо специально придумывать. А вот сами метрики приложения из запросов ПРОПАЛИ: не замерли на последнем значении, а именно перестали возвращаться. Это важно: график не «застывает», он обрывается.

// Обратная сторона модели опроса - недолговечные задачи. Скрипт, который живёт 200 миллисекунд, опросить невозможно: к моменту прихода Prometheus его уже нет. Для таких случаев ставят промежуточный приёмник, куда задача сама отправляет результат перед смертью, а Prometheus опрашивает уже его.

модель опроса

сборщик сам ходит за метриками по расписанию

метрика up

1, если опрос цели удался; готовый сигнал недоступности

промежуточный приёмник

место, куда короткоживущие задачи кладут метрики перед смертью

Счётчик, измеритель и гистограмма

Счётчик только растёт. У меня «всего запросов» показал 21 564 успешных и 899 ошибок. Само по себе это число бесполезно: оно накопилось с момента запуска. Смысл появляется от скорости роста - я посчитал её и получил 345,5 запроса в секунду и 14,5 ошибки в секунду.

Измеритель может расти и падать: это мгновенное значение вроде «запросов прямо сейчас в обработке» (у меня 10) или «свободно памяти». Его читают как есть, скорость роста для него бессмысленна.

// Гистограмма - счётчики попаданий в корзины по длительности. У меня стояли корзины 0,005, 0,01, 0,025, 0,05, 0,1, 0,25, 0,5, 1, 2,5 и 5 секунд плюс «всё остальное». Из неё считаются квантили - значения, ниже которых лежит заданная доля запросов, - но считаются по корзинам, а не по точным значениям, и это накладывает ограничения, о которых отдельно.

// И ещё один важный факт про счётчики, который я проверил специально. Приложение перезапустилось - счётчик начался с нуля (у меня 3821 вместо 21 564). Сырое значение при этом «упало», а вот скорость роста осталась правильной, 316 в секунду: функция расчёта скорости умеет замечать сброс счётчика и не считает его отрицательным всплеском.

счётчик

только растёт; смысл имеет его скорость роста, а не само значение

измеритель

мгновенное значение, может расти и падать

гистограмма

счётчики попаданий в корзины; из неё считают квантили

Кардинальность: чем платят за красивые метки

Ряд данных в Prometheus - это уникальное сочетание имени метрики и всех её меток. Метрика с меткой статуса на два значения даёт 2 ряда. Та же метрика с меткой идентификатора пользователя даёт столько рядов, сколько было пользователей: в моём замере 500 при пятистах пользователях, ровно один к одному.

Дальше умножение. Добавили метку с адресом клиента - плюс тысячи. Добавили путь запроса, а в нём номер заказа - плюс миллионы. Каждый ряд занимает память в текущем срезе и место на диске, а запросы по ним замедляются. У меня 1107 рядов держали 79 мегабайт, и это игрушечный стенд.

// Правило простое: в метках живут ЗАКРЫТЫЕ множества. Статус, метод, код ответа, имя сервиса, зона - у них конечное и небольшое число значений. Идентификаторы пользователей, заказов, сессий, полные пути с числами - в метки не кладут никогда. Если такая детализация нужна, для неё есть логи и трассировки, где стоимость устроена иначе.

ряд данных

уникальное сочетание имени метрики и всех её меток

кардинальность

число таких сочетаний; растёт умножением значений меток

Как отвечать: «Что такое кардинальность метрик и чем она опасна?»

Кардинальность - это число рядов данных, а ряд это уникальное сочетание имени метрики и всех её меток. Опасность в том, что метки перемножаются, и растёт всё очень быстро. Я это специально мерил на стенде: обычная метрика с меткой статуса дала 2 ряда, а та же метрика с идентификатором пользователя в метке - 500 рядов при пятистах пользователях, один к одному. На реальном сервисе это миллионы рядов, каждый из которых занимает память в текущем срезе и место на диске, а запросы по ним замедляются. Правило, которым я пользуюсь: в метки идут только закрытые множества - статус, метод, код ответа, имя сервиса. Идентификаторы, полные пути с номерами и адреса клиентов туда не кладут никогда, для такой детализации есть логи и трассировки.

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

На чём валятся

• −Кладут в метки идентификаторы пользователей и заказов и взрывают хранилище.
• −Читают сырое значение счётчика вместо его скорости роста.
• −Ждут, что метрики упавшего сервиса «замрут» на последнем значении. Они пропадают.
• −Пытаются опрашивать короткоживущие задачи вместо промежуточного приёмника.
• −Считают, что счётчик после перезапуска сломает график. Расчёт скорости умеет замечать сброс.