--- title: "Скрейпинг: prometheus.yml и сервис-дискавери" description: "prometheus.yml настройка под Go-сервис: scrape_configs, job_name, metrics_path, scrape interval 15 секунд, relabel и сервис-дискавери — от таргета до up." course: "Мониторинг Go с Prometheus: метрики, Grafana, алерты" url: "https://golangmaster.ru/courses/prometheus/lessons/23-scrape-config/" published: "2026-09-19" updated: "2026-09-24" minutes: 18 --- # Скрейпинг: prometheus.yml и сервис-дискавери *Курс «Мониторинг Go с Prometheus: метрики, Grafana, алерты», урок 23 из 25. ~18 минут. Обновлено 24.09.2026. Источник: https://golangmaster.ru/courses/prometheus/lessons/23-scrape-config/* Настройка prometheus.yml — это список целей scrape_configs и интервалы опроса: именно она решает, узнает ли Prometheus о вашем /metrics, который открывается в браузере, но никем не читается. Разберём job_name, scrape interval, relabel и сервис-дискавери — путь от строчки конфига до зелёной метрики up. Сервис переехал на новый стенд, /metrics открывается, метрики красивые — а в Grafana тишина, потому что у нового хоста нет цели в конфиге Prometheus. Это второй акт той самой истории из [третьего урока](/courses/prometheus/lessons/03-ustanovka-client-golang/): живой endpoint — половина контракта, вторая половина — тот, кто регулярно забирает данные. Prometheus работает по pull-модели: сам ничего не ищет в вашей инфраструктуре сверх того, что сказано в prometheus.yml, и молчит ровно до тех пор, пока цель не объявлена. В этом уроке разберём настройку скрейпа целиком: глобальные интервалы, разделы scrape_configs с job_name и metrics_path, правила relabel, честный обзор сервис-дискавери — и то, как за минуту проверить, что цель зелёная. ### prometheus.yml: глобальная секция и scrape_configs Конфиг Prometheus — YAML с четырьмя основными секциями. В global живут дефолты: scrape_interval — как часто опрашивать цели, scrape_timeout — сколько ждать ответа, evaluation_interval — как часто пересчитывать правила. Раздел rule_files подключает файлы алертов и записей — то самое место, которого ждал [урок про алерты](/courses/prometheus/lessons/14-alerts-obzor/), когда обещал научить подключать правила к серверу. Наконец, scrape_configs — список задач: каждая имеет job_name, уникальный в конфиге, и список целей через static_configs или сервис-дискавери. job_name становится лейблом job на каждой серии этого таргета, и по нему фильтруются запросы и дашборды — поэтому имя задачи стоит выбирать так же дисциплинированно, как namespace метрик из [предыдущего урока](/courses/prometheus/lessons/22-reestry-i-namespaces/): коротко, доменом сервиса, без окружения внутри имени. ### Рабочий минимум prometheus.yml ```go global: scrape_interval: 15s scrape_timeout: 10s evaluation_interval: 15s rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: shop metrics_path: /metrics static_configs: - targets: ["10.0.0.11:8080", "10.0.0.12:8080"] labels: env: dev - job_name: prometheus static_configs: - targets: ["localhost:9090"] ``` Глобальные пятнадцать секунд распространяются на все задачи, у которых нет своего scrape_interval. Первая задача скрейпит две реплики сервиса: job=shop прилипает к их сериям, а env=dev — удобный лейбл окружения, заданный на уровне цели. Вторая задача — самообслуживание Prometheus: его внутренние метрики, включая счётчик скрейпов, полезны всегда. ### scrape interval: цена частоты опроса scrape interval — компромисс между свежестью графиков и объёмом хранилища: каждая цель с каждой серией пишет сэмпл на каждый опрос. Арифметика честная: сто серий при опросе раз в пятнадцать секунд дают около шестисот тысяч сэмплов в сутки на один такой таргет, и при сотнях таргетов интервал перерастает в бюджет железа. Дефолт конфига — минута, пятнадцать секунд — рабочий выбор для сервисов, потому что графики отзывчивы, а объём умеренный; раз в пять секунд опрашивают только отдельные критичные задачи. Вторая связь важнее для кода: окно rate в PromQL обязано содержать минимум два сэмпла, иначе значение пустое, — при интервале пятнадцать секунд окно в минуту спокойно, а окно в десять секунд пустое почти всегда. Практическое правило из [урока про PromQL](/courses/prometheus/lessons/12-promql-basics/): окно 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-правила. ### Дискавери и отдельный интервал на задачу ```go scrape_configs: - job_name: shop scrape_interval: 15s dns_sd_configs: - names: ["shop.internal"] type: A port: 8080 relabel_configs: - source_labels: [__meta_dns_name] target_label: dns_zone - job_name: slow-jobs scrape_interval: 1m metrics_path: /internal/metrics static_configs: - targets: ["reports.internal:9100"] ``` Первая задача получает реплики по DNS-имени: Prometheus переопрашивает запись и сам добавляет и убирает цели. relabel_configs переносит имя DNS-записи в лейбл — так на дашборде видно источник. Вторая задача показывает, что интервал и путь задаются на задачу: тяжёлые эндпоинты опрашивают реже, служебные пути не обязаны называться /metrics. ### Relabel: правила до скрейпа и после Relabel — это конвейер правил над лейблами, и у него два входа. relabel_configs выполняется до скрейпа и работает с метаданными цели: __address__, __scheme__, __metrics_path__ и метки дискавери с префиксом __meta_. Классика — переписать instance, вытащить зону из адреса, дописать общий лейбл окружения. metric_relabel_configs выполняется после скрейпа, на уже полученных сериях, и здесь живут два важных жеста: drop — выкинуть ненужные метрики до записи в хранилище, и keep — оставить только разрешённые. Регулярка применяется к указанным source_labels, и её же ловушка — косая черта в YAML и границы совпадения: regex анкерится по всей строке, поэтому debug.* не совпадёт с именем без префикса-начала. Правило границы: метрики дропают конфигом только как предохранитель — постоянная гигиена имён живёт в коде, как учили уроки про реестр и кардинальность. ### Правила relabel в конфиге ```go scrape_configs: - job_name: shop static_configs: - targets: ["10.0.0.11:8080"] relabel_configs: - source_labels: [__address__] regex: "([^:]+):\\d+" target_label: host metric_relabel_configs: - source_labels: [__name__] regex: "debug_.*" action: drop ``` Первое правило вырезает хост из адреса и кладёт в лейбл host — до скрейпа, на метаданных цели. Второе работает уже с полученными сериями: всё, что начинается с debug_, в хранилище не попадает. Дроп по регулярке — предохранитель от утечки отладочных метрик, а не замена дисциплине в коде. ### Проверка: зелёный таргет за минуту После правки конфига проверка занимает минуту и не требует Grafana. Сначала promtool check config prometheus.yml — синтаксис и ссылки на файлы правил до перезапуска. Затем перезагрузка: сигнал SIGHUP или endpoint перезагрузки, если сервер запущен с включённым жизненным циклом. Дальше страница /targets или запрос к API: у каждой цели виден последний статус, длительность скрейпа и число полученных сэмплов. Зелёный таргет подтверждает метрика up со значением один; серый — цель пропала из конфига, красный — опрос не удался, и причина лежит в столбце ошибки. На дашбордах для наблюдения за самим скрейпом служат scrape_duration_seconds — время, которое сервер тратил на опрос, и scrape_samples_scraped — размер выборки: их рост при неизменном коде показывает, что endpoint тяжелеет, обычно из-за кардинальности из [семнадцатого урока](/courses/prometheus/lessons/17-kardinalnost/). Отдельный жест — SIGHUP перечитывает и файлы правил, поэтому правка алерта не требует рестарта сервера; рестарт нужен только при смене флагов запуска. > **Типичная ошибка: job добавили, таргет красный до вечера.** Конфиг отредактировали, сервер перезапустили, а цель красная: endpoint отдаёт 500. Ошибка ищется в двух местах: metrics_path не совпадает с реальным путём — сервис отдаёт метрики на /internal/metrics, а конфиг ходит на /metrics; или endpoint падает на сборе — паника коллектора из-за дубликата регистрации, о которой [предыдущий урок](/courses/prometheus/lessons/22-reestry-i-namespaces/) писал fail fast. Полдня уходит, когда ищут в сетке и фаерволах, а страница цели прямо показывает HTTP-код и текст ошибки. Читайте столбец Error до рестартов. ### Причины красного таргета и их проверка - Неверный metrics_path: сверить с curl по фактическому пути сервиса - Endpoint отвечает 500: текст ошибки на странице цели, чаще всего дубликат регистрации - Сеть и порт: curl с хоста Prometheus на таргет — первый шаг проверки - Таймаут: ответ тяжелее scrape_timeout — смотреть scrape_duration_seconds - Схема http вместо https: перенаправления ломают скрейп — проверить scheme - Цель пропала из дискавери: серый статус — источник целей не отдаёт адрес ### Поля скрейпа и их дефолты | Поле | Что делает | Дефолт | | --- | --- | --- | | scrape_interval | частота опроса цели | 1m | | scrape_timeout | ожидание ответа, меньше интервала | 10s | | metrics_path | путь эндпоинта метрик | /metrics | | scheme | http или https | http | | honor_labels | чьи лейблы приоритетнее: цели или конфига | false | | evaluation_interval | частота пересчёта правил | 1m | ### Проверка: окно rate и интервал **Вопрос:** scrape_interval равен 15 секундам. Какое окно rate заведомо рабочее? - ✅ 1m: в окне около четырёх сэмплов - 10s: одного-двух сэмплов хватит - 15s: окно равно интервалу - Любое: rate не зависит от интервала Rate требует минимум двух сэмплов в окне, а устойчивые значения начинаются с трёх-четырёх точек: при интервале в пятнадцать секунд минута — спокойный минимум. Окно короче двух интервалов чаще пустое, чем заполненное, и графики дырявятся. ### Проверка: где дропнуть чужую метрику **Вопрос:** Метрики debug_* уже приходят с таргета. Какая секция их отбросит? - ✅ metric_relabel_configs: правила работают после скрейпа над сериями - relabel_configs: правила работают до скрейпа - static_configs: через параметр exclude - global: глобальным дроп-листом До скрейпа существуют только метаданные цели — дропать серии нечего. metric_relabel_configs получает уже собранные серии и умеет их фильтровать: drop, keep и переписывание лейблов. static_configs и global таких механизмов не имеют. ### Пустое окно ```go # prometheus.yml scrape_interval: 30s # запрос панели rate(http_requests_total[15s]) ``` **Что выведет программа?** - ✅ График с пустыми точками: в окне реже двух сэмплов - Полный график: rate усреднит недостающие точки - Одна линия на нуле: rate вернёт 0 - Ошибка запроса: окно не кратно интервалу При опросе раз в тридцать секунд в пятнадцатисекундном окне оказывается меньше двух сэмплов, и rate возвращает пустое значение. График дырявый или пустой целиком. Правило — окно не меньше двух интервалов, лучше четырёх. ### Соберите задачу скрейпа Допишите имя задачи, путь и интервал опроса. ```go scrape_configs: - ___: shop ___: /internal/metrics ___: 30s static_configs: - targets: ["10.0.0.11:8080"] ``` Подсказка: Задача называется job_name, путь эндпоинта — metrics_path, частота опроса — scrape_interval; всё это поля задачи в scrape_configs. Правильные ответы в пропусках: `job_name`, `metrics_path`, `scrape_interval` ### Путь от конфига до графика Расставьте шаги настройки скрейпа. Правильный порядок строк: 1. `В prometheus.yml добавляется задача с job_name и списком целей` 2. `Конфиг проверяется promtool-ом до перезагрузки сервера` 3. `Prometheus перечитывает конфиг по SIGHUP или reload-эндпоинту` 4. `Дискавери или static_configs отдают адрес, сервер опрашивает /metrics` 5. `Серии с лейблом job попадают в хранилище каждые scrape interval` 6. `Панель в Grafana строит график по запросу с фильтром по job` ### Карточки: скрейпинг - **scrape_configs и job_name** — Список задач опроса; job_name уникален в конфиге и становится лейблом job на всех сериях цели. - **scrape interval** — Частота опроса: дефолт минута, рабочий выбор 15s. Окно rate — не меньше двух, лучше четырёх интервалов; timeout строго меньше интервала. - **metrics_path** — Путь эндпоинта метрик, дефолт /metrics; задают на задачу, когда сервис отдаёт метрики по служебному пути. - **Сервис-дискавери** — Источник целей, который сервер опрашивает сам: dns_sd_configs, http_sd_configs, file_sd_configs и тяжёлые consul/kubernetes — контракт один: адреса плюс relabel. - **metric_relabel_configs** — Правила над полученными сериями: drop и keep — предохранители хранилища; relabel_configs работает до скрейпа с метаданными цели. > **Проверка на локальном стеке.** YAML и promtool в браузерной песочнице не исполняются — песочница знает только fmt, strings, strconv, math, sort, errors и time. Рабочая связка локальная: docker-compose из середины курса, сервис из [третьего урока](/courses/prometheus/lessons/03-ustanovka-client-golang/), prometheus.yml из этого урока и страница /targets: сначала красный таргет с читаемой ошибкой, потом зелёный up — и путь проверки запомнен телом. Скрейп связывает код из первой половины курса с сервером и дашбордами. Запросы для панелей — из [урока про PromQL](/courses/prometheus/lessons/12-promql-basics/), само построение — из [урока про Grafana](/courses/prometheus/lessons/13-grafana-obzor/), а правила в rule_files подключаются по шаблону [урока про алерты](/courses/prometheus/lessons/14-alerts-obzor/). Если таргет красный из-за дубликатов регистрации — вернитесь к [уроку про реестры](/courses/prometheus/lessons/22-reestry-i-namespaces/); если хранилище пухнет — [урок про кардинальность](/courses/prometheus/lessons/17-kardinalnost/) и дроп-правила из этого урока работают в паре. Дальше — [эксплуатация: что мониторить в первую очередь](/courses/prometheus/lessons/24-ekspluataciya/), а полный маршрут — на [странице Prometheus](/courses/prometheus/). ## Коротко: что запомнить - Конфиг Prometheus: global с интервалами, rule_files для правил, scrape_configs со списком задач. - job_name становится лейблом job на сериях цели и фильтрует дашборды — выбирается как namespace метрик. - scrape interval — компромисс свежести и объёма: дефолт 1m, рабочий выбор 15s, окно rate — от двух интервалов. - scrape_timeout строго меньше scrape_interval, иначе ответы опаздывают к следующему опросу. - Сервис-дискавери (dns, http, файлы) отдаёт адреса вместо ручного списка — relabel-правила общие для всех источников. - relabel_configs работает до скрейпа с метаданными, metric_relabel_configs — после, с дропом серий. - Проверка цели: promtool, страница /targets, метрика up и scrape_duration_seconds. ## Домашнее задание Поднимите учебный сервис и Prometheus из докер-композа, напишите prometheus.yml с глобальными интервалами и двумя задачами: сервис через static_configs и вторую с отдельным scrape_interval и нестандартным metrics_path. Проверьте конфиг promtool-ом, перезагрузите сервер и добейтесь зелёного up на странице /targets. Добавьте metric_relabel_configs с дропом тестовой метрики и убедитесь, что она пропала из /api/v1/label/__name__/values. Затем сломайте metrics_path и прочитайте текст ошибки на странице цели. ## Вопросы и ответы по уроку ### Какой scrape interval выбрать сервису? Пятнадцать секунд — разумный старт: графики отзывчивы, хранилище растёт умеренно. Минута подойдёт для тяжёлых эндпоинтов и фоновых задач; пять секунд — только для узкого круга критичных задач, потому что объём сэмплов и нагрузка на endpoint растут пропорционально. Ключевое согласование: окна rate на дашбордах обязаны быть кратны интервалу с запасом в два-четыре раза. ### Можно ли обойтись без сервис-дискавери? Да, до десятка целей static_configs читается глазами и даже приятнее своей явностью. Дискавери нужен, когда цели появляются и исчезают без правки конфига: реплики за балансировщиком, поды при деплое. Промежуточный вариант — file_sd_configs: оркестратор пишет список целей в JSON-файл, Prometheus перечитывает его по расписанию, а yaml остаётся статичным. ### Почему метрика up важнее любого графика? up — единственная метрика, которую Prometheus пишет сам, от себя, о каждом опросе: единица при успехе, ноль при неудаче. Всё остальное приходит с таргета и молчит вместе с ним: когда сервис умер, его собственные метрики исчезают, и только up продолжает говорить. Алерт на up == 0 в течение пары минут — минимальный дежурный сигнал, dead man's switch строится на нём же.