После добавления label пропала история метрики: идентичность серии Prometheus

К метрике запросов добавили label region. После выкладки в Grafana появились новые линии с короткой историей, а старые закончились. Значения счётчика тоже будто начали жизнь заново. Здесь важно разделить два события: изменение значения существующего счётчика и появление совершенно другой временной серии.

В Prometheus серию определяют имя метрики и полный набор labels. http_requests_total{job="api",instance="a"} и та же метрика с дополнительным region="west" имеют разные идентичности. Исторические samples старой серии не получают новый label задним числом.

Найдём обе формы данных

http_requests_total{job="api"}
http_requests_total{job="api",region="west"}
http_requests_total{job="api",region=""}

Первое выражение показывает все подходящие формы. Второе выбирает новую региональную серию. Третье соответствует пустому или отсутствующему region: это полезно для поиска старой формы, если пустое значение не используется намеренно в новой схеме. Сравнивайте labels в табличном представлении, а не только одинаковые legend на графике.

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

Почему rate не соединяет историю автоматически

Коррекция сброса счётчика работает внутри одной серии. Она не ищет похожий instance с другим набором labels. У новой серии сначала должно накопиться достаточно samples для окна скорости. Короткий провал после изменения labels поэтому возможен даже при непрерывном трафике.

sum by (job) (rate(http_requests_total{job="api"}[5m]))

Такой запрос не фиксирует region и объединяет скорости подходящих серий. Он может сохранить общий график на переходе, но смысл зависит от способа выкладки. Если старая и новая формы одновременно публикуют одни и те же запросы, сумма удвоит трафик. Если новая заменяет старую, переходные окна содержат участки разных серий с собственной экстраполяцией.

Поэтому сначала выясните, какие именно samples существовали одновременно. Удобно сравнить число серий по instance и region с временем обновления каждой реплики. Универсального выражения, которое угадает дубли и автоматически склеит любую смену схемы, нет.

Спроектируем label с устойчивым смыслом

Region полезен, если нужно регулярно сравнивать фиксированный набор регионов. Версия сборки, request_id или пользовательский идентификатор могут быстро увеличивать число комбинаций. Даже один новый label создаёт отдельные серии для каждого существующего набора остальных labels и каждого своего значения. Временные измерения лучше хранить там, где они действительно нужны для поиска отдельных событий.

Если атрибут описывает процесс и меняется при каждой выкладке, иногда удобнее отдельная info-метрика со значением 1. Тогда основной счётчик сохраняет устойчивую схему, а справочные сведения присоединяются отдельно с проверкой уникальности. Такой выбор не устраняет все сложности: ключ связи должен однозначно определять экземпляр.

Проведём миграцию потребителей

До изменения составьте список панелей, recording rules и алертов, которые используют метрику. Проверьте точные селекторы, группировки и шаблоны legend. У алерта новый label может создать новую идентичность и начать pending заново. Если label попадает в маршрутизацию, изменится также путь уведомления.

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

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

Ещё по теме

• Many-to-many matching not allowed в PromQL: как сопоставить серии
• P95 в Prometheus: как считать задержку по histogram и не усреднять процентили

Продолжить изучение

Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».