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

  • Статья

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

Сообщения об известных ошибках

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

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

Если данные по-прежнему не отображаются, проверка, если для рабочей области Log Analytics настроенаdisableLocalAuth = true. Если да, обновите его обратно disableLocalAuth = false.

az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"

az resource update --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]" --api-version "2021-06-01" --set properties.features.disableLocalAuth=False
Сообщение об ошибке "Ошибка извлечения данных" Хотя кластер AKS настраивается для мониторинга работоспособности и производительности, подключение устанавливается между кластером и рабочей областью Log Analytics. Рабочая область Log Analytics используется для хранения всех данных мониторинга для кластера. Эта ошибка может возникать при удалении рабочей области Log Analytics. Проверьте, удалена ли рабочая область. Если это было, повторное отслеживание кластера с помощью аналитики контейнеров. Затем укажите существующую рабочую область или создайте новую. Для повторной активации отключите мониторинг кластера и снова включите аналитику контейнеров.
"Ошибка извлечения данных" после добавления аналитики контейнеров с помощью az aks cli При включении мониторинга с помощью az aks cliаналитики контейнеров может быть неправильно развернута. Проверьте, развернуто ли решение. Чтобы проверить, перейдите в рабочую область Log Analytics и убедитесь, что решение доступно, выбрав устаревшие решения на панели слева. Чтобы устранить эту проблему, повторно разверните решение. Следуйте инструкциям в разделе "Включить аналитику контейнеров".
Сообщение об ошибке "Отсутствует регистрация подписки" Если появится сообщение об ошибке "Отсутствует регистрация подписки для Microsoft.OperationsManagement", ее можно устранить, зарегистрируя поставщик ресурсов Microsoft.OperationsManagement в подписке, в которой определена рабочая область. Инструкции см. в разделе "Устранение ошибок для регистрации поставщика ресурсов".
Сообщение об ошибке "URL-адрес ответа, указанный в запросе, не соответствует URL-адресам ответа, настроенным для приложения: "<идентификатор> приложения". Это сообщение об ошибке может появиться при включении динамических журналов. Сведения о решении см. в разделе "Просмотр данных контейнера в режиме реального времени" с помощью аналитики контейнеров.

Чтобы помочь диагностировать эту проблему, мы предоставляем сценарий устранения неполадок.

Ошибка авторизации при подключении или обновлении

При включении аналитики контейнеров или обновлении кластера для поддержки сбора метрик может возникнуть ошибка, например "Клиент <user's Identity> с идентификатором <user's objectId> объекта не имеет авторизации для выполнения действий Microsoft.Authorization/roleAssignments/write через область".

В процессе подключения или обновления была предпринята попытка назначения роли издателя метрик мониторинга в ресурсе кластера. Пользователь, инициирующий процесс включения или обновления аналитики для контейнеров для поддержки коллекции метрик, должен иметь доступ к разрешению Microsoft.Authorization/roleAssignments/write в области ресурсов кластера AKS. Доступ к этому разрешению предоставляется только членам встроенных ролей владельца и администратора доступа пользователей. Если политикам безопасности требуется назначить разрешения на уровне детализации, ознакомьтесь с настраиваемыми ролями Azure и назначьте им разрешения.

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

Аналитика для контейнеров включена, но не сообщает никакие сведения

Чтобы диагностировать проблему, если не удается просмотреть сведения о состоянии или не возвращаются результаты из запроса журнала:

  1. Проверьте состояние агента, выполнив следующую команду:

    kubectl get ds ama-logs --namespace=kube-system

    Количество модулей pod должно быть равно количеству узлов Linux в кластере. Результат должен выглядеть, как показано в примере ниже, что означает успешное выполнение развертывания:

    User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs   2         2         2         2            2           <none>           1d

  2. Если у вас есть узлы Windows Server, проверка состояние агента, выполнив следующую команду:

    kubectl get ds ama-logs-windows --namespace=kube-system

    Число модулей pod должно быть равно количеству узлов Windows в кластере. Результат должен выглядеть, как показано в примере ниже, что означает успешное выполнение развертывания:

    User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs-windows           2         2         2         2            2           <none>       1d

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

    kubectl get deployment ama-logs-rs --namespace=kube-system

    Результат должен выглядеть, как показано в примере ниже, что означает успешное выполнение развертывания:

    User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

  4. Проверьте состояние модуля pod, чтобы убедиться, что она выполняется с помощью команды kubectl get pods --namespace=kube-system.

    Выходные данные должны выглядеть примерно так, как состояние Running ama-logs:

    User@aksuser:~$ kubectl get pods --namespace=kube-system
NAME                                READY     STATUS    RESTARTS   AGE
aks-ssh-139866255-5n7k5             1/1       Running   0          8d
azure-vote-back-4149398501-7skz0    1/1       Running   0          22d
azure-vote-front-3826909965-30n62   1/1       Running   0          22d
ama-logs-484hw                      1/1       Running   0          1d
ama-logs-fkq7g                      1/1       Running   0          1d
ama-logs-windows-6drwq              1/1       Running   0          1d

  5. Если модули pod находятся в состоянии выполнения, но данные в Log Analytics или данные не отправляются только в течение определенной части дня, это может быть признаком того, что ежедневное ограничение выполнено. Когда это ограничение выполняется каждый день, данные перестают прием в рабочую область Log Analytics и сбрасываются во время сброса. Дополнительные сведения см. в статье Log Analytics Daily Cap.

Модули Pod Pod для агента аналитики контейнеров не запланированы в кластере, отличном от AKS

Модули pod Агента аналитики аналитики контейнеров имеют зависимость от следующих селекторов узлов на рабочих узлах (или агента) для планирования:

nodeSelector:
  beta.kubernetes.io/os: Linux
  kubernetes.io/role: agent

Если рабочие узлы не подключены, модули pod agent ReplicaSet не будут запланированы. Инструкции по присоединению метки см. в разделе Kubernetes, назначаемого селекторами меток.

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

Модули pod агента аналитики контейнеров используют конечную точку cAdvisor на агенте узла для сбора метрик производительности. Убедитесь, что контейнеризованный агент на узле настроен на разрешение cAdvisor secure port: 10250 или cAdvisor unsecure port: 10255 открытие всех узлов в кластере для сбора метрик производительности. Дополнительные сведения см. в предварительных требованиях для гибридных кластеров Kubernetes.

Кластеры, отличные от AKS, не отображаются в аналитике контейнеров

Для просмотра кластера, отличного от AKS, в службе "Аналитика контейнеров" требуется доступ на чтение в рабочей области Log Analytics, которая поддерживает эту информацию и контейнер ресурсов решения аналитики контейнеров Аналитика (рабочая область).

Метрики не собираются

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

    az role assignment list --assignee "SP/UserassignedMSI for Azure Monitor Agent" --scope "/subscriptions/<subid>/resourcegroups/<RG>/providers/Microsoft.ContainerService/managedClusters/<clustername>" --role "Monitoring Metrics Publisher"

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

  2. Для кластеров с включенным удостоверением pod Microsoft Entra и с помощью MSI:

    • Убедитесь, что необходимые метки kubernetes.azure.com/managedby: aks присутствует в модулях pod агента Azure Monitor, выполнив следующую команду:

      kubectl get pods --show-labels -n kube-system | grep ama-logs

    • Убедитесь, что исключения включены, если удостоверение pod включено с помощью одного из поддерживаемых методов.https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity

      Для этого выполните следующую команду:

      kubectl get AzurePodIdentityException -A -o yaml

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

      apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: mic-exception
namespace: default
spec:
podLabels:
app: mic
component: mic
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: aks-addon-exception
namespace: kube-system
spec:
podLabels:
kubernetes.azure.com/managedby: aks

Установка расширения контейнеров Azure Monitor завершается сбоем в кластере Kubernetes с поддержкой Azure Arc.

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

Решение этой проблемы заключается в очистке существующих ресурсов агента аналитики контейнеров, если он существует. Затем включите расширение контейнеров Azure Monitor.

Для кластеров, отличных от AKS

  1. В кластере K8s, подключенном к Azure Arc, выполните следующую команду, чтобы проверить, существует ли azmon-containers-release-1 выпуск диаграммы Helm.

    helm list -A

  2. Если выходные данные предыдущей команды указывают на наличие azmon-containers-release-1 , удалите выпуск диаграммы Helm:

    helm del azmon-containers-release-1

Для кластеров AKS

  1. Выполните следующие команды и найдите профиль надстройки агента Azure Monitor, чтобы проверить, включена ли надстройка мониторинга AKS:

    az  account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>

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

    az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>

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

Получение повторяющихся оповещений

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

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

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

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

  • AKS без авторизации на основе ролей Kubernetes (RBAC)
  • AKS включен с помощью единого входа на основе Microsoft Entra SAML
  • AKS со включенной авторизацией Kubernetes RBAC;
  • AKS с привязкой к роли кластера clusterMonitoringUser
  • Кластеры Kubernetes с поддержкой Azure Arc

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

Значения свойств Image и Name не отображаются при запросе таблицы ContainerLog

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

Вариант 1

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

Измените запросы, чтобы включить Image и ImageTag свойства из таблицы, присоединившись к ContainerID свойствуContainerInventory. Можно включить Name свойство (как ранее появилось в ContainerLog таблице) из KubepodInventory поля таблицы ContainerName , присоединившись к свойству ContainerID . Этот вариант является рекомендуемым.

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

//Let's say we're querying an hour's worth of logs
let startTime = ago(1h);
let endTime = now();
//Below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//Below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//Now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//Now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were rewritten
//Outer left is safer so you don't lose logs even if we can't find container metadata for loglines (due to latency, time skew between data types, etc.)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
  ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

Вариант 2

Повторное создание коллекции для этих свойств для каждой строки журнала контейнера.

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

Примечание.

Не рекомендуется использовать второй вариант для крупных кластеров с более чем 50 узлами. Он создает вызовы сервера API из каждого узла в кластере для выполнения этого обогащения. Этот вариант также увеличивает размер данных для каждой собранной строки журнала.

Не удается обновить кластер после подключения

Ниже приведен сценарий. Вы включили аналитику контейнеров для кластера Служба Azure Kubernetes. Затем вы удалили рабочую область Log Analytics, где кластер отправлял свои данные. Теперь, когда вы пытаетесь обновить кластер, он завершается ошибкой. Чтобы обойти эту проблему, необходимо отключить мониторинг, а затем повторно создать ее, ссылаясь на другую действительную рабочую область в подписке. Тогда повторная попытка обновить кластер должна выполняться и завершаться успешно.

Не собирать журналы в кластере Azure Stack HCI

Если вы зарегистрировали кластер или настроили Аналитика HCI до ноября 2023 года, функции, использующие агент Azure Monitor в HCI, такие как Arc для серверов Аналитика, виртуальные машины Аналитика, контейнер Аналитика, Defender для облака или Microsoft Sentinel, могут не собирать журналы и данные событий должным образом. Сведения о перенастройке агента и HCI см. в разделе "Восстановление агента AMA" для HCI, чтобы выполнить перенастройку агента и HCI Аналитика.

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

Если мониторинг включен для записи метрик работоспособности для узлов и модулей pod кластера AKS, эти метрики работоспособности доступны в портал Azure. Сведения об использовании аналитики для контейнеров см. в руководстве по просмотру данных работоспособности Службы Azure Kubernetes.