Основы сбора метрик: метрики, targets, экспортёры и Service Discovery
Мониторинг на базе Prometheus строится вокруг сбора и агрегации метрик из множества источников. В этой главе рассматриваются базовые понятия: что именно считается метрикой, какие типы метрик существуют, как Prometheus находит источники (targets) и как динамически конфигурировать сбор через Service Discovery, какие роли выполняют экспортёры и как выстроить эффективную конфигурацию сбора на большом горизонте обслуживания. Рассматривается архитектура на уровне технологий и процессов, чтобы обеспечить надёжность, расширяемость и предсказуемость эксплуатации мониторинга больших платформ.
В контексте production-архитектуры Prometheus основным ограничителем является не столько простой сбор метрик, сколько эффективное управление динамикой источников метрик, размером и качеством метрик, а также грамотная интеграция со стратегиями хранения и федерации. Глава фокусируется на основных концепциях и практиках, которые применимы как в небольших кластерах, так и в больших многокластерных средах с использованием federation и удалённого хранения (Thanos, Cortex, Mimir).
- Основные концепты: что такое метрика, каковы типы данных и как они экспонируются.
- Targets и Service Discovery: какие механизмы обеспечивают поиск источников и как их конфигурировать.
- Экспортёры: зачем нужны внешние процессы и как выбрать подходящие в контексте инфраструктуры.
- Конфигурация сбора: scrape_configs, relabeling и безопасность сбора.
- Архитектурные практики для масштабирования: как поддерживать работоспособность мониторинга при росте числа источников и требований к хранению.
Метрики: принципы и форматы
Метрика в Prometheus - это числовой временной ряд с набором размерностей (labels). Каждое значение имеет имя метрики и набор пар ключ-значение в виде лейблов, которые позволяют различать контекст. В отличие от традиционной системной метрики, Prometheus по умолчанию ориентирован на прерывный сбор по HTTP-сервису и работу с временными рядами в памяти и на длительный горизонт хранения.
Ключевые аспекты:
- Типы метрик: counter, gauge, histogram и summary. Counter накапливает значения, gauge хранит текущее состояние, histogram и summary дают распределения значений, что критично для анализа латентности и частоты ошибок.
- Формат экспонирования: Prometheus читает данные в открытом текстовом формате (OpenMetrics). Этот формат обеспечивает единообразие представления, совместимость с инструментами и упрощает парсинг.
- Имена и лейблы: имена метрик должны быть описательными и следовать соглашениям (snake_case, использование префиксов, минимизация дубликатов). Лейблы добавляют контекст (клиент, регион, среда и т. д.), но чрезмерное усложнение карточности может привести к перегрузке базы данных и аномалиям в запросах.
- Кардинальность: высокая кардинальность (много уникальных значений лейблов) может привести к проблемам с производительностью и памяти. Разумная стратегия - держать лейблы, которые необходимы для агрегации и разбивки, и избегать использования нейтральных идентификаторов (например, user_id) в качестве лейблов, если они не востребованы для аналитики на уровне сохранения.
- Примеры экспозиции: на стороне приложения или экспортёра метрика может выглядеть так:
## HELP http_requests_total The total number of HTTP requests ## TYPE http_requests_total counter http_requests_total{method="post",code="200"} 1027Это иллюстрирует базовую модель: имя метрики, набор лейблов и значение в конкретном моменте времени.
Почему это важно:
- Правильное моделирование метрик и выбор типов данных позволяют быстро отвечать на бизнес-вопросы: латентность, пропускная способность, устойчивость сервисов.
- Следование единым конвенциям именования упрощает совместную работу команд и ускоряет внедрение новых источников метрик.
- Контроль кардинальности позволяет держать эксплуатацию под контролем и избегать перегрузок хранилища и запросов.
Targets и Service Discovery
Targets - это конкретные конечные точки, которые Prometheus опрашивает для сбора метрик. Service Discovery (SD) - это набор механизмов, которые позволяют динамически находить новые источники метрик и удалять устаревшие. В современном production-окружении источники метрик часто меняются: контейнеры перезапускаются, новые сервисы добавляются, инфраструктура меняет свои параметры. SD обеспечивает плавность этих изменений без ручного вмешательства.
Основные механизмы SD:
- Static_configs: перечисление адресов вручную или через скриптовые наборы. Подходит для тестовых сред и небольших deployments.
- File-based SD (file_sd_configs): список таргетов записывается в файлы и обновляется внешними процессами. Хорошо сочетается с orchestration-Systems, где внешний планировщик может эти файлы обновлять.
- Kubernetes SD: динамическое обнаружение через Kubernetes API. Поддерживает роли, namespace, метки и аннотации, что позволяет гибко фильтровать таргеты.
- DNS-based SD и cloud SD (EC2, GCE и т. п.): соответствующие интеграции позволяют находить таргеты по DNS или по облачным метаданным.
- Relabeling: трансформация лейблов и таргетов на уровне SD и scrape_configs. Позволяет отделить источники от критических контекстов и привести таргеты к единообразному формату.
Решение по SD в Prometheus строится на сочетании конфигураций и правил переработки метаданных. Основные принципы:
- Разделение контекста источника и целевых метрик: лейблы, такие как instance, job и target, переназначаются и фильтруются в процессе relabeling.
- Использование relabel_configs и metric_relabel_configs для фильтрации нежелательных таргетов и удаления или переработки метрик на входе сбора.
- Проверка корректности конфигурации: для предотвращения перегрузки и ошибок конфигурации полезно тестировать scrape_configs с инструментом promtool и поддерживать версии конфигураций в репозитории.
Пример: базовый static и file-based SD
scrape_configs:
- **job_name**: 'example-static'
static_configs:
- **targets**: ['service-1:9100', 'service-2:9100']
- **job_name**: 'example-file'
file_sd_configs:
- files: ['targets/*.yml']
В этом контексте поверхность SD становится не простой маршрутизирующей инфраструктурой, а центральной точкой адаптации к изменчивым условиям. В больших системах целесообразно разделять задачи SD по кластерам, окружениям и уровням доступа, чтобы минимизировать влияние изменений на общую карту таргетов и архитектуру мониторинга.
Важные практики:
- Минимизируйте количество таргетов, где это возможно, но не снижайте информативность. Производительность опроса прямо зависит от числа таргетов.
- Используйте file_sd_configs для внешних планировщиков и CI/CD, которые обновляют таргеты при развёртывании новых сервисов.
- Применяйте relabel_configs для нормализации формата адресов и hostname, чтобы единообразно отображать источники в интерфейсе Prometheus и Grafana.
- Обеспечьте устойчивость SD к отказам: репликация таргетов в разных зонах и корректная обработка ошибок сетевых путей.
Экспортёры: архитектура, роли и примеры
Экспортёры - это отдельные процессы, которые собирают метрики в формате, понятном Prometheus, и публикуют их по HTTP на заранее определённом адресе. В производственной среде они играют две ключевые роли:
- Инструментирование инфраструктуры и приложений без прямой модификации кода: экспортёры внешне работают поверх сервисов и настраиваются на сбор метрик.
- Отдельный слой агрегации и нормализации: экспортёры позволяют централизовать логику сборки и управления метриками, изолируя её от бизнес-логики приложений.
Типичные примеры экспортёров:
- node_exporter: сбор системной информации на уровне операционной системы (CPU, память, диск, сеть). Часто является базовым слоем мониторинга для физических серверов и виртуальных машин.
- cadvisor: специализированный экспортёр для метрик контейнерной среды, особенно полезен в сочетании с Kubernetes и Docker.
- blackbox_exporter: проверка доступности внешних сервисов, URL-эндпоинтов, сетевых путей, задержек и ошибок, без необходимости модификации целевых сервисов.
- exporter-specific: экспортёры для баз данных (mysql_exporter, postgres_exporter), очередей сообщений и других компонентов инфраструктуры (например, kafka_exporter и т. д.).
Интеграция экспортёров в архитектуру мониторинга следует рассматривать как часть инфраструктурной платформы:
- Приложения и сервисы иногда сами предоставляют встроенные метрики, которые можно экспортировать напрямую или через агентский экспортёр.
- При внешнем экспорте важно учесть влияние на безопасность и производительность. Экспортёры должны работать в изоляции от бизнес-логики и иметь ограничение по ресурсам (CPU, память).
- В больших средах рекомендуется централизованная политика по обновлениям экспортёров и совместимости версий между экспортёрами и версиями Prometheus.
Безопасность и доступ: при внедрении экспортёров важна изоляция сетей и аутентификация. Прямой доступ к экспонируемым метрикам следует ограничивать, используя TLS, аутентификацию и, по возможности, сетевые политики, чтобы предотвратить несанкционированный сбор.
Инструменты для мониторинга экспортёров и их здоровья:
- Метрики самого экспортёра: большинство экспортёров публикуют внутренние показатели о состоянии функционирования.
- Метрики Prometheus: включение health-флагов и конфигураций, которые позволяют валидировать, что экспортёр активен и возвращает корректные данные.
- Итоговая конфигурация scraping: следует устанавливать разумные интервалы опроса, чтобы экспортёры не становились узким местом.
Принципы проектирования экспортеров:
- Приватность и безопасность: экспортёры не должны проводить небезопасный доступ к критическим данным.
- Расширяемость: по мере роста инфраструктуры добавляются новые экспортёры без изменения существующей архитектуры.
- Совместимость: необходимо следить за версиями OpenMetrics и совместимостью форматов экспонируемых данных.
Конфигурация сбора, relabeling и безопасность
Гибкость конфигурации сбора обеспечивает как корректность данных, так и управляемость в крупных окружениях. Основной механизм - scrape_configs в Prometheus. Он описывает, какие таргеты будут опрашиваться, какие интервалы сбора применяются, какие пути метрик и какие схемы используются.
Ключевые элементы:
- scrape_interval и scrape_timeout: интервал опроса и тайм-аут. В production рекомендуется разделять частые операции сбора и более консервативные параметры по умолчанию, учитывая требования к задержке и нагрузке на сеть.
- metrics_path и scheme: путь к метрикам и протокол. В большинстве случаев путь /metrics, схема - http или https, в зависимости от инфраструктуры и требований безопасности.
- Bearer token, Basic auth и TLS-конфигурация: необходимы для безопасного доступа к защищённым таргетам. В Kubernetes и облачных средах часто применяется TLS с mutual TLS и сервисные аккаунты, чтобы ограничить доступ.
- Relabeling (relabel_configs) и metric relabel_configs: правила преобразования, фильтрации и нормализации метаданных на входе и на выходе из scrape-процесса. Они позволяют отфильтровывать таргеты, нормализовать имена и адреса, скрывать чувствительную информацию и упрощать агрегацию на уровне дашбордов.
- drop и keep: механизмы в relabel_configs для исключения определённых таргетов или включения только нужных.
Пример типичной конфигурации relabeling, иллюстрирующий преобразование адреса и фильтрацию источников:
scrape_configs:
- **job_name**: 'example-app'
static_configs:
- **targets**: ['app-1:9100','app-2:9100','app-3:9100']
relabel_configs:
- **source_labels**: [__address__]
target_label: instance
replacement: '$1'
- **source_labels**: [__meta_kubernetes_pod_name]
action: keep
regex: .*
Это позволяет установить единый идентификатор экземпляра и фильтровать таргеты на основе метаданных окружения. Более сложные сценарии включают metric_relabel_configs, которые применяются к самим метрикам после их получения, чтобы, например, удалить чувствительные лейблы или снизить кардинальность, прежде чем данные попадут в хранилище.
Безопасность конфигурации сборов требует:
- Шифрование канала между Prometheus и таргетами (TLS) и проверка подлинности целевых сервисов.
- Гранулированный доступ к конфигурационным файлам мониторинга: управление версиями и аудит изменений.
- Минимизация экспонирования внутри приватных сетей и ограничение доступа к панели Prometheus и API.
Архитектурные паттерны для масштабирования и эксплуатация больших платформ
На фоне роста числа источников метрик и требований к долгосрочному хранению возникает набор архитектурных подходов, которые позволяют сохранить управляемость и производительность мониторинга.
Ключевые паттерны:
- Многоуровневая сборка: выделение отдельных командным подходом слоёв экспонирования метрик - базовый слой системной и контейнерной метрики (node_exporter, cadvisor) и надслой бизнес-метрик, Instrumentation Client в сервисах. Это снижает сложность и облегчает отладку.
- Многоинстансная схема Prometheus: параллельная развёртка нескольких инстансов Prometheus с локальной зонной агрегацией и последующей федерацией для центрального анализа. Это уменьшает нагрузку на единичный узел и упрощает горизонтальное масштабирование.
- Федерация и удалённое хранение: для долгосрочного хранения метрик и глобального анализа применяются архитектуры федерации и внешние слои хранения (Thanos, Cortex, Mimir). Федерация позволяет агрегировать сводные данные из нескольких кластеров, снижаю нагрузку на центральный источник и улучшая доступность. Удалённое хранение обеспечивает долговременный анализ и экономию локальных ресурсов Prometheus.
- Безопасность и управление изменениями: в больших системах критически важно иметь единый процесс выпуска конфигураций мониторинга, тестирование конфигураций (promtool) и налаженный пайплайн обновления, чтобы исключить регрессии и просто дать возможность оперативно разворачивать изменения без простоев.
- Мониторинг экспортеров и инфраструктуры: качество мониторинга зависит не только от сборов, но и от здоровья экспортёров и их способность держать данные в соответствии с требованиями. В больших средах полезны политики управления устойчивостью экспортёров, включающие мониторинг их состояния и регулярное обновление до совместимых версий.
Преимущества и компромиссы:
- Федерация и remote storage улучшают долговременную аналитическую пригодность, но требуют дополнительных компонентов и сложности в архитектуре. Они полезны для больших платформ, где потребление локальных ресурсов и единая аналитика по всем кластерам критичны.
- Локальные Prometheus-инстансы дают скорость отклика и простоту, но ограничивают горизонт масштабирования. Баланс достигается через многоинстансную архитектуру с централизованной координацией.
- Экспортёры должны быть правильно управляемы, чтобы не становиться узким местом в мониторинге. В крупных системах их обновление, настройка безопасности и согласование версий - часть политик эксплуатации.
Key takeaways
- Метрика в Prometheus - это временной ряд с именем, типом и лейблами, размещаемый в формате OpenMetrics; правильное моделирование метрик критично для аналитики и производительности.
- Service Discovery и targets позволяют динамически находить источники метрик; выбор механизмов SD зависит от инфраструктуры (Static, File-based, Kubernetes SD и т. д.).
- Экспортёры - это ключевой инструмент интеграции: они позволяют централизовать сбор метрик и снизить влияние на код приложений, но требуют внимания к производительности и безопасности.
- Конфигурация сбора через scrape_configs и relabel_configs обеспечивает гибкость, безопасность и возможность управления кардинальностью метрик.
- В крупных системах полезно рассмотреть федерацию и удалённое хранение, чтобы обеспечить масштабируемость, долговременное хранение и единый аналитический интерфейс среди нескольких кластеров.
- Принципы безопасности: TLS, аутентификация, ограждённая сеть и ограничение доступа важны как для источников метрик, так и для самого Prometheus.
- Постоянное тестирование конфигураций и наличие процессов обновления конфигураций мониторинга - залог устойчивой эксплуатации больших платформ.
FAQ
- Что такое OpenMetrics и зачем он нужен в Prometheus?
OpenMetrics - это открытый стандарт формата экспонирования метрик. Он обеспечивает единообразное описание метрик, типов и значений. В Prometheus это позволяет сервисам и экспортёрам публиковать метрики в совместимом формате, что упрощает интеграцию, автоматическую валидацию и совместимость между различными версиями инструментов.
- Как Prometheus узнаёт, какие таргеты ему нужно опрашивать?
Prometheus использует Service Discovery (SD) и static/file-based конфигурации. SD-подходы автоматизируют поиск источников на основе инфраструктуры (Kubernetes, DNS, EC2 и т. д.), а static/file-based конфигурации применяются, когда источники известны заранее или меняются нечасто. Relabel_configs позволяют нормализовать и фильтровать таргеты на входе в сбор.
- Чем отличаются scrape_configs и relabel_configs?
Scrape_configs описывает параметры сбора: таргеты, путь метрик, таймауты и порядок сбора. Relabel_configs применяются к таргетам и их лейблам, чтобы изменить их, исключить или переназначить, что влияет на то, какие данные будут собраны и как они будут храниться.
- Какие типы метрик поддерживаются и как их правильно использовать?
Prometheus поддерживает counter, gauge, histogram и summary. Counter применяется для счётчиков событий, gauge - текущие значения, histogram и summary - распределения значений (позволяют анализировать латентность и частоту). Выбор типа зависит от аналитических задач: события и их рост - counter; текущие состояния - gauge; распределение латентности - histogram/summary.
- Какие экспортёры стоит рассматривать в инфраструктуре?
Классические и полезные экспортёры: node_exporter для системной информации на серверах, cadvisor для контейнерной среды, blackbox_exporter для внешних проверок доступности и Latency; для баз данных существуют специализированные экспортёры (например, postgres_exporter). Важно помнить про совместимость версий и влияние экспортёров на производительность.
- Как обеспечить безопасность доступа к метрикам?
Используйте TLS/HTTPS и аутентификацию к таргетам, ограничивайте сетевые доступы между компонентами, применяйте политики сети и ролевой доступ к конфигурациям мониторинга. В Kubernetes часто применяют сервисные учётные данные и mTLS между компонентами мониторинга.
- Как масштабировать мониторинг в больших кластерах?
Подходы включают развёртывание нескольких инстансов Prometheus (горизонтальное масштабирование на уровне источников), федерацию для агрегирования данных из разных кластеров, и использование удалённого хранения (Thanos, Cortex, Mimir) для долгосрочного хранения и глобального анализа. Важно поддерживать чистую архитектуру правдоподобной агрегации и контролируемую кардинальность метрик.
- Что такое federation и чем она отличается от remote storage?
Federation позволяет агрегировать подмножество данных из нескольких Prometheus в центральный инстанс, сохраняя локальные данные и облегчая кросс-кластерный анализ. Remote storage (Thanos, Cortex, Mimir) - обеспечивает долговременное хранение и единый глобальный набор метрик, где данные могут быть распределены и доступны независимо от локальных инстансов Prometheus. В сочетании они дают баланс между быстротой локального доступа и долговременной аналитикой.
- Как тестировать конфигурацию мониторинга?
Используйте инструмент promtool для валидации конфигураций, написания тестов и проверки правил. Регулярное тестирование помогает предотвратить регрессии и проверить, что новые таргеты правильно конфигурированы и новые экспортёры корректно публикуют метрики.
- Какие практики важны для эксплуатации больших мониторов?
Обеспечьте документирование конфигураций, используйте версии и ревизии конфигураций, применяйте CI/CD для обновления мониторинга, поддерживайте мониторинг самого мониторинга (health checks, синхронизация времени), внедряйте политики по ограничению кардинальности и применяйте удалённое хранение для долгосрочного анализа.
