Solucionar problemas de Insights do contêiner

Ao configurar o monitoramento do cluster do AKS (Serviço de Kubernetes do Azure) com os Insights do Contêiner, poderá encontrar um problema que impede a coleta de dados ou os relatórios de status. 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 os Insights de contêiner.

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

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

Ao habilitar os Insights do contêiner ou atualizar um cluster para dar suporte à coleta de métricas, você poderá receber um erro como "O cliente <user's Identity> com a ID <user's objectId> de objeto não tem autorização para executar a ação Microsoft.Authorization/roleAssignments/write no escopo".

Durante a integração ou o processo de atualização, é fita uma tentativa de concessão da atribuição de função do Publicador de Métricas de Monitoramento no recurso de cluster. O usuário que inicia o processo para habilitar os Insights do contêiner ou a atualização para dar suporte à coleção de métricas, deve ter acesso à permissão Microsoft.Authorization/roleAssignments/write no escopo do recurso de cluster do AKS. Somente os membros das funções internas Proprietário e Administrador de Acesso do 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 as Funções personalizadas do Azure e atribua permissão aos usuários que precisam dela.

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

O Insights do contêiner está habilitado, mas não está relatando nenhuma informação

Para diagnosticar o problema se você não conseguir exibir as informações de status ou 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 do Linux no cluster. A saída deve ser semelhante ao seguinte exemplo, que indica que ela 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 seguinte exemplo, que indica que ela 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 seguinte exemplo, que indica que ela 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á em execução usando o comandokubectl get pods --namespace=kube-system.

   A saída deve ser semelhante ao seguinte exemplo 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 em execução, mas não houver dados no Log Analytics ou os dados aparecerem para serem enviados apenas durante uma determinada parte do dia, pode ser uma indicação de que o limite diário foi atingido. Quando esse limite é atingido a cada dia, a ingestão de dados é interrompida no Workspace do Log Analytics e é reiniciada no momento da redefinição. Para obter mais informações, confira Limite diário do Log Analytics.

6. Se os Insights de contêiner estiverem habilitados usando o Terraform e msi_auth_for_monitoring_enabled estiver definido como true, verifique se os recursos DCR e DCRA também estão implantados para habilitar a coleta de logs. Para obter etapas detalhadas, consulte Habilitar Insights de contêiner.

Os Pods ReplicaSet do agente do Insights do contêiner não estão agendados em um cluster não AKS

Os Pods ReplicaSet do agente do Insights do contêiner têm uma dependência nos seguintes seletores de nó nos nós do trabalhador (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 atribui seletor de rótulo.

Os gráficos de desempenho não mostram a CPU ou memória de nós e contêineres em um cluster não Azure

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

Clusters não AKS não são exibidos nos Insights do contêiner

Para exibir o cluster não AKS no Insights do contêiner, o acesso de leitura é necessário no workspace do Log Analytics que dá suporte a este Insight e no recurso de solução do Insights do contêiner ContainerInsights (espaço de trabalho).

As métricas não estão sendo coletadas

1. Verifique se a atribuição de função Publicador de Métricas de Monitoramento 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 os clusters com a MSI, a ID do cliente atribuída pelo usuário para o Agente do Azure Monitor é alterada toda vez que o monitoramento é habilitado e desabilitado. Portanto, a atribuição de função deve existir na ID do cliente da MSI atual.

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

   • Verifique se o rótulo necessário kubernetes.azure.com/managedby: aks está presente no pods do Agente do Azure Monitor 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 estiver habilitada usando um dos métodos com suporte 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
     

Falha na instalação da Extensão de Contêineres do Azure Monitor em um cluster do Kubernetes habilitado para o Azure Arc

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

A solução para esse problema é limpar os recursos existentes do agente de Insights do contêiner 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 gráfico do Helm azmon-containers-release-1 existe ou não:

   helm list -A

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

   helm del azmon-containers-release-1

Para clusters do AKS

1. Execute os seguintes comandos e procure o perfil do complemento do Agente do Azure Monitor para verificar se o Complemento do 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 do complemento do Agente do Azure Monitor com uma ID do recurso do workspace do Log Analytics, esta informação indica que o Complemento do 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 uma investigação mais completa.

Alertas duplicados que estão sendo recebidos

Você pode ter habilitado as regras de alerta do Prometheus sem desabilitar os alertas recomendados para insights de contêiner. Veja Migrar dos alertas recomendados por Contêiner insights para as regras de alerta recomendadas pelo Prometheus (versão prévia).

Eu vejo a faixa de informações "Você não tem as permissões de cluster corretas que restringirão seu acesso aos recursos dos Insights do Contêiner. Entre em contato com o administrador do cluster para obter a permissão certa"

O Container Insights historicamente permitiu que os usuários acessassem a experiência do portal do Azure com base na permissão de acesso do workspace do Log Analytics. Agora, ele verifica a permissão no nível do cluster para fornecer acesso à experiência do portal do Azure. Talvez seja necessário que o administrador do cluster atribua essa permissão.

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

• AKS sem autorização de RBAC (controle de acesso baseado em função) do Kubernetes habilitada
• AKS habilitado com logon único baseado no Microsoft Entra SAML
• AKS habilitado com autorização do RBAC do Kubernetes
• AKS configurado com a associação de função de cluster ,clusterMonitoringUser
• Cluster do 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 AKS e Opções de acesso e identidade para Serviço de Kubernetes do Azure (AKS) para saber mais sobre atribuições de função.

Não vejo os valores de propriedade Imagem e Nome 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 inclui essas propriedades com seus valores:

Opção 1

Fazer junção de outras tabelas para incluir esses valores de propriedade nos resultados.

Modifique suas consultas para incluir as propriedades Image e ImageTag da tabela ContainerInventory fazendo junção na propriedade ContainerID. Você pode incluir a propriedade Name (pois ela apareceu anteriormente na tabela ContainerLog) da tabela KubepodInventory do campo ContainerName fazendo a junção na propriedade ContainerID. Recomendamos essa opção.

O exemplo a seguir é uma consulta detalhada de exemplo que explica como obter esses valores de campo por meio de 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

Reabilitar a coleção para essas propriedades para cada linha de log de contêiner.

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

Não consigo atualizar um cluster após a integração

Este é o cenário: você habilitou insights de contêiner para um cluster do Serviço de Kubernetes do Azure. Em seguida, você excluiu o workspace do Log Analytics para onde o cluster estava enviando seus dados. Agora, quando você tenta atualizar o cluster, ocorre um erro. Para solucionar esse problema, você deve desabilitar o monitoramento e reabilitá-lo fazendo referência a um workspace diferente válido em sua assinatura. Quando você tentar executar a atualização do cluster novamente, isso deverá ser processado e concluído com êxito.

Não coletar logs no cluster do Azure Stack HCI

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 Insights do Arc para servidores, Insights de VM, Insights do contêiner, Defender para Nuvem ou Microsoft Sentinel podem não estar coletando logs e dados de eventos corretamente. Consulte Reparar o agente AMA para HCI para obter etapas para reconfigurar o agente e o HCI Insights.

Próximas etapas

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