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

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

Это важно

В этой статье описывается устаревшая стратегия отправки метрик Prometheus из кластера Kubernetes в рабочую область Log Analytics. Эта стратегия заменена включением Managed Prometheus для кластера Kubernetes. См. статью "Включить функции Azure Monitor" для кластеров Kubernetes.

Для этой конфигурации требуется конфигурирование надстройки мониторинга для агента Azure Monitor, используемого в Container insights для отправки данных в рабочую область Log Analytics. Для этого необходимо предоставить конечную точку метрик Prometheus через экспортеров или pod-ов, а затем настроить надстройку мониторинга для агента 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`, агент Container insights собирает данные с pod Kubernetes во всем кластере для следующих аннотаций Prometheus: `prometheus.io/scrape:` `prometheus.io/scheme:` `prometheus.io/path:` `prometheus.io/port:`
	`prometheus.io/scrape`	Логический	истина или ложь	Включает скрейпинг 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] на единицы времени, такие как s, m и h.
На уровне узла или на уровне кластера	`fieldpass` `fielddrop`	Строка	Массив, разделённый запятыми	Можно указать определенные метрики, которые следует или не следует собирать в конечной точке, задав список разрешений (`fieldpass`) и запретов (`fielddrop`). Сначала необходимо задать список разрешений.

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

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

Скачайте файл YAML шаблона ConfigMap и сохраните его как container-azm-ms-agentconfig.yaml. Если вы уже развернули ConfigMap в кластере и хотите обновить его, используя новую конфигурацию, можно изменить ранее использовавшийся файл ConfigMap,
Чтобы извлекать метрики 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"]
```
Чтобы настроить извлечение метрик Prometheus по определенному URL-адресу в кластере, настройте файл 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
urls = ["http://myurl:9101/metrics"] ## An array of urls to scrape metrics from
```
Чтобы настроить извлечение метрик Prometheus из DaemonSet агента для каждого отдельного узла в кластере, настройте в ConfigMap следующие параметры, приведенные в примере:
```
prometheus-data-collection-settings: |- 
# Custom Prometheus metrics data collection settings 
[prometheus_data_collection_settings.node] 
interval = "1m"  ## Valid time units are s, m, h. 
urls = ["http://$NODE_IP:9103/metrics"] 
fieldpass = ["metric_to_pass1", "metric_to_pass2"] 
fielddrop = ["metric_to_drop"] 
```
$NODE_IP — это определенный параметр аналитики контейнеров, который можно использовать вместо IP-адреса узла. Все буквы должны быть прописными.
Чтобы настроить извлечение метрик Prometheus, указав заметку pod, сделайте следующее:
1. В 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
monitor_kubernetes_pods = true 
```
1. Укажите следующую конфигурацию для аннотаций pod:
```
- prometheus.io/scrape:"true" #Enable scraping for this pod 
- prometheus.io/scheme:"http" #If the metrics endpoint is secured then you will need to set this to `https`, if not default `http`
- prometheus.io/path:"/mymetrics" #If the metrics path is not /metrics, define it with this annotation. 
- prometheus.io/port:"8000" #If port is not 9102 use this annotation
```
Чтобы ограничить мониторинг определенными пространствами имен для объектов pod с заметками, можно, например, включить только объекты pod, выделенные для рабочих нагрузок. Для этого установите для параметра monitor_kubernetes_pod значение true в ConfigMap, Затем добавьте фильтр пространства имен monitor_kubernetes_pods_namespaces, чтобы указать, из каких пространств имен извлекать данные. Например, monitor_kubernetes_pods_namespaces = ["default1", "default2", "default3"].
Выполните следующую команду 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.

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

Чтобы убедиться в успешном применении конфигурации к кластеру, выполните следующую команду, чтобы просмотреть логи из Пода агента: 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. Данные отправляются каждый час с уровнем серьезности Предупреждение для ошибок сбора данных и уровнем серьезности Ошибка для ошибок в конфигурации. Если ошибки отсутствуют, запись в таблице содержит данные с уровнем серьезности Info, который указывает на отсутствие ошибок. Свойство Tags содержит дополнительные сведения об идентификаторе модуля pod и контейнера, в котором произошла ошибка, а также первое вхождение, последнее вхождение и подсчет за последний час.
Для Azure Red Hat OpenShift версии 3.x и версии 4.x проверьте журналы агента Azure Monitor, выполнив поиск в таблице ContainerLog, чтобы проверить, включена ли коллекция журналов openshift-azure-logging.

Ошибки предотвращают синтаксический анализ файла агентом 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.

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-08-25