Устранение неполадок со сбором данных журналов контейнеров в Azure Monitor

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

Создаются повторяющиеся оповещения

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

Разрешения кластера

Если у вас нет необходимых разрешений для кластера, может появиться сообщение об ошибке. You do not have the right cluster permissions which will restrict your access to Container Insights features. Please reach out to your cluster admin to get the right permission.

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

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

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

Дополнительные сведения о назначении ролей см. в разделе «Назначение разрешений роли пользователю или группе» для AKS, а чтобы узнать больше о назначениях ролей, см. «Варианты доступа и удостоверений для Azure Kubernetes Service (AKS)».

Проблемы с подключением и обновлением

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

Отсутствует регистрация подписки

Если вы видите ошибку Missing Subscription registration, зарегистрируйте поставщика ресурсов Microsoft.OperationsManagement в подписке рабочей области Log Analytics. См. раздел "Устранение ошибок для регистрации поставщика ресурсов".

Ошибка авторизации

При включении аналитики контейнеров или обновлении кластера может возникнуть ошибка, например The client <user's identity> with object id <user's objectId> does not have authorization to perform action Microsoft.Authorization/roleAssignments/write over scope.

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

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

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

Установка расширения контейнеров Azure Monitor завершается сбоем

Ошибка manifests contain a resource that already exists указывает, что ресурсы агента аналитики контейнеров уже существуют в кластере Kubernetes с поддержкой Azure Arc, что означает, что агент аналитики контейнеров уже установлен. Чтобы устранить эту проблему, удалите существующие ресурсы агента аналитики контейнеров и включите расширение контейнеров Azure Monitor.

Кластеры AKS

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

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

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

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

Кластеры, отличные от AKS

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

helm list  -A

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

helm del azmon-containers-release-1

Отсутствующие данные

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

Ошибка при получении данных

Сообщение Error retrieving data об ошибке может возникать, если рабочая область Log Analytics, в которой кластер отправлял свои данные, была удалена. Если это так, отключите мониторинг кластера и снова включите аналитику контейнеров с помощью другой рабочей области.

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

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

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

Если disableLocalAuth = true, выполните следующую команду.

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 |

Ежедневное ограничение выполнено

Если достигнуто ежедневное ограничение для рабочей области Log Analytics, она перестанет собирать данные до времени сброса. См. ежедневный лимит Log Analytics.

Развертывание DCR не выполнено с помощью Terraform

Если служба "Аналитика контейнеров" включена с помощью Terraform и msi_auth_for_monitoring_enabled настроена на значение true, необходимо удостовериться, что ресурсы DCR и DCRA также развернуты для обеспечения сбора журналов. См. раздел "Включить аналитику контейнеров" с помощью Terraform.

Аналитика контейнеров не сообщает никаких сведений

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

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

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
```
Если у вас есть узлы 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
```
Проверьте состояние развертывания с помощью следующей команды:

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
```

Проверьте состояние 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

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

Не осуществляется сбор метрик

Убедитесь, что назначение роли издателя метрик мониторинга существует с помощью следующей команды 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.
Для кластеров с включенной идентификацией Microsoft Entra pod и использованием 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

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

Значения изображения и имени не заполнены в таблице ContainerLog

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

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

В следующем примере запроса показано, как получить соединения для получения этих значений.

//Set the time window for the query
let startTime = ago(1h);
let endTime = now();
//
//Get the latest Image & ImageTag for every containerID
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;
//
//Get the latest Name for every containerID
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//
//Join the above to get a jointed table that has name, image & imagetag. Outer left is used in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//
//Join ContainerLog table with the jointed table above, project-away redundant fields/columns, and rename columns that were rewritten. Outer left is used so logs aren't lost even if no container metadata for loglines is found.
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

Предупреждение

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

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

Журналы, не собираемые в локальном кластере Azure

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

Отсутствующие данные в больших кластерах

Если данные отсутствуют в любой из следующих таблиц, скорее всего, проблема связана с анализом больших полезных нагрузок из-за большого количества podов или узлов. Эта известная проблема в подключаемом модуле Ruby для анализа больших полезных данных JSON из-за PODS_CHUNK_SIZE по умолчанию, которая составляет 1000.

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

ИнвентарьKubePod
KubeNodeInventory
KubeEvents
Инвентарь KubePV
KubeServices

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

# verify if kube context being set for right cluster
kubectl cluster-info

# check if the configmap configured with smaller PODS_CHUNK_SIZE chunksize already
kubectl logs <ama-logs-rs pod name> -n kube-system -c ama-logs | grep PODS_CHUNK_SIZE

# If it's configured, the output will be similar to "Using config map value: PODS_CHUNK_SIZE = 10"

Если кластер уже настроен для меньшего PODS_CHUNK_SIZE значения, необходимо включить кластер для большого кластера.
Если кластер использует значение по умолчанию PODS_CHUNK_SIZE=1000, проверьте, имеет ли кластер большое количество модулей (pod) или узлов.
```
# check the total number of PODS
kubectl get pods -A -o wide | wc -l

# check the total number of NODES
kubectl get nodes -o wide | wc -l
```

После подтверждения, что количество pods и узлов достаточно, и кластер использует значение по умолчанию PODS_CHUNK_SIZE=1000, затем используйте следующие команды для настройки configmap.

# Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace
kubectl get cm -n kube-system | grep container-azm-ms-agentconfig

# If there is no existing container-azm-ms-agentconfig configmap, then configmap needs to be downloaded  and applied
curl -L https://raw.githubusercontent.com/microsoft/Docker-Provider/refs/heads/ci_prod/kubernetes/container-azm-ms-agentconfig.yaml -o container-azm-ms-agentconfig
kubectl apply -f container-azm-ms-agentconfig

# Edit the configmap and uncomment agent_settings.chunk_config and PODS_CHUNK_SIZE lines under agent-settings: |- in the configmap
kubectl edit cm -n kube-system  container-azm-ms-agentconfig -o yaml

Убитый агент OOM

Контейнер daemonset завершается из-за OOM (Out Of Memory) ошибки

Начните с определения того, какой контейнер получает OOM, убитый с помощью следующих команд. Это определит ama-logs, ama-logs-prometheusили оба.

# verify if kube context being set for right cluster
kubectl cluster-info

# get the ama-logs pods and status
kubectl get pods -n kube-system -o custom-columns=NAME:.metadata.name | grep -E ama-logs-[a-z0-9]{5}

# from the result of above command, find out which ama-logs pod instance getting OOM killed
kubectl describe pod <ama-logs-pod> -n kube-system

# review the output of the above command to findout which ama-logs container is getting OOM killed

Проверьте наличие ошибок сети в mdsd.err файле журнала с помощью следующих команд.

mkdir log
# for ama-logs-prometheus container use -c ama-logs-prometheus instead of -c ama-logs
kubectl cp -c ama-logs kube-system/<ama-logs pod name>:/var/opt/microsoft/linuxmonagent/log log
cd log
cat mdsd.err

Если ошибки возникают из-за блокировки исходящей конечной точки, см. сведения о требованиях к брандмауэру сети для мониторинга кластера Kubernetes для требований к конечной точке.
Если ошибки возникают из-за отсутствия конечной точки сбора данных (DCE) или правила сбора данных (DCR), повторно включите Container insights, используя руководство Включение мониторинга для кластеров Kubernetes.
Если нет ошибок, это может быть связано с логарифмической шкалой. См. сбор журналов большого объема в Container Insights (предварительная версия).

Контейнер ReplicaSet завершился из-за OOM.

Определите, как часто ama-logs-rs ваш pod завершается из-за недостатка памяти, с помощью следующих команд.

# verify if kube context being set for right cluster
kubectl cluster-info

# get the ama-logs pods and status
kubectl get pods -n kube-system -o wide | grep ama-logs-rs

# from the result of above command, find out which ama-logs pod instance getting OOM killed
kubectl describe pod <ama-logs-rs-pod> -n kube-system

# review the output of the above command to confirm the OOM kill

Если ama-logs-rs убиваются из-за OOM, проверьте, есть ли сетевые ошибки, с помощью следующих команд.
```
 mkdir log
 kubectl cp -c ama-logs kube-system/<ama-logs-rs pod name>:/var/opt/microsoft/linuxmonagent/log log
 cd log
 cat mdsd.err
```
Если ошибки возникают из-за блокировки исходящей конечной точки, см. сведения о требованиях к брандмауэру сети для мониторинга кластера Kubernetes для требований к конечной точке.
Если ошибки возникают из-за отсутствия конечной точки сбора данных (DCE) или правила сбора данных (DCR), повторно включите Container insights, используя руководство Включение мониторинга для кластеров Kubernetes.

Если сетевые ошибки отсутствуют, проверьте, включен ли сбор данных уровня кластера с помощью Prometheus, проверив настройки [prometheus_data_collection_settings.cluster] в ConfigMap.

# Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace
kubectl get cm -n kube-system | grep container-azm-ms-agentconfig
# If there is no existing container-azm-ms-agentconfig configmap, then means cluster level prometheus data collection not enabled

Проверьте размер кластера с точки зрения количества узлов и модулей pod.

# Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace
NodeCount=$(kubectl get nodes | wc -l)
echo "Total number of nodes: ${NodeCount}"
PodCount=$(kubectl get pods -A -o wide | wc -l)
echo "Total number of pods: ${PodCount}"

# If there is no existing container-azm-ms-agentconfig configmap, then means cluster level prometheus data collection is not enabled.

Если определить проблему, связанную с масштабом кластера, необходимо увеличить ограничение памяти ama-logs-rs. Откройте запрос в службу поддержки корпорации Майкрософт, чтобы сделать этот запрос.

Проблемы с задержкой

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

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

let clusterResourceId = "/subscriptions/<subscriptionId>/resourceGroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>";
let startTime = todatetime('2024-11-20T20:34:11.9117523Z');
let endTime = todatetime('2024-11-21T20:34:11.9117523Z');
KubePodInventory #Update this table name to the one you want to check
| where _ResourceId =~ clusterResourceId
| where TimeGenerated >= startTime and TimeGenerated <= endTime
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize max(E2EIngestionLatency), max(AgentLatency) by Computer
| project Computer, max_AgentLatency, max_ingestionLatency = (max_E2EIngestionLatency -  max_AgentLatency),max_E2EIngestionLatency

Если вы видите высокую задержку агента, проверьте, настроен ли другой интервал сбора журналов, отличный от 60 секунд в DCR Службы аналитики контейнеров.

# set the subscriptionId of the cluster
az account set -s "<subscriptionId>"
# check if ContainerInsightsExtension  data collection rule association exists
az monitor data-collection rule association list --resource <clusterResourceId>
# get the data collection rule resource id associated to ContainerInsightsExtension from above step
az monitor data-collection rule show  --ids  <dataCollectionRuleResourceIdFromAboveStep>
# check if there are any data collection settings related to interval from the output of the above step

Проблемы с многострочным ведением журнала

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

Поддерживает сообщения журнала до 64 КБ вместо ограничения по умолчанию 16 КБ.
Объединяет трассировки стека вызовов исключений для поддерживаемых языков .NET, Go, Python и Java.

Убедитесь, что схема Multiline и ContainerLogV2 включены с помощью следующих команд.

    # get the list of ama-logs and these pods should be in Running state
    # If these are not in Running state, then this needs to be investigated
    kubectl get po -n kube-system | grep ama-logs

    # exec into any one of the ama-logs daemonset pod and check for the environment variables
    kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash

    # after exec into the container run this command
    env | grep AZMON_MULTILINE

    # result should have environment variables which indicates the multiline and languages enabled
    AZMON_MULTILINE_LANGUAGES=java,go
    AZMON_MULTILINE_ENABLED=true

    # check if the containerlog v2 schema enabled or not
    env | grep AZMON_CONTAINER_LOG_SCHEMA_VERSION

    # output should be v2. If not v2, then check whether this is being enabled through DCR
    AZMON_CONTAINER_LOG_SCHEMA_VERSION=v2

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-04-18