Кардинальность: тихий убийца Prometheus

Серия в Prometheus — это имя метрики плюс каждая пара лейбл-значение; количество серий метрики равно произведению количества значений по всем лейблам. Счётчик запросов с лейблами route (пять маршрутов), method (четыре метода) и status (три класса) даёт шестьдесят серий на инстанс — это нормально и именно так работают срезы из урока про лейблы. Добавьте четвёртый лейбл user_id с пятьюдесятью тысячами значений — получите два с половиной миллиона серий с одного счётчика на одном инстансе. Произведение — коварная арифметика: два безобидных лейбла по десять значений дают сотню, а лейбл со свободным текстом — бесконечность, потому что значения приходят от пользователей и маршрутизаторов. Отдельный сезон боли — churn: когда старые серии постоянно умирают, а новые рождаются, индекс не успевает остывать. К этой категории относятся лейблы из времени, номера задачи и ID пода: их значения ограничены, но меняются слишком часто.

У Prometheus есть собственные серии о себе, и главный счётчик здесь — prometheus_tsdb_head_series: число серий в голове базы на момент скрейпа. Стабильная линия говорит, что набор лейблов стабилен; наклонная вверх — что серии плодятся, и именно так выглядел тот самый user_id на графике. Второй запрос — разложение по метрикам: count by (__name__)({__name__=~".+"}) вернёт число серий на каждую метрику и покажет чемпиона за один запрос. Третий признак — scrape_duration_seconds: время скрейпа вашего /metrics, которое при высокой кардинальности растёт вместе с объёмом ответа: экспозиция из сотен тысяч строк передаётся по сети каждые тридцать секунд, и это не гипотеза, а арифметика. В коде тот же счётчик можно завести себе: реестр умеет отдавать свой набор метрик, и по нему считается число серий без сервера Prometheus — сниппет ниже превращается в тест, который падает в CI, когда серия перешагивает границу.

Кардинальность бьёт по самому Prometheus, а не по вашему сервису, и это делает её тихой: приложение чувствует себя прекрасно, пока не падает мониторинг. Первая жертва — память: каждая серия живёт в индексе головы, и миллионы серий означают гигабайты, которые не освобождаются простым рестартом дня. Вторая — время скрейпа: экспорт растёт, и одновременно опрашиваются сотни таргетов, поэтому scrape_duration_seconds ползёт вверх у всех. Третья — запросы: агрегация по миллионам серий занимает секунды, дашборды подвисают, и тот же эффект ловит любой алерт с тяжёлым выражением. Сервер защищается лимитами конфигурации: sample_limit и series_limit на таргет обрывают скрейп с ошибкой, когда бюджет исчерпан, — и это правильное поведение, потому что падение одного таргета лучше падения всего Prometheus. О настройках скрейпа и лимитов подробнее будет в уроке про prometheus.yml; для кода важнее вывод: лимит на стороне сервера — предохранитель, а не решение, решение живёт в лейблах.

Справедливости ради посчитаем и встроенные серии: набор go_ и process_ из GoCollector и ProcessCollector — это несколько десятков серий с постоянным составом: лейблов почти нет, значения не меняются, и вклад кардинальности от них нулевой. Несколько десятков против сотен тысяч от одного неудачного лейбла — разница в четыре порядка, поэтому чинить надо не встроенный набор, а собственные метрики. Реальный риск в другом: пакет collectors позволяет включить расширенные метрики рантайма из runtime/metrics, и их набор уже заметно больше базового — включайте осознанно, а не флажком на всякий случай. Второй источник спокойствия — именно постоянство: серии go_ не рождаются и не умирают в процессе жизни, то есть не создают churn. Отсюда простое правило для ревью: серия оправдана, если вы можете назвать её количество заранее; всё, что рождается от входящих данных — идентификаторов, путей, текстов, — серия не оправдана почти никогда.

Три способа справиться с высококардинальными данными, и первый — единственный настоящий. Убрать: идентификатор уходит из лейбла в лог с request id, где поиск по пользователю работает и без Prometheus. Агрегировать на клиенте: вместо серии на пользователя — серия на класс, например код ответа или тип операции; срез по конкретному пользователю теряется, но он и не задача метрик. Агрегировать на сервере: sum by (route) спрячет user_id в результате запроса, но серии продолжат храниться и жрать память — это косметика, и применять её стоит только когда лейбл уже нельзя убрать из кода до следующего релиза. Спорное мнение с границей: отдельные системы — Loki для логов, трейсинг — существуют ровно для высококардинальных вопросов, и попытка воспроизвести их в лейблах метрик всегда проигрывает по цене. Если вопрос звучит как «что случилось с этим пользователем», это вопрос к логам из урока про request id, а не к гистограмме.