Solucionar problemas de informações do contêiner

Ao configurar a monitorização do cluster do Azure Kubernetes Service (AKS) com as informações do contentor, pode encontrar um problema que impede a recolha de dados ou o estado de comunicação. Este artigo discute alguns problemas comuns e etapas de solução de problemas.

Mensagens de erro conhecidas

A tabela a seguir resume os erros conhecidos que você pode encontrar ao usar o Container insights.

Para ajudar a diagnosticar o problema, fornecemos um script de solução de problemas.

Erro de autorização durante a operação de inclusão ou atualização

Quando você habilita o Container insights ou atualiza um cluster para dar suporte à coleta de métricas, pode receber um erro como "O cliente <user's Identity> com id <user's objectId> de objeto não tem autorização para executar ações Microsoft.Authorization/roleAssignments/write sobre o escopo".

Durante o processo de integração ou atualização, a concessão da atribuição de função de Publicador de Métricas de Monitoramento é tentada no recurso de cluster. O usuário que inicia o processo para habilitar o Container insights ou a atualização para dar suporte à coleta de métricas deve ter acesso à permissão Microsoft.Authorization/roleAssignments/write no escopo do recurso do cluster AKS. Somente os membros das funções internas de Proprietário e Administrador de Acesso de Usuário recebem acesso a essa permissão. Se suas políticas de segurança exigirem que você atribua permissões de nível granular, consulte Funções personalizadas do Azure e atribua permissão aos usuários que a exigem.

Você também pode conceder manualmente essa função no portal do Azure: Atribua a função Publicador ao escopo Métricas de Monitoramento . Para obter etapas detalhadas, consulte Atribuir funções do Azure usando o portal do Azure.

As informações do contentor estão ativadas, mas não são reportadas informações

Para diagnosticar o problema se não for possível visualizar as informações de status ou se nenhum resultado for retornado de uma consulta de log:

1. Verifique o status do agente executando o seguinte comando:

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

   O número de pods deve ser igual ao número de nós Linux no cluster. A saída deve ser semelhante ao exemplo a seguir, que indica que foi implantada corretamente:

   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. Se você tiver nós do Windows Server, verifique o status do agente executando o seguinte comando:

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

   O número de pods deve ser igual ao número de nós do Windows no cluster. A saída deve ser semelhante ao exemplo a seguir, que indica que foi implantada corretamente:

   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. Verifique o status da implantação usando o seguinte comando:

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

   A saída deve ser semelhante ao exemplo a seguir, que indica que foi implantada corretamente:

   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. Verifique o status do pod para verificar se ele está sendo executado usando o comando kubectl get pods --namespace=kube-system.

   A saída deve ser semelhante ao exemplo a seguir com um status de Running para 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. Se os pods estiverem em um estado de execução, mas não houver dados no Log Analytics ou os dados parecerem enviar apenas durante uma determinada parte do dia, isso pode ser uma indicação de que o limite diário foi atingido. Quando esse limite é atingido todos os dias, os dados param de ser ingeridos no espaço de trabalho do Log Analytics e são redefinidos no momento da redefinição. Para obter mais informações, consulte Log Analytics Daily Cap.

6. Se o Containter insights estiver habilitado usando o Terraform e msi_auth_for_monitoring_enabled estiver definido como true, certifique-se de que os recursos DCR e DCRA também sejam implantados para habilitar a coleta de logs. Para obter etapas detalhadas, consulte habilitar Insights de contêiner.

Os Pods ReplicaSet do agente de informações do contentor não estão agendados num cluster que não seja do AKS

Os ReplicaSet Pods do agente do Container Insights dependem dos seguintes seletores de nó nos nós de trabalho (ou agente) para o agendamento:

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

Se os nós de trabalho não tiverem rótulos de nó anexados, os pods ReplicaSet do agente não serão agendados. Para obter instruções sobre como anexar o rótulo, consulte Kubernetes atribuir seletores de rótulo.

Os gráficos de desempenho não mostram a CPU ou a memória dos nós e contentores num cluster que não seja do Azure

Os pods do agente do Container Insights usam o ponto de extremidade do cAdvisor no agente do nó para coletar métricas de desempenho. Verifique se o agente conteinerizado no nó está configurado para permitir cAdvisor secure port: 10250 ou cAdvisor unsecure port: 10255 ser aberto em todos os nós do cluster para coletar métricas de desempenho. Consulte os pré-requisitos para clusters Kubernetes híbridos para obter mais informações.

Os clusters que não sejam do AKS não são apresentados nas informações do contentor

Para exibir o cluster não-AKS no Container insights, o acesso de leitura é necessário no espaço de trabalho do Log Analytics que oferece suporte a essa perceção e no recurso da solução Container insights ContainerInsights (espaço de trabalho).

As métricas não estão a ser recolhidas

1. Verifique se a atribuição de função do Monitoring Metrics Publisher existe usando o seguinte comando da 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"
   

   Para clusters com MSI, a ID do cliente atribuída pelo usuário para o Agente do Azure Monitor muda sempre que o monitoramento é habilitado e desabilitado, portanto, a atribuição de função deve existir na ID do cliente MSI atual.

2. Para clusters com a identidade pod do Microsoft Entra habilitada e usando MSI:

   • Verifique se o rótulo necessário kubernetes.azure.com/managedby: aks está presente nos pods do Azure Monitor Agent usando o seguinte comando:

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

   • Verifique se as exceções estão habilitadas quando a identidade do pod está habilitada usando um dos métodos suportados em https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.

     Execute o seguinte comando para verificar:

     kubectl get AzurePodIdentityException -A -o yaml

     Você deve receber uma saída semelhante ao exemplo a seguir:

     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
     

A instalação da Extensão de Contentores do Azure Monitor falha num cluster do Kubernetes compatível com o Azure Arc

O erro "manifestos contêm um recurso que já existe" indica que os recursos do agente Container insights já existem no cluster Kubernetes habilitado para Azure Arc. Esse erro indica que o agente do Container insights já está instalado. Ele é instalado por meio de um gráfico Helm azuremonitor-containers ou do Complemento de Monitoramento se for um cluster AKS conectado via Azure Arc.

A solução para esse problema é limpar os recursos existentes do agente Container insights, se ele existir. Em seguida, habilite a Extensão de Contêineres do Azure Monitor.

Para clusters não-AKS

1. No cluster K8s conectado ao Azure Arc, execute o seguinte comando para verificar se a versão do azmon-containers-release-1 gráfico Helm existe ou não:

   helm list -A

2. Se a saída do comando anterior indicar que o azmon-containers-release-1 existe, exclua a versão do gráfico Helm:

   helm del azmon-containers-release-1

Para clusters AKS

1. Execute os seguintes comandos e procure o perfil de complemento do Agente do Azure Monitor para verificar se o Complemento de Monitoramento do AKS está habilitado:

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

2. Se a saída incluir uma configuração de perfil de complemento do Agente do Azure Monitor com uma ID de recurso do espaço de trabalho do Log Analytics, essas informações indicam que o Complemento de Monitoramento do AKS está habilitado e deve ser desabilitado:

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

Se as etapas anteriores não resolverem os problemas de instalação da Extensão de Contêineres do Azure Monitor, crie um tíquete de suporte para enviar à Microsoft para investigação adicional.

Receção de alertas duplicados

Você pode ter ativado as regras de alerta do Prometheus sem desabilitar os alertas recomendados do Container insights. Consulte Migrar dos alertas recomendados do Container insights para as regras de alerta recomendadas do Prometheus (visualização).

Vejo o banner de informações "Você não tem as permissões de cluster corretas que restringirão seu acesso aos recursos do Container Insights. Entre em contato com o administrador do cluster para obter a permissão certa"

Historicamente, o Container Insights permite que os usuários acessem a experiência do portal do Azure com base na permissão de acesso do espaço de trabalho do Log Analytics. Agora, ele verifica a permissão no nível de cluster para fornecer acesso à experiência do portal do Azure. Talvez você precise do administrador do cluster para atribuir essa permissão.

Para acesso básico somente leitura no nível de cluster, atribua a função Leitor de Monitoramento para os seguintes tipos de clusters.

• AKS sem autorização de controle de acesso baseado em função (RBAC) do Kubernetes habilitada
• AKS ativado com logon único baseado em SAML do Microsoft Entra
• AKS ativado com autorização RBAC do Kubernetes
• AKS configurado com a função de cluster clusterMonitoringUser
• Clusters Kubernetes habilitados para Azure Arc

Consulte Atribuir permissões de função a um usuário ou grupo para obter detalhes sobre como atribuir essas funções para o AKS e opções de acesso e identidade para o Serviço Kubernetes do Azure (AKS) para saber mais sobre atribuições de função.

Não vejo os valores de propriedades Image e Name preenchidos quando consulto a tabela ContainerLog

Para a versão do agente ciprod12042019 e posterior, por padrão, essas duas propriedades não são preenchidas para cada linha de log para minimizar o custo incorrido nos dados de log coletados. Há duas opções para consultar a tabela que incluem essas propriedades com seus valores:

Opção 1

Junte outras tabelas para incluir esses valores de propriedade nos resultados.

Modifique suas consultas para incluir Image e propriedades da ContainerInventory tabela juntando-se à ContainerID ImageTag propriedade. Você pode incluir a Name propriedade (como ela aparecia anteriormente na ContainerLog tabela) do ContainerName campo da KubepodInventory tabela juntando-se à ContainerID propriedade. Recomendamos esta opção.

O exemplo a seguir é uma consulta detalhada de exemplo que explica como obter esses valores de campo com junções.

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

Opção 2

Reative a coleta dessas propriedades para cada linha de log de contêiner.

Se a primeira opção não for conveniente devido às alterações de consulta envolvidas, você poderá reativar a coleta desses campos. Habilite a configuração log_collection_settings.enrich_container_logs no mapa de configuração do agente conforme descrito nas definições de configuração de coleta de dados.

Não consigo atualizar um cluster após a inclusão

Aqui está o cenário: você habilitou o Container insights para um cluster do Serviço Kubernetes do Azure. Em seguida, você excluiu o espaço de trabalho do Log Analytics para o qual o cluster estava enviando seus dados. Agora, quando você tenta atualizar o cluster, ele falha. Para contornar esse problema, você deve desabilitar o monitoramento e, em seguida, reativá-lo fazendo referência a um espaço de trabalho válido diferente em sua assinatura. Quando você tenta executar a atualização de cluster novamente, ela deve ser processada e concluída com êxito.

Não coletando logs no cluster HCI do Azure Stack

Se você registrou seu cluster e/ou configurou o HCI Insights antes de novembro de 2023, os recursos que usam o agente do Azure Monitor no HCI, como Arc for Servers Insights, VM Insights, Container Insights, Defender for Cloud ou Microsoft Sentinel, podem não estar coletando logs e dados de eventos corretamente. Consulte Reparar o agente AMA para HCI para obter as etapas para reconfigurar o agente e o HCI Insights.

Próximos passos

Quando o monitoramento é habilitado para capturar métricas de integridade para os nós e pods do cluster AKS, essas métricas de integridade estão disponíveis no portal do Azure. Para saber como usar informações de contêiner, consulte Exibir a integridade do Serviço Kubernetes do Azure.