Problemen met Container Insights oplossen

Artikel
10/15/2024

Wanneer u de bewaking van uw AKS-cluster (Azure Kubernetes Service) configureert met Container Insights, kan er een probleem optreden dat het verzamelen of rapporteren van gegevens voorkomt. In dit artikel worden enkele veelvoorkomende problemen en stappen voor probleemoplossing besproken.

Veelvoorkomende foutberichten

De volgende tabel bevat een overzicht van bekende fouten die kunnen optreden wanneer u Container Insights gebruikt.

Foutberichten	Actie
Foutbericht 'Geen gegevens voor geselecteerde filters'	Het kan enige tijd duren voordat de controlegegevensstroom voor nieuwe clusters tot stand is gebracht. Sta ten minste 10 tot 15 minuten toe dat gegevens voor uw cluster worden weergegeven. Als de gegevens nog steeds niet worden weergegeven, controleert u of de Log Analytics-werkruimte is geconfigureerd voor `disableLocalAuth = true`. Zo ja, werk dan terug naar `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`
Foutbericht 'Fout bij het ophalen van gegevens'	Hoewel een AKS-cluster is ingesteld voor status- en prestatiebewaking, wordt er een verbinding tot stand gebracht tussen het cluster en een Log Analytics-werkruimte. Een Log Analytics-werkruimte wordt gebruikt om alle bewakingsgegevens voor uw cluster op te slaan. Deze fout kan optreden wanneer uw Log Analytics-werkruimte is verwijderd. Controleer of de werkruimte is verwijderd. Als dat het was, kan de bewaking van uw cluster opnieuw worden uitgevoerd met Container Insights. Geef vervolgens een bestaande werkruimte op of maak een nieuwe werkruimte. Als u opnieuw wilt inschakelen, schakelt u bewaking voor het cluster uit en schakelt u containerinzichten opnieuw in .
'Fout bij het ophalen van gegevens' na het toevoegen van Container Insights via `az aks cli`	Wanneer u bewaking inschakelt met behulp van, `az aks cli`worden containerinzichten mogelijk niet goed geïmplementeerd. Controleer of de oplossing is geïmplementeerd. Als u dit wilt controleren, gaat u naar uw Log Analytics-werkruimte en kijkt u of de oplossing beschikbaar is door verouderde oplossingen te selecteren in het deelvenster aan de linkerkant. U kunt dit probleem oplossen door de oplossing opnieuw te implementeren. Volg de instructies in Container Insights inschakelen.
Foutbericht 'Ontbrekende abonnementsregistratie'	Als u de fout 'Ontbrekende abonnementsregistratie voor Microsoft.OperationsManagement' ontvangt, kunt u dit oplossen door de resourceprovider Microsoft.OperationsManagement te registreren in het abonnement waarin de werkruimte is gedefinieerd. Zie Fouten voor resourceproviderregistratie oplossen voor de stappen.
Foutbericht 'De antwoord-URL die is opgegeven in de aanvraag komt niet overeen met de antwoord-URL's die zijn geconfigureerd voor de toepassing: '<toepassings-id>'.	Dit foutbericht wordt mogelijk weergegeven wanneer u livelogboeken inschakelt. Zie Containergegevens in realtime weergeven met Container Insights voor de oplossing.

Om het probleem vast te stellen, hebben we een script voor probleemoplossing opgegeven.

Verificatiefout tijdens onboarding of updatebewerking

Wanneer u Container Insights inschakelt of een cluster bijwerkt om het verzamelen van metrische gegevens te ondersteunen, krijgt u mogelijk een foutmelding zoals 'De client <user's Identity> met object-id <user's objectId> heeft geen autorisatie om actie Microsoft.Authorization/roleAssignments/write uit te voeren binnen het bereik'.

Tijdens het onboarding- of updateproces wordt geprobeerd om de roltoewijzing Monitoring Metrics Publisher toe te kennen op de clusterresource. De gebruiker die het proces initieert om Container Insights of de update in te schakelen ter ondersteuning van de verzameling metrische gegevens, moet toegang hebben tot de machtiging Microsoft.Authorization/roleAssignments/write voor het resourcebereik van het AKS-cluster. 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.

U kunt deze rol ook handmatig verlenen vanuit Azure Portal: wijs de rol Uitgever toe aan het bereik Metrische bewakingsgegevens . Raadpleeg Azure-rollen toewijzen met de Azure Portal voor informatie over het toewijzen van rollen.

Container Insights is ingeschakeld, maar rapporteert geen informatie

Om het probleem vast te stellen als u geen statusinformatie kunt weergeven of als er geen resultaten worden geretourneerd vanuit een logboekquery:

Controleer de status van de agent door de volgende opdracht uit te voeren:

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 controleren of deze wordt uitgevoerd met behulp van de opdracht kubectl get pods --namespace=kube-system.

De uitvoer moet lijken op het volgende voorbeeld met de status Running van ama-logboeken:

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 een actieve status hebben, maar er geen gegevens in Log Analytics staan of gegevens alleen tijdens een bepaald deel van de dag worden verzonden, kan dit een indicatie zijn dat aan de daglimiet is voldaan. Wanneer aan deze limiet elke dag wordt voldaan, worden gegevens niet meer opgenomen in de Log Analytics-werkruimte en worden ze opnieuw ingesteld op het moment dat ze opnieuw worden ingesteld. Zie Log Analytics Daily Cap voor meer informatie.
Als Containter-inzichten 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 Container Insights inschakelen voor gedetailleerde stappen.

ReplicaSet-pods van Container Insights-agent worden niet gepland op een niet-AKS-cluster

ReplicaSet-pods voor containerinzichtenagents hebben een afhankelijkheid van de volgende knooppuntkiezers op de werkknooppunten (of agent) voor de planning:

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

Als er geen knooppuntlabels aan uw werkknooppunten zijn gekoppeld, worden agentReplicaSet-pods niet gepland. Zie Kubernetes labelkiezers toewijzen voor instructies voor het koppelen van het label.

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 voor meer informatie.

Niet-AKS-clusters worden niet weergegeven in Container Insights

Als u het niet-AKS-cluster in Container Insights wilt weergeven, is leestoegang vereist in de Log Analytics-werkruimte die dit inzicht ondersteunt en op de Container Insights-oplossingsresource ContainerInsights (werkruimte).

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

De installatie van de Azure Monitor Containers-extensie mislukt op een Kubernetes-cluster met Azure Arc

De fout 'manifesten bevatten een resource die al bestaat' geeft aan dat de resources van de Container Insights-agent al bestaan in het Kubernetes-cluster met Azure Arc. Deze fout geeft aan dat de Container Insights-agent al is geïnstalleerd. Deze wordt geïnstalleerd via een Helm-grafiek azuremonitor-containers of de bewakingsinvoegtoepassing als het een AKS-cluster is dat is verbonden via Azure Arc.

De oplossing voor dit probleem is het opschonen van de bestaande resources van de Container Insights-agent als deze bestaat. Schakel vervolgens de Azure Monitor Containers-extensie in.

Voor niet-AKS-clusters

Voer op basis van het K8s-cluster dat is verbonden met Azure Arc de volgende opdracht uit om te controleren of de azmon-containers-release-1 Helm-grafiekrelease al dan niet bestaat:

helm list -A
Als de uitvoer van de voorgaande opdracht aangeeft dat deze azmon-containers-release-1 bestaat, verwijdert u de Helm-grafiekrelease:

helm del azmon-containers-release-1

Voor AKS-clusters

Voer de volgende opdrachten uit en zoek het invoegtoepassingsprofiel van de Azure Monitor-agent om te controleren of de invoegtoepassing AKS-bewaking is ingeschakeld:
```
az  account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>
```
Als de uitvoer een configuratie van een invoegtoepassingsprofiel voor de Azure Monitor-agent bevat met een resource-id van een Log Analytics-werkruimte, geeft deze informatie aan dat de invoegtoepassing AKS-bewaking is ingeschakeld en moet worden uitgeschakeld:

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

Als de voorgaande stappen de installatie van azure Monitor Containers Extension-problemen niet hebben opgelost, maakt u een ondersteuningsticket om naar Microsoft te verzenden voor verder onderzoek.

Dubbele waarschuwingen die worden ontvangen

Mogelijk hebt u Prometheus-waarschuwingsregels ingeschakeld zonder containerinzichten aanbevolen waarschuwingen uit te schakelen. Zie Migrate from Container Insights recommended alerts to Prometheus recommended alert rules (preview).

Container Insights heeft gebruikers in het verleden 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
Kubernetes-clusters met Azure Arc

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.

Ik zie de waarden van de eigenschap Afbeelding en Naam niet ingevuld wanneer ik een query op de ContainerLog-tabel voer

Voor agentversie ciprod12042019 en hoger worden deze twee eigenschappen standaard niet ingevuld voor elke logboeklijn om de kosten voor verzamelde logboekgegevens te minimaliseren. Er zijn twee opties om een query uit te voeren op de tabel die deze eigenschappen met hun waarden bevat:

Optie 1

Voeg andere tabellen toe om deze eigenschapswaarden op te nemen in de resultaten.

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

Het volgende voorbeeld is een voorbeeld van een gedetailleerde query waarin wordt uitgelegd hoe u deze veldwaarden kunt ophalen met joins.

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

Optie 2

Verzameling opnieuw in te stellen voor deze eigenschappen voor elke containerlogboekregel.

Als de eerste optie niet handig is vanwege betrokken querywijzigingen, kunt u deze velden opnieuw verzamelen. Schakel de instelling log_collection_settings.enrich_container_logs in de configuratietoewijzing van de agent in, zoals beschreven in de configuratie-instellingen voor gegevensverzameling.

Notitie

We raden de tweede optie niet aan voor grote clusters met meer dan 50 knooppunten. Er worden API-serveroproepen gegenereerd vanaf elk knooppunt in het cluster om deze verrijking uit te voeren. Met deze optie wordt ook de gegevensgrootte verhoogd voor elke verzamelde logboeklijn.

Ik kan een cluster niet upgraden na onboarding

Dit is het scenario: U hebt Container Insights ingeschakeld voor een Azure Kubernetes Service-cluster. Vervolgens hebt u de Log Analytics-werkruimte verwijderd waarin het cluster de gegevens heeft verzonden. Wanneer u het cluster nu probeert te upgraden, mislukt het. Als u dit probleem wilt omzeilen, moet u bewaking uitschakelen en deze vervolgens opnieuw inschakelen door te verwijzen naar een andere geldige werkruimte in uw abonnement. Wanneer u de clusterupgrade opnieuw probeert uit te voeren, moet dit worden verwerkt en voltooid.

Logboeken niet verzamelen in Een Azure Stack HCI-cluster

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

Volgende stappen

Wanneer bewaking is ingeschakeld voor het vastleggen van metrische statusgegevens voor de AKS-clusterknooppunten en -pods, zijn deze metrische statusgegevens beschikbaar in Azure Portal. Zie Azure Kubernetes-Servicestatus voor meer informatie over het gebruik van Container Insights.

Delen via