Мониторинг кластеров Kubernetes с помощью служб Azure и облачных собственных средств

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

Внимание

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

Слои и роли среды Kubernetes

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

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

Роли	Description
Разработчик	Разработка и обслуживание приложения, работающего в кластере. Отвечает за конкретный трафик приложения, включая производительность приложения и сбои. Обеспечивает надежность приложения в соответствии с соглашениями об уровне обслуживания.
Инженер платформы	Отвечает за кластер Kubernetes. Подготавливает и поддерживает платформу, используемую разработчиком.
Сетевой инженер	Отвечает за трафик между рабочими нагрузками и любыми входящего и исходящего трафика в кластере. Анализирует сетевой трафик и выполняет анализ угроз.

Выбор средств мониторинга

Azure предоставляет полный набор служб на основе Azure Monitor для мониторинга работоспособности и производительности различных уровней инфраструктуры Kubernetes и приложений, зависящих от него. Эти службы работают вместе друг с другом, чтобы обеспечить полное решение для мониторинга и рекомендуется использовать как для AKS, так и для кластеров Kubernetes, работающих в других облаках. Возможно, у вас есть инвестиции в облачные собственные технологии, поддерживаемые Cloud Native Computing Foundation, в этом случае вы можете интегрировать средства Azure в существующую среду.

Выбор средств для развертывания и их конфигурации зависит от требований конкретной среды. Например, вы можете использовать управляемые предложения в Azure для Prometheus и Grafana или использовать существующую установку этих средств с кластерами Kubernetes в Azure. Ваша организация также может использовать альтернативные средства для сбора и анализа журналов Kubernetes, таких как Splunk или Datadog.

Внимание

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

Сетевой инженер

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

Службы Azure для сетевого администратора

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

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

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

Уровень монитора 1 — сеть

Ниже приведены распространенные сценарии мониторинга сети.

• Создайте журналы потоков для регистрации сведений о IP-трафике, проходящих через группы безопасности сети, используемые кластером, а затем используйте аналитику трафика для анализа и предоставления аналитических сведений об этих данных. Скорее всего, вы будете использовать ту же рабочую область Log Analytics для аналитики трафика, которую вы используете для аналитики контейнеров и журналов плоскости управления.
• С помощью аналитики трафика можно определить, передается ли какой-либо трафик из непредвиденных портов, используемых кластером, а также, если трафик передается по общедоступным IP-адресам, которые не должны предоставляться. Используйте эти сведения для определения необходимости изменения правил сети.
• Для кластеров AKS используйте надстройку "Наблюдаемость сети" для AKS (предварительная версия) для мониторинга и наблюдения за доступом между службами в кластере (трафик на востоке запада).

Инженер платформы

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

Крупные организации также могут иметь архитектор флота, который аналогичен инженеру платформы, но отвечает за несколько кластеров. Они нуждаются в видимости во всей среде и должны выполнять административные задачи в масштабе. Рекомендации по масштабированию включены в приведенные ниже рекомендации. Дополнительные сведения о создании ресурса Fleet для нескольких кластеров и сценариев масштабирования см. в статье "Что такое Диспетчер флота Azure Kubernetes (предварительная версия)".

Службы Azure для инженера платформы

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

Служба	Description
Аналитика контейнеров	Служба Azure для AKS и кластеров Kubernetes с поддержкой Azure Arc, использующих контейнерную версию агента Azure Monitor для сбора журналов stdout/stderr, метрик производительности и событий Kubernetes из каждого узла в кластере. Он также собирает метрики из плоскости управления Kubernetes и сохраняет их в рабочей области. Данные можно просмотреть в портал Azure или запросить с помощью Log Analytics.
Управляемая служба Azure Monitor для Prometheus	Prometheus — это облачное решение метрик из Cloud Native Compute Foundation и наиболее распространенное средство, используемое для сбора и анализа данных метрик из кластеров Kubernetes. Управляемая служба Azure Monitor для Prometheus — это полностью управляемое решение, совместимое с языком запросов Prometheus (PromQL) и оповещениями Prometheus и интегрируется с Управляемым Grafana Azure для визуализации. Эта служба поддерживает инвестиции в средства открытый код без сложности управления собственной средой Prometheus.
Kubernetes с поддержкой Azure Arc	Позволяет подключаться к кластерам Kubernetes, работающим в других облаках, чтобы управлять и настраивать их в Azure. С установленным агентом Arc вы можете отслеживать AKS и гибридные кластеры вместе с помощью одинаковых методов и средств, включая аналитику контейнеров и Prometheus.
Управляемая Grafana Azure	Полностью управляемая реализация Grafana, которая является платформой визуализации данных с открытым исходным кодом, обычно используемой для представления Prometheus и других данных. Для мониторинга Kubernetes и устранения неполадок с полным стеком доступны несколько предопределенных панелей мониторинга Grafana.

Настройка мониторинга для инженера платформы

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

Включение очистки метрик Prometheus

Внимание

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

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

• Выберите параметр Включить метрики Prometheus при создании кластера AKS.
• Выберите параметр Включить метрики Prometheus при включении аналитики контейнеров в существующем кластере AKS или кластере Kubernetes с поддержкой Azure Arc.
• Включите существующий кластер AKS или кластер Kubernetes с поддержкой Arc (предварительная версия).

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

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

Включение Grafana для анализа данных Prometheus

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

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

Включение Аналитика контейнера для сбора журналов

При включении Аналитика контейнеров для кластера Kubernetes он развертывает контейнерную версию агента Azure Monitor, которая отправляет данные в рабочую область Log Analytics в Azure Monitor. Аналитика контейнеров собирает данные о stdout/stderr, журналах инфраструктуры и производительности. Все данные журнала хранятся в рабочей области Log Analytics, где их можно анализировать с помощью язык запросов Kusto (KQL).

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

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

• Аналитика контейнеров собирает многие из одинаковых значений метрик, что и Prometheus. Вы можете отключить коллекцию этих метрик, настроив аналитику контейнеров только для сбора журналов и событий , как описано в разделе "Включение параметров оптимизации затрат в аналитике контейнеров". Эта конфигурация отключает возможности аналитики контейнеров в портал Azure, но вы можете использовать Grafana для визуализации метрик Prometheus и Log Analytics для анализа данных журнала, собранных аналитикой контейнеров.
• Уменьшите затраты на прием данных аналитики контейнеров, уменьшая объем собранных данных.
• Чтобы улучшить взаимодействие с запросами с данными, собранными аналитикой контейнеров и сократить затраты на сбор, включите схему ContainerLogV2 для каждого кластера. Если вы используете только журналы для случайного устранения неполадок, попробуйте настроить эту таблицу как базовые журналы.

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

Сбор журналов плоскости управления для кластеров AKS

Журналы компонентов уровня управления AKS реализуются в Azure в виде журналов ресурсов. Контейнер Аналитика не использует эти журналы, поэтому необходимо создать собственные запросы журналов для просмотра и анализа. Дополнительные сведения о структуре журналов и запросах см. в статье "Как запрашивать журналы из контейнеров Аналитика".

Создайте параметр диагностики для каждого кластера AKS для отправки журналов ресурсов в рабочую область Log Analytics. Используйте Политика Azure для обеспечения согласованной конфигурации в нескольких кластерах.

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

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

Категория	Включить?	Назначение
kube-apiserver	Включить	Рабочая область Log Analytics
kube-audit	Включить	хранилище Azure. Позволяет свести к минимуму затраты, сохраняя при этом журналы аудита на случай, если они потребуются аудитору.
kube-audit-admin	Включить	Рабочая область Log Analytics
kube-controller-manager	Включить	Рабочая область Log Analytics
kube-scheduler	Отключить
cluster-autoscaler	Включите, если включено автомасштабирование	Рабочая область Log Analytics
guard	Включить, включен ли идентификатор Microsoft Entra	Рабочая область Log Analytics
AllMetrics	Отключить, так как метрики собираются в Управляемом Prometheus	Рабочая область Log Analytics

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

Сбор журнала действий для кластеров AKS

Изменения конфигурации кластеров AKS хранятся в журнале действий. Создайте параметр диагностики для отправки этих данных в рабочую область Log Analytics для анализа с другими данными мониторинга. Эта коллекция данных не стоит, и вы можете анализировать или оповещать данные с помощью Log Analytics.

Мониторинг уровня 2. Компоненты уровня кластера

Уровень кластера включает следующие компоненты:

Компонент	Требования к мониторингу
Узел	Изучите состояние готовности и производительность ЦП, памяти, диска и IP-адреса для каждого узла и заранее отслеживайте тенденции их использования перед развертыванием любых рабочих нагрузок.

Ниже приведены распространенные сценарии мониторинга компонентов уровня кластера.

Аналитика контейнеров

• Используйте представление кластера для просмотра производительности узлов в кластере, включая использование ЦП и памяти.
• Используйте представление "Узлы", чтобы просмотреть работоспособность каждого узла и работоспособность и производительность модулей pod, работающих на них. Дополнительные сведения об анализе работоспособности и производительности узла см. в статье "Мониторинг производительности кластера Kubernetes с помощью контейнеров Аналитика".
• В разделе "Отчеты" используйте книги мониторинга узлов для анализа емкости диска, операций ввода-вывода диска и использования GPU. Дополнительные сведения об этих книгах см . в книгах мониторинга узлов.
• В разделе "Мониторинг" выберите книги, а затем — использование IP-адресов подсети, чтобы просмотреть выделение и назначение IP-адресов на каждом узле для выбранного диапазона времени.

Панели мониторинга Grafana

• Используйте предварительно созданную панель мониторинга в Управляемой Grafana для Kubelet, чтобы увидеть работоспособность и производительность каждого из них.
• Используйте панели мониторинга Grafana со значениями метрик Prometheus, связанными с диском, например node_disk_io_time_seconds_total и windows_logical_disk_free_bytes для мониторинга подключенного хранилища.
• Несколько панелей мониторинга Kubernetes доступны для визуализации производительности и работоспособности узлов на основе данных, хранящихся в Prometheus.

Служба Log Analytics

• Выберите категорию "Контейнеры" в диалоговом окне запросов для рабочей области Log Analytics, чтобы получить предварительно созданные запросы журналов для кластера, включая запрос журнала инвентаризации изображений, который извлекает данные из таблицы ContainerImageInventory, заполненной аналитикой контейнеров.

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

• Для сценариев устранения неполадок может потребоваться доступ к узлам непосредственно для обслуживания или немедленной коллекции журналов. В целях безопасности узлы AKS не предоставляются в Интернете, но вы можете использовать kubectl debug команду для SSH для узлов AKS. Дополнительные сведения об этом процессе см. в Подключение с SSH для Служба Azure Kubernetes узлов кластера AKS для обслуживания или устранения неполадок.

Анализ затрат

• Настройте OpenCost, который является проектом песочницы с открытым исходным кодом, нейтральным поставщиком CNCF для понимания затрат Kubernetes, для поддержки анализа затрат на кластер. Он экспортирует подробные данные о затратах в хранилище Azure.
• Используйте данные из OpenCost для разбивки относительного использования кластера различными командами в организации, чтобы можно было выделить затраты между ними.
• Используйте данные из OpenCost, чтобы убедиться, что кластер использует полную емкость своих узлов путем плотной упаковки рабочих нагрузок, используя меньше больших узлов в отличие от множества небольших узлов.

Уровень монитора 3. Компоненты Управляемого Kubernetes

Управляемый уровень Kubernetes включает следующие компоненты:

Компонент	Наблюдение
Сервер API	Отслеживайте состояние сервера API и определите любое увеличение нагрузки запроса и узкие места, если служба отключена.
kubelet	Отслеживайте Kubelet, чтобы помочь устранить неполадки управления pod, модули pod не запускаются, узлы не готовы или модули pod, которые будут убиты.

Ниже приведены распространенные сценарии мониторинга управляемых компонентов Kubernetes.

Аналитика контейнеров

• В разделе "Мониторинг" выберите метрики для просмотра счетчика "Запросы на полет".
• В разделе "Отчеты" используйте книгу Kubelet для просмотра работоспособности и производительности каждого kubelet . Дополнительные сведения об этих книгах см . в книгах мониторинга ресурсов.

Grafana

• Используйте предварительно созданную панель мониторинга в Управляемой Grafana для Kubelet, чтобы увидеть работоспособность и производительность каждого kubelet.
• Используйте панель мониторинга, например сервер API Kubernetes, для полного представления производительности сервера API. Здесь можно получить такие значения, как задержка запросов и время обработки рабочих очередей.

Служба Log Analytics

• Используйте запросы журналов с журналами ресурсов для анализа журналов уровня управления, созданных компонентами AKS.

• Все действия конфигурации для AKS регистрируются в журнале действий. При отправке журнала действий в рабочую область Log Analytics его можно проанализировать с помощью Log Analytics. Например, следующий пример запроса можно использовать для возврата записей, определяющих успешное обновление во всех кластерах AKS.

  AzureActivity
  | where CategoryValue == "Administrative"
  | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
  | extend properties=parse_json(Properties_d) 
  | where properties.message == "Upgrade Succeeded"
  | order by TimeGenerated desc
  

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

• В сценариях устранения неполадок можно воспользоваться журналами kubelet, выполнив для доступа к ним процесс, описанный в статье Получение журналов kubelet из узлов кластера Службы Azure Kubernetes (AKS).

Мониторинг объектов и рабочих нагрузок Kubernetes уровня 4

Уровень объектов и рабочих нагрузок Kubernetes включает следующие компоненты:

Компонент	Требования к мониторингу
Развертывания	Отслеживайте фактическое состояние развертывания в сравнении с требуемым, а также состояние модулей Pod, которые на них выполняются, и использование ресурсов этих модулей.
Объекты pod	Отслеживайте состояние и использование ресурсов модулей Pod, работающих в кластере AKS, в том числе их ЦП и памяти.
Контейнеры	Мониторинг использования ресурсов, включая ЦП и память, контейнеров, работающих в кластере AKS.

Ниже приведены распространенные сценарии мониторинга объектов и рабочих нагрузок Kubernetes.

Аналитика контейнеров

• Используйте представления узлов и контроллеров для просмотра работоспособности и производительности модулей pod, выполняемых на них, и детализации до работоспособности и производительности своих контейнеров.
• Используйте представление "Контейнеры", чтобы просмотреть работоспособность и производительность контейнеров. Дополнительные сведения об анализе работоспособности и производительности контейнера см. в статье "Мониторинг производительности кластера Kubernetes с помощью контейнеров Аналитика".
• В разделе "Отчеты" используйте книгу "Развертывания" для просмотра метрик развертывания. Дополнительные сведения см. в разделе "Метрики развертывания и HPA" с помощью Аналитика контейнеров.

Панели мониторинга Grafana

• Используйте предварительно созданные панели мониторинга в Управляемой Grafana для узлов и модулей Pod, чтобы просмотреть их работоспособность и производительность.
• Несколько панелей мониторинга Kubernetes доступны для визуализации производительности и работоспособности узлов на основе данных, хранящихся в Prometheus.

Динамические данные

• В сценариях устранения неполадок контейнер Аналитика предоставляет доступ к динамическим журналам контейнеров AKS (stdout/stderror), событиям и метрикам pod. Дополнительные сведения об этой функции см. в статье "Просмотр журналов Kubernetes", событий и метрик pod в режиме реального времени.

Оповещения для инженера платформы

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

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

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

Тип оповещения	Описание
Оповещения Prometheus	Оповещения Prometheus записываются на языке запросов Prometheus (Prom QL) и применяются к метрикам Prometheus, хранящимся в управляемых службах Azure Monitor для Prometheus. Рекомендуемые оповещения уже включают наиболее распространенные оповещения Prometheus, и при необходимости можно создавать дополнительные правила генерации оповещений.
Правила генерации оповещений метрик	Правила генерации оповещений метрик используют те же значения метрик, что и обозреватель метрик. На самом деле можно создать правило генерации оповещений непосредственно из обозревателя метрик с данными, которые вы сейчас анализируете. Правила генерации оповещений метрик могут быть полезны для оповещения о производительности AKS с помощью любых значений в эталонных метриках данных AKS.
Правила генерации оповещений поиска по журналам	Используйте правила генерации оповещений поиска по журналам, чтобы создать оповещение из результатов запроса журнала. Дополнительные сведения см. в статье "Создание оповещений поиска по журналам из Аналитика контейнеров" и "Как запрашивать журналы из контейнеров Аналитика".

Рекомендуемые оповещения

Начните с набора рекомендуемых оповещений Prometheus из правил генерации оповещений метрик в аналитике контейнеров (предварительная версия), которые включают наиболее распространенные условия генерации оповещений для кластера Kubernetes. Вы можете добавить дополнительные правила генерации оповещений позже при определении дополнительных условий генерации оповещений.

разработчик.

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

Службы Azure для разработчика

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

Служба	Description
Application Insights.	Функция Azure Monitor, которая обеспечивает мониторинг производительности приложений (APM) для мониторинга приложений, работающих в кластере Kubernetes, от разработки, тестирования и рабочей среды. Быстрое выявление и устранение проблем с задержкой и надежностью с помощью распределенных трассировок. Поддерживает OpenTelemetry для инструментирования, нейтрального от поставщика.

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

Уровень монитора 5 . Приложение

Ниже приведены распространенные сценарии мониторинга приложения.

Производительность приложения

• Используйте представление производительности в Application Insights для просмотра производительности различных операций в приложении.
• Используйте Profiler для записи и просмотра трассировок производительности для приложения.
• Используйте карту приложений для просмотра зависимостей между компонентами приложения и выявления узких мест.
• Включите распределенную трассировку, которая предоставляет профилировщик производительности, который работает как стеки вызовов для архитектур облачных и микрослужб, чтобы повысить наблюдаемость взаимодействия между службами.

Ошибки приложений

• Используйте вкладку "Сбои" Application Insights для просмотра количества неудачных запросов и наиболее распространенных исключений.
• Убедитесь, что оповещения об аномалиях сбоя, идентифицированных с помощью интеллектуального обнаружения , настроены правильно.

Мониторинг работоспособности

• Создайте тест доступности в Application Insights, чтобы создать повторяющийся тест для мониторинга доступности и реагирования приложения.
• Используйте отчет об уровне обслуживания для вычисления и отчета об уровне обслуживания для веб-тестов.
• Используйте заметки , чтобы определить, когда развернута новая сборка, чтобы визуально проверить любые изменения производительности после обновления.

Журналы приложений

• Аналитика контейнеров отправляет журналы stdout/stderr в рабочую область Log Analytics. Сведения о разных журналах и службах Kubernetes см. в журналах ресурсов для списка таблиц, в которые отправляются все.

Сетка служб

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

См. также

• Дополнительные сведения о мониторинге Служба Azure Kubernetes (AKS) см. в статье "Мониторинг AKS".