Скрейпинг: prometheus.yml и сервис-дискавери

Конфиг Prometheus — YAML с четырьмя основными секциями. В global живут дефолты: scrape_interval — как часто опрашивать цели, scrape_timeout — сколько ждать ответа, evaluation_interval — как часто пересчитывать правила. Раздел rule_files подключает файлы алертов и записей — то самое место, которого ждал урок про алерты, когда обещал научить подключать правила к серверу. Наконец, scrape_configs — список задач: каждая имеет job_name, уникальный в конфиге, и список целей через static_configs или сервис-дискавери. job_name становится лейблом job на каждой серии этого таргета, и по нему фильтруются запросы и дашборды — поэтому имя задачи стоит выбирать так же дисциплинированно, как namespace метрик из предыдущего урока: коротко, доменом сервиса, без окружения внутри имени.

scrape interval — компромисс между свежестью графиков и объёмом хранилища: каждая цель с каждой серией пишет сэмпл на каждый опрос. Арифметика честная: сто серий при опросе раз в пятнадцать секунд дают около шестисот тысяч сэмплов в сутки на один такой таргет, и при сотнях таргетов интервал перерастает в бюджет железа. Дефолт конфига — минута, пятнадцать секунд — рабочий выбор для сервисов, потому что графики отзывчивы, а объём умеренный; раз в пять секунд опрашивают только отдельные критичные задачи. Вторая связь важнее для кода: окно rate в PromQL обязано содержать минимум два сэмпла, иначе значение пустое, — при интервале пятнадцать секунд окно в минуту спокойно, а окно в десять секунд пустое почти всегда. Практическое правило из урока про PromQL: окно rate берут не меньше четырёх интервалов скрейпа. И третье: scrape_timeout обязан быть меньше scrape_interval, иначе ответы приходят после следующего опроса. Цену изменения проверяют до выката: prometheus_tsdb_head_series и прирост данных за сутки показывают эффект до того, как диск закончится, а фоновым задачам и тяжёлым отчётам допустимо оставить интервал в минуту — там изменения медленнее точности дашборда.

static_configs честно работает до десятка целей: два-три реплики, база, шлюз — список читается глазами. Дальше начинается боль: поды меняют адреса при каждом деплое, и конфиг, правимый руками, отстаёт от реальности. Для этого в Prometheus встроены механизмы сервис-дискавери — списки целей, которые сервер запрашивает сам и обновляет по расписанию. Обзорно о рабочих вариантах: dns_sd_configs опрашивает DNS-записи A, AAAA или SRV — удобно для docker-compose и consul-шаблонов, где реплики видны по имени сервиса; http_sd_configs ходит по вашему URL и читает JSON-список целей — минимальный самописный дискавери, который возвращает то, что знает ваш оркестратор. Есть и тяжёлые интеграции — consul_sd_configs, kubernetes_sd_configs, файловый file_sd_configs, — устроенные по одному принципу: источник целей отделён от правил обработки. Разбор каждой интеграции — тема отдельной книги; для курса достаточно понимать контракт: дискавери отдаёт адреса, дальше работают те же relabel-правила.

Relabel — это конвейер правил над лейблами, и у него два входа. relabel_configs выполняется до скрейпа и работает с метаданными цели: __address__, __scheme__, __metrics_path__ и метки дискавери с префиксом __meta_. Классика — переписать instance, вытащить зону из адреса, дописать общий лейбл окружения. metric_relabel_configs выполняется после скрейпа, на уже полученных сериях, и здесь живут два важных жеста: drop — выкинуть ненужные метрики до записи в хранилище, и keep — оставить только разрешённые. Регулярка применяется к указанным source_labels, и её же ловушка — косая черта в YAML и границы совпадения: regex анкерится по всей строке, поэтому debug.* не совпадёт с именем без префикса-начала. Правило границы: метрики дропают конфигом только как предохранитель — постоянная гигиена имён живёт в коде, как учили уроки про реестр и кардинальность.

После правки конфига проверка занимает минуту и не требует Grafana. Сначала promtool check config prometheus.yml — синтаксис и ссылки на файлы правил до перезапуска. Затем перезагрузка: сигнал SIGHUP или endpoint перезагрузки, если сервер запущен с включённым жизненным циклом. Дальше страница /targets или запрос к API: у каждой цели виден последний статус, длительность скрейпа и число полученных сэмплов. Зелёный таргет подтверждает метрика up со значением один; серый — цель пропала из конфига, красный — опрос не удался, и причина лежит в столбце ошибки. На дашбордах для наблюдения за самим скрейпом служат scrape_duration_seconds — время, которое сервер тратил на опрос, и scrape_samples_scraped — размер выборки: их рост при неизменном коде показывает, что endpoint тяжелеет, обычно из-за кардинальности из семнадцатого урока. Отдельный жест — SIGHUP перечитывает и файлы правил, поэтому правка алерта не требует рестарта сервера; рестарт нужен только при смене флагов запуска.