Отправка метрик Prometheus в рабочую область Log Analytics с помощью аналитики контейнеров

  • Статья

В этой статье описывается, как отправлять метрики Prometheus из кластера Kubernetes, отслеживаемого аналитикой контейнеров, в рабочую область Log Analytics. Прежде чем выполнить эту конфигурацию, необходимо сначала убедиться, что вы удаляете метрики Prometheus из кластера с помощью управляемой службы Azure Monitor для Prometheus, который является рекомендуемыми способами для мониторинга кластеров. Используйте конфигурацию, описанную в этой статье, только если вы также хотите отправить эти данные в рабочую область Log Analytics, где можно проанализировать ее с помощью запросов журналов и оповещений поиска по журналам.

Для этой конфигурации требуется настроить надстройку мониторинга для агента Azure Monitor, которая является той же, которая используется аналитикой контейнеров для отправки данных в рабочую область Log Analytics. Для этого необходимо предоставить конечную точку метрик Prometheus через экспортеров или модулей pod, а затем настроить надстройку мониторинга для агента Azure Monitor, используемого аналитикой контейнеров, как показано на следующей схеме.

Схема архитектуры мониторинга контейнеров, отправляя метрики Prometheus в журналы Azure Monitor.

Параметры очистки Prometheus (для метрик, хранящихся в виде журналов)

Активная очистка метрик из Prometheus выполняется с одной из двух перспектив ниже, а метрики отправляются в настроенную рабочую область Log Analytics:

  • На уровне кластера: определено в разделе ConfigMap [Prometheus data_collection_settings.cluster].
  • На уровне узла: определено в разделе ConfigMap [Prometheus_data_collection_settings.node].
Конечная точка Область Пример
Заметка Pod На уровне кластера prometheus.io/scrape: "true"
prometheus.io/path: "/mymetrics"
prometheus.io/port: "8000"
prometheus.io/scheme: "http"
Служба Kubernetes На уровне кластера http://my-service-dns.my-namespace:9100/metrics
http://metrics-server.kube-system.svc.cluster.local/metrics​
URL-адрес/конечная точка На узел или на уровне кластера http://myurl:9101/metrics

Если указан URL-адрес, то аналитика контейнеров собирает только данные конечной точки. Если указана служба Kubernetes, имя службы разрешается с помощью DNS-сервера кластера для получения IP-адреса, а затем извлекаются данные разрешенной службы.

Область Ключ Тип данных значение Описание
На уровне кластера Укажите один из следующих трех методов получения конечных точек для метрик.
urls Строка Массив с разделителями-запятыми Конечная точка HTTP (указан IP-адрес или допустимый URL-путь). Например: urls=[$NODE_IP/metrics]. ($NODE_IP — это специальный параметр для аналитики контейнеров, который можно использовать вместо IP-адреса узла. Необходимо использовать прописные буквы.)
kubernetes_services Строка Массив с разделителями-запятыми Массив служб Kubernetes для сбора метрик из kube-state-metrics. Здесь следует использовать полные доменные имена. Например: kubernetes_services = ["http://metrics-server.kube-system.svc.cluster.local/metrics",http://my-service-dns.my-namespace.svc.cluster.local:9100/metrics].
monitor_kubernetes_pods Логический true или false Если задано значение true в параметрах на уровне кластера, агент аналитики контейнеров удаляет модули pod Kubernetes во всем кластере для следующих заметок Prometheus:
prometheus.io/scrape:
prometheus.io/scheme:
prometheus.io/path:
prometheus.io/port:
prometheus.io/scrape Логический true или false Включает извлечение объекта pod, monitor_kubernetes_pods должен иметь значение true.
prometheus.io/scheme Строка HTTP По умолчанию для извлечения данных по HTTP.
prometheus.io/path Строка Массив с разделителями-запятыми Путь к HTTP-ресурсу, на котором следует получать метрики. Если для пути метрик не указано /metrics, укажите его с помощью этой заметки.
prometheus.io/port Строка 9102 Укажите порт для сбора данных. Если порт не задан, по умолчанию используется значение 9102.
monitor_kubernetes_pods_namespaces Строка Массив с разделителями-запятыми Список разрешенных пространств имен для сбора метрик из модулей Kubernetes.
Например: monitor_kubernetes_pods_namespaces = ["default1", "default2", "default3"]
На уровне узла urls Строка Массив с разделителями-запятыми Конечная точка HTTP (указан IP-адрес или допустимый URL-путь). Например: urls=[$NODE_IP/metrics]. ($NODE_IP — это специальный параметр для аналитики контейнеров, который можно использовать вместо IP-адреса узла. Необходимо использовать прописные буквы.)
На уровне узла или на уровне кластера interval Строка 60 с Интервал сбора по умолчанию равен одной минуте (60 секунд). В параметрах сбора можно изменить единицы времени для [prometheus_data_collection_settings.node] и (или) [prometheus_data_collection_settings.cluster], указать, например, с, мин., час.
На уровне узла или на уровне кластера fieldpass
fielddrop		 Строка Массив с разделителями-запятыми Можно указать определенные метрики, которые следует или не следует собирать в конечной точке, задав список разрешений (fieldpass) и запретов (fielddrop). Сначала необходимо задать список разрешений.

Настройка ConfigMaps для указания конфигурации скребка Prometheus (для метрик, хранящихся в виде журналов)

Выполните следующие действия, чтобы настроить файл конфигурации ConfigMap для кластера. ConfigMaps представляет собой глобальный список, и к агенту можно применить только один ConfigMap. Другой список ConfigMaps, аннулирующий сбор данных, недопустим.

  1. Скачайте файл YAML шаблона ConfigMap и сохраните его как container-azm-ms-agentconfig.yaml. Если вы уже развернули ConfigMap в кластере и хотите обновить его, используя новую конфигурацию, можно изменить ранее использовавшийся файл ConfigMap,

  2. Чтобы извлекать метрики Prometheus, измените YAML-файл ConfigMap, дополнив настройки.

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

    prometheus-data-collection-settings: |- ​
# Custom Prometheus metrics data collection settings
[prometheus_data_collection_settings.cluster] ​
interval = "1m"  ## Valid time units are s, m, h.
fieldpass = ["metric_to_pass1", "metric_to_pass12"] ## specify metrics to pass through ​
fielddrop = ["metric_to_drop"] ## specify metrics to drop from collecting
kubernetes_services = ["http://my-service-dns.my-namespace:9102/metrics"]

  3. Выполните следующую команду kubectl: kubectl apply -f <configmap_yaml_file.yaml>.

    Пример: kubectl apply -f container-azm-ms-agentconfig.yaml.

Изменение конфигурации и ее вступление в силу может занять несколько минут. Все модули pod ama-logs в кластере перезагрузятся. По завершении перезапусков появится сообщение, подобное приведенному ниже, с результатом configmap "container-azm-ms-agentconfig" created.

Проверка конфигурации

Чтобы убедиться в успешном применении конфигурации к кластеру, выполните следующую команду для проверки журналов из объекта pod агента: kubectl logs ama-logs-fdf58 -n=kube-system.

Если из модулей pod агента Azure Monitor возникают ошибки конфигурации, выходные данные отображают ошибки, аналогичные следующему примеру:

***************Start Config Processing******************** 
config::unsupported/missing config schema version - 'v21' , using defaults

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

  • Из журналов объектов pod агента с помощью той же команды kubectl logs.

  • Из динамических данных. В журналах динамических данных отображаются ошибки, аналогичные следующему примеру:

    2019-07-08T18:55:00Z E! [inputs.prometheus]: Error in plugin: error making HTTP request to http://invalidurl:1010/metrics: Get http://invalidurl:1010/metrics: dial tcp: lookup invalidurl on 10.0.0.10:53: no such host

  • Из таблицы KubeMonAgentEvents в рабочей области Log Analytics. Данные отправляются каждый час с уровнем серьезности Предупреждение для ошибок сбора и уровнем Ошибка для ошибок конфигурации. Если ошибки отсутствуют, запись в таблице содержит данные с информацией о серьезности, которая не сообщает об ошибках. Свойство Теги содержит дополнительные сведения об объекте pod и идентификаторе контейнера, в которых произошла ошибка, а также о первом и последнем случае ошибок и их количестве за последний час.

  • Для Azure Red Hat OpenShift версии 3.x и версии 4.x проверьте журналы агента Azure Monitor, выполнив поиск в таблице ContainerLog , чтобы проверить, включена ли коллекция журналов openshift-azure-log.

Ошибки предотвращают синтаксический анализ файла агентом Azure Monitor, что приводит к перезапуску и использованию конфигурации по умолчанию. После исправления ошибок в ConfigMap для кластеров, отличных от Azure Red Hat OpenShift версии 3.x, сохраните YAML-файл и примените обновленный ConfigMaps, выполнив команду kubectl apply -f <configmap_yaml_file.yaml.

Для Azure Red Hat OpenShift версии 3.x измените и сохраните обновленный ConfigMaps, выполнив команду oc edit configmaps container-azm-ms-agentconfig -n openshift-azure-logging.

Запрос данных метрик Prometheus

Чтобы просмотреть метрики Prometheus, скребированные Azure Monitor, и любые ошибки конфигурации и слома, сообщаемые агентом, просмотрите данные метрик запроса Prometheus.

Просмотр метрик Prometheus в Grafana

Аналитика контейнеров поддерживает просмотр метрик, хранящихся в рабочей области Log Analytics, на панелях мониторинга Grafana. Мы предоставили шаблон, который можно скачать из репозитория панели мониторинга Grafana. Используйте его в качестве отправной точки и образца, когда будете учиться запрашивать другие данных из отслеживаемых кластеров для визуализации на пользовательских панелях мониторинга Grafana.

Следующие шаги