Condividi tramite

Risolvere i problemi relativi a Informazioni dettagliate contenitore

  • Articolo

Quando si configura il monitoraggio del cluster del servizio Azure Kubernetes con dati analitici sui contenitori, è possibile riscontrare un problema che impedisce la raccolta di dati o la segnalazione dello stato. Questo articolo presenta alcuni problemi comuni e i passaggi per la risoluzione dei problemi.

Messaggi di errore noti

La tabella seguente riepiloga gli errori noti che possono verificarsi quando si usa Informazioni dettagliate contenitore.

Messaggi di errore Azione
Messaggio di errore "Nessun dato per i filtri selezionati" L'attivazione del flusso di dati di monitoraggio per i cluster appena creati potrebbe richiedere del tempo. Attendere almeno 10/15 minuti perché vengano visualizzati i dati per il cluster.

Se i dati non vengono ancora visualizzati, verificare se l'area di lavoro Log Analytics è configurata per disableLocalAuth = true. In caso affermativo, eseguire di nuovo l'aggiornamento a 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
Messaggio di errore "Errore durante il recupero dei dati" Durante la configurazione di un cluster del servizio Azure Kubernetes per il monitoraggio dell'integrità e delle prestazioni, viene stabilita una connessione tra il cluster e un'area di lavoro Log Analytics. Un'area di lavoro Log Analytics viene usata per archiviare tutti i dati di monitoraggio per il cluster. Questo errore potrebbe verificarsi quando l'area di lavoro Log Analytics è stata eliminata. Controllare se l'area di lavoro è stata eliminata. In caso affermativo, è possibile riabilitare il monitoraggio del cluster con Informazioni dettagliate contenitore. Specificare quindi un'area di lavoro esistente o crearne una nuova. Per riattivare, disabilitare il monitoraggio per il cluster e abilitare nuovamente Informazioni dettagliate contenitore.
"Errore durante il recupero dei dati" dopo l'aggiunta di Informazioni dettagliate contenitore tramite az aks cli Quando si abilita il monitoraggio tramite az aks cli, Informazioni dettagliate contenitore potrebbe non essere stato distribuito correttamente. Controllare se la soluzione è distribuita. Per eseguire la verifica, passare all'area di lavoro Log Analytics e controllare se la soluzione è disponibile, selezionando Soluzioni dal riquadro sul lato sinistro. Per risolvere questo problema, ridistribuire la soluzione. Seguire le istruzioni in Abilitare Informazioni dettagliate contenitore.
Messaggio di errore "Registrazione sottoscrizione mancante" Se viene visualizzato l'errore 'Registrazione della sottoscrizione mancante per Microsoft.OperationsManagement', è possibile risolverlo registrando il provider di risorse Microsoft.OperationsManagement nella sottoscrizione in cui è definita l'area di lavoro. Per la procedura, vedere Risolvere gli errori per la registrazione del provider di risorse.
Messaggio di errore "L'URL di risposta specificato nella richiesta non corrisponde agli URL di risposta configurati per l'applicazione: '<ID applicazione>'". Questo messaggio di errore potrebbe essere visualizzato quando si abilitano i log in tempo reale. Per la soluzione, vedere Visualizzare i dati del contenitore in tempo reale con Informazioni dettagliate contenitore.

Per diagnosticare il problema, è stato fornito uno script di risoluzione dei problemi.

Errore di autorizzazione durante l'operazione di onboarding o aggiornamento

Quando si abilita Informazioni dettagliate contenitore o si aggiorna un cluster per supportare la raccolta delle metriche, è possibile che venga visualizzato un errore simile a "Il client <user's Identity> con ID oggetto <user's objectId> non dispone dell'autorizzazione per eseguire un'azione sull'ambito Microsoft.Authorization/roleAssignments/write".

Durante il processo di onboarding o aggiornamento, la concessione dell'assegnazione del ruolo server di pubblicazione metriche di monitoraggio viene tentata nella risorsa cluster. L'utente che avvia il processo per abilitare Informazioni dettagliate contenitore o l'aggiornamento per supportare la raccolta di metriche, deve avere accesso all'autorizzazione Microsoft.Authorization/roleAssignments/write nell'ambito della risorsa cluster del servizio Azure Kubernetes. Tra i ruoli predefiniti, l'accesso a questa operazione viene concesso soltanto ai ruoli Proprietario e Amministratore accesso utenti. Se i criteri di sicurezza richiedono l'assegnazione di autorizzazioni a livello granulare, vedere Ruoli personalizzati di Azure e assegnare l'autorizzazione agli utenti che la richiedono.

È anche possibile concedere manualmente questo ruolo dal portale di Azure: assegnare il ruolo Server di pubblicazione all'ambito Metriche di monitoraggio. Per la procedura dettagliata, vedere Assegnare ruoli di Azure usando il portale di Azure.

I dati analitici sui contenitori sono abilitate ma non segnalano informazioni

Per diagnosticare il problema se non è possibile visualizzare le informazioni sullo stato o non vengono restituiti risultati da una query di log:

  1. Controllare lo stato dell'agente eseguendo questo comando:

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

    Il numero di pod deve essere uguale al numero di nodi Linux nel cluster. L'output dovrebbe essere simile all'esempio seguente, da cui risulta che la distribuzione è stata eseguita correttamente:

    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 sono presenti nodi di Windows Server, controllare lo stato dell'agente eseguendo questo comando:

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

    Il numero di pod deve essere uguale al numero di nodi Windows nel cluster. L'output dovrebbe essere simile all'esempio seguente, da cui risulta che la distribuzione è stata eseguita correttamente:

    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. Controllare lo stato della distribuzione usando questo comando:

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

    L'output dovrebbe essere simile all'esempio seguente, da cui risulta che la distribuzione è stata eseguita correttamente:

    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. Per verificare se il pod è in esecuzione, verificarne lo stato con il comando kubectl get pods --namespace=kube-system.

    L'output dovrebbe essere simile all'esempio seguente con lo stato di Running per 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 i pod sono in stato di esecuzione, ma non sono presenti dati in Log Analytics o i dati sembrano essere inviati solo durante una determinata parte del giorno, ciò potrebbe essere un'indicazione che il limite giornaliero è stato raggiunto. Quando questo limite viene raggiunto ogni giorno, i dati non vengono inseriti nell'area di lavoro Log Analytics e vengono reimpostati al momento della reimpostazione. Per altre informazioni, vedere Limite giornalieri di Log Analytics.

  6. Se Informazioni dettagliate contenitore è abilitato tramite Terraform e msi_auth_for_monitoring_enabled è impostato su true, assicurarsi che le risorse DCR e DCRA vengano distribuite anche per abilitare la raccolta dei log. Per i passaggi dettagliati, vedere Abilitare Informazioni dettagliate contenitore.

I pod ReplicaSet dell'agente dati analitici sui contenitori non sono pianificati in un cluster non del servizio Azure Kubernetes

I pod di ReplicaSet dell'agente di Informazioni dettagliate contenitore hanno una dipendenza dai seguenti selettori di nodo nei nodi di lavoro (o agente) per la pianificazione:

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

Se ai nodi di lavoro non sono associate etichette di nodo, i pod ReplicaSet dell'agente non verranno pianificati. Per istruzioni su come allegare l'etichetta, vedere Assegnare i selettori di etichetta a Kubernetes.

I grafici delle prestazioni non mostrano CPU o memoria di nodi e contenitori in un cluster non di Azure

I pod dell'agente di Informazioni dettagliate contenitore usano l'endpoint cAdvisor nell'agente del nodo per raccogliere le metriche delle prestazioni. Verificare che l'agente in contenitori nel nodo sia configurato in modo da consentire l'apertura di cAdvisor secure port: 10250 o cAdvisor unsecure port: 10255 su tutti i nodi del cluster per raccogliere le metriche delle prestazioni. Per altre informazioni, vedere i prerequisiti per i cluster Kubernetes ibridi.

I cluster non del servizio Azure Kubernetes non vengono visualizzati in Dati analitici sui contenitori

Per visualizzare il cluster non del servizio Azure Kubernetes in Informazioni dettagliate contenitore, è necessario l'accesso in lettura all'area di lavoro Log Analytics che supporta queste informazioni dettagliate e alla risorsa della soluzione Informazioni dettagliate contenitore ContainerInsights (area di lavoro).

Le metriche non vengono raccolte

  1. Verificare che l'assegnazione di ruolo server di pubblicazione metriche di monitoraggio esista usando il comando dell'interfaccia della riga di comando seguente:

    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"

    Per i cluster con MSI, l'ID client assegnato dall'utente per l'agente di Monitoraggio di Azure cambia ogni volta che il monitoraggio viene abilitato e disabilitato, quindi l'assegnazione di ruolo deve esistere nell'ID client MSI corrente.

  2. Per i cluster con l'identità del pod Microsoft Entra abilitata e che utilizzano MSI:

    • Verificare che l'etichetta necessaria kubernetes.azure.com/managedby: aks sia presente nei pod dell'agente di Monitoraggio di Azure usando il comando seguente:

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

    • Verificare che le eccezioni siano abilitate quando l'identità del pod è abilitata utilizzando uno dei metodi supportati in https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.

      Eseguire il comando seguente per verificare:

      kubectl get AzurePodIdentityException -A -o yaml

      L'output ricevuto avrà un aspetto analogo al seguente esempio:

      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

L'installazione dell'estensione contenitori di Monitoraggio di Azure ha esito negativo in un cluster Kubernetes abilitato per Azure Arc

L'errore "i manifesti contengono una risorsa che esiste già" indica che le risorse dell'agente di Informazioni dettagliate contenitore esistono già nel cluster Kubernetes abilitato per Azure Arc. Questo errore indica che l'agente di Informazioni dettagliate contenitore è già installato. Viene installato tramite un grafico Helm azuremonitor-containers o il componente aggiuntivo Monitoraggio, se si tratta di un cluster del servizio Azure Kubernetes connesso tramite Azure Arc.

La soluzione a questo problema consiste nel pulire le risorse esistenti dell'agente di Informazioni dettagliate contenitore, se presente. Abilitare quindi l'estensione Contenitori di Monitoraggio di Azure.

Per i cluster non del servizio Azure Kubernetes

  1. Nel cluster K8s connesso ad Azure Arc, eseguire il comando seguente per verificare se la versione del grafico Helm azmon-containers-release-1 esiste o meno:

    helm list -A

  2. Se l'output del comando precedente indica che esiste azmon-containers-release-1, eliminare la versione del grafico Helm:

    helm del azmon-containers-release-1

Per i cluster del servizio Azure Kubernetes

  1. Eseguire i comandi seguenti e cercare il profilo del componente aggiuntivo Agente di Monitoraggio di Azure per verificare se il componente aggiuntivo monitoraggio del servizio Azure Kubernetes è abilitato:

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

  2. Se l'output include una configurazione del profilo del componente aggiuntivo agente di Monitoraggio di Azure con un ID risorsa dell'area di lavoro Log Analytics, queste informazioni indicano che il componente aggiuntivo monitoraggio del servizio Azure Kubernetes è abilitato e deve essere disabilitato:

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

Se i passaggi precedenti non hanno risolto i problemi di installazione dell'estensione contenitori di Monitoraggio di Azure, creare un ticket di supporto da inviare a Microsoft per ulteriori analisi.

Ricezione di avvisi duplicati

È possibile che siano state abilitate le regole di avviso di Prometheus senza disabilitare gli avvisi consigliati di Informazioni dettagliate contenitore. Vedere Eseguire la migrazione dagli avvisi consigliati di Informazioni dettagliate contenitore alle regole di avviso consigliate di Prometheus (anteprima).

Viene visualizzato il banner informativo "Non si dispone delle autorizzazioni del cluster appropriate che limitano l'accesso alle funzionalità di Informazioni dettagliate contenitore. Contattare l'amministratore del cluster per ottenere l'autorizzazione giusta"

Informazioni dettagliate contenitore ha storicamente consentito agli utenti di accedere all'esperienza del portale di Azure in base all'autorizzazione di accesso dell'area di lavoro Log Analitics. Adesso controlla l'autorizzazione a livello di cluster per fornire l'accesso all'esperienza del portale di Azure. Potrebbe essere necessario che l'amministratore del cluster assegni questa autorizzazione.

Per l'accesso di base a livello di cluster di sola lettura, assegnare il ruolo Lettore di monitoraggio per i tipi di cluster seguenti.

  • Servizio Azure Kubernetes senza abilitazione dell'autorizzazione del controllo degli accessi in base al ruolo (RBAC)
  • Servizio Azure Kubernetes abilitato con l'accesso Single Sign-On basato su SAML di Microsoft Entra
  • Servizio Azure Kubernetes con autorizzazione del controllo degli accessi in base al ruolo di Kubernetes abilitata
  • Servizio Azure Kubernetes configurato con l'associazione di ruolo cluster clusterMonitoringUser
  • Cluster Kubernetes abilitati per Azure Arc

Vedere Assegnare autorizzazioni di ruolo a un utente o a un gruppo per i dettagli su come assegnare questi ruoli per il servizio Azure Kubernetes e consultare le opzioni di accesso e identità per il servizio Azure Kubernetes per altre informazioni sulle assegnazioni di ruolo.

Quando si esegue una query sulla tabella ContainerLog, i valori delle proprietà Image e Name non vengono visualizzati

Per la versione dell'agente ciprod12042019 e successive, per impostazione predefinita queste due proprietà non vengono popolate per ogni riga di log, in modo da ridurre al minimo i costi legati ai dati di log raccolti. Sono disponibili due opzioni per eseguire una query sulla tabella che includono queste proprietà con i rispettivi valori:

Opzione 1

Unire altre tabelle per includere i valori delle proprietà nei risultati.

Modificare le query in modo da includere le proprietà Image e ImageTag dalla tabella ContainerInventory tramite join alla proprietà ContainerID. È possibile includere la proprietà Name (come in precedenza è apparsa nella tabella ContainerLog) dal campo KubepodInventory della tabella ContainerName tramite join della proprietà ContainerID. Questa opzione è consigliata.

L'esempio seguente illustra una query dettagliata di esempio che spiega come ottenere questi valori di campo con i join.

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

Opzione 2

Abilitare di nuovo la raccolta per queste proprietà per ogni riga di log del contenitore.

Se la prima opzione non è conveniente a causa delle modifiche apportate alle query, è possibile riabilitare la raccolta di questi campi. Abilitare l'impostazione log_collection_settings.enrich_container_logs nella mappa di configurazione dell'agente, come descritto nelle impostazioni di configurazione della raccolta dati.

Nota

Non è consigliabile utilizzare la seconda opzione per cluster di grandi dimensioni con più di 50 nodi. Genera chiamate del server API da ogni nodo del cluster per eseguire questo arricchimento. Questa opzione aumenta anche le dimensioni dei dati per ogni riga di log raccolta.

Non è possibile aggiornare il cluster dopo l'onboarding

Lo scenario è il seguente: si è abilitato Informazioni dettagliate contenitore per un cluster del servizio Azure Kubernetes. È stata quindi eliminata l'area di lavoro Log Analytics a cui il cluster ha inviato i dati. Ora, nel tentativo di aggiornare il cluster, l'operazione ha esito negativo. Per risolvere questo problema, è necessario disabilitare il monitoraggio e quindi ripristinarlo facendo riferimento a un'altra area di lavoro valida nella sottoscrizione. Quando si tenta di eseguire di nuovo l'aggiornamento del cluster, il processo dovrebbe essere elaborato e completato correttamente.

Mancata raccolta dei log nel cluster Azure Stack HCI

Se il cluster è stato registrato e/o configurato HCI Insights prima di novembre 2023, le funzionalità che usano l'agente di Monitoraggio di Azure in HCI, ad esempio Arc for Servers Insights, Informazioni dettagliate macchina virtuale, Informazioni dettagliate contenitore, Defender per il cloud o Microsoft Sentinel potrebbero non raccogliere correttamente i log e i dati degli eventi. Per i passaggi per riconfigurare l'agente e HCI Insights, vedere Ripristinare l'agente AMA per HCI.

Passaggi successivi

Con il monitoraggio abilitato per acquisire le metriche di integrità per i nodi del cluster servizio Azure Kubernetes e dei pod, queste metriche di integrità sono disponibili nel portale di Azure. Per informazioni su come usare Informazioni dettagliate contenitore, vedere Visualizzare l'integrità del servizio Azure Kubernetes.