Share via

Risolvere i problemi relativi alle informazioni dettagliate sui contenitori

  • Articolo

Quando si configura il monitoraggio del cluster servizio Azure Kubernetes (servizio Azure Kubernetes) con Informazioni dettagliate sui contenitori, è possibile che si verifichi un problema che impedisce la raccolta o lo stato dei report dei dati. Questo articolo illustra alcuni problemi comuni e procedure di risoluzione dei problemi.

Messaggi di errore noti

La tabella seguente riepiloga gli errori noti che possono verificarsi quando si usano informazioni dettagliate sui contenitori.

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 per visualizzare 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" Mentre un cluster del servizio Azure Kubernetes è configurato 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 può 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 sui contenitori. 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 sui contenitori az aks cli Quando si abilita il monitoraggio tramite az aks cli, le informazioni dettagliate sui contenitori potrebbero non essere distribuite correttamente. Controllare se la soluzione è distribuita. Per verificare, passare all'area di lavoro Log Analytics e verificare se la soluzione è disponibile selezionando Soluzioni legacy nel riquadro a sinistra. Per risolvere questo problema, ridistribuire la soluzione. Seguire le istruzioni in Abilitare informazioni dettagliate sui contenitori.
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 sui contenitori.

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

Errore di autorizzazione durante l'operazione di onboarding o aggiornamento

Quando si abilitano informazioni dettagliate sui contenitori 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 <user's objectId> oggetto 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 sui contenitori 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. Solo ai membri del ruolo predefinito Proprietario e Accesso utenti Amministrazione istrator viene concesso l'accesso a questa autorizzazione. 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 lo richiedono.

È anche possibile concedere manualmente questo ruolo dal portale di Azure: Assegnare il ruolo server di pubblicazione all'ambito Metriche di monitoraggio. Per i passaggi dettagliati, vedere Assegnare ruoli di Azure usando il portale di Azure.

Le informazioni dettagliate 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

    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           beta.kubernetes.io/os=linux   1d

  2. Se sono presenti nodi di Windows Server, controllare lo stato dell'agente eseguendo il comando seguente:

    kubectl get ds omsagent-win --namespace=kube-system

    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           beta.kubernetes.io/os=windows   1d

  3. Controllare lo stato della distribuzione con la versione dell'agente 06072018 o versione successiva usando il comando seguente:

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

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

    User@aksuser:~$ kubectl get deployment omsagent-rs -n=kube-system
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE    AGE
ama-logs   1         1         1            1            3h

  4. Controllare lo stato del pod per verificare che sia in esecuzione usando il comando kubectl get pods --namespace=kube-system.

    L'output dovrebbe essere simile all'esempio seguente con lo stato di Running per omsagent:

    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 si trovano in uno stato di esecuzione, ma non sono presenti dati in Log Analytics o i dati sembrano essere inviati solo durante una determinata parte del giorno, potrebbe essere un'indicazione che il limite giornaliero è stato soddisfatto. Quando questo limite viene soddisfatto ogni giorno, i dati non vengono inseriti nell'area di lavoro Log Analytics e reimpostati al momento della reimpostazione. Per altre informazioni, vedere Limite giornaliero di Log Analytics.

I pod replicaset dell'agente di Informazioni dettagliate contenitore non sono pianificati in un cluster non del servizio Azure Kubernetes

L'agente di Informazioni dettagliate contenitore ReplicaSet Pods ha una dipendenza dai selettori di nodo seguenti 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 per consentire cAdvisor secure port: 10250 o cAdvisor unsecure port: 10255 aprire in 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 Informazioni dettagliate sui contenitori

Per visualizzare il cluster non servizio Azure Kubernetes in Informazioni dettagliate sui contenitori, è necessario l'accesso in lettura nell'area di lavoro Log Analytics che supporta queste informazioni dettagliate e sulla 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 IDENTITÀ del servizio gestito, 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 tramite MSI:

    • Verificare che l'etichetta necessaria kubernetes.azure.com/managedby: il servizio Azure Kubernetes è 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 usando 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 dovrebbe essere simile all'esempio seguente:

      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 non riesce in un cluster Kubernetes abilitato per Azure Arc

L'errore "manifesti contengono una risorsa già esistente" 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 esistente. 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 azmon-containers-release-1 grafico Helm 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 indagini.

Avvisi duplicati ricevuti

È possibile che siano state abilitate le regole di avviso prometheus senza disabilitare gli avvisi consigliati di Informazioni dettagliate contenitore. Vedere Eseguire la migrazione dagli avvisi consigliati di Informazioni dettagliate sui contenitori 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 corretta"

Container Insights ha storicamente consentito agli utenti di accedere all'esperienza di portale di Azure in base all'autorizzazione di accesso dell'area di lavoro Log Analytics. Controlla ora l'autorizzazione a livello di cluster per fornire l'accesso all'esperienza di 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 autorizzazione del controllo degli accessi in base al ruolo (RBAC) abilitata
  • Servizio Azure Kubernetes abilitato con Single Sign-On basato su Microsoft Entra SAML
  • Servizio Azure Kubernetes con autorizzazione del controllo degli accessi in base al ruolo di Kubernetes abilitata
  • Servizio Azure Kubernetes configurato con l'associazione di ruoli del clusterMonitoraggioUtente
  • Cluster Kubernetes abilitati per Azure Arc

Per altre informazioni sulle assegnazioni di ruolo, vedere Assegnare autorizzazioni di ruolo a un utente o a un gruppo per informazioni dettagliate su come assegnare questi ruoli per il servizio Azure Kubernetes e le opzioni di accesso e identità per servizio Azure Kubernetes (servizio Azure Kubernetes).

I valori delle proprietà Image e Name non vengono visualizzati quando si esegue una query sulla tabella ContainerLog

Per la versione dell'agente ciprod12042019 e versioni successive, per impostazione predefinita queste due proprietà non vengono popolate per ogni riga di log per ridurre al minimo i costi sostenuti sui 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 Image le proprietà e ImageTag dalla ContainerInventory tabella tramite join sulla ContainerID proprietà . È possibile includere la Name proprietà (come in precedenza è apparsa nella ContainerLog tabella) dal KubepodInventory campo della ContainerName tabella unendo la ContainerID proprietà . È consigliabile scegliere questa opzione.

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

Raccolta ripristinabile per queste proprietà per ogni riga di log del contenitore.

Se la prima opzione non è utile 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 usare 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 un cluster dopo l'onboarding

Ecco lo scenario: Sono state abilitate informazioni dettagliate sui contenitori per un cluster servizio Azure Kubernetes. È stata quindi eliminata l'area di lavoro Log Analytics in cui il cluster ha inviato i dati. Ora, quando si tenta di aggiornare il cluster, l'operazione ha esito negativo. Per risolvere questo problema, è necessario disabilitare il monitoraggio e quindi ripristinarlo facendo riferimento a un'area di lavoro valida diversa 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 è stato 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, VM Insights, Container Insights, Defender per il cloud o Microsoft Sentinel potrebbero non raccogliere correttamente i log e i dati degli eventi. Vedere Ripristinare l'agente AMA per HCI per i passaggi per riconfigurare l'agente e HCI Insights.

Passaggi successivi

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