relabel_configs и metric_relabel_configs: на каком этапе меняются метки

Prometheus собирает слишком много данных. В одном случае лишними оказываются целые targets тестового окружения, в другом — только отладочная метрика внутри нужного exporter. Обе задачи можно выразить через relabeling, но одинаковая запись в разных секциях меняет совершенно разные части процесса.

До HTTP-запроса Prometheus знает адрес target и метаданные обнаружения. После запроса у него появляются samples с именами метрик и собственными labels. relabel_configs работает с targets до scrape, а metric_relabel_configs — с собранными samples перед приёмом. От этого зависит, какие поля доступны и какую работу вы действительно экономите.

Исключим target до обращения к нему

Пусть статическая конфигурация помечает машины окружением env. Собирать нужно только prod:

scrape_configs:
  - job_name: app
    static_configs:
      - targets: ['app-prod:9100']
        labels:
          env: prod
      - targets: ['app-test:9100']
        labels:
          env: test
    relabel_configs:
      - source_labels: [env]
        regex: prod
        action: keep

Правило keep сохраняет targets, у которых объединённое значение source_labels совпало с regex. Test будет исключён до сетевого запроса. Это уменьшает количество опросов. В конфигурации service discovery источником часто становятся временные labels с префиксом __meta_; они доступны именно на этой стадии.

Внутренние labels с двойным подчёркиванием обычно удаляются после target relabeling. Если значение обнаружения нужно видеть в запросах, перенесите его в обычный label на этом этапе. Не ожидайте, что __meta-поле автоматически окажется у каждой сохранённой метрики.

Отфильтруем конкретные samples

Теперь нужный production-exporter публикует крупную debug-метрику. Сам target нужен, поэтому добавим фильтр по имени:

    metric_relabel_configs:
      - source_labels: [__name__]
        regex: app_debug_payload_bytes
        action: drop

Этот блок добавляется к тому же scrape job. Имя метрики доступно через __name__. Prometheus уже скачал и разобрал ответ, поэтому фильтр не уменьшает размер HTTP-передачи или работу exporter. Он уменьшает число samples, поступающих в хранилище. Если дорого именно формирование ответа, нужно менять инструментацию или набор публикуемых метрик на источнике.

Автоматически создаваемые серии вроде up не проходят обычный metric relabeling. Поэтому удаление всех app-метрик не равнозначно исчезновению target. Страница targets и значение up могут продолжать показывать успешный scrape.

Почему удаление label требует осторожности

Высококардинальный label хочется просто убрать через labeldrop. Но если он различал две серии с одинаковыми остальными labels, после удаления они станут одним и тем же набором. Это не содержательное суммирование. Возможны конфликты samples, а результат перестанет выражать исходные наблюдения.

Допустим, по user_id публикуется число запросов. Удалить user_id у всех строк — не способ получить общий счётчик. Общий счёт нужно формировать в инструментации или вычислять корректной агрегацией сохранённых серий. Прежде чем менять labels при приёме, выпишите два исходных примера и получившиеся наборы: они должны оставаться однозначными.

Проверим оба этапа отдельно

После проверки YAML и штатного применения конфигурации откройте targets. Для отброшенного test проверьте результат обнаружения и relabeling. Для production запросите конкретную debug-метрику на новом интервале и убедитесь, что остальные app-метрики продолжают поступать. Старые сохранённые samples не исчезают автоматически из истории.

Сравните показатели samples до и после metric relabeling и длительность scrape. Если уменьшилось хранение, но сеть и exporter по-прежнему перегружены, это ожидаемый предел выбранного этапа. Решение становится понятным, когда каждый фильтр отвечает на конкретный вопрос: обращаться ли к target вообще или какие полученные samples сохранять.

Ещё по теме

• Alertmanager шлёт слишком много сообщений: group_by и интервалы уведомлений
• Dashboard Grafana сбрасывает изменения: UI, provisioning и источник файла

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

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