Сбор метрик: pull-архитектура, targets и job definitions
Prometheus строит свою систему мониторинга вокруг модели pull: он опрашивает указанные конечные точки за метриками по заданной периодичности и собирает их в собственной временной базе данных. Эта глава углубляется в архитектуру сбора, роли targets и job definitions, принципы динамического обнаружения сервисов, а также способы интеграции экспортеров и внешних систем. Рассматриваются типовые конфигурации, лучшие практики и практические сценарии внедрения в организацию.
Сбор метрик - это не только техническая настройка. Это часть дисциплины мониторинга: как определить источники, как структурировать конфигурацию, как минимизировать ошибки и задержки, как обеспечить масштабируемость и устойчивость к изменениям инфраструктуры. Понимание pull-архитектуры и связанных с ней механизмов позволяет эффективно управлять ростом числа сервисов и разнообразием окружений, не теряя контролируемости и предсказуемости поведения системы мониторинга.
- Обзор pull-архитектуры Prometheus: принципы, ограничения и место в экосистеме.
- Targets и job definitions: структура scrape_configs, формирование источников метрик, relabeling и фильтрация.
- Service discovery: динамическое обнаружение источников, подходы к устойчивой конфигурации.
- Экспортеры и интеграции: как подключать приложения и инфраструктуру к Prometheus.
- Практические шаги внедрения: планирование, конфигурация, тестирование и эволюция конфигураций.
Архитектура сбора метрик: pull-подход, роль targets и jobs
pull-архитектура Prometheus предполагает активное обращение сервиса к каждому endpoints за метриками. Эндпойнты должны экспонировать данные в формате, поддерживаемом Prometheus, чаще всего через путь /metrics. В обычной конфигурации Prometheus обращается к этим точкам на заданной частоте (scrape_interval) и сохраняет полученные выборки в своей временнóй БД. Важнейшие параметры конфигурации сканирования включают scrape_interval, scrape_timeout и параметры стабильности лейблов.
Преимущество pull-модели очевидно: Prometheus контролирует частоту опроса и сегментацию источников, упрощает аутентификацию и безопасность на границе сбора, а также облегчает ретривал метрик после сбоев. Ключевым ограничением является зависимость от доступности конечной точки: если приложение не отвечает в течение timeout, Prometheus пометит target как «up=0» и повторит попытку позже. В случаях временно-живых задач или ETL-пайплайнов, где источники создаются динамически или имеют короткую продолжительность жизни, допускается использование Pushgateway как исключение: push-архитектура используется для метрик краткоживущих процессов, но не как основная модель сбора.
Диаграммно, процесс выглядит так: источники метрик (targets) expose /metrics → Prometheus (scrapers) периодически запрашивает данные → данные попадают в TSDB Prometheus → к данным можно применить PromQL, алерты, ретроконфигурации и т.д. Источники метрик обозначаются через job definitions в scrape_configs, которые могут ссылаться на множество targets.
В контексте архитектуры лидирующими элементами являются:
- targets: набор точек, которые Prometheus опрашивает. Это могут быть хосты, контейнеры, службы или внешние системы. Каждый target может нести свои лейблы, помогающие сегментацию и фильтрацию данных.
- jobs: логическая группировка scrape_configs, которая задаёт параметры опроса и применяет единый набор relabel_configs к всем целям внутри группы.
- metrics_path и задание пути к метрикам: по умолчанию /metrics, но его можно переопределить в scrape_configs, чтобы адаптироваться под специфические экспортеры или приложения.
- relabeling: механизм динамического переименования и фильтрации лейблов на входе в Prometheus, позволяющий «очистить» данные до сохранения. Relabeling упрощает сценарии миграции, интеграции с внешними системами и контроля доступа к данным.
Важная концепция, которая следует из архитектуры, - разделение между конфигурацией scrape_configs и самим источником данных. Конфигурация оперирует на уровне Prometheus и не обязана быть привязана к конкретным приложениям: она может использовать статические списки, динамическое обнаружение, секцию SD и правила перезаписи лейблов.
Принципы pull-архитектуры и их последствия
- Контроль над частотой сбора. scrapes_interval задаёт период опроса, и для разных групп можно использовать разные интервалы. Это позволяет оптимизировать нагрузку на сеть и потребление ресурсов TSDB.
- Локальная консистентность лейблов. Prometheus хранит лейблы как часть идентификаторов временных рядов. Неправильная конфигурация relabel_configs может приводить к избыточности данных или неполной картины мониторинга.
- Обновление источников без перезагрузки. Динамические источники (Kubernetes, Consul, файл-based discovery) позволяют добавлять и удалять targets без остановки Prometheus. Это критично в средах с микро-службами и частыми изменениями инфраструктуры.
- Обработка ошибок сети и тайм-аутов. Если конкретный target не отвечает, Prometheus пометит его как down и попытается снова. Со временем можно настроить более устойчивую конфигурацию ретраев и retry-логики через scrape_timeout и другие параметры.
- Взаимосвязь с Pushgateway. Для кратковременных задач или рабочих процессов, которые не могут «публиковать» метрики в pull-модель, существует Pushgateway. Но его следует использовать только для специальных сценариев, а не как основной источник метрик.
Релевантные практики
- Выносите конфигурацию источников и групп в код как часть параметризируемого развёртывания, используя инфраструктурный как код подход (IaC). Это позволяет синхронизировать конфигурацию мониторинга с темпами разработки и развёртывания.
- Разделяйте окружения (dev/stage/prod) по job-ам и по SD конфигурациям. Это упрощает поиск и устранение проблем, а также снижает риск перекрестного влияния между средами.
- Сегментируйте данные в Prometheus через лейблы. Корректные лейблы позволяют гибко фильтровать, агрегировать и строить понятные дашборды.
Targets и job definitions: как формализовать источники метрик
Job definitions определяют, какие источники метрик и с какими параметрами следует опрашивать Prometheus. Основной конструкцией выступает scrape_configs внутри конфигурационного файла Prometheus. В рамках scrape_configs можно описать множество параметров: job_name, static_configs или SD-конфигурации (file_sd_configs, kubernetes_sd_configs и т. д.), scrape_interval, metrics_path, relabel_configs и т. д.
Targets - это конкретные конечные точки, указанные в static_configs или получаемые через SD. Каждый target может иметь набор лейблов, которые Prometheus распространяет в виде метрик и служебной информации для дальнейшей агрегации.
Структура scrape_configs
- job_name: уникальное имя группы источников; служит ключом для группирования сквозной конфигурации.
- scrape_interval: частота опроса для этой группы. Может переопределяться на глобальном уровне.
- scrape_timeout: максимальное время ожидания ответа от target.
- metrics_path: путь, по которому приложение экспонирует метрики (по умолчанию /metrics).
- static_configs: список targets, заданных явно, и связанных лейблов.
- и другие конфигурации SD: kubernetes_sd_configs, file_sd_configs, consul_sd_configs и т. д.
- relabel_configs: набор правил перераспределения лейблов и фильтрации target-ов перед сохранением.
Пример минимальной конфигурации scrape_configs
scrape_configs:
- **job_name**: 'node'
static_configs:
- **targets**: ['node01.example.com:9100', 'node02.example.com:9100']
labels:
environment: prod
В этом примере два узла с Node Exporter на порту 9100 будут опрашиваться с интервалом, заданным глобальным scrape_interval. Лейбл environment: prod добавляется к каждому target и далее используется в графиках и алертах.
Детализация relabeling и фильтрации
relabel_configs - ключевой механизм фильтрации и трансформации лейблов на входе. Он позволяет:
- исключать certain targets из сбора (например, по адресу или по лейблу environment),
- переименовывать лейблы, чтобы унифицировать их во всех источниках,
- переопределять значения лейблов на основе исходных данных,
- удалять лишние лейблы перед попаданием в Prometheus, чтобы уменьшить размер данных и повысить читаемость метрик.
Важно помнить, что relabeling выполняется на уровне Prometheus, поэтому неверные правила могут привести к потере метрик или к дублированию данных. Рекомендуется начинать с простых правил и постепенно усложнять конфигурацию после валидирования на тестовом окружении.
Варианты Service Discovery и динамических источников
- static_configs - наименее сложный вариант, когда targets перечислены явно. Хорош для простых окружений и тестовых стендов.
- file_sd_configs - позволяет держать список targets в внешнем файле (JSON или YAML). Удобно для CI/CD и миграций, когда источники часто меняются.
- kubernetes_sd_configs - динамическое обнаружение по Kubernetes: роли node, pod, service, endpoint и т. д. Позволяет автоматически пополнять targets при изменении состояния кластера.
- consul_sd_configs и другие интеграции - позволяют получать targets из систем сервис-дискавери в рамках существующей инфраструктуры.
- dns_sd_configs - обнаружение через DNS SRV/A-записи, полезно в хорошо структурированных сетях и кластерах.
Преимущества подходов SD очевидны: устранение ручного ввода, адаптивность к изменению инфраструктуры и снижение операционных рисков. Однако SD требует внимательного контроля над политикой лейблов и над тем, какие источники попадают под сбор, чтобы не создавать лишнюю нагрузку или не собирать устаревшие данные.
Экспортеры и интеграции: как подключать приложения и инфраструктуру
Сбор метрик в Prometheus начинается с интеграции источников. В большинстве случаев это достигается за счет instrumentation внутри приложений на стороне клиента Prometheus или через готовые экспортеры, которые конвертируют внешние сигналы в формат, понятный Prometheus.
- Node Exporter - классический экспортер для системного уровня: CPU, память, диск, сеть, файловая система и т. д. Обычно разворачивается на каждом узле и экспортирует данные в порт 9100.
- Blackbox Exporter - экспортер для внешних проверок доступности и времени отклика внешних сервисов. Сценарии проверок определяются в конфигурации Prometheus и позволяют увидеть, доступна ли зависимость в нужный момент времени.
- Приложения и базы данных. В большинстве современных языков имеются клиентские библиотеки Prometheus, которые позволяют самостоятельно экспонировать метрики через /metrics. Для баз данных существуют готовые экспортеры (PostgreSQL, MySQL, MongoDB и т. д.), которые преобразуют внутренние показатели в набор метрик Prometheus.
Российские и открытые решения в рамках данной темы чаще всего представлены как внедрение Prometheus совместно с локальными окружениями и сторонними системами CaaS/облачными провайдерами. В качестве примера можно рассмотреть использование VictoriaMetrics в роли внешнего TSDB или функции remote_write для расширения возможностей хранения и масштабирования. Однако основной фреймворк остается Prometheus, а экспортёры и дополнительные сервисы выступают как адаптеры и мосты к инфраструктуре.
При выборе экспортеров следует учитывать: характер метрик, частоту обновления, стоимость интеграции и влияние на нагрузку. Например, Node Exporter подходит для детального обзора системного состояния и часто используется как стандартный стартовый набор. Blackbox Exporter хорошо решает задачи внешней доступности и сетевой мониторинга без необходимости внедрять изменения в целевых сервисах. Для приложений, где instrumentation возможно по архитектуре, целесообразнее внедрять клиентские библиотеки, так как они дают более структурированное и управляемое наблюдение.
Конфигурация scrape_configs и лучшие практики
Эффективная конфигурация scrape_configs - это основа устойчивого мониторинга. Практические принципы:
- Разделение по окружения и обязанностям. В конфигурации разделяют группы targets по окружениям (prod, stage) и по типам сервисов (infra, app-мониторинг, внешние зависимости). Это упрощает отладку и корректную агрегацию.
- Упор на предсказуемость интервалов. Выбор scrape_interval зависит от частоты изменений в метриках и требований к точности. Для инфраструктуры может быть разумно использовать 15-30 секунд, для бэкэнд-сервисов - 30-60 секунд. Уменьшение интервала повышает нагрузку на сеть и On-PPrometheus-Tsdb, поэтому баланс достигается через продуманную политику.
- Управление тайм-аутами и ретраями. scrape_timeout чаще всего меньше либо равен scrape_interval. При нестабильной сети целесообразно настраивать retries и исключать падения в рамках агрегации, чтобы не искажать показатели.
- relabel_configs как инструмент согласования данных. Переименование лейблов, фильтрация targets по условиям, формирование унифицированных лейблов и добавление контекстной информации (окружение, регион и т. д.). Это облегчает создание унифицированных дашбордов и точечных алерт.
- Безопасность и доступ к метрикам. В случаях, когда метрики доступны через сеть, применяются такие механизмы, как TLS, базовая аутентификация или mTLS, особенно для внешних эндпойнтов и критичной инфраструктуры.
- Версионирование конфигураций. Хранение scrape_configs как часть кода инфраструктуры обеспечивает прозрачность изменений, ускоряет аудит и позволяет безопасно разворачивать обновления в пайплайне CI/CD.
- Эксплуатационные аспекты. Следует планировать мониторинг самого Prometheus: хранение и резервное копирование конфигураций, настройку автоматического обновления конфигураций, мониторинг доступности Targets через встроенную страницу /targets, где можно увидеть текущий статус и ошибки.
Ключ к успешной конфигурации - последовательная настройка и тестирование на тестовом окружении перед развёртыванием в продакшн. В рамках тестирования полезны простые наборы проверок: валидируем конфигурацию на совместимость с существующими экспортеров, проверяем, что targets действительно доступны и метрики соответствуют ожиданиям (например, по именам метрик и типам).
Пример конфигурации и практические сценарии
Ниже приведён минимальный фрагмент scrape_configs и пояснения к нему. Это не полнота, а демонстрация структуры и режимов использования.
scrape_configs:
- **job_name**: 'kubernetes-node'
kubernetes_sd_configs:
- **role**: node
relabel_configs:
- **source_labels**: [__address__]
target_label: instance
- **action**: drop
regex: ^$ # пример фильтрации, если нужен пустой адрес
Этот пример демонстрирует базовую интеграцию с Kubernetes: Prometheus автоматически находит ноды через kubernetes_sd_configs и применяет relabel_configs для формирования единообразного набора лейблов. В реальной конфигурации можно дополнительно подключить node_exporter, указать targets для конкретных узлов, и определить более сложные правила relabel_configs, чтобы исключить временно неактивные сервисы или привести к единому набору лейблов.
Для внешних сервисов или тестово-развёртываемых компонентов можно использовать file_sd_configs, который хранит список targets в внешних файлах. Такой подход позволяет управляющим изменениям конфигурации в CI/CD не мешать рабочим очередям мониторинга и обеспечивает повторяемость.
Практический сценарий внедрения
-
Планирование источников метрик. Совместите источники с требованиями к бизнес-метрикам и операционной повестке: инфраструктура, сервисы, внешние зависимости. Определите, какие лейблы будут ключевыми для фильтрации и агрегации (environment, region, team).
-
Развертывание базовых экспортеров. Установите node_exporter на физических/виртуальных узлах и базовые приложения с instrumentation. Убедитесь, что сбор метрик через /metrics доступен и стабилен.
-
Формирование scrape_configs. Создайте минимальные и расширенные job definitions: базовый сбор метрик узлов, сбор метрик приложения, внешние проверки через Blackbox Exporter и дополнительные источники, которые требуют динамического обнаружения.
-
Верификация и мониторинг сбора. Проверьте страницу /targets на вашем экземпляре Prometheus, убедитесь, что targets состояние "up" и что метрики поступают в Prometheus. Используйте promtool для проверки базовых конфигураций и тестирования правил, если они применяются к метрикам.
-
Введение в рабочие процессы и аудит изменений. Внесение изменений в scrape_configs должно сопровождаться версионированием в вашем IaC и процессами ревью. Обеспечьте документирование: какие источники включены, какие правила relabel_configs применяются, какие окружения покрываются.
-
Эволюция и масштабирование. По мере роста инфраструктуры добавляйте новые SD-конфигурации (Kubernetes, Consul и другие). Применяйте устойчивые паттерны: разделение по окружения, шифрование каналов передачи, мониторинг доступности Targets и Prometheus-экосистемы.
Модель данных, хранение и интерпретация метрик
Prometheus строит временные ряды по метрикам, идентифицируемые именем метрики и набором лейблов. Лейблы дают контекст (окружение, узел, роль, регион) и позволяют сегментировать данные для агрегаций в Grafana или PromQL. Важно придерживаться конвенций именования метрик и постоянных лейблов там, где это оправдано. В противном случае можно получить неупорядоченные дашборды и сложные запросы, а также проблемы с консистентностью данных.
Модель данных Prometheus - это не только структура хранения; это основа для эффективной аналитики и алертинга. Правильная агрегация по лейблам позволяет строить понятные графики и динамические предупреждения. В рамках архитектуры pull-метрики становятся частью единой картины инфраструктуры, и каждая метрика получает возможность стать частью бизнес-аналитики при корректной агрегации и визуализации.
Практики устойчивости и безопасность
- Защита доступа к метрикам. Метрики часто содержат системные и конфигурационные детали. При необходимости ограничьте доступ к /metrics с помощью TLS и аутентификации. В случаях bot-бот-овых интеграций используйте ограничение по IP или VPN.
- Защита от перегрузки. Контролируйте нагрузку: не опрашивайте слишком часто критические источники; применяйте разумные интервалы и тайм-аути; мониторьте нагрузку на Prometheus и TSDB.
- Роли и ответственность. Распределите ответственность за источники метрик между командами: кто поддерживает instrumentation, кто конфигурирует SD, кто отвечает за обновления и безопасность.
- Документация и аудит. Ведите документацию по конфигурациям scrape_configs и SD-конфигураций; храните конфигурацию как код и обеспечьте аудит изменений.
Key takeaways
- Pull-архитектура Prometheus позволяет централизованно управлять опросом метрик и упрощает контроль над частотой сбора и доступом к данным.
- Targets и jobs формируют основу конфигурации мониторинга: job определяет параметры опроса, targets - конкретные источники.
- Service discovery обеспечивает динамическое поддержание списка источников, снижая операционные затраты и риск ошибок.
- Relabel_configs позволяют унифицировать данные, фильтровать ненужные источники и адаптировать данные под единые политики.
- Экспортеры и instrumentation - ключ к сбору качественных данных. Выбор подхода зависит от типа приложения и инфраструктуры.
- Практическая зрелость требует IaC-подхода к scrape_configs, тестирования изменений и контроля версий.
FAQ
- Что такое pull-архитектура и почему она используется в Prometheus?
- Pull-архитектура означает, что Prometheus сам запрашивает метрики у конечных точек по заданной частоте. Это обеспечивает централизованный контроль над частотой сбора, позволяет эффективно управлять доступом к данным и упрощает масштабирование за счёт единообразной модели конфигурации. Проблемы, связанные с доступностью целевых точек, можно выявлять и отслеживать через статус targets на странице /targets.
- Что означает понятие targets и как оно связано с job definitions?
- Targets - это конкретные endpoints, которые Prometheus опрашивает за метриками. Job definitions (scrape_configs) объединяют группы targets под единым именем и параметрами опроса, такими как интервал сбора, путь к метрикам и правила relabeling. Таким образом, targets - это исполнители, а job definitions - правила, которые описывают, как эти исполнители собирают данные.
- Как работает динамическое обнаружение сервисов (service discovery)?
- Service discovery автоматически обновляет список targets на основе интеграций с инфраструктурой: Kubernetes, Consul, файлы SD и другие. Это снимает необходимость вручную обновлять конфигурацию. Важно корректно определить лейблы и правила relabeling, чтобы собирать данные, не перегружая Prometheus устаревшими или дубликатными точками.
- Какие особенности у relabel_configs и зачем они нужны?
- relabel_configs - это набор правил для манипуляции лейблами на входе в Prometheus. Они позволяют унифицировать структуру лейблов, фильтровать targets, переименовывать источники, добавлять контекстные лейблы (окружение, регион) и удалять ненужные. Это критично для согласованности данных и упрощения запросов PromQL и визуализации.
- Как выбрать частоту опроса scrape_interval?
- Выбор scrape_interval зависит от частоты изменений в ваших метриках и требуемой точности. Для инфраструктурных метрик интервалы часто короче (например, 15-30 секунд), для бизнес-логики сервисов можно использовать более длинные интервалы (30-60 секунд). Важно соблюдать баланс между точностью и нагрузкой на сеть и TSDB. В продуманных системах применяется разные интервалы для разных видов источников и окружений.
- Что делать с ephemeral-или batch-сервисами?
- Для кратковременных процессов, которые не подходят под pull-архитектуру, применяют Pushgateway как исключение, позволяя отправлять метрики от таких задач в Prometheus. Однако Pushgateway не предназначен для постоянного мониторинга и должен использоваться умеренно, с ясной политикой в отношении жизненного цикла задач и нагрузок.
- Какие примеры экспортеров чаще всего необходимы?
- Node Exporter для системного состояния узлов; Blackbox Exporter для проверки доступности внешних сервисов; специализированные экспортеры для баз данных и приложений (PostgreSQL, MySQL и пр.). Выбор экспортеров должен основываться на реальных требованиях к мониторингу и характере инструментируемых систем.
- Как проверить корректность конфигурации scrape_configs?
- Начните с проверки статуса targets на странице Prometheus (/targets). Убедитесь, что targets отмечены как up и что данные приходят в Prometheus. Для тестирования конфигураций можно использовать инструменты в рамках инфраструктуры, включая валидацию YAML и локальные тестовые стенды. При необходимости применяйте promtool для тестирования сопутствующих правил, например alerting rules, если они завязаны на собираемые метрики.
- Как обеспечить безопасность доступа к метрикам?
- Рекомендуется ограничить доступ к метрикам с помощью TLS и, при необходимости, аутентификации. Внесите конфигурацию в CI/CD и примените практики минимального необходимого доступа. Для сегментации и мультиарендности используйте лейблы и роли, чтобы ограничить видимость конкретных метрик и источников.
