В этом материале
Relabel_configs фильтрует и изменяет targets до scrape, metric_relabel_configs — samples перед ingestion. Выбор стадии определяет, какие расходы исчезнут. Отбрасывание метрики после получения ответа не отменяет выполненный запрос к exporter и не уменьшает его работу автоматически.
Relabel_configs фильтрует и изменяет targets до scrape, metric_relabel_configs — samples перед ingestion. Выбор стадии определяет, какие расходы исчезнут. Отбрасывание метрики после получения ответа не отменяет выполненный запрос к exporter и не уменьшает его работу автоматически.
Нарисуйте путь данных
Зафиксируйте discovery, target relabeling, scrape, metric relabeling и локальную запись. Для remote_write существует отдельный write_relabel_configs перед отправкой. Эти настройки используют похожий формат, но применяются к разным объектам в разные моменты. Сохраните job и фактические labels до изменения. Не переносите правило между стадиями только по совпадению YAML ключей: метки discovery могут существовать до scrape и уже отсутствовать при обработке samples, а name относится к серии.
Выберите нужный эффект
Если узел вообще не должен опрашиваться, фильтруйте target. Если exporter нужен, но часть его метрик не требуется хранить, используйте metric relabeling. Если локальные серии нужны, а удалённый backend должен получать только часть, рассматривайте write relabeling. Последний вариант не удаляет уже принятую локальную историю. Metric relabeling не применяется к автоматически создаваемым рядам вроде up. Сохраняйте это различие при проверке: up может остаться, хотя выбранные exporter samples больше не поступают.
Разберите учебное правило drop
Представим job, где нужны host metrics, но исключается отдельное семейство debug_*. Правило по name в metric_relabel_configs может отбрасывать эти samples перед ingestion. При этом exporter всё ещё получает scrape и формирует ответ. Сравните scrape_samples_scraped со scrape_samples_post_metric_relabeling, затем проверьте наличие нужных рядов. Пример объясняет точку фильтрации; он не обещает экономию сетевого трафика или CPU exporter без изменений на его стороне.
| Стадия | Что может прекратиться |
|---|---|
| Target relabel | Сам опрос исключённого target |
| Metric relabel | Приём выбранных samples в TSDB |
| Write relabel | Отправка выбранных samples удалённо |
| Exporter configuration | Генерация ненужных данных у источника |
Сохраните уникальность labels
Удаление label не эквивалентно суммированию рядов. Если разные серии после labeldrop становятся неразличимыми, возникают конфликты вместо корректной агрегации. Сначала исследуйте конкретный labelset и область job. Проверяйте конфигурацию доступным promtool и применяйте к тестовой группе. Не удаляйте широким regexp метки, нужные алертам или идентификации экземпляра. Исторические samples также не исчезают моментально от смены правила: отделяйте новую ingestion policy от retention существующего хранилища.
Проверьте требуемую границу
После reload сравните target discovery, up, число scraped/post-relabel samples и наличие нужных серий. Для write relabeling дополнительно проверьте удалённый приём отдельно от локального. Артефакт должен содержать правило, стадию, ожидаемый эффект и измеренное подтверждение. Если цель состояла в уменьшении exporter load, а изменился только local ingestion, исправление не соответствует цели. Такой протокол показывает, что именно фильтр изменил и какие части pipeline продолжают работать как прежде.
Связанные разборы: gpu monitoring scorecard; inference capacity planning.