Подключение Prometheus: настройка, соглашения имен, аутентификация

Prometheus выступает как сердце мониторинга в стекe observability вместе с Grafana. В продакшн-средах вопросы корректной настройки источника данных, единых соглашений об именовании метрик и надёжной аутентификации становятся критическими: они определяют качество визуализации, скорость диагностики и устойчивость кибербезопасности. Глава охватывает архитектурные принципы взаимодействия Grafana и Prometheus, рекомендуемые конвенции имен метрик и лейблов, подходы к аутентификации на уровне Prometheus и Grafana, а также практические шаги по реализации в реальных условиях.

Краткое содержание главы

Архитектура взаимодействия Grafana и Prometheus: чем руководствоваться при выборе схемы размещения и защиты.
Соглашения имен и структурирование метрик Prometheus: принципы дизайна, лейблы и контроль за кардинальностью.
Аутентификация и безопасность: варианты защиты Prometheus за пределами Grafana и конфигурации на стороне Grafana.
Реализация на практике: настройка data source Grafana, базовые примеры конфигураций и диагностика.
Валидация и мониторинг конфигураций: как проверить корректность соединения, убедиться в применении политик безопасности и устойчиво масштабировать.

Архитектура взаимодействия Grafana и Prometheus: протоколы, точки взаимодействия и схемы защиты

Grafana обращается к Prometheus через HTTP API, используя PromQL для получения временных рядов. Основной поток данных строится следующим образом: пользователь в Grafana формирует запрос, Grafana распаковывает параметры и отправляет запрос к Prometheus к соответствующему API-эндпоинту, после чего Prometheus возвращает серию точек времени в формате JSON. В этом контексте PromQL - язык запросов, позволяющий построить агрегации и выборки по временным рядам с учётом метрик и лейблов. Важным является то, что архитектура допускает несколько источников Prometheus: один или несколько инстансов в кластере Kubernetes, standalone серверы или федерации.

Протоколы взаимодействия и их особенности:

HTTP(S): все обращения к Prometheus происходят по REST-подобному интерфейсу; API-подразделение включает /api/v1/query, /api/v1/query_range и другие вызовы.
TLS и шифрование: для обеспечения целостности и конфиденциальности данные между Grafana и Prometheus должны передаваться по TLS, особенно в небезопасных сетях.
Аутентификация и авторизация: Prometheus сам по себе не является полноценной системой аутентификации в чистом виде; в продакшне его обычно размещают за прокси-аутентификацией (NGINX, Traefik ForwardAuth, oauth2-proxy) или же используют базовую аутентификацию на уровне прокси, а Grafana - через механизм авторизации внутри самой Grafana или через прокси.

Схемы размещения и их влияние на безопасность:

Прямой доступ без прокси: простота настройки, но слабое разделение ролей и ограниченная защита API. Подходит для локальных стендов и разработки.
За прокси с базовой аутентификацией: Prometheus закрыт за прокси-сервером; Grafana настраивает данные через базовую аутентификацию или через JWT/OAuth, что обеспечивает более предсказуемый контроль доступа.
За прокси с поддержкой OAuth2 или mTLS: наивысшая степень безопасности, но требует сложной настройки и внедрения секретов. Может быть реализовано через nginx+auth_request, oauth2-proxy, Dex или Traefik.

На уровне Grafana рекомендуется активировать безопасные каналы связи и корректно настроить параметры источника Prometheus:

URL Prometheus: указывайте полный URL конечной точки, доступной через TLS.
Аутентификацию на уровне источника: если Prometheus защищён прокси, применяйте базовую аутентификацию или bearer-токены через конфигурацию источника Grafana.
Валидация сертификатов: включайте проверку TLS-сертификатов (TLS/SSL verification) и sendo применяйте доверенные CA для противодействия атакам «man-in-the-middle».
Мониторинг доверенных узлов: для узких границ доступа используйте списки разрешённых IP и механизмы ACL на прокси.

Примерная схема может выглядеть так: пользователи Grafana подключаются к Grafana через SSO, Grafana обращается к Prometheus через TLS, Prometheus - за прокси-слоем, который реализует аутентификацию (базовая аутентификация или OAuth2); в случае необходимости remote_write/remote_read данные из Prometheus могут уходить в долгосрочное хранилище, например ClickHouse или VictoriaMetrics, через отдельные конвейеры.

Соглашения имён и структура метрик Prometheus

Ключ к эффективной аналитике - единые и предсказуемые имени метрик и лейблов. Это облегчает поиск, агрегацию и легенды в Grafana, а также упрощает кросс-командную работу над дашбордами.

Названия метрик: базовая формула naming-конвенций строится вокруг предметной области. Рекомендуется использовать префикс, описывающий объект и действие: например, http_requests_total, database_query_duration_seconds, cpu_usage_seconds_total. Включение единиц измерения в суффиксах - полезно, но не должно дублировать контекст; единицы лучше отделять в документации, если они критичны.
Лейблы (label keys): выбор ключей должен отвечать требованиям низкой кардинальности и устойчивости. Основной набор в Kubernetes-окружении - namespace, pod, container, job, instance, service; можно добавлять поле cluster_name для многокластерной архитектуры. Важно избегать динамических лейблов, значения которых растут экспоненциально (например, URL-части пути, user_id без фильтрации).
Кардинальность: ограничение числа уникальных серий на метрику имеет решающее значение для производительности. Избегайте добавления по каждому пользователю, уникальным параметрам запроса или случайной строке; применяйте агрегацию на стороне экспортеров и используйте relabeling в Prometheus для конвейера на этапе scrape_config.
Стандартизация метрик и лейблов: единообразие должно охватывать как экспортёры, так и конфигурацию scrape. Определите централизованную карту метрик и соответствующих им лейблов в проектной документации.
Примеры и шаблоны: рекомендуется иметь готовые шаблоны для часто встречающихся сценариев (HTTP-запросы, обработка очередей, метрики базы данных). Это снижает риск «разброда» в именах и делает дашборды предсказуемыми.

Практический пример конвенций:

Метрика: http_requests_total
Лейблы: job, instance, service, endpoint, status_code
Единицы: счетчик (total) без явной единицы в названии; количество запросов - единицы «count»
Метрика гаузера очереди: queue_size_items, лейблы: queue_name, namespace, service

Преимущества таких правил - понятные легенды, возможность использования единых регулярок в Grafana и простая миграция существующих дашбордов под новые правила.

Аутентификация и безопасность: варианты защиты Prometheus и настройки Grafana

Разнообразие архитектур требует согласованного подхода к аутентификации на уровне всего стека. В продвинутой среде обязательно отделять аутентификацию пользователей Grafana и доступ к самим данным Prometheus.

Аутентификация пользователей Grafana: Grafana поддерживает внешние провайдеры SSO (OAuth, OIDC, SAML) и локальную систему учётных записей. В продуктивной среде это обеспечивает единый вход, аудит и ускоряет управление доступом.
Аутентификация к Prometheus через Grafana: если Grafana напрямую обращается к Prometheus, лучше использовать аутентификацию на уровне прокси-перед Prometheus или прямую передачу учётных данных через конфигурацию data source. В Prometheus нет встроенного полнофункционального механизма авторизации; поэтому чаще применяется прокси с базовой аутентификацией или OAuth2.
Прокси для Prometheus: использование NGINX, Traefik, или oauth2-proxy для защиты API. Вариант с OAuth2-прокси позволяет интегрироваться с корпоративной идентификацией и снижает риск несанкционированного доступа.
TLS и mTLS: для межсервисной защиты целесообразно включать TLS и рассмотреть возможность mutual TLS между Grafana и Prometheus, если инфраструктура поддерживает распределённую идентификацию компонентов. Это повышает защиту от подмены целевых служб.
Управление секретами: не храните пароли в явном виде в конфигурациях. Используйте секрет-менеджеры (Vault, Kubernetes Secrets, AWS Secrets Manager) и привязывайте их через механизмы окружения или конфигурационные плагины Grafana и прокси.
Роли и аудит: валидируйте доступ по ролям (RBAC) и коды действий в Grafana. В Prometheus наблюдайте за попытками доступа через прокси, чтобы предотвращать сканирование API и другие нежелательные активности.

Пример конфигурации: прокси-nginx с базовой аутентификацией для защиты Prometheus

server {
  listen 443 ssl;
  server_name prometheus.example.com;

  location / {
    proxy_pass http://prometheus:9090/;
    proxy_set_header Host $host;
    auth_basic "Prometheus";
    auth_basic_user_file /etc/nginx/.htpasswd;
  }
}

Этот минимальный пример иллюстрирует базовую защиту; в реальном окружении предпочтительно заменить базовую аутентификацию на OAuth2-прокси или Dex с интеграцией в корпоративную IDM-систему.

Пример конфигурации Grafana data source для Prometheus behind прокси

{
  "name": "Prometheus",
  "type": "prometheus",
  "url": "https://prometheus.example.com",
  "access": "proxy",
  "basicAuth": true,
  "basicAuthUser": "grafana",
  "basicAuthPassword": "REDACTED",
  "jsonData": {
    "tlsSkipVerify": false
  }
}

Такой подход позволяет отделить аутентификацию Grafana от самой инфраструктуры Prometheus и использовать централизованные политики доступа.

Реализация на практике: настройка Grafana и Prometheus

Ниже приводится схематика действий и практические шаги по реализации подключения Prometheus к Grafana с учётом соглашений имен и аутентификации.

Шаг 1: определить топологию размещения и выбрать схему защиты. Решение зависит от требований безопасности, регуляторных норм и наличия корпоративного IDM.
Шаг 2: настроить Prometheus для сбора метрик и, при необходимости, включить подключения к защищённым эндпойнтам через http_client_config:
```
scrape_configs:
  - **job_name**: 'kubernetes-nodes'
    static_configs:
      - **targets**: ['node1.example.com:9100', 'node2.example.com:9100']
    http_client_config:
      basic_auth:
        username: 'exporter'
        password: 'secret'
      tls_config:
        ca_file: '/etc/prometheus/certs/ca.pem'
        cert_file: '/etc/prometheus/certs/prometheus.crt'
        key_file: '/etc/prometheus/certs/prometheus.key'
```
Такой блок демонстрирует, как использовать базовую аутентификацию и TLS-клиентские сертификаты для защищённых источников.
Шаг 3: внедрить прокси-защиту Prometheus (если применимо) и настроить TLS. В конфигурацию прокси добавляются правила маршрутизации и политики авторизации.
Шаг 4: добавить Prometheus в Grafana как источник данных:
- URL: https://prometheus.example.com
- Access: proxy
- Аутентификация: базовая (если используется прокси) или Bearer JWT, если прокси поддерживает его.
- TLS: включить проверки сертификатов, указать CA или отключить verify только в тестах (не рекомендуется в проде).
Шаг 5: проверить соединение и начальные запросы. В Grafana откройте Data Source → Explore → PromQL, выполните простой запрос: sum(rate(http_requests_total[5m])) by (service). Убедитесь, что данные приходят и легенда формируется корректно.
Шаг 6: применить Naming Conventions. В панели снабдите легенду и фильтры по лейблам: service, namespace, pod, instance, endpoint и т. п. Убедитесь, что Grafana Legend формируется предсказуемо и одинаково между дашбордами.

Валидация и диагностика

Эндпойнты Prometheus и конфигурации Grafana должны проходить регулярную валидацию. Практические меры включают:

Тестирование API Prometheus: curl -u :
https://prometheus.example.com/api/v1/targets включить базовую аутентификацию и проверить доступность целевых метрик.
Проверка PromQL-запросов в Grafana: используйте Explore для проверки корректности выражений и полноты возвращаемых временных рядов.
Диагностика TLS-сертификатов: периодически обновляйте сертификаты и проверяйте, что цепочка доверия корректна на обеих сторонах.
Мониторинг задержек и ошибок: проследите, чтобы инспектор запросов Grafana показывал ожидаемую задержку; в случае проблем с доступом к Prometheus просмотрите логи прокси и Prometheus.
Управление версионированием: синхронизируйте версии Grafana, Prometheus и прокси-слоев, чтобы исключить несовместимости и специфичные баги.

Key takeaways

Архитектура Grafana-Prometheus требует продуманной защиты и выбора подходящей схемы аутентификации на уровне прокси и данных.
Соглашения имен метрик и лейблов должны быть стандартизированы для снижения кардинальности и упрощения агрегаций в Grafana.
Аутентификация в связке Grafana-Prometheus опирается на три уровня: пользовательская аутентификация Grafana, доступ к Prometheus через прокси (или через Grafana data source), и TLS/аутентификация между компонентами.
Практические примеры конфигураций ( Prometheus scrape_config с http_client_config и Grafana data source JSON) помогают быстро перейти к рабочему режиму.
Регулярная диагностика и мониторинг доступа позволяют поддерживать безопасность и надёжность системы, особенно в кластерах с множеством целевых сервисов и динамически изменяющимися источниками.

FAQ

Как мне подключить Prometheus к Grafana, если Prometheus находится за прокси с OAuth2?

В Grafana используйте data source с URL прокси и настройте authentication через OAuth2-покупку, если прокси поддерживает передачу OIDC JWT-токенов. В противном случае используйте Bearer токен в http_client_config на стороне Prometheus или настройте прокси, чтобы принимать токены и передавать их к Prometheus.

Какие требования к именованию метрик в Kubernetes-кластере?

Рекомендовано использовать понятные и стабильные лейблы: namespace, pod, container, service, instance, job. Избегайте динамических значений, которые приводят к высокой кардинальности; запланируйте RELABEL-конвейеры, чтобы нормализовать данные перед хранением.

Что делать, если Grafana не может получить данные из Prometheus?

Проверьте адрес и TLS-сертификаты, протестируйте доступ curl к Prometheus API, проверьте настройки прокси, а также убедитесь, что Grafana использует верный URL и корректную схему аутентификации. Изучите логи Grafana и Prometheus и используйте инструмент Explore в Grafana для локализации проблемы.

Какие способы защиты Prometheus за пределами Grafana являются предпочтительными?

Наилучшая практика - разместить Prometheus за прокси-сервером с поддержкой аутентификации и TLS, использовать OAuth2-proxy или Dexter/ Dex, и внедрить мTLS внутри инфраструктуры. Это снижает риск несанкционированного доступа и упрощает единое управление доступом.

Какую роль играет TLS в связке Grafana-Prometheus?

TLS обеспечивает конфиденциальность и целостность данных. Он предотвращает перехват и подмену запросов. В условиях корпоративной инфраструктуры рекомендуется использовать доверенные CA, проверку сертификатов и возможность mutual TLS между компонентами, когда это возможно.

Как избежать проблем с высокой кардинальностью при экспорте метрик?

Избегайте экспорта лейблов, значения которых существенно зависят от частых параметров пользователя, и централизуйте лейблы на уровне экспортёров. Применяйте relabeling и агрегацию там, где это возможно, и ограничивайте метрики по количеству целевых сред.

Какие тесты полезны после внедрения подключения Prometheus в Grafana?

Выполните end-to-end тест: добавьте несколько дашбордов с PromQL-запросами, проверьте резонирующую легенду, убедитесь, что фильтры по лейблам работают, проверьте работу аутентификации и TLS, протестируйте сценарии восстановления и масштабирования, например, имитацию добавления нового сервиса и проверку корректной регистрации в Prometheus.

Какие шаги стоит предпринять для масштабирования в крупной организации?

Разграничьте роли по проектам и кластерам, используйте федерацию Prometheus для агрегации данных из нескольких кластеров, применяйте централизованный proxy/identity-проекты, поддерживайте единые правила именования, и регулярно обновляйте политики доступа и сертификатов в CI/CD-пайплайне.

Какие открытые решения стоит рассмотреть для ускоренного внедрения?

В качестве open-source решений можно рассмотреть NGINX как прокси с базовой аутентификацией, oauth2-proxy для OAuth-соединений, и Dex в связке с OIDC; это обеспечивает совместимый и масштабируемый подход к аутентификации и авторизации без значительных изменений в Prometheus и Grafana.

Как сочетать соглашения имён с расширенной observability, включая логи и трассировку?

Применяйте единые политики именования и лейблов в Prometheus и в совместимом стеке для логов и трассировки. В Grafana можно строить кросс-системные дашборды, где legенд-форматы унифицированы, например, через общие лейблы (service, namespace, cluster). Это упрощает корреляцию между метриками, логами и трассировками.

← Предыдущая статья

Управление пользователями: RBAC, группы, SSO

Следующая статья →

Подключение PostgreSQL: настройки, схемы и рекомендации