Problemen met Container Insights oplossen

2025-04-22

In dit artikel worden enkele veelvoorkomende problemen en probleemoplossingsstappen besproken bij het gebruik van Container Insights om uw Kubernetes-cluster te bewaken.

Er worden dubbele waarschuwingen gemaakt

Mogelijk hebt u Prometheus-waarschuwingsregels ingeschakeld zonder de aanbevolen waarschuwingen van Container Insights uit te schakelen. Zie Migreer van Container Insights aanbevolen waarschuwingen naar Prometheus aanbevolen waarschuwingsregels (voorbeeld).

Clustermachtigingen

Als u geen vereiste machtigingen voor het cluster hebt, ziet u mogelijk het foutbericht. 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.

Container Insights heeft gebruikers eerder toegang gegeven tot de Azure-portal-ervaring op basis van de toegangsmachtiging van de Log Analytics-werkruimte. Nu wordt de machtiging op clusterniveau gecontroleerd om toegang te bieden tot de Azure Portal-ervaring. Mogelijk hebt u de clusterbeheerder nodig om deze machtiging toe te wijzen.

Wijs voor eenvoudige alleen-lezentoegang op clusterniveau de rol Bewakingslezer toe voor de volgende typen clusters.

AKS zonder RBAC-autorisatie (Op rollen gebaseerd toegangsbeheer) van Kubernetes ingeschakeld
AKS ingeschakeld met eenmalige aanmelding op basis van Microsoft Entra SAML
AKS ingeschakeld met Kubernetes RBAC-autorisatie
AKS geconfigureerd met de clusterrolbinding clusterMonitoringUser
Azure Arc-ingeschakelde Kubernetes-clusters

Zie Rolmachtigingen toewijzen aan een gebruiker of groep voor meer informatie over het toewijzen van deze rollen voor AKS- en toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS) voor meer informatie over roltoewijzingen.

Onboarding- en updateproblemen

In de volgende secties worden problemen beschreven die kunnen optreden wanneer u Container Insights in uw cluster onboardt of bijwerkt.

Ontbrekende abonnementsregistratie

Als u de fout Missing Subscription registrationziet, registreert u de resourceprovider Microsoft.OperationsManagement in het abonnement van uw Log Analytics-werkruimte. Zie Fouten oplossen voor de registratie van de resourceprovider.

Autorisatiefout

Wanneer u Container Insights inschakelt of een cluster bijwerkt, wordt er mogelijk een foutbericht weergegeven zoals The client <user's identity> with object id <user's objectId> does not have authorization to perform action Microsoft.Authorization/roleAssignments/write over scope.

Tijdens het onboarding- of updateproces wordt geprobeerd om de rol Monitoring Metrics Publisher toe te wijzen aan de clusterresource. De gebruiker die het proces initieert, moet toegang hebben tot de machtiging Microsoft.Authorization/roleAssignments/write voor het AKS-clusterresourcebereik. Alleen leden van de ingebouwde rollen Eigenaar en Beheerder voor gebruikerstoegang krijgen toegang tot deze machtiging. Als voor uw beveiligingsbeleid u gedetailleerde machtigingen moet toewijzen, raadpleegt u aangepaste Azure-rollen en wijst u machtigingen toe aan de gebruikers die dit vereisen. Wijs de rol Publisher toe aan de Monitoring Metrics via de Azure-portal met behulp van de richtlijnen bij Azure-rollen toewijzen met behulp van de Azure-portal.

Kan een cluster niet upgraden

Als u containerinzichten niet kunt upgraden op een AKS-cluster nadat het is geïnstalleerd, is de Log Analytics-werkruimte waar het cluster de gegevens heeft verzonden mogelijk verwijderd. Schakel bewaking voor het cluster uit en schakel containerinzichten opnieuw in met behulp van een andere werkruimte.

De installatie van de Azure Monitor Containers-extensie mislukt

De fout manifests contain a resource that already exists geeft aan dat resources van de Container Insights-agent al bestaan op een Kubernetes-cluster met Azure Arc. Dit betekent dat de Container Insights-agent al is geïnstalleerd. Los dit probleem op door de bestaande resources van de Container Insights-agent op te schonen en vervolgens de Azure Monitor Containers-extensie in te schakelen.

AKS-clusters

Voer de volgende commando's uit en zoek naar het Azure Monitor Agent add-on profiel om te controleren of de AKS Monitoring-invoegtoepassing is ingeschakeld.

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

Als de uitvoer een Azure Monitor Agent-invoegtoepassingsprofielconfiguratie bevat met een resource-ID van de Log Analytics-werkruimte, is de AKS-bewakingsinvoegtoepassing geactiveerd en moet deze worden uitgeschakeld met de volgende opdracht.

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

Niet-AKS-clusters

Voer het volgende commando uit op het cluster om te controleren of de azmon-containers-release-1 Helm-chartrelease bestaat.

helm list  -A

Als de uitvoer aangeeft dat de azmon-containers-release-1 bestaat, verwijdert u de Helm-chart release met de volgende opdracht.

helm del azmon-containers-release-1

Ontbrekende gegevens

Het kan tot 15 minuten duren voordat gegevens worden weergegeven nadat u Container insights hebt ingeschakeld voor een cluster. Als u na 15 minuten geen gegevens ziet, raadpleegt u de volgende secties voor mogelijke problemen en oplossingen.

Foutbericht bij het ophalen van gegevens

Het foutbericht Error retrieving data kan optreden als de Log Analytics-werkruimte waar het cluster de gegevens verzendt, is verwijderd. Als dit het geval is, schakelt u bewaking voor het cluster uit en schakelt u containerinzichten opnieuw in met behulp van een andere werkruimte.

Lokale verificatie uitgeschakeld

Controleer of de Log Analytics-werkruimte is geconfigureerd voor lokale verificatie met de volgende CLI-opdracht.

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

Als disableLocalAuth = true, voert u de volgende opdracht uit.

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 |

Daglimiet voldaan

Wanneer aan de dagelijkse limiet wordt voldaan voor een Log Analytics-werkruimte, stopt het verzamelen van gegevens totdat de tijd voor opnieuw instellen is bereikt. Zie de dagelijkse limiet van Log Analytics.

DCR niet geïmplementeerd met Terraform

Als Container Insights is ingeschakeld met Terraform en msi_auth_for_monitoring_enabled is ingesteld op true, moet u ervoor zorgen dat DCR- en DCRA-resources ook worden geïmplementeerd om logboekverzameling in te schakelen. Zie Containerinzichten inschakelen.

Container insights rapporteert geen informatie

Gebruik de volgende stappen als u geen statusgegevens kunt weergeven of als er geen resultaten worden geretourneerd vanuit een logboekquery.

Controleer de status van de agent met de volgende opdracht:

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

Het aantal pods moet gelijk zijn aan het aantal Linux-knooppunten in het cluster. De uitvoer moet er ongeveer uitzien als in het volgende voorbeeld, waarmee wordt aangegeven dat deze correct is geïmplementeerd:
```
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
```
Als u Windows Server-knooppunten hebt, controleert u de status van de agent door de volgende opdracht uit te voeren:

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

Het aantal pods moet gelijk zijn aan het aantal Windows-knooppunten in het cluster. De uitvoer moet er ongeveer uitzien als in het volgende voorbeeld, waarmee wordt aangegeven dat deze correct is geïmplementeerd:
```
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
```
Controleer de implementatiestatus met behulp van de volgende opdracht:

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

De uitvoer moet er ongeveer uitzien als in het volgende voorbeeld, waarmee wordt aangegeven dat deze correct is geïmplementeerd:
```
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
```

Controleer de status van de pod om te bevestigen dat deze draait met behulp van de opdracht kubectl get pods --namespace=kube-system.

De uitvoer moet lijken op het volgende voorbeeld met de status Running voor 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

Als de pods actief zijn, maar er geen gegevens in Log Analytics worden gevonden of als gegevens alleen op een bepaald moment van de dag worden verzonden, kan dit erop wijzen dat de dagelijkse limiet is bereikt. Wanneer deze limiet elke dag wordt bereikt, stoppen gegevens met worden opgenomen in de Log Analytics-werkruimte en wordt het opnieuw ingesteld op het resetmoment. Zie Log Analytics Daily Cap voor meer informatie.

Er worden geen metrische gegevens verzameld

Controleer of de roltoewijzing Monitoring Metrics Publisher bestaat met behulp van de volgende CLI-opdracht:
```
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"
```
Voor clusters met MSI verandert de door de gebruiker toegewezen client-id voor Azure Monitor Agent telkens wanneer bewaking wordt ingeschakeld en uitgeschakeld, zodat de roltoewijzing moet bestaan op de huidige MSI-client-id.
Voor clusters waarvoor Microsoft Entra-pod-identiteit is ingeschakeld en MSI gebruikt:
- Controleer of het vereiste label kubernetes.azure.com/managedby: aks aanwezig is op de Azure Monitor Agent-pods met behulp van de volgende opdracht:
  
  kubectl get pods --show-labels -n kube-system | grep ama-logs
- Controleer of uitzonderingen zijn ingeschakeld wanneer podidentiteit is ingeschakeld met behulp van een van de ondersteunde methoden op https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.
  
  Voer de volgende opdracht uit om te controleren:
  
  kubectl get AzurePodIdentityException -A -o yaml
  
  U zou uitvoer moeten ontvangen die vergelijkbaar is met het volgende voorbeeld:
```
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
```

Prestatiegrafieken tonen geen CPU of geheugen van knooppunten en containers in een niet-Azure-cluster

Container Insights-agentpods gebruiken het cAdvisor eindpunt op de knooppuntagent om metrische prestatiegegevens te verzamelen. Controleer of de containeragent op het knooppunt is geconfigureerd om toe te staan cAdvisor secure port: 10250 of cAdvisor unsecure port: 10255 te worden geopend op alle knooppunten in het cluster om metrische prestatiegegevens te verzamelen. Zie de vereisten voor hybride Kubernetes-clusters.

Afbeeldings- en naamwaarden die niet zijn ingevuld in de ContainerLog-tabel

Voor agentversie ciprod12042019 en later worden deze twee eigenschappen niet standaard ingevuld voor elke logboekregel om de kosten te minimaliseren die worden gemaakt voor logboekgegevens die worden verzameld. U kunt de verzameling van deze eigenschappen inschakelen of uw query's wijzigen om deze eigenschappen uit andere tabellen op te nemen.

Wijzig uw query's om de Image en ImageTag eigenschappen uit de ContainerInventory tabel op te nemen door te joinen op de ContainerID eigenschap. U kunt de Name eigenschap (zoals deze eerder in de ContainerLog tabel is weergegeven) opnemen in het KubepodInventory-veld van de ContainerName tabel door te koppelen aan de ContainerID eigenschap.

In de volgende voorbeeldquery ziet u hoe u joins kunt gebruiken om deze waarden op te halen.

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

Waarschuwing

Het inschakelen van de eigenschappen wordt niet aanbevolen voor grote clusters met meer dan 50 knooppunten. Hiermee worden API-serveroproepen gegenereerd vanaf elk knooppunt in het cluster en wordt ook de gegevensgrootte verhoogd voor elke verzamelde logboekregel.

Als u het verzamelen van deze velden wilt inschakelen zodat u uw query's niet hoeft te wijzigen, schakelt u de instelling log_collection_settings.enrich_container_logs in de agentconfiguratietoewijzing in zoals beschreven in de configuratie-instellingen voor gegevensverzameling.

Logboeken die niet worden verzameld in een lokaal Azure-cluster

Als u uw cluster vóór november 2023 hebt geregistreerd en/of Insights hebt geconfigureerd voor Azure Local, zijn functies die gebruikmaken van de Azure Monitor-agent op Azure Local, zoals Arc for Servers Insights, VM Insights, Container Insights, Defender for Cloud of Microsoft Sentinel mogelijk niet correct logboeken en gebeurtenisgegevens verzameld. Zie AMA-agent herstellen voor Azure Local voor stappen voor het opnieuw configureren van de agent en Inzichten voor Azure Local.

Ontbrekende gegevens in grote clusters

Als er gegevens ontbreken in een van de volgende tabellen, is het waarschijnlijke probleem gerelateerd aan het parseren van grote gegevenshoeveelheden vanwege een groot aantal pods of knooppunten. Dit is een bekend probleem in de ruby-invoegtoepassing om de grote JSON-payload te parseren vanwege de standaardinstelling voor PODS_CHUNK_SIZE, die 1000 is.

Er zijn plannen om de standaardwaarde PODS_CHUNK_SIZE aan te passen op een kleinere waarde om dit probleem op te lossen.

Kube Pod-inventaris
KubeNodeInventory
KubeEvents
KubePVInventory
KubeServices

Controleer of u een kleinere PODS_CHUNK_SIZE waarde in uw cluster hebt geconfigureerd met behulp van de volgende opdrachten.

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

Als het cluster al is geconfigureerd voor een kleinere PODS_CHUNK_SIZE waarde, moet u het cluster inschakelen voor een groot cluster.

Als het cluster de standaardwaarde PODS_CHUNK_SIZE=1000gebruikt, controleert u of het cluster een groot aantal pods of knooppunten heeft.

# 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

Nadat u hebt bevestigd dat het aantal pods en knooppunten redelijk hoog is en het cluster de standaardwaarde PODS_CHUNK_SIZE=1000 gebruikt, gebruikt u de volgende opdrachten om de configmap te configureren.

# 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

Agent OOM vermoord

Daemonset-container die OOM vermoordde

Begin met het identificeren van welke container OOM wordt gedood met behulp van de volgende opdrachten. Dit identificeert ama-logs, ama-logs-prometheusof beide.

# 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

Controleer of er netwerkfouten in mdsd.err het logboekbestand zijn met behulp van de volgende opdrachten.

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

Als fouten worden veroorzaakt door het uitgaande eindpunt wordt geblokkeerd, raadpleegt u de netwerkfirewallvereisten voor het bewaken van het Kubernetes-cluster voor eindpuntvereisten.
Als er fouten optreden vanwege ontbrekend eindpunt voor gegevensverzameling (DCE) of DCR (Data Collection Rule), kunt u containerinzichten opnieuw inschakelen met behulp van de richtlijnen bij Bewaking inschakelen voor Kubernetes-clusters.
Als er geen fouten zijn, kan dit betrekking hebben op logaritmische schaal. Zie de verzameling logboeken met hoge schaal in Container Insights (preview).a0>

Replicasetcontainer die door OOM wordt gedood

Bepaal hoe vaak de ama-logs-rs-pod een OOM-kill krijgt met behulp van de volgende commando's.

# 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

Als ama-logs-rs worden gedood door OOM, controleert u of er netwerkfouten zijn met de volgende opdrachten.

 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

Als fouten worden veroorzaakt door het uitgaande eindpunt wordt geblokkeerd, raadpleegt u de netwerkfirewallvereisten voor het bewaken van het Kubernetes-cluster voor eindpuntvereisten.
Als er fouten optreden vanwege ontbrekend eindpunt voor gegevensverzameling (DCE) of DCR (Data Collection Rule), kunt u containerinzichten opnieuw inschakelen met behulp van de richtlijnen bij Bewaking inschakelen voor Kubernetes-clusters.

Als er geen netwerkfouten zijn, controleert u of prometheus-scraping op clusterniveau is ingeschakeld door de instellingen voor [prometheus_data_collection_settings.cluster] in configmap te controleren.

# 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

Controleer de clustergrootte in termen van het aantal knooppunten en pods.

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

Als u vaststelt dat het probleem te maken heeft met de schaal van het cluster, moet de geheugenlimiet voor ama-logs-rs worden verhoogd. Open een ondersteuningsaanvraag bij Microsoft om deze aanvraag te doen.

Latentieproblemen

Container Insights verzamelt standaard elke 60 seconden bewakingsgegevens, tenzij u instellingen voor gegevensverzameling configureert of een transformatie toevoegt. Zie De opnametijd van logboekgegevens in Azure Monitor voor gedetailleerde informatie over latentie en verwachte opnametijden in een Log Analytics-werkruimte.

Controleer de latenties voor het gerapporteerde tabel- en tijdvenster in de Log Analytics-werkruimte die is gekoppeld aan de clusters met behulp van de volgende query.

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

Als u hoge agentlatenties ziet, controleert u of u een ander interval voor logboekverzameling hebt geconfigureerd dan standaard 60 seconden in de Container Insights DCR.

# 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

Problemen met logboekregistratie met meerdere regels

De functie voor logboeken met meerdere regels kan worden ingeschakeld met configmap en ondersteunt de volgende scenario's.

Ondersteunt logboekberichten tot 64 kB in plaats van de standaardlimiet van 16 kB.
Smeedt stacktraces van uitzondering-aanroepen in ondersteunde talen .NET, Go, Python en Java.

Controleer of de functie met meerdere regels en het ContainerLogV2-schema zijn ingeschakeld met de volgende opdrachten.

    # 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