Бөлісу құралы:

Мониторинг Служба Azure Kubernetes

  • Мақала

В этой статье рассматриваются следующие вопросы:

  • Типы данных мониторинга, которые можно собирать для этой службы.
  • Способы анализа данных.

Примечание.

Если вы уже знакомы с этой службой и (или) Azure Monitor и просто хотите знать, как анализировать данные мониторинга, см . раздел "Анализ " в конце этой статьи.

При наличии критически важных приложений и бизнес-процессов, использующих ресурсы Azure, необходимо отслеживать и получать оповещения для системы. Служба Azure Monitor собирает и агрегирует метрики и журналы из каждого компонента системы. Azure Monitor предоставляет представление о доступности, производительности и устойчивости, а также уведомляет вас о проблемах. Вы можете использовать портал Azure, PowerShell, Azure CLI, REST API или клиентские библиотеки для настройки и просмотра данных мониторинга.

Внимание

Kubernetes — это сложная распределенная система со многими движущимися частями. Требуется мониторинг на нескольких уровнях. Хотя AKS является управляемой службой Kubernetes, одна и та же строгость мониторинга на нескольких уровнях по-прежнему требуется. В этой статье содержатся общие сведения и рекомендации по мониторингу кластера AKS.

Аналитические выводы (Insights)

Некоторые службы в Azure имеют встроенную панель мониторинга в портал Azure, которая предоставляет отправную точку для мониторинга службы. Эти панели мониторинга называются аналитическими сведениями, и их можно найти в Центре аналитики Azure Monitor в портал Azure.

Аналитика контейнеров Azure Monitor собирает пользовательские метрики для узлов, модулей pod, контейнеров и постоянных томов. Дополнительные сведения см. в разделе "Метрики", собранные аналитикой контейнеров.

Azure Monitor Application Insights используется для мониторинга производительности приложений (APM). Сведения о включении Application Insights с изменениями кода см. в статье "Включить Azure Monitor OpenTelemetry". Сведения о включении Application Insights без изменений кода см. в статье автоинструментация AKS. Дополнительные сведения о инструментировании см . в основах сбора данных.

Данные мониторинга

AKS создает те же типы данных мониторинга, что и другие ресурсы Azure, описанные в разделе "Мониторинг данных из ресурсов Azure". Дополнительные сведения о метриках и журналах, созданных AKS, см . в справочнике по данным мониторинга AKS. Другие службы и функции Azure собирают другие данные и обеспечивают другие параметры анализа, как показано на следующей схеме и таблице.

Схема сбора данных мониторинга из AKS.

Оригинал Description
Метрики платформы Метрики платформы автоматически собираются для кластеров AKS без затрат. Эти метрики можно проанализировать с помощью обозревателя метрик или использовать их для оповещений метрик.
Метрики Prometheus Если включить очистку метрик для кластера, управляемая служба Azure Monitor для Prometheus собирает метрики Prometheus и сохраняет их в рабочей области Azure Monitor. Анализируйте их с помощью предварительно созданных панелей мониторинга в Управляемой Grafana Azure и с помощью оповещений Prometheus.
Журналы действий Журнал действий собирается автоматически для кластеров AKS без затрат. Эти журналы отслеживают такие сведения, как при создании кластера или изменении конфигурации. Чтобы проанализировать его с другими данными журнала, отправьте журнал действий в рабочую область Log Analytics.
Журналы ресурсов Журналы плоскости управления для AKS реализуются в виде журналов ресурсов. Создайте параметр диагностики для отправки их в рабочую область Log Analytics, где можно анализировать и оповещать их с помощью запросов журналов в Log Analytics.
Аналитика контейнеров Аналитика контейнеров собирает различные журналы и данные о производительности из кластера, включая потоки stdout/stderr, и храните их в рабочей области Log Analytics и метриках Azure Monitor. Анализ этих данных с помощью представлений и книг, включенных в аналитику контейнеров или с помощью обозревателя метрик Log Analytics и метрик.
Application Insights Azure Monitor Application Insights собирает журналы, метрики и распределенные трассировки. Эта телеметрия хранится в рабочей области Log Analytics для анализа в портал Azure.

Типы ресурсов

Azure использует концепцию типов ресурсов и идентификаторов для идентификации всего в подписке. Типы ресурсов также являются частью идентификаторов ресурсов для каждого ресурса, работающего в Azure. Например, для виртуальной машины используется Microsoft.Compute/virtualMachinesодин тип ресурса. Список служб и связанных с ними типов ресурсов см. в разделе "Поставщики ресурсов".

Azure Monitor аналогично упорядочивает основные данные мониторинга в метрики и журналы на основе типов ресурсов, которые также называются пространствами имен. Различные метрики и журналы доступны для различных типов ресурсов. Служба может быть связана с несколькими типами ресурсов.

Дополнительные сведения о типах ресурсов для AKS см. в Служба Azure Kubernetes справочнике по данным мониторинга.

Хранилище данных

Для Azure Monitor:

  • Данные метрик хранятся в базе данных метрик Azure Monitor.
  • Данные журнала хранятся в хранилище журналов Azure Monitor. Log Analytics — это средство в портал Azure, которое может запрашивать это хранилище.
  • Журнал действий Azure — это отдельное хранилище с собственным интерфейсом в портал Azure.

При необходимости можно перенаправить данные журнала метрик и действий в хранилище журналов Azure Monitor. Затем с помощью Log Analytics можно запрашивать данные и сопоставлять их с другими данными журнала.

Многие службы могут использовать параметры диагностики для отправки данных метрик и журналов в другие расположения хранилища за пределами Azure Monitor. Примеры включают служба хранилища Azure, размещенные партнерские системы и системы партнеров, отличные от Azure, с помощью Центров событий.

Подробные сведения о том, как Azure Monitor хранит данные, см. на платформе данных Azure Monitor.

Метрики платформы Azure Monitor

Azure Monitor предоставляет метрики платформы для большинства служб. Эти метрики перечислены ниже.

  • По отдельности определяется для каждого пространства имен.
  • Хранится в базе данных метрик временных рядов Azure Monitor.
  • Упрощенный и способный поддерживать оповещения практически в режиме реального времени.
  • Используется для отслеживания производительности ресурса с течением времени.

Коллекция: Azure Monitor автоматически собирает метрики платформы. Настройка не требуется.

Маршрутизация. Вы также можете направлять метрики платформы в журналы Azure Monitor или Log Analytics, чтобы запросить их с другими данными журнала. Дополнительные сведения см. в параметре диагностики метрик. Сведения о настройке параметров диагностики для службы см. в статье "Создание параметров диагностики" в Azure Monitor.

Список всех метрик, которые можно собрать для всех ресурсов в Azure Monitor, см. в статье "Поддерживаемые метрики в Azure Monitor".

Список доступных метрик для AKS см. в Служба Azure Kubernetes справочнике по данным мониторинга.

Метрики играют важную роль в мониторинге кластера, выявлении проблем и оптимизации производительности в кластерах AKS. Метрики платформы записываются с помощью сервера метрик, установленного в пространстве имен kube-system, которое периодически ломает метрики от всех узлов Kubernetes, обслуживаемых Kubelet. Кроме того, следует включить метрики Управляемого prometheus Azure для сбора метрик контейнеров и метрик объектов Kubernetes, таких как состояние объектов deployments. Дополнительные сведения см. в разделе "Сбор метрик Prometheus" из кластера AKS.

AKS также предоставляет метрики из критических компонентов уровня управления, таких как сервер API, ETCD, планировщик через Управляемый Prometheus Azure. Эта функция в настоящее время доступна для предварительного ознакомления. Дополнительные сведения см. в разделе "Мониторинг Служба Azure Kubernetes (AKS) метрики плоскости управления (предварительная версия)".

Метрики, отличные от Azure Monitor

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

Следующие службы и функции Azure Monitor можно использовать для дополнительного мониторинга кластеров Kubernetes. Эти функции можно включить во время создания кластера AKS на вкладке "Интеграция" в портал Azure, Azure CLI, Terraform, Политика Azure или подключить кластер к ним позже. Каждая из этих функций может повлечь за собой затраты, поэтому ознакомьтесь с сведениями о ценах для каждого из них, прежде чем включить их.

Служба, компонент или функция Description
Аналитика контейнеров Использует контейнерную версию агента Azure Monitor для сбора журналов stdout/stderr и событий Kubernetes из каждого узла в кластере. Эта функция поддерживает различные сценарии мониторинга для кластеров AKS. Мониторинг кластера AKS можно включить при создании с помощью Azure CLI, Политика Azure, портал Azure или Terraform. Если при создании кластера не включить аналитику контейнеров, см. статью "Включить аналитику контейнеров" для кластера Служба Azure Kubernetes (AKS), чтобы включить его.

Аналитика контейнеров хранит большую часть своих данных в рабочей области Log Analytics и обычно использует ту же рабочую область Log Analytics, что и журналы ресурсов для кластера. Ознакомьтесь с архитектурой рабочей области Log Analytics, чтобы узнать, сколько рабочих областей следует использовать и где их найти.
Управляемая служба Azure Monitor для Prometheus Prometheus — это облачное решение метрик из Cloud Native Compute Foundation. Это наиболее распространенный инструмент, используемый для сбора и анализа данных метрик из кластеров Kubernetes. Управляемая служба Azure Monitor для Prometheus — это полностью управляемое решение для мониторинга, совместимое с Prometheus в Azure. Если вы не включите управляемый Prometheus при создании кластера, ознакомьтесь с метриками Сбора метрик Prometheus из кластера AKS для других параметров, чтобы включить его.

Управляемая служба Azure Monitor для Prometheus хранит свои данные в рабочей области Azure Monitor, которая связана с рабочей областью Grafana, чтобы вы могли анализировать данные с помощью Управляемой Grafana Azure.
Управляемая Grafana Azure Полностью управляемая реализация Grafana, которая является платформой визуализации данных с открытым исходным кодом, обычно используемой для представления данных Prometheus. Для мониторинга Kubernetes и устранения неполадок с полным стеком доступны несколько предопределенных панелей мониторинга Grafana. Если вы не включите управляемый Grafana при создании кластера, см. статью "Ссылка на рабочую область Grafana". Вы можете связать его с рабочей областью Azure Monitor, чтобы получить доступ к метрикам Prometheus для кластера.

Мониторинг метрик плоскости управления AKS (предварительная версия)

В этом разделе показано, как использовать функцию метрик плоскости управления (предварительная версия). Соберите метрики из плоскости управления и просмотрите данные телеметрии в Azure Monitor. Функция метрик уровня управления полностью совместима с Prometheus и Grafana. Эта функция обеспечивает более подробную информацию о доступности и производительности компонентов плоскости управления, таких как сервер API, ETCD, Планировщик, Автомасштабирование и диспетчер контроллеров. Эти метрики можно использовать для повышения общей наблюдаемости и поддержания эффективности работы для кластера AKS.

Предварительные требования и ограничения

Установка расширения aks-preview

Внимание

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

  • Установите или обновите aks-preview расширение Azure CLI с помощью az extension add команды или az extension update команды.

    # Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension
az extension update --name aks-preview

Регистрация флага AzureMonitorMetricsControlPlanePreview

  1. AzureMonitorMetricsControlPlanePreview Зарегистрируйте флаг компонента с помощью az feature register команды.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

    Через несколько минут отобразится состояние Registered (Зарегистрировано).

  2. Проверьте состояние регистрации с помощью az feature show команды.

    az feature show --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

  3. Когда состояние отражает зарегистрировано, обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.

    az provider register --namespace "Microsoft.ContainerService"

Включение метрик плоскости управления в кластере AKS

Можно включить метрики плоскости управления с помощью управляемой службы Azure Monitor для надстройки Prometheus при создании нового кластера или обновлении существующего кластера.

Включите метрики плоскости управления в новом кластере AKS:

Сведения о сборе метрик Prometheus из кластера Kubernetes см. в разделе "Включить Prometheus" и Grafana для кластеров AKS и следуйте инструкциям на вкладке CLI для кластера AKS.

Включение метрик плоскости управления в существующем кластере AKS

  • Если в кластере уже есть надстройка Prometheus, обновите кластер, чтобы убедиться, что он начнет собирать метрики плоскости управления с помощью az aks update команды.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

Примечание.

В отличие от метрик, собранных из узлов кластера, метрики плоскости управления собираются компонентом, который не является частью надстройки ama-metrics . Включение флага компонента и управляемой AzureMonitorMetricsControlPlanePreview надстройки Prometheus гарантирует сбор метрик уровня управления. После включения сбора метрик может потребоваться несколько минут, чтобы данные отображались в рабочей области.

Метрики плоскости управления запросами

Метрики плоскости управления хранятся в рабочей области Azure Monitor в регионе кластера. Метрики можно запрашивать непосредственно из рабочей области или с помощью управляемого экземпляра Grafana Azure, подключенного к рабочей области.

Просмотрите метрики плоскости управления в рабочей области Azure Monitor, выполнив следующие действия.

  1. В портал Azure перейдите к кластеру AKS.

  2. В разделе Мониторинг выберите Аналитические сведения.

    Снимок экрана: рабочая область Azure Monitor.

Примечание.

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

Настройка метрик плоскости управления

AKS включает предварительно настроенный набор метрик для сбора и хранения для каждого компонента. Поля API server и etcd по умолчанию включены. Этот список можно настроить с помощью ama-settings-configmap.

Целевые объекты по умолчанию включают следующие значения:

controlplane-apiserver = true
controlplane-cluster-autoscaler = false
controlplane-kube-scheduler = false
controlplane-kube-controller-manager = false
controlplane-etcd = true

Все конфигурации должны применяться к пространству kube-system имен для любого кластера.

Дополнительные сведения о метриках профиля см. в разделе "Минимальный профиль приема" для minimal-ingestion метрик плоскости управления в управляемом Prometheus.

  • Прием только минимальных метрик из целевых объектов по умолчанию

    При настройке default-targets-metrics-keep-list.minimalIngestionProfile="true"для каждого из целевых объектов по умолчанию приемываются только минимальный набор метрик: controlplane-apiserver и controlplane-etcd.

  • Прием всех метрик из всех целевых объектов

    Соберите все метрики из всех целевых объектов в кластере, выполнив следующие действия:

    1. Скачайте файл ama-metrics-settings-configmap.yaml и переименуйте его configmap-controlplane.yamlв .

    2. Задайте minimalingestionprofile = false.

    3. В разделе default-scrape-settings-enabledубедитесь, что целевые объекты, для которых требуется слом, заданы true. Единственными целевыми объектами, которые можно указать, являются: controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-schedulerи controlplane-kube-controller-managercontrolplane-etcd.

    4. Примените ConfigMap с помощью kubectl apply команды.

      kubectl apply -f configmap-controlplane.yaml

      После применения конфигурации в рабочей области Azure Monitor метрики из указанных целевых объектов отображаются в рабочей области Azure Monitor.

  • Прием нескольких других метрик в дополнение к минимальным метрикам

    Этот minimal ingestion profile параметр помогает уменьшить объем приемов метрик, так как он собирает только метрики, используемые панелями мониторинга по умолчанию, правилами записи по умолчанию и оповещениями по умолчанию. Чтобы настроить этот параметр, выполните следующие действия.

    1. Скачайте файл ama-metrics-settings-configmap и переименуйте его configmap-controlplane.yamlв .

    2. Задайте minimalingestionprofile = true.

    3. В разделе default-scrape-settings-enabledубедитесь, что целевые объекты, для которых требуется слом, заданы true. Единственными целевыми объектами, которые можно указать, являются: controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-schedulerи controlplane-kube-controller-managercontrolplane-etcd.

    4. В разделе default-targets-metrics-keep-listукажите список метрик для true целевых объектов. Например:

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. Примените ConfigMap с помощью kubectl apply команды.

      kubectl apply -f configmap-controlplane.yaml

    После применения конфигурации в рабочей области Azure Monitor метрики из указанных целевых объектов отображаются в рабочей области Azure Monitor.

  • Прием только определенных метрик из некоторых целевых объектов

    1. Скачайте файл ama-metrics-settings-configmap и переименуйте его configmap-controlplane.yamlв .

    2. Задайте minimalingestionprofile = false.

    3. В разделе default-scrape-settings-enabledубедитесь, что целевые объекты, для которых требуется слом, заданы true. Единственными целевыми объектами, которые можно указать здесь: controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-schedulerиcontrolplane-kube-controller-managercontrolplane-etcd .

    4. В разделе default-targets-metrics-keep-listукажите список метрик для true целевых объектов. Например:

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. Примените ConfigMap с помощью kubectl apply команды.

      kubectl apply -f configmap-controlplane.yaml

      После применения конфигурации в рабочей области Azure Monitor метрики из указанных целевых объектов отображаются в рабочей области Azure Monitor.

Устранение неполадок с метриками уровня управления

Убедитесь, что флаг AzureMonitorMetricsControlPlanePreview компонента включен и ama-metrics запущены модули pod.

Примечание.

Методы устранения неполадок для управляемой службы Azure Prometheus не преобразуют здесь напрямую, так как компоненты слом плоскости управления не присутствуют в управляемой надстройке Prometheus.

  • Форматирование ConfigMap

    Убедитесь, что вы используете правильное форматирование в ConfigMap и что поля, в частностиdefault-targets-metrics-keep-listminimal-ingestion-profile, и default-scrape-settings-enabledправильно заполнены их предполагаемыми значениями.

  • Изоляция уровня управления от плоскости данных

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

  • Прием событий

    После применения изменений можно открыть обозреватель метрик на странице обзора Azure Monitor или из раздела "Мониторинг " выбранного кластера и проверить увеличение или уменьшение количества событий, полученных в минуту. Это поможет определить, отсутствует ли определенная метрика или отсутствуют ли все метрики.

  • Определенная метрика не предоставляется

    Существуют случаи, когда метрики документируются, но не предоставляются из целевого объекта и не перенаправляются в рабочую область Azure Monitor. В этом случае необходимо убедиться, что другие метрики перенаправляются в рабочую область.

  • Нет доступа к рабочей области Azure Monitor

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

Отключение метрик плоскости управления в кластере AKS

Метрики плоскости управления можно отключить в любое время, отключив надстройку Prometheus и отменив регистрацию флага AzureMonitorMetricsControlPlanePreview функции.

  1. Удалите надстройку метрик, которая удаляет метрики Prometheus с помощью az aks update команды.

    az aks update --disable-azure-monitor-metrics --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

  2. Отключите удаление метрик плоскости управления в кластере AKS, отменив AzureMonitorMetricsControlPlanePreview регистрацию флага функции с помощью az feature unregister команды.

    az feature unregister "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

Вопросы и ответы

  • Можно ли сломать метрики плоскости управления с помощью локального Prometheus?

    Нет, в настоящее время вы не можете сломать метрики плоскости управления с локальным Prometheus. Локальная среда Prometheus может удалять только один экземпляр в зависимости от подсистемы балансировки нагрузки. Метрики не являются надежными, так как часто несколько реплик метрик уровня управления видны только с помощью управляемого Prometheus

  • Почему агент пользователя недоступен через метрики плоскости управления?

    Метрики плоскости управления в Kubernetes не имеют агента пользователя. Агент пользователя доступен только через журналы плоскости управления, доступные в параметрах диагностики.

Журналы ресурсов Azure Monitor

Журналы ресурсов предоставляют аналитические сведения об операциях, выполненных ресурсом Azure. Журналы создаются автоматически, но их необходимо перенаправить в журналы Azure Monitor, чтобы сохранить или запросить их. Журналы организованы по категориям. Заданное пространство имен может содержать несколько категорий журналов ресурсов.

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

Маршрутизация: рекомендуемая по умолчанию — маршрутизация журналов ресурсов в журналы Azure Monitor, чтобы запросить их с другими данными журнала. Также доступны другие расположения, такие как служба хранилища Azure, Центры событий Azure и некоторые партнеры по мониторингу Майкрософт. Дополнительные сведения см. в журналах ресурсов Azure и назначениях журналов ресурсов.

Подробные сведения о сборе, хранении и маршрутизации журналов ресурсов см. в разделе "Параметры диагностики" в Azure Monitor.

Список всех доступных категорий журналов ресурсов в Azure Monitor см. в статье "Поддерживаемые журналы ресурсов" в Azure Monitor.

Все журналы ресурсов в Azure Monitor имеют одинаковые поля заголовков, а затем поля для конкретной службы. Общая схема показана в разделе Схема журнала ресурсов Azure Monitor.

Доступные категории журналов ресурсов, связанные таблицы Log Analytics и схемы журналов для AKS, см. в Служба Azure Kubernetes справочнике по данным мониторинга.

Плоскость управления AKS или журналы ресурсов

Журналы плоскости управления для кластеров AKS реализуются в виде журналов ресурсов в Azure Monitor. Журналы ресурсов не собираются и хранятся, пока не создадите параметр диагностики для их маршрутизации в одно или несколько расположений. Обычно они отправляются в рабочую область Log Analytics, где хранится большая часть данных для аналитики контейнеров.

Дополнительные сведения о создании параметра диагностики см. в статье "Создание параметров диагностики" с помощью портал Azure, CLI или PowerShell. Создавая параметр диагностики, нужно указать, какие категории журналов должны собираться. Категории для AKS перечислены в справочнике по данным мониторинга AKS.

Внимание

При сборе журналов ресурсов для AKS может быть существенное значение, особенно для журналов аудита kube. Рассмотрим следующие рекомендации, чтобы уменьшить объем собранных данных:

  • Отключите ведение журнала аудита kube, если не требуется.
  • Включите сбор данных от kube-audit-admin, который исключает события аудита типа get и list.
  • Включите журналы, относящиеся к ресурсам, как описано здесь, и настройте AKSAudit таблицу в качестве базовых журналов.

Дополнительные рекомендации и оптимизацию затрат см. в статье "Мониторинг кластеров Kubernetes" с помощью служб Azure и облачных средств для оптимизации затрат и Azure Monitor для дальнейшего сокращения затрат на мониторинг.

AKS поддерживает режим диагностика Azure или режим, зависящий от ресурса, для журналов ресурсов. Этот режим указывает таблицы в рабочей области Log Analytics, в которой отправляются данные. Режим диагностика Azure отправляет все данные в таблицу AzureDiagnostics, а режим для конкретных ресурсов отправляет данные в AKS Audit, AKS Audit Admin и AKS Control Plane, как показано в таблице в журналах ресурсов.

Для AKS рекомендуется использовать режим для конкретного ресурса по следующим причинам:

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

Примечание.

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

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

Пример запросов журнала

Внимание

При выборе журналов из меню кластера AKS log Analytics открывается с областью запроса, заданной для текущего кластера. Это означает, что запросы к журналам будут содержать данные только из этого ресурса. Если вы хотите выполнить запрос, содержащий данные из других кластеров или данных из других служб Azure, выберите "Журналы" в меню Azure Monitor. Подробные сведения см. в статье Область запросов журнала и временной диапазон в Azure Monitor Log Analytics.

Если параметр диагностики для кластера использует режим azure диагностика, журналы ресурсов для AKS хранятся в таблице AzureDiagnostics. Вы можете отличить один журнал от другого по столбцу Категория. Описание каждой категории см. в справочнике по журналам ресурсов AKS.

Description Запрос журнала
Подсчет журналов для каждой категории
(Режим диагностика Azure)		 AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| суммирование count() по категориям
Все журналы сервера API
(Режим диагностика Azure)		 AzureDiagnostics
| Where Category == "kube-apiserver"
Все журналы аудита kube в диапазоне времени
(Режим диагностика Azure)		 let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated между(starttime.). endtime)
| Where Category == "kube-audit"
| событие extend = parse_json(log_s)
| расширение HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| расширение Apiserver = pod_s
| расширение SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
Все журналы аудита
(режим, зависящий от ресурса)		 AKSAudit
Все журналы аудита, за исключением событий аудита получения и списка
(режим, зависящий от ресурса)		 AKSAuditAdmin
Все журналы сервера API
(режим, зависящий от ресурса)		 AKSControlPlane
| Where Category == "kube-apiserver"

Чтобы получить доступ к набору предварительно созданных запросов в рабочей области Log Analytics, ознакомьтесь с интерфейсом запросов Log Analytics и выберите тип ресурсов Kubernetes Services. Список распространенных запросов для аналитики контейнеров см . в разделе "Запросы аналитики контейнеров".

Плоскость данных AKS и журналы Container Insights

Container Insights собирает различные типы данных телеметрии из контейнеров и кластеров Kubernetes, чтобы помочь вам отслеживать, устранять неполадки и получать аналитические сведения о контейнерных приложениях, работающих в кластерах AKS. Список таблиц с подробными описаниями, используемыми службой аналитики контейнеров, представлен в справочнике по таблицам Azure Monitor. Все эти таблицы доступны для запросов журналов.

Параметры оптимизации затрат позволяют настраивать и управлять данными метрик, собранными с помощью агента аналитики контейнеров. Эта функция поддерживает параметры сбора данных для выбора отдельных таблиц, интервалов сбора данных и пространств имен, чтобы исключить сбор данных с помощью правил сбора данных Azure Monitor (DCR). Эти параметры управляют объемом приема и сокращают затраты на мониторинг аналитических сведений о контейнерах. Собранные данные аналитики контейнеров можно настроить с помощью портал Azure, используя следующие параметры. Выбор любых параметров, отличных от всех (по умолчанию), приводит к тому, что аналитика контейнеров становится недоступной.

Группировка Таблицы Примечания.
Все (по умолчанию) Все стандартные таблицы аналитики контейнеров Требуется для включения визуализаций аналитики контейнеров по умолчанию
Производительность Perf, InsightsMetrics
Журналы и события ContainerLog или ContainerLogV2, KubeEvents, KubePodInventory Рекомендуется, если вы включили управляемые метрики Prometheus
Рабочие нагрузки, развертывания и hpAs InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices
Постоянные тома InsightsMetrics, KubePVInventory

Журналы и события группирования записывают журналы из таблиц ContainerLog или ContainerLogV2, KubeEvents, KubePodInventory, но не метрик. Рекомендуемый путь для сбора метрик — включить Управляемые службы Azure Monitor Prometheus для Prometheus из кластера AKS и использовать Azure Managed Grafana для визуализации данных. Дополнительные сведения см. в статье Управление рабочей областью в Azure Monitor.

Схема ContainerLogV2

Azure Monitor Container Insights предоставляет схему для журналов контейнеров, известных как ContainerLogV2, что является рекомендуемой возможностью. Этот формат включает следующие поля для упрощения распространенных запросов для просмотра данных, связанных с кластерами AKS и Kubernetes с поддержкой Azure Arc:

  • ContainerName
  • PodName
  • PodNamespace

Кроме того, эта схема совместима с планом данных "Базовые журналы ", который предлагает низкую стоимость для стандартных журналов аналитики. План данных журнала "Базовый" позволяет сэкономить на стоимости приема и хранения подробных журналов большого объема в рабочей области Log Analytics для отладки, устранения неполадок и аудита. Это не влияет на затраты на аналитику и оповещения. Дополнительные сведения см. в разделе "Управление таблицами" в рабочей области Log Analytics.

ContainerLogV2 — это рекомендуемый подход и является схемой по умолчанию для клиентов, использующих аналитику контейнеров с помощью проверки подлинности управляемых удостоверений с помощью ARM, Bicep, Terraform, Policy и портал Azure. Дополнительные сведения о включении ContainerLogV2 с помощью правила сбора данных кластера (DCR) или ConfigMap см. в разделе "Включить схему ContainerLogV2".

Журнал действий Azure

Журнал действий содержит события уровня подписки, отслеживающие операции для каждого ресурса Azure, как видно извне этого ресурса; например, создание нового ресурса или запуск виртуальной машины.

Коллекция: события журнала действий автоматически создаются и собираются в отдельном хранилище для просмотра в портал Azure.

Маршрутизация. Вы можете отправлять данные журнала действий в журналы Azure Monitor, чтобы их можно было анализировать вместе с другими данными журнала. Также доступны другие расположения, такие как служба хранилища Azure, Центры событий Azure и некоторые партнеры по мониторингу Майкрософт. Дополнительные сведения о маршрутизации журнала действий см. в разделе "Обзор журнала действий Azure".

Просмотр журналов контейнеров Служба Azure Kubernetes (AKS), событий и метрик pod в режиме реального времени

В этом разделе описано, как использовать функцию динамических данных в Container Insights для просмотра журналов контейнеров Служба Azure Kubernetes (AKS), событий и метрик pod в режиме реального времени. Эта функция обеспечивает прямой доступ к kubectl logs -ckubectl get событиям, событиям и kubectl top pods помогает устранять неполадки в режиме реального времени.

Примечание.

AKS использует архитектуры ведения журнала на уровне кластера Kubernetes. Журналы контейнеров находятся внутри /var/log/containers узла. Сведения о доступе к узлу см. в разделе "Подключение к узлам кластера Служба Azure Kubernetes (AKS).

Сведения о настройке функции динамических данных см. в разделе "Настройка динамических данных" в Container Insights. Эта функция напрямую обращается к API Kubernetes. Дополнительные сведения о модели проверки подлинности см. в API Kubernetes.

Просмотр динамических журналов ресурсов AKS

Примечание.

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

  1. В портал Azure перейдите к кластеру AKS.

  2. В разделе ресурсов Kubernetes выберите рабочие нагрузки.

  3. Выберите развертывание, pod, набор реплик, набор состояния, задание или задание Cron, для которого требуется просмотреть журналы, а затем выберите "Динамические журналы".

  4. Выберите ресурс, для которого нужно просмотреть журналы.

    В следующем примере показаны журналы для ресурса Pod :

    Снимок экрана: развертывание динамических журналов.

Просмотр динамических журналов

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

  1. В портал Azure перейдите к кластеру AKS.

  2. В разделе Мониторинг выберите Аналитические сведения.

  3. Выберите вкладку "Кластер", "Узлы", "Контроллеры" или "Контейнеры", а затем выберите объект, для которого нужно просмотреть журналы.

  4. В обзоре ресурса выберите "Динамические журналы".

    Примечание.

    Чтобы просмотреть данные из рабочей области Log Analytics, выберите "Просмотреть журналы" в Log Analytics. Дополнительные сведения о просмотре журналов, событий и метрик см. в статье "Как запрашивать журналы из Container Insights".

    После успешной проверки подлинности, если данные можно получить, он начинает потоковую передачу на вкладку "Динамические журналы". Данные журнала можно просмотреть здесь в непрерывном потоке. На следующем рисунке показаны журналы для ресурса контейнера :

    Снимок экрана, на котором показан параметр представления данных в журналах live logs контейнера.

Просмотр трансляций

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

  1. В портал Azure перейдите к кластеру AKS.

  2. В разделе Мониторинг выберите Аналитические сведения.

  3. Выберите вкладку "Кластер", "Узлы", "Контроллеры" или "Контейнеры", а затем выберите объект, для которого нужно просмотреть события.

  4. На странице обзора ресурсов выберите "Трансляции".

    Примечание.

    Чтобы просмотреть данные из рабочей области Log Analytics, выберите "Просмотреть события" в Log Analytics. Дополнительные сведения о просмотре журналов, событий и метрик см. в статье "Как запрашивать журналы из Container Insights".

    После успешной проверки подлинности, если данные можно получить, он начинает потоковую передачу на вкладку "Трансляции". На следующем рисунке показаны события для ресурса контейнера :

    Снимок экрана, на котором показан параметр представления данных о событиях в режиме реального времени контейнера.

Просмотр метрик

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

  1. В портал Azure перейдите к кластеру AKS.

  2. В разделе Мониторинг выберите Аналитические сведения.

  3. Перейдите на вкладку "Узлы " или "Контроллеры ", а затем выберите объект Pod , для которого нужно просмотреть метрики.

  4. На странице обзора ресурсов выберите "Метрики live".

    Примечание.

    Чтобы просмотреть данные из рабочей области Log Analytics, выберите "Просмотреть события" в Log Analytics. Дополнительные сведения о просмотре журналов, событий и метрик см. в статье "Как запрашивать журналы из Container Insights".

    После успешной проверки подлинности, если данные можно получить, он начинает потоковую передачу на вкладку "Метрики трансляции". На следующем рисунке показаны метрики для ресурса Pod :

    Снимок экрана, на котором показан параметр представления данных в динамическом режиме pod Metrics.

Анализ данных мониторинга

Существует множество средств для анализа данных мониторинга.

Средства Azure Monitor

Azure Monitor поддерживает следующие основные средства:

  • Обозреватель метрик— средство в портал Azure, позволяющее просматривать и анализировать метрики для ресурсов Azure. Дополнительные сведения см. в разделе "Анализ метрик" с помощью обозревателя метрик Azure Monitor.

  • Log Analytics— средство в портал Azure, позволяющее запрашивать и анализировать данные журнала с помощью языка запросов Kusto (KQL). Дополнительные сведения см. в статье Начало работы с запросами журнала в Azure Monitor.

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

Средства, которые позволяют более сложной визуализации, включают:

  • Панели мониторинга, позволяющие объединить различные виды данных в одну область в портал Azure.
  • Книги, настраиваемые отчеты, которые можно создать в портал Azure. Книги могут включать текст, метрики и запросы журналов.
  • Grafana — открытое средство платформы, которое работает на операционных панелях мониторинга. С помощью Grafana можно создавать панели мониторинга, содержащие данные из нескольких источников, отличных от Azure Monitor.
  • Power BI— служба бизнес-аналитики, которая предоставляет интерактивные визуализации в различных источниках данных. Вы можете настроить Power BI на автоматический импорт данных журналов из Azure Monitor, чтобы воспользоваться этими визуализациями.

Средства экспорта Azure Monitor

Вы можете получить данные из Azure Monitor в другие средства с помощью следующих методов:

Сведения о начале работы с REST API для Azure Monitor см . в пошаговом руководстве по REST API мониторинга Azure.

Обзорная страница мониторинга на портале Azure

Вкладка "Мониторинг" на странице "Обзор" для ресурса кластера AKS позволяет быстро просматривать данные мониторинга в портал Azure. Эта вкладка содержит графы с общими метриками для кластера, разделенного пулом узлов. Для дальнейшего анализа данных в обозревателе метрик можно выбрать любой из этих графов.

Вкладка "Мониторинг " также содержит ссылки на Managed Prometheus и Container Insights для кластера. Если вам нужно включить эти средства, их можно включить здесь. Вы также можете увидеть баннер в верхней части экрана, который рекомендует включить другие функции для улучшения мониторинга кластера.

Совет

Вы можете получить доступ к функциям мониторинга для всех кластеров AKS в подписке, выбрав Azure Monitor на домашней странице портал Azure.

Запросы Kusto

Данные мониторинга можно анализировать в хранилище журналов Azure Monitor или Log Analytics с помощью языка запросов Kusto (KQL).

Внимание

При выборе журналов в меню службы на портале Log Analytics откроется область запроса, заданная текущей службой. Эта область означает, что запросы журналов будут включать только данные из этого типа ресурса. Если вы хотите выполнить запрос, содержащий данные из других служб Azure, выберите журналы в меню Azure Monitor . Подробные сведения см. в статье Область запросов журнала и временной диапазон в Azure Monitor Log Analytics.

Список распространенных запросов для любой службы см. в интерфейсе запросов Log Analytics.

видны узлы

Оповещения Azure Monitor заранее уведомляют вас о конкретных условиях, обнаруженных в данных мониторинга. Оповещения позволяют выявлять и устранять проблемы в системе, прежде чем клиенты заметят их. Дополнительные сведения см. в оповещениях Azure Monitor.

Существует множество источников распространенных оповещений для ресурсов Azure. Примеры распространенных оповещений для ресурсов Azure см. в примерах запросов оповещений журнала. Сайт базовых оповещений Azure Monitor (AMBA) предоставляет полуавтомативный метод реализации важных оповещений метрик платформы, панелей мониторинга и рекомендаций. Сайт применяется к постоянно расширяющемуся подмножество служб Azure, включая все службы, которые являются частью целевой зоны Azure (ALZ).

Общая схема оповещений стандартизирует потребление уведомлений об оповещениях Azure Monitor. Дополнительные сведения см. в разделе "Общая схема оповещений".

Типов оповещений

Вы можете получать оповещения о любых источниках данных метрик или журналов на платформе данных Azure Monitor. Существует множество различных типов оповещений в зависимости от служб, которые вы отслеживаете, и данных мониторинга, которые вы собираете. Различные типы оповещений имеют различные преимущества и недостатки. Дополнительные сведения см. в разделе "Выбор правильного типа оповещений мониторинга".

В следующем списке описаны типы оповещений Azure Monitor, которые можно создать:

  • Оповещения метрик оценивают метрики ресурсов через регулярные интервалы. Метрики могут быть метриками платформы, пользовательскими метриками, журналами из Azure Monitor, преобразованными в метрики или метриками Application Insights. Оповещения метрик также могут применять несколько условий и динамические пороговые значения.
  • Оповещения журнала позволяют пользователям использовать запрос Log Analytics для оценки журналов ресурсов на предопределенной частоте.
  • Оповещения журнала действий активируются при возникновении нового события журнала действий, соответствующего определенным условиям. Работоспособность ресурсов оповещения и оповещения о работоспособности служб — это оповещения журнала действий, которые сообщают о работоспособности службы и ресурсов.

Некоторые службы Azure также поддерживают оповещения интеллектуального обнаружения, оповещения Prometheus или рекомендуемые правила генерации оповещений.

Для некоторых служб можно отслеживать масштаб, применяя одно правило генерации оповещений метрик к нескольким ресурсам одного типа, которые существуют в одном регионе Azure. Для каждого отслеживаемого ресурса отправляются отдельные уведомления. Сведения о поддерживаемых службах и облаках Azure см. в статье "Мониторинг нескольких ресурсов с помощью одного правила генерации оповещений".

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

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

  • Знания поставщика ресурсов о важных сигналах и пороговых значениях для мониторинга ресурса.
  • Данные, указывающие клиентам, которые обычно оповещают об этом ресурсе.

Примечание.

Рекомендуемые правила генерации оповещений доступны для следующих вариантов:

  • Виртуальные машины
  • ресурсы Служба Azure Kubernetes (AKS)
  • Рабочие области Log Analytics

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

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

Уровень видны узлы
Уровень кластера KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Уровень узла KubeNodeUnreachable
KubeNodeReadinessFlapping
Уровень pod KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

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

  • Число результатов: подсчитывает количество строк, возвращаемых запросом, и может использоваться для работы с такими событиями, как журналы событий Windows, системный журнал и исключения приложений.
  • Вычисление значения: делает вычисление на основе числового столбца и может использоваться для включения любого количества ресурсов. Примером является процент ЦП.

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

Правила генерации оповещений AKS

В следующей таблице перечислены некоторые предлагаемые правила генерации оповещений для AKS. Эти оповещения являются лишь примерами. Вы можете задать оповещения для любой метрики, записи журнала или записи журнала действий, указанной в справочнике по данным мониторинга Служба Azure Kubernetes.

Условие Description
Процент > использования ЦП 95 Возникает, когда среднее использование ЦП на всех узлах превышает пороговое значение.
Рабочий набор памяти в процентах > от 100 Возникает, когда средний рабочий набор по всем узлам превышает пороговое значение.

Рекомендации Помощника

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

Дополнительные сведения о Помощнике по Azure см. в обзоре Помощника по Azure.

Примечание.

Если вы создаете или запускаете приложение, работающее в службе, аналитика приложений Azure Monitor может предложить дополнительные типы оповещений.

Наблюдаемость сети

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

Если надстройка "Наблюдаемость сети" включена, она собирает и преобразует полезные метрики в формат Prometheus, который можно визуализировать в Grafana. При включении собранные метрики автоматически получаются в управляемой службе Azure Monitor для Prometheus. Панель мониторинга Grafana доступна в репозитории общедоступной панели мониторинга Grafana для визуализации метрик наблюдаемости сети, собранных Prometheus. Дополнительные сведения см. в разделе "Настройка наблюдения за сетями" для получения подробных инструкций.

Связанный контент