Condividi tramite

Risoluzione dei problemi di raccolta dei log dei contenitori in Azure Monitor

Questo articolo illustra alcuni problemi comuni e procedure di risoluzione dei problemi quando si usano informazioni dettagliate sui contenitori per monitorare il cluster Kubernetes.

Vengono creati avvisi duplicati

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

Autorizzazioni del cluster

Se non si dispone delle autorizzazioni necessarie per il cluster, è possibile che venga visualizzato il messaggio di errore. You do not have the right cluster permissions which will restrict your access to Container Insights features. Please reach out to your cluster admin to get the right permission.

In precedenza, Container Insights consentiva agli utenti di accedere all'esperienza del portale di Azure in base all'autorizzazione di accesso dell'area di lavoro Log Analytics. 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
  • AKS abilitato con autorizzazione RBAC di Kubernetes
  • Servizio Azure Kubernetes configurato con l'associazione di ruolo cluster clusterMonitoringUser
  • Cluster Kubernetes abilitato 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.

Problemi di integrazione e aggiornamento

Le sezioni seguenti descrivono i problemi che possono verificarsi durante l'onboarding o l'aggiornamento di Informazioni dettagliate sui contenitori nel cluster.

Registrazione della sottoscrizione mancante

Se viene visualizzato l'errore Missing Subscription registration, registrare il provider di risorse Microsoft.OperationsManagement nella sottoscrizione dell'area di lavoro Log Analytics. Vedere Risolvere gli errori di registrazione del provider di risorse.

Errore di autorizzazione

Quando si abilitano informazioni dettagliate sui contenitori o si aggiorna un cluster, è possibile che venga visualizzato un errore simile a The client <user's identity> with object id <user's objectId> does not have authorization to perform action Microsoft.Authorization/roleAssignments/write over scope.

Durante il processo di onboarding o aggiornamento, viene eseguito un tentativo di assegnazione del ruolo Server di pubblicazione delle metriche di monitoraggio alla risorsa cluster. L'utente che avvia il processo deve avere accesso all'autorizzazione Microsoft.Authorization/roleAssignments/write nell'ambito delle risorse del cluster AKS. 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. Assegnare il ruolo di Server di pubblicazione alle Metriche di monitoraggio con il portale di Azure usando le indicazioni fornite in Assegnare i ruoli di Azure usando il portale di Azure.

Non è possibile aggiornare un cluster

Se non è possibile aggiornare Informazioni dettagliate sui contenitori in un cluster del servizio Azure Kubernetes dopo l'installazione, l'area di lavoro Log Analytics in cui il cluster inviava i dati potrebbe essere stata eliminata. Disabilitare il monitoraggio per il cluster e abilitare nuovamente Informazioni dettagliate contenitore usando un'altra area di lavoro.

L'installazione dell'estensione Contenitori di Monitoraggio di Azure non riesce

L'errore manifests contain a resource that already exists indica che le risorse dell'agente di Informazioni dettagliate contenitore esistono già in un cluster Kubernetes abilitato per Azure Arc, il che significa che l'agente di Informazioni dettagliate contenitore è già installato. Risolvere questo problema eseguendo la pulizia delle risorse esistenti dell'agente di Container Insights e quindi abilitare l'estensione Azure Monitor per Contenitori.

Cluster del servizio Azure Kubernetes

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>

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, il componente aggiuntivo Monitoraggio del servizio Azure Kubernetes è abilitato e deve essere disabilitato con il comando seguente.

az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>
Per i cluster non del servizio Azure Kubernetes

Eseguire il comando seguente sul cluster per verificare se la versione del grafico Helm azmon-containers-release-1 esiste.

helm list  -A

Se l'output indica che esiste azmon-containers-release-1, eliminare la versione del grafico Helm con il comando seguente.

helm del azmon-containers-release-1

Dati mancanti

L'attivazione di Container insights su un cluster può richiedere fino a 15 minuti prima che i dati appaiano. Se i dati non vengono visualizzati dopo 15 minuti, vedere le sezioni seguenti per problemi e soluzioni potenziali.

Messaggio di errore durante il recupero dei dati

Il messaggio Error retrieving data di errore potrebbe verificarsi se l'area di lavoro Log Analytics in cui il cluster inviava i dati è stato eliminato. In tal caso, disabilitare il monitoraggio per il cluster e abilitare nuovamente Informazioni dettagliate contenitore usando un'altra area di lavoro.

Autenticazione locale disabilitata

Controllare se l'area di lavoro Log Analytics è configurata per l'autenticazione locale con il comando dell'interfaccia della riga di comando seguente.

az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"

Se disableLocalAuth = true, eseguire il comando seguente.

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 |

Limite giornaliero raggiunto

Quando viene raggiunto il limite giornaliero per un'area di lavoro Log Analytics, la raccolta dei dati verrà interrotta fino al tempo di reimpostazione. Vedere Limite giornaliero di Log Analytics.

DCR non distribuita con Terraform

Se "Container insights" è 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. Vedere Abilitare informazioni dettagliate sui contenitori con Terraform.

Informazioni dettagliate contenitore che non contengono alcuna informazione

Se non è possibile visualizzare le informazioni sullo stato o non vengono restituiti risultati da una query di log, seguire questa procedura.

  1. Controllare lo stato dell'agente con il comando seguente:

    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 che il pod sia in esecuzione, controllane lo stato utilizzando 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.

Le metriche non vengono raccolte

  1. Verificare che l'assegnazione del ruolo Monitoring Metrics Publisher esista usando il seguente comando 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"

    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

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 sulle 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. Consulta i prerequisiti per i cluster Kubernetes ibridi.

Valori di immagine e nome non popolati nella tabella ContainerLog

Per la versione ciprod12042019 dell'agente e versioni successive, queste due proprietà non vengono popolate per impostazione predefinita per ogni riga di log per ridurre al minimo i costi sostenuti nei dati di log raccolti. È possibile abilitare la raccolta di queste proprietà o modificare le query per includere queste proprietà da altre tabelle.

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 è apparsa in precedenza nella tabella ContainerLog) nel campo KubepodInventory della tabella ContainerName unendo alla proprietà ContainerID.

La query di esempio seguente illustra come utilizzare le join per recuperare questi valori.

//Set the time window for the query
let startTime = ago(1h);
let endTime = now();
//
//Get the latest Image & ImageTag for every containerID
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;
//
//Get the latest Name for every containerID
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//
//Join the above to get a jointed table that has name, image & imagetag. Outer left is used in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//
//Join ContainerLog table with the jointed table above, project-away redundant fields/columns, and rename columns that were rewritten. Outer left is used so logs aren't lost even if no container metadata for loglines is found.
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

Avvertimento

L'abilitazione delle proprietà non è consigliata per cluster di grandi dimensioni con più di 50 nodi. Genera chiamate del server API da ogni nodo del cluster e aumenta anche le dimensioni dei dati per ogni riga di log raccolta.

Per abilitare la raccolta di questi campi in modo da non dover modificare le query, abilitare l'impostazione log_collection_settings.enrich_container_logs nella mappa di configurazione dell'agente come descritto nelle impostazioni di configurazione della raccolta dati.

Log non raccolti nel cluster locale di Azure

Se il cluster è stato registrato e/o configurato Insights per Azure Local prima di novembre 2023, le funzionalità che usano l'agente di Monitoraggio di Azure in Azure Locale, ad esempio Arc for Servers Insights, VM Insights, Container Insights, Defender for Cloud o Microsoft Sentinel potrebbero non raccogliere correttamente i log e i dati degli eventi. Per i passaggi per riconfigurare l'agente e gli Insights per Azure Locale, vedere Riparazione dell'agente AMA per Azure Locale.

Dati mancanti in cluster di grandi dimensioni

Se i dati non sono presenti in una delle tabelle seguenti, il problema probabile è correlato all'analisi dei payload di grandi dimensioni a causa di un numero elevato di pod o nodi. Questo problema è noto nel plug-in Ruby per analizzare il payload JSON di grandi dimensioni a causa del PODS_CHUNK_SIZE predefinito, ovvero 1000.

Esistono piani per modificare il valore PODS_CHUNK_SIZE predefinito in un valore più piccolo per risolvere questo problema.

  • KubePodInventory
  • KubeNodeInventory
  • KubeEvents
  • InventarioKubePV
  • KubeServices

  1. Verificare se nel cluster è stato configurato un valore più piccolo PODS_CHUNK_SIZE usando i comandi seguenti.

    # verify if kube context being set for right cluster
kubectl cluster-info

# check if the configmap configured with smaller PODS_CHUNK_SIZE chunksize already
kubectl logs <ama-logs-rs pod name> -n kube-system -c ama-logs | grep PODS_CHUNK_SIZE

# If it's configured, the output will be similar to "Using config map value: PODS_CHUNK_SIZE = 10"

  2. Se il cluster è già configurato per un valore più piccolo PODS_CHUNK_SIZE , è necessario abilitare il cluster per un cluster di grandi dimensioni.

  3. Se il cluster usa l'impostazione predefinita PODS_CHUNK_SIZE=1000, verificare se il cluster ha un numero elevato di pod o nodi.

    # check the total number of PODS
kubectl get pods -A -o wide | wc -l

# check the total number of NODES
kubectl get nodes -o wide | wc -l

  4. Dopo aver confermato il numero di pod e nodi è ragionevolmente elevato e il cluster usa il valore predefinito PODS_CHUNK_SIZE=1000 , usare i comandi seguenti per configurare configmap.

    # Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace
kubectl get cm -n kube-system | grep container-azm-ms-agentconfig

# If there is no existing container-azm-ms-agentconfig configmap, then configmap needs to be downloaded  and applied
curl -L https://raw.githubusercontent.com/microsoft/Docker-Provider/refs/heads/ci_prod/kubernetes/container-azm-ms-agentconfig.yaml -o container-azm-ms-agentconfig
kubectl apply -f container-azm-ms-agentconfig

# Edit the configmap and uncomment agent_settings.chunk_config and PODS_CHUNK_SIZE lines under agent-settings: |- in the configmap
kubectl edit cm -n kube-system  container-azm-ms-agentconfig -o yaml

Agente terminato a causa di esaurimento di memoria

Contenitore Daemonset terminato a causa di esaurimento di memoria

  1. Per iniziare, identificare quale contenitore viene terminato per esaurimento di memoria (OOM) usando i comandi seguenti. In questo modo verranno identificati ama-logs, ama-logs-prometheuso entrambi.

    # verify if kube context being set for right cluster
kubectl cluster-info

# get the ama-logs pods and status
kubectl get pods -n kube-system -o custom-columns=NAME:.metadata.name | grep -E ama-logs-[a-z0-9]{5}

# from the result of above command, find out which ama-logs pod instance getting OOM killed
kubectl describe pod <ama-logs-pod> -n kube-system

# review the output of the above command to findout which ama-logs container is getting OOM killed

  2. Controllare se sono presenti errori di rete nel mdsd.err file di log usando i comandi seguenti.

    mkdir log
# for ama-logs-prometheus container use -c ama-logs-prometheus instead of -c ama-logs
kubectl cp -c ama-logs kube-system/<ama-logs pod name>:/var/opt/microsoft/linuxmonagent/log log
cd log
cat mdsd.err

  3. Se gli errori sono causati dall'endpoint in uscita sono bloccati, vedere Requisiti del firewall di rete per il monitoraggio del cluster Kubernetes per i requisiti degli endpoint.

  4. Se gli errori sono dovuti all'endpoint di raccolta dati mancante (DCE) o alla regola di raccolta dati (DCR), riabilitare le informazioni dettagliate sui contenitori usando le indicazioni riportate in Abilitare il monitoraggio per i cluster Kubernetes.

  5. Se non sono presenti errori, potrebbe essere correlato alla scalabilità dei log. Vedere Raccolta di log su larga scala in Informazioni dettagliate contenitore (anteprima).

Contenitore del set di repliche terminato a causa di esaurimento di memoria

  1. Identificare con quale frequenza il pod ama-logs-rs viene terminato a causa di esaurimento di memoria utilizzando i seguenti comandi.

    # verify if kube context being set for right cluster
kubectl cluster-info

# get the ama-logs pods and status
kubectl get pods -n kube-system -o wide | grep ama-logs-rs

# from the result of above command, find out which ama-logs pod instance getting OOM killed
kubectl describe pod <ama-logs-rs-pod> -n kube-system

# review the output of the above command to confirm the OOM kill

  2. Se ama-logs-rs viene terminato a causa di esaurimento di memoria, verificare se sono presenti errori di rete con i comandi seguenti.

     mkdir log
 kubectl cp -c ama-logs kube-system/<ama-logs-rs pod name>:/var/opt/microsoft/linuxmonagent/log log
 cd log
 cat mdsd.err

  3. Se gli errori sono causati dall'endpoint in uscita sono bloccati, vedere Requisiti del firewall di rete per il monitoraggio del cluster Kubernetes per i requisiti degli endpoint.

  4. Se gli errori sono dovuti all'endpoint di raccolta dati mancante (DCE) o alla regola di raccolta dati (DCR), riabilitare le informazioni dettagliate sui contenitori usando le indicazioni riportate in Abilitare il monitoraggio per i cluster Kubernetes.

  5. Se non sono presenti errori di rete, verificare se lo scraping prometheus a livello di cluster è abilitato esaminando le impostazioni [prometheus_data_collection_settings.cluster] in configmap.

    # Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace
kubectl get cm -n kube-system | grep container-azm-ms-agentconfig
# If there is no existing container-azm-ms-agentconfig configmap, then means cluster level prometheus data collection not enabled

  6. Controllare le dimensioni del cluster in base al conteggio dei nodi e dei pod.

    # Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace
NodeCount=$(kubectl get nodes | wc -l)
echo "Total number of nodes: ${NodeCount}"
PodCount=$(kubectl get pods -A -o wide | wc -l)
echo "Total number of pods: ${PodCount}"

# If there is no existing container-azm-ms-agentconfig configmap, then means cluster level prometheus data collection is not enabled.

  7. Se si determina che il problema è correlato alla scalabilità del cluster, è necessario aumentare il limite di memoria ama-logs-rs. Aprire un caso di supporto con Microsoft per effettuare questa richiesta.

Problemi di latenza

Per impostazione predefinita, Informazioni dettagliate contenitore raccolgono i dati di monitoraggio ogni 60 secondi, a meno che non si configurino le impostazioni di raccolta dati o non si aggiunga una trasformazione. Per informazioni dettagliate sulla latenza e sui tempi di inserimento previsti in un'area di lavoro Log Analytics, vedere Tempo di inserimento dei dati di log in Monitoraggio di Azure .

Controllare le latenze per la tabella segnalata e l'intervallo di tempo nell'area di lavoro Log Analytics associata ai cluster usando la query seguente.

let clusterResourceId = "/subscriptions/<subscriptionId>/resourceGroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>";
let startTime = todatetime('2024-11-20T20:34:11.9117523Z');
let endTime = todatetime('2024-11-21T20:34:11.9117523Z');
KubePodInventory #Update this table name to the one you want to check
| where _ResourceId =~ clusterResourceId
| where TimeGenerated >= startTime and TimeGenerated <= endTime
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize max(E2EIngestionLatency), max(AgentLatency) by Computer
| project Computer, max_AgentLatency, max_ingestionLatency = (max_E2EIngestionLatency -  max_AgentLatency),max_E2EIngestionLatency

Se vengono visualizzate latenze degli agenti elevate, verificare se è stato configurato un intervallo di raccolta di log diverso rispetto al valore predefinito di 60 secondi nel Registro Azure Container Insights.

# set the subscriptionId of the cluster
az account set -s "<subscriptionId>"
# check if ContainerInsightsExtension  data collection rule association exists
az monitor data-collection rule association list --resource <clusterResourceId>
# get the data collection rule resource id associated to ContainerInsightsExtension from above step
az monitor data-collection rule show  --ids  <dataCollectionRuleResourceIdFromAboveStep>
# check if there are any data collection settings related to interval from the output of the above step

Problemi di registrazione multilinea

La funzionalità di registrazione su più righe può essere abilitata tramite configmap e supporta i seguenti scenari.

  • Supporta i messaggi di log fino a 64 KB anziché il limite predefinito di 16 KB.
  • Unisce le tracce dello stack di chiamate di eccezione per i linguaggi supportati .NET, Go, Python e Java.

Verificare che la funzionalità multilinea e lo schema ContainerLogV2 siano abilitati con i comandi seguenti.

    # get the list of ama-logs and these pods should be in Running state
    # If these are not in Running state, then this needs to be investigated
    kubectl get po -n kube-system | grep ama-logs

    # exec into any one of the ama-logs daemonset pod and check for the environment variables
    kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash

    # after exec into the container run this command
    env | grep AZMON_MULTILINE

    # result should have environment variables which indicates the multiline and languages enabled
    AZMON_MULTILINE_LANGUAGES=java,go
    AZMON_MULTILINE_ENABLED=true

    # check if the containerlog v2 schema enabled or not
    env | grep AZMON_CONTAINER_LOG_SCHEMA_VERSION

    # output should be v2. If not v2, then check whether this is being enabled through DCR
    AZMON_CONTAINER_LOG_SCHEMA_VERSION=v2
  • Last updated on