Solucionar problemas de informações do contêiner

Artigo
02/15/2024

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

Mensagens de erro	Ação
Mensagem de erro "Nenhum dado para filtros selecionados"	Poderá demorar algum tempo a estabelecer o fluxo de dados de monitorização para os clusters recentemente criados. Aguarde pelo menos 10 a 15 minutos para que os dados apareçam no cluster. Se os dados ainda não aparecerem, verifique se o espaço de trabalho do Log Analytics está configurado para `disableLocalAuth = true`. Em caso afirmativo, atualize novamente para `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`
Mensagem de erro "Erro ao recuperar dados"	Enquanto um cluster AKS está sendo configurado para monitoramento de integridade e desempenho, uma conexão é estabelecida entre o cluster e um espaço de trabalho do Log Analytics. Um espaço de trabalho do Log Analytics é usado para armazenar todos os dados de monitoramento do cluster. Esse erro pode ocorrer quando seu espaço de trabalho do Log Analytics foi excluído. Verifique se o espaço de trabalho foi excluído. Se estiver, reative o monitoramento do cluster com o Container insights. Em seguida, especifique um espaço de trabalho existente ou crie um novo. Para reativar, desative o monitoramento para o cluster e habilite as informações de contêiner novamente.
"Erro ao recuperar dados" depois de adicionar informações do Container através de `az aks cli`	Quando você habilita o monitoramento usando `az aks cli`o , o Container insights pode não ser implantado corretamente. Verifique se a solução está implantada. Para verificar, vá para o espaço de trabalho do Log Analytics e veja se a solução está disponível selecionando Soluções herdadas no painel do lado esquerdo. Para resolver esse problema, reimplante a solução. Siga as instruções em Ativar informações de contêiner.
Mensagem de erro "Registo de subscrição em falta"	Se você receber o erro "Registro de assinatura ausente para Microsoft.OperationsManagement", poderá resolvê-lo registrando o provedor de recursos Microsoft.OperationsManagement na assinatura onde o espaço de trabalho está definido. Para conhecer as etapas, consulte Resolver erros para registro do provedor de recursos.
Mensagem de erro "O url de resposta especificado na solicitação não corresponde aos urls de resposta configurados para o aplicativo: '<ID> do aplicativo'."	Poderá ver esta mensagem de erro quando ativar os registos em tempo real. Para obter a solução, consulte Exibir dados de contêiner em tempo real com 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 integraçã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.

O Container insights está habilitado, mas não relata nenhuma informação

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:

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

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

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.

Os ReplicaSet Pods do agente de insights de contêiner não estão agendados em um cluster não 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 de nós e contêineres em um 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 não-AKS não são exibidos no Container insights

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 sendo coletadas

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.
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 Contêineres do Azure Monitor falha em um cluster Kubernetes habilitado para 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

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

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

Alertas duplicados que estão sendo recebidos

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).

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 das 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 à ContainerIDImageTag 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.

Nota

Não recomendamos a segunda opção para clusters grandes com mais de 50 nós. Ele gera chamadas de servidor de API de cada nó no cluster para executar esse enriquecimento. Essa opção também aumenta o tamanho dos dados para cada linha de log coletada.

Não consigo atualizar um cluster após a integraçã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.