Новые targets без рестарта Prometheus: обновляем file_sd атомарно

Список машин меняется несколько раз в день. Пока адреса находятся прямо в prometheus.yml, каждое изменение требует генерации основной конфигурации и reload. Это связывает относительно простую операцию инвентаризации со всем конфигом мониторинга. File-based service discovery позволяет вынести список целей в отдельный JSON или YAML и обновлять его независимо.

В основной конфигурации остаётся описание job и путь к файлам. Внешний генератор отвечает только за адреса и общие метки группы. Prometheus следит за файлами discovery и обновляет цели. При этом параметры scrape, аутентификация и relabeling остаются в обычной конфигурации: смена инвентаря не должна незаметно менять способ сбора данных.

Разделить конфиг и инвентарь

Например, job node читает группы целей из каталога targets. Путь должен быть доступен процессу Prometheus; при контейнерном запуске это путь внутри контейнера.

scrape_configs:
  - job_name: node
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/*.json

Файл с одной группой может содержать два exporter и общую метку окружения:

[
  {
    "targets": ["node-a.example:9100", "node-b.example:9100"],
    "labels": {"environment": "staging"}
  }
]

Адреса example здесь обозначают ваши реальные машины. Формат target включает host и порт, а не полный URL с произвольным путём. Если exporters требуют разный путь или схему, эту связь нужно описать предусмотренными настройками и метками, а не прятать разные форматы в строке адреса.

Не публиковать половину файла

Генератор должен сначала записать новый документ во временный файл в том же файловом разделе, проверить JSON и только затем заменить рабочий через rename. Временное имя не должно соответствовать glob *.json, иначе Prometheus может попытаться прочитать его раньше завершения записи. Атомарная замена делает видимым либо прежний документ, либо новый целиком.

Перед публикацией проверьте не только синтаксис, но и содержимое: пустой список может быть валидным результатом ошибки инвентаря. Полезно сравнить число targets с прежним значением и остановить публикацию при неожиданно большом удалении. Такая проверка относится к контракту вашего генератора, потому что Prometheus не знает, сколько машин ожидалось в организации.

На учебном стенде добавьте одну цель и убедитесь, что она появилась в Targets без перезапуска процесса. Затем уберите её и проверьте исчезновение из discovery. Отдельно сопоставьте discovered labels и итоговые labels после relabeling: адрес может находиться в файле, но быть отброшен правилами.

В контейнерном окружении удобнее монтировать каталог, содержащий файлы, и проверять видимость замены из контейнера. Привязка одиночного файла имеет особенности при замене inode. После настройки изменение инвентаря становится короткой операцией с собственным контролем результата, а основной конфиг Prometheus остаётся стабильным и проще проверяется при review.

Продолжить практику

Одно выражение или правило становится полезным, когда связано с конкретным действием инженера. В программе курса «Prometheus и Grafana: мониторинг и observability» — метрики учебного сервиса, exporters, обзорный и диагностический дашборды, SLI/SLO и алерты с инструкциями. Практика включает воспроизведение отказа или роста задержек и расследование по сигналам системы. Это продолжение для тех, кто хочет собрать мониторинг, по которому можно принимать решения во время сбоя.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Метрики и уведомления без неверных выводов.