Мониторинг метрик Prometheus

Prometheus — это набор инструментов с открытым исходным кодом для мониторинга и оповещения, популярный в сообществе Kubernetes. Prometheus собирает метрики с нескольких конечных точек HTTP(S), которые предоставляют метрики в формате OpenMetrics. Список доступных экспортеров см. в документации Prometheus.

Типы внедрения метрик Prometheus

Ключ-АСТРОМ может обрабатывать Counter, Gauge, Histogram и Summary метрики Prometheus в Kubernetes с помощью экспортеров Prometheus и делать их доступными для построения графиков, оповещения и анализа.

Counter

Метрика Counter (счетчик) Prometheus¹ — это монотонно возрастающее значение, обычно используемое для измерений, которые могут только увеличиваться или оставаться постоянными. Ключ-АСТРОМ использует тип метрики COUNT, использующий дельта-кодирование² для уменьшения избыточности данных, для обработки данных. Таким образом, значение, отображаемое в Ключ-АСТРОМ, отражает не фактическое значение счётчика, а его изменение (дельту) в течение наблюдений.

Этот метод приводит к тому, что счетчик метрика отображается с задержкой в ​​одну минуту по сравнению с метрикой Gauge, если сбор данных по обеим метрикам начался одновременно. Подробнее см. в справочнике по протоколу сбора метрик.

Получение метрик счетчика Дельта-кодирование, используемое типом приема Ключ-АСТРОМ COUNT, означает, что принятое значение отражает не фактическое значение, а разницу между измерениями.

¹ Официальная документация Prometheus: Counter

² Дельта-кодирование, также известное как дельта-сжатие, сохраняет данные путем вычисления разницы между двумя наблюдениями или целевыми значениями. Этот метод, используемый в основном для незначительного изменения данных, позволяет избежать переизбытка данных.

Gauge

В отличие от Counter, метрика Gauge¹ хранит одно числовое значение, которое может увеличиваться и уменьшаться, и обычно используется для измерения таких показателей, как текущее использование памяти или количество пользователей онлайн. В Ключ-АСТРОМ тип метрики GAUGE будет использоваться для сбора данных.

¹ Официальная документация Prometheus: Gauge

Histogram

Histograms (гистограммы)¹ предоставляют собой визуальное представление о распределении и частоте встречи числовых данных. Для базовой метрики <basename> Ключ-АСТРОМ будет обрабатывать данные в соответствии со следующей таблицей.

Метрика Prometheus	Тип метрики Ключ-АСТРОМ
<basename>_bucket{le="<upper inclusive bound>"}	COUNT
<basename>_bucket_sum	COUNT
<basename>_bucket_count	COUNT

Дополнительная гибкость и контроль обеспечиваются схемой настроек builtin:histogram-metrics, которая позволяет настроить сбор метрик <basename>_bucket{le="<upper inclusive bound>"}.

¹ Официальная документация Prometheus: Histogram

Summary

Как и гистограмма, метрика Summary¹ представляет собой выборку наблюдений. В отличие от метрики гистограммы, сегменты Summary представлены φ-квантилями, где 0 ≤ φ ≤ 1. Для базовой метрики <basename> Ключ-АСТРОМ будет обрабатывать данные в соответствии со следующей таблицей.

Метрика Prometheus	Тип метрики Ключ-АСТРОМ
<basename>{quantile="<φ>"}	GAUGE
<basename>_sum	COUNT
<basename>_count	COUNT

¹ Официальная документация Prometheus: Summary.

Не поддерживаемые типы метрик

Следующие типы в настоящее время не поддерживаются Ключ-АСТРОМ:

• метрики info, gaugehistogram или statesetec
• exemplars

Предустановка

Мы рекомендуем использовать АктивныйШлюз, работающий внутри кластера Kubernetes, из которого вы хотите получить метрики Prometheus. Если АктивныйШлюз работает вне отслеживаемого кластера (например, в виртуальной машине или в другом кластере Kubernetes), он не сможет получить данные с конечных точек Prometheus в подах, требующих аутентификации (например, RBAC или аутентификации клиента). Работа АктивногоШлюза внутри кластеров также обеспечит повышение производительности.

• В Ключ-АСТРОМ перейдите на страницу настроек мониторинга кластера Kubernetes и включите
  • Мониторинг пространств имен, служб, рабочих нагрузок и модулей Kubernetes
  • Мониторинг аннотированных экспортеров Prometheus
• Аннотированные определения модулей. Подробности см. ниже.
• Убедитесь, что политика вашей сети позволяет АктивномуШлюзу подключаться к экспортерам.
  Например, если вы развернули АктивныйШлюз в кластере Kubernetes с помощью Ключ-АСТРОМ Operator и у вас есть аннотированные экспортеры Prometheus в пространстве имен online-boutique, а также у вас есть сетевая политика, определенная для этого пространства имен, вам необходимо убедиться, что модуль АктивногоШлюза, расположенный в пространстве имен astromkey, может подключаться к аннотированным экспортерам Prometheus в пространстве имен online-boutique.

Аннотирование экспортных модулей Prometheus

Ключ-АСТРОМ собирает метрики со всех модулей, аннотированных свойством metrics.astromkey.com/scrape, заданным true в определении модуля. Эта функция применяется ко всем модулям во всем кластере Kubernetes, независимо от того, запущен ли модуль в пространстве имён, соответствующем селектору пространства имён Ключ-АСТРОМ.

В зависимости от фактического экспортера в модуле вам может потребоваться задать дополнительные аннотации к определению модуля, чтобы Ключ-АСТРОМ мог правильно обрабатывать эти метрики.

Включение сбора метрик (необходимо)

Установите metrics.astromkey.com/scrape в true для того, чтобы Ключ-АСТРОМ мог собирать метрики Prometheus, доступные для этого модуля.

Порт метрик (необходимо)

По умолчанию метрики Prometheus доступны на первом открытом TCP-порту модуля. Установите соответствующий порт metrics.astromkey.com/port.

Чтобы определить значение порта, ознакомьтесь со списком распространенных портов для известных экспортеров в разделе Назначение портов по умолчанию.

Путь к конечной точке метрик (необязательно)

Используется metrics.astromkey.com/path для переопределения конечной точки Prometheus по умолчанию (/metrics).

HTTP/HTTPS (необязательно)

Установите значение metrics.astromkey.com/secure в true, если хотите собирать метрики, предоставляемые экспортёром по HTTPS. Значение по умолчанию — false, поскольку большинство экспортёров предоставляют свои метрики по HTTP.

Если вы хотите пропустить проверку TLS-сертификата (например, при использовании самоподписанных сертификатов), можно задать аннотацию metrics.astromkey.com/insecure_skip_verify в true. Однако эта аннотация учитывается только при использовании АктивногоШлюза, развёрнутого внутри отслеживаемого кластера, и при настройке подключения Kubernetes для мониторинга локальной конечной точки API Kubernetes.

Фильтрация показателей (необязательно)

Используется metrics.astromkey.com/filter для определения фильтра, позволяющего включить ("mode": "include") или исключить ("mode": "exclude") список метрик. Если аннотация фильтра не определена, собираются все метрики. Синтаксис фильтра также поддерживает звёздочку (*). Этот символ позволяет фильтровать ключи метрик, которые начинаются, заканчиваются или содержат определённую последовательность, например:

• redis_db* фильтрует все метрики, начинающиеся с redis_db
• *insights* фильтрует все метрики, содержащие insights
• *bytes фильтрует все метрики, заканчивающиеся на bytes

Использование символа * внутри фильтра, например redis_*_bytes, не поддерживается.

Фильтр применяется к исходному ключу метрики, поэтому важно знать, что Ключ-АСТРОМ автоматически добавляет суффиксы к некоторым ключам метрики в зависимости от исходного ключа метрики и типа метрики. Подробнее см. в разделе Полезная нагрузка (ниже).

Для summary и histogram фильтр применяется ко всему семейству метрик, как указано в строке #TYPE формата OpenMetrics. Например, если фильтруется семейство сводных метрик foo_seconds, фильтруются все точки метрик, включая foo_seconds_count и foo_seconds_sum. И наоборот, если foo_seconds_count указано как фильтр, фильтрация не применяется, поскольку такого семейства метрик нет.

В этом примере показано, как использовать синтаксис фильтра в определении модуля с аннотациями:

apiVersion: v1 kind: Pod metadata:   name: mypod   annotations:     metrics.astromkey.com/scrape: 'true'     metrics.astromkey.com/path: '/path/to-metrics'     metrics.astromkey.com/port: '9001'     metrics.astromkey.com/secure: 'false'     metrics.astromkey.com/filter: |       {         "mode": "include",         "names": [             "redis_db_keys",             "*insights*",             "*bytes"             ]       } spec:   containers:   - name: mycontainer     image: myregistry/myimage:mytag

Значения metrics.astromkey.com/path, metrics.astromkey.com/port и metrics.astromkey.com/secure зависят от используемого экспортера; адаптируйте их к вашим требованиям. Чтобы определить значение порта, см. раздел Распределение портов по умолчанию, где представлен список распространённых портов для известных экспортеров.

Аутентификация клиента (необязательно)

Требования: Добавьте разрешения на доступ secrets и configmaps для astromkey-kubernetes-monitoring СlusterRole.

Некоторые системы требуют дополнительной аутентификации перед сбором данных Ключ-АСТРОМ. В таких случаях вы можете задать следующие дополнительные аннотации:

• metrics.astromkey.com/tls.ca.crt
• metrics.astromkey.com/tls.crt
• metrics.astromkey.com/tls.key

Необходимые сертификаты/ключи автоматически загружаются из secret/configmaps, указанного в значении аннотации.

Схема значений аннотации: <configmap|secret>:<namespace>:<resource_name>:<field_name_in_data_section>.

Например, аннотации могут выглядеть следующим образом:

apiVersion: v1 kind: Pod metadata:   name: mypod   annotations:     metrics.astromkey.com/scrape: 'true'     metrics.astromkey.com/path: '/path/to-metrics'     metrics.astromkey.com/port: '9001'     metrics.astromkey.com/secure: 'false'     metrics.astromkey.com/tls.ca.crt: 'configmap:kubernetes-config:etcd-metric-serving-ca:ca-bundle.crt'     metrics.astromkey.com/tls.crt: 'secret:kubernetes-config:etcd-metric-client:tls.crt'     metrics.astromkey.com/tls.key: 'secret:kubernetes-config:etcd-metric-client:tls.key' spec:   containers:   - name: mycontainer     image: myregistry/myimage:mytag

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

HTTP — базовая аутентификация (необязательно)

Требования: Добавьте разрешения на доступ secrets для astromkey-kubernetes-monitoring СlusterRole.

Для систем, требующих базовой HTTP-аутентификации перед сбором данных, вы можете применить следующие дополнительные аннотации.

• metrics.astromkey.com/http.auth.basic.username
• metrics.astromkey.com/http.auth.basic.password

В следующем примере показаны два секрета, созданных в пространстве имён default: один для имени пользователя и один для пароля. Вышеупомянутые аннотации затем используются в модуле, при этом ссылки на секреты содержатся в значениях аннотаций.

apiVersion: v1 kind: Secret metadata:   name: user-secret data:   username: bXktdXNlcm5hbWUtc2VjcmV0Cg== --- apiVersion: v1 kind: Secret metadata:   name: password-secret data:   password: bXktcGFzc3dvcmQtc2VjcmV0Cg==

apiVersion: v1 kind: Pod metadata:   name: mypod   annotations:     metrics.astromkey.com/scrape: 'true'     metrics.astromkey.com/path: '/path/to-metrics'     metrics.astromkey.com/port: '9001'     metrics.astromkey.com/secure: 'false'     metrics.astromkey.com/http.auth.basic.username: 'secret:default:user-secret:username'     metrics.astromkey.com/http.auth.basic.password: 'secret:default:password-secret:password' spec:   containers:   - name: mycontainer     image: myregistry/myimage:mytag

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

HTTP — аутентификация токена-носителя (необязательно)

Требования:

• АктивныйШлюз версии 1.317+
• Добавьте разрешения на доступ secrets для astromkey-kubernetes-monitoring СlusterRole.

Для систем, требующих аутентификации токена на предъявителя перед сбором данных, можно применить дополнительную аннотацию metrics.astromkey.com/http.auth.

В следующем примере показан секрет token-secret, созданный в пространстве имён default. Требуемый токен Bearer хранится под ключом bearer.

apiVersion: v1 kind: Secret metadata:   name: token-secret data:   bearer: bXktYmVhcmVyLXRva2VuCg==

Затем аннотация используется в модуле, при этом секрет указывается в значениях аннотации.

apiVersion: v1 kind: Pod metadata:   name: mypod   annotations:     metrics.astromkey.com/scrape: 'true'     metrics.astromkey.com/path: '/path/to-metrics'     metrics.astromkey.com/port: '9001'     metrics.astromkey.com/secure: 'false'     metrics.astromkey.com/http.auth: 'secret:default:token-secret:bearer' spec:   containers:   - name: mycontainer     image: myregistry/myimage:mytag

Прием метрик от экспортеров, требующих аутентификации с помощью токена Bearer, возможен только при развертывании АктивногоШлюза внутри отслеживаемого кластера и настройке параметров подключения Kubernetes для мониторинга локальной конечной точки API Kubernetes.

Авторизация управления доступом на основе ролей (RBAC) для сбора метрик

Для модулей-экспортеров, таких как node-exporter, kube-state-metrics, и openshift-state-metrics, требуется авторизация RBAC. Для этих модулей добавьте аннотацию:

metrics.astromkey.com/http.auth: 'builtin:default'

Эта аннотация применяет токен astromkey-kubernetes-monitoring из учетной записи службы в качестве заголовка авторизации для запросов к экспортеру.

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

Дополнительную информацию об аннотировании модулей см. в разделе Аннотировать сервисы Kubernetes (ниже).

Аннотировать сервисы Kubernetes

Требования: добавьте разрешение на доступ к службам для astromkey-kubernetes-monitoring СlusterRole (не требуется для пользователей Ключ-АСТРОМ Operator, так как оно включено по умолчанию в clusterrole-kubernetes-monitoring.yaml).

Вы также можете аннотировать сервисы вместо модулей. Модули, соответствующие сервисам Kubernetes, автоматически обнаруживаются с помощью селектора меток сервисов, что приводит к сбору данных со всех модулей, принадлежащих сервису.

Служба и соответствующие ей модули должны располагаться в одном пространстве имен. В metrics.astromkey.com/portаннотации должен быть указан целевой порт контейнера-пода в сервисе, а не собственный порт сервиса, поскольку сервис не используется для проксирования процесса сбора данных.

Дополнительную информацию о том, как аннотировать службы, см. в разделе Лучшие практики аннотаций (ниже).

Лучшие практики аннотаций

Существует несколько способов размещения аннотаций в модулях или сервисах. Ниже вы можете определить, какой подход лучше всего подходит для вашего сценария.

Рекомендуется, если у вас есть полный доступ

Если у вас есть полный контроль над шаблоном модуля или определением сервиса, мы рекомендуем добавлять аннотации, редактируя эти файлы. Это самый надёжный способ обеспечить сохранение аннотаций. Мы рекомендуем редактировать шаблон модуля, а не определение сервиса, так как это требует меньше прав (например, если у вас нет доступа к сервисам).

Преимущество: аннотации сохраняются, поэтому их не нужно создавать заново при удалении модуля.

Варианты, если у вас нет полного контроля

Если у вас нет полного контроля над шаблоном модуля, у вас есть следующие возможности:

1. Аннотирование существующего сервиса (в YAML).

Требования: контроль над существующим YAML и разрешение на редактирование существующего объекта сервиса Kubernetes.

Преимущества: сохранение аннотаций.

Недостатки: отсутствуют.

Пример:

kind: Service apiVersion: v1 metadata:   name: astromkey-monitoring-node-exporter   namespace: kubernetes-monitoring   annotations:     metrics.astromkey.com/port: '12071'     metrics.astromkey.com/scrape: 'true'     metrics.astromkey.com/secure: 'true'     metrics.astromkey.com/path: '/metrics' spec:   ports:     - name: astromkey-monitoring-node-exporter-port       port: 9100       targetPort: 12071   selector:     app.kubernetes.io/name: node-exporter

2. Создание новой службы (в YAML).

Требования: имя новой службы должно начинаться с префикса astromkey-monitoring-. Эта служба должна находиться в том же пространстве имён, что и модули, и иметь разрешение на создание объекта службы Kubernetes. Служба предпочтительно должна быть без IP (clusterIP установлено значение None), поскольку это подчёркивает, что служба не используется для проксирования.

Преимущества: Вы контролируете исходную рабочую нагрузку/сервис.

Недостатки: Требуется синхронизация с селектором меток. Поддерживается только селектор меток.

Пример:

kind: Service apiVersion: v1 metadata:   name: astromkey-monitoring-node-exporter   namespace: kubernetes-monitoring   annotations:     metrics.astromkey.com/port: '12071'     metrics.astromkey.com/scrape: 'true'     metrics.astromkey.com/secure: 'true'     metrics.astromkey.com/path: '/metrics' spec:   ports:     - name: astromkey-monitoring-node-exporter-port       port: 12071   selector:     app.kubernetes.io/name: node-exporter   clusterIP: None

3. Аннотирование существующего сервиса (в CLI).

Требования: наличие разрешения на редактирование существующего объекта сервиса Kubernetes.

Преимущества: не требуется синхронизация селектора меток.

Недостатки: аннотации не сохраняются, поэтому изменения будут перезаписывать аннотации. Поддерживается только селектор меток.

4. Аннотирование существующих модулей (в CLI).

Требования: отсутствуют.

Преимущества: можно быстро протестировать прием метрик.

Недостатки: аннотации не сохраняются, поэтому изменения будут перезаписывать аннотации.

Просмотр показателей на дашборде

Метрики из экспортеров Prometheus доступны в визуализации метрик для создания пользовательских диаграмм. Выберите «Создать пользовательскую диаграмму» и нажмите «Попробовать» в верхнем баннере. Подробнее см. в Визуализация метрик.

Вы можете просто найти ключевые показатели по всем доступным метрикам и определить, как вы хотите их анализировать и отображать в виде диаграмм. После этого вы можете закрепить свои диаграммы на дашборде.

Оповещения метрик

Вы также можете создавать собственные оповещения на основе собранных Prometheus метрик. Перейдите в раздел Настройки > Обнаружение аномалий > События метрик и выберите Добавить событие метрик. На странице Добавить событие метрик найдите метрику Prometheus по её ключу и создайте оповещение. Подробнее см. в разделе События метрик, вызывающих оповещения.

Ограничения

Текущие ограничения интеграции метрик Prometheus следующие:

Несколько экспортеров в модуле

В настоящее время поддержка нескольких экспортеров не поддерживается; можно выбрать только тот экспортер, который используется с аннотацией metrics.astromkey.com/port.

Количество модулей, метрик и точек данных метрик

Эта интеграция поддерживает максимум

• 1000 экспортеров
• 1000 метрик на модуль
• 500 000 точек метрических данных на модуль

Несмотря на то, что допускаются более крупные наборы данных, это может привести к пропускам при приеме данных, поскольку Ключ-АСТРОМ собирает все метрики каждую минуту перед отправкой их в кластер.

Методы мониторинга

Существует два различных метода мониторинга технологий:

• Первый метод предполагает использование фреймворка Расширения 2.0, который изначально поддерживает несколько расширений для экспортеров Prometheus. Этот метод предоставляет комплексные функции мониторинга, включая технологические панели мониторинга, возможности оповещения, визуализацию топологии и страницы сущностей. Однако этот метод работает за пределами Kubernetes.
• Второй метод включает аннотирование модулей Prometheus в Kubernetes для извлечения данных из экспортеров Prometheus. Хотя этот метод обеспечивает более собственный подход Kubernetes, в настоящее время он обеспечивает минимальное функциональное совпадение с функциями, предоставляемыми фреймворком Расширения 2.0.

Эти два метода обслуживают разные контексты, работают независимо друг от друга и используют разные показатели.

Мониторинг потребления

Если у вас есть лицензия DPS, вы можете получить дополнительную информацию о потреблении пользовательских метрик в вашей среде из нашей документации по лицензированию .

• Полный мониторинг стека включает фиксированное количество точек данных пользовательских метрик для каждого ГБ, которые вносят вклад в потребление ГБ-часов вашей средой для контейнеров с кодовыми модулями.

Если у вас классическая лицензия, метрики Prometheus в средах Kubernetes подлежат потреблению DDU.

• Метрики Prometheus от экспортеров, работающих на хостах, отслеживаемых ЕдинымАгентом, сначала вычитаются из вашей квоты включённых метрик на единицу хоста. После превышения этой квоты любые дополнительные метрики расходуют DDU.
• Метрики Prometheus от экспортеров, работающих на хостах, не отслеживаемых ЕдинымАгентом, всегда потребляют DDU.

Устранение неполадок

Для устранения проблем с интеграцией Prometheus скачайте расширение Kubernetes Monitoring Statistics.

Подробнее см. статью сообщества Как устранить проблемы с отсутствующими метриками Prometheus.