Поделиться через

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

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

Для этой конфигурации требуется конфигурирование надстройки мониторинга для агента Azure Monitor, используемого в Container insights для отправки данных в рабочую область 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, агент 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 отменял коллекции.

  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.

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

Чтобы убедиться в успешном применении конфигурации к кластеру, выполните следующую команду, чтобы просмотреть логи из Пода агента: 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.

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