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

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

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

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

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

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

При включении аналитики контейнеров или обновлении кластера для поддержки сбора метрик может возникнуть ошибка, например "Клиент <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.

6. Если аналитика Containter включена с помощью Terraform и msi_auth_for_monitoring_enabled задана для trueэтого параметра, убедитесь, что ресурсы DCR и DCRA также развертываются для включения сбора журналов. Подробные инструкции см. в разделе "Включение аналитики контейнеров".

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

Модули 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, которая поддерживает эту информацию и ресурс решения аналитики контейнеров ContainerInsights (рабочая область).

Не осуществляется сбор данных метрик

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
     

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

Ошибка "Манифесты содержат ресурс, который уже существует" указывает, что ресурсы агента аналитики контейнеров уже существуют в кластере 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 (предварительная версия).

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

Служба Container Insights исторически позволяла пользователям получать доступ к портал 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 на карте конфигурации агента, как описано в параметрах конфигурации сбора данных.

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

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

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

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

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

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