Dela via

Felsöka containerinsikter

  • Artikel

När du konfigurerar övervakning av ditt AKS-kluster (Azure Kubernetes Service) med containerinsikter kan det uppstå ett problem som förhindrar datasamling eller rapporteringsstatus. I den här artikeln beskrivs några vanliga problem och felsökningssteg.

Kända felmeddelanden

I följande tabell sammanfattas kända fel som kan uppstå när du använder Container Insights.

Felmeddelanden Åtgärd
Felmeddelandet "Inga data för valda filter" Det kan ta lite tid att upprätta övervakningsdataflödet för kluster som skapats nyligen. Tillåt minst 10 till 15 minuter för att data ska visas för klustret.

Om data fortfarande inte visas kontrollerar du om Log Analytics-arbetsytan har konfigurerats för disableLocalAuth = true. Om ja, uppdatera tillbaka till 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
Felmeddelandet "Det gick inte att hämta data" Medan ett AKS-kluster konfigureras för hälso- och prestandaövervakning upprättas en anslutning mellan klustret och en Log Analytics-arbetsyta. En Log Analytics-arbetsyta används för att lagra alla övervakningsdata för klustret. Det här felet kan inträffa när Log Analytics-arbetsytan har tagits bort. Kontrollera om arbetsytan har tagits bort. I så fall kan du återanvända övervakning av klustret med containerinsikter. Ange sedan en befintlig arbetsyta eller skapa en ny. Om du vill kunna återanvända inaktiverar du övervakning för klustret och aktiverar containerinsikter igen.
"Det gick inte att hämta data" när containerinsikter har lagts till via az aks cli När du aktiverar övervakning med hjälp az aks cliav kanske containerinsikter inte distribueras korrekt. Kontrollera om lösningen har distribuerats. Kontrollera genom att gå till Log Analytics-arbetsytan och se om lösningen är tillgänglig genom att välja Äldre lösningar i fönstret till vänster. Lös problemet genom att distribuera om lösningen. Följ anvisningarna i Aktivera containerinsikter.
Felmeddelande om att prenumerationsregistrering saknas Om du får felet "Prenumerationsregistrering saknas för Microsoft.OperationsManagement" kan du lösa det genom att registrera resursprovidern Microsoft.OperationsManagement i prenumerationen där arbetsytan har definierats. Stegen finns i Lösa fel för registrering av resursprovider.
Felmeddelandet "Svars-URL:en som anges i begäran matchar inte de svars-URL:er som konfigurerats för programmet: "<program-ID>". Du kan se det här felmeddelandet när du aktiverar liveloggar. Lösningen finns i Visa containerdata i realtid med containerinsikter.

För att diagnostisera problemet har vi angett ett felsökningsskript.

Auktoriseringsfel vid registrering eller uppdatering

När du aktiverar Container Insights eller uppdaterar ett kluster för att stödja insamling av mått kan du få ett felmeddelande som "Klienten <user's Identity> med objekt-ID <user's objectId> har inte behörighet att utföra åtgärder Microsoft.Authorization/roleAssignments/write över omfånget".

Under registrering eller uppdatering görs ett försök att bevilja rolltilldelningen Monitoring Metrics Publisher på klusterresursen. Användaren som initierar processen för att aktivera containerinsikter eller uppdateringen för att stödja insamlingen av mått måste ha åtkomst till behörigheten Microsoft.Authorization/roleAssignments/write i AKS-klusterresursomfånget. Endast medlemmar i de inbyggda rollerna Ägare och Administratör för användaråtkomst beviljas åtkomst till den här behörigheten. Om dina säkerhetsprinciper kräver att du tilldelar detaljerade behörigheter läser du Anpassade Azure-roller och tilldelar behörighet till de användare som behöver dem.

Du kan också bevilja den här rollen manuellt från Azure Portal: Tilldela utgivarrollen till omfånget Övervakningsmått. Detaljerade steg finns i Tilldela Azure-roller med hjälp av Azure Portal.

Containerinsikter är aktiverade men rapporterar ingen information

Diagnostisera problemet om du inte kan visa statusinformation eller om inga resultat returneras från en loggfråga:

  1. Kontrollera statusen för agenten genom att köra följande kommando:

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

    Antalet poddar ska vara lika med antalet Linux-noder i klustret. Utdata bör likna följande exempel, vilket indikerar att det har distribuerats korrekt:

    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. Om du har Windows Server-noder kontrollerar du agentens status genom att köra följande kommando:

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

    Antalet poddar ska vara lika med antalet Windows-noder i klustret. Utdata bör likna följande exempel, vilket indikerar att det har distribuerats korrekt:

    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. Kontrollera distributionsstatusen med hjälp av följande kommando:

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

    Utdata bör likna följande exempel, vilket indikerar att det har distribuerats korrekt:

    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. Kontrollera statusen för podden för att kontrollera att den körs med hjälp av kommandot kubectl get pods --namespace=kube-system.

    Utdata bör likna följande exempel med statusen Running för för ama-loggar:

    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. Om poddarna är i ett körningstillstånd, men det inte finns några data i Log Analytics eller om data bara verkar skickas under en viss del av dagen, kan det vara en indikation på att det dagliga taket har uppfyllts. När den här gränsen uppfylls varje dag slutar data att matas in på Log Analytics-arbetsytan och återställs vid återställningstiden. Mer information finns i Log Analytics Daily Cap.

  6. Om Containter Insights är aktiverat med Terraform och msi_auth_for_monitoring_enabled är inställt på truekontrollerar du att DCR- och DCRA-resurser också distribueras för att aktivera logginsamling. Detaljerade steg finns i aktivera containerinsikter.

Containerinsikter-agenten ReplicaSet Pods schemaläggs inte i ett icke-AKS-kluster

Container Insights-agenten ReplicaSet Pods har ett beroende av följande nodväljare på arbetsnoderna (eller agenten) för schemaläggningen:

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

Om dina arbetsnoder inte har nodetiketter kopplade schemaläggs inte agentreplikuppsättningspoddar. Anvisningar om hur du bifogar etiketten finns i Tilldela etikettväljare för Kubernetes.

Prestandadiagram visar inte CPU eller minne för noder och behållare i ett kluster som inte är Azure

Container Insights-agentpoddar använder cAdvisor-slutpunkten på nodagenten för att samla in prestandamått. Kontrollera att den containerbaserade agenten på noden är konfigurerad för att tillåta cAdvisor secure port: 10250 eller cAdvisor unsecure port: 10255 öppnas på alla noder i klustret för att samla in prestandamått. Mer information finns i förhandskraven för Kubernetes-hybridkluster .

Icke-AKS-kluster visas inte i containerinsikter

Om du vill visa det icke-AKS-klustret i Container Insights krävs läsåtkomst på Log Analytics-arbetsytan som stöder den här insikten och på containerinsiktslösningsresursen ContainerInsights (arbetsyta).

Värden samlas inte in

  1. Kontrollera att rolltilldelningen Monitoring Metrics Publisher finns med hjälp av följande CLI-kommando:

    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"

    För kluster med MSI ändras det användartilldelade klient-ID:t för Azure Monitor Agent varje gång övervakning aktiveras och inaktiveras, så rolltilldelningen bör finnas på det aktuella MSI-klient-ID:t.

  2. För kluster med Microsoft Entra-poddidentitet aktiverad och med MSI:

    • Kontrollera att den obligatoriska etiketten kubernetes.azure.com/managedby: aks finns i Azure Monitor Agent-poddarna med hjälp av följande kommando:

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

    • Kontrollera att undantag är aktiverade när poddidentiteten är aktiverad med någon av metoderna som stöds på https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.

      Kör följande kommando för att verifiera:

      kubectl get AzurePodIdentityException -A -o yaml

      Du bör få utdata som liknar följande exempel:

      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

Installationen av Azure Monitor Containers-tillägget misslyckas i ett Azure Arc-aktiverat Kubernetes-kluster

Felet "manifest innehåller en resurs som redan finns" anger att resurser i Container Insights-agenten redan finns i Det Azure Arc-aktiverade Kubernetes-klustret. Det här felet anger att Container Insights-agenten redan är installerad. Det installeras antingen via ett Helm-diagram för azuremonitor-containers eller övervakningstillägget om det är ett AKS-kluster som är anslutet via Azure Arc.

Lösningen på det här problemet är att rensa befintliga resurser i Container Insights-agenten om den finns. Aktivera sedan Azure Monitor Containers-tillägget.

För icke-AKS-kluster

  1. Mot K8s-klustret som är anslutet till Azure Arc kör du följande kommando för att kontrollera om azmon-containers-release-1 Helm-diagramversionen finns eller inte:

    helm list -A

  2. Om utdata från föregående kommando anger att det azmon-containers-release-1 finns tar du bort Helm-diagramversionen:

    helm del azmon-containers-release-1

För AKS-kluster

  1. Kör följande kommandon och leta efter tilläggsprofilen för Azure Monitor Agent för att kontrollera om AKS-övervakningstillägget är aktiverat:

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

  2. Om utdata innehåller en Azure Monitor Agent-tilläggsprofilkonfiguration med ett Resurs-ID för Log Analytics-arbetsytan anger den här informationen att AKS-övervakningstillägget är aktiverat och måste inaktiveras:

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

Om föregående steg inte löste problemet med installationen av Azure Monitor Containers-tillägget skapar du ett supportärende som ska skickas till Microsoft för vidare undersökning.

Duplicerade varningar som tas emot

Du kan ha aktiverat Prometheus-aviseringsregler utan att inaktivera rekommenderade aviseringar för Container Insights. Se Migrera från Container Insights rekommenderade aviseringar till Prometheus rekommenderade aviseringsregler (förhandsversion).

Jag ser infobanderollen "Du har inte rätt klusterbehörigheter som begränsar din åtkomst till Container Insights-funktioner. Kontakta klusteradministratören för att få rätt behörighet"

Container Insights har tidigare gett användare åtkomst till Azure Portal-upplevelsen baserat på åtkomstbehörigheten för Log Analytics-arbetsytan. Den kontrollerar nu behörigheten på klusternivå för att ge åtkomst till Azure Portal-upplevelsen. Du kan behöva klusteradministratören för att tilldela den här behörigheten.

För grundläggande skrivskyddad åtkomst på klusternivå tilldelar du rollen Övervakningsläsare för följande typer av kluster.

  • AKS utan Rollbaserad åtkomstkontroll (RBAC) för Kubernetes aktiverad
  • AKS aktiverat med Microsoft Entra SAML-baserad enkel inloggning
  • AKS aktiverat med Kubernetes RBAC-auktorisering
  • AKS konfigurerat med klusterrollbindningsklustretÖvervakaAnvändare
  • Azure Arc-aktiverade Kubernetes-kluster

Mer information om hur du tilldelar rolltilldelningar för AKS och åtkomst- och identitetsalternativ för Azure Kubernetes Service (AKS) finns i Tilldela rollbehörigheter till en användare eller grupp.

Egenskapsvärdena för bild och namn fylls inte i när jag frågar i tabellen ContainerLog

För agentversionen ciprod12042019 och senare fylls dessa två egenskaper som standard inte i för varje loggrad för att minimera kostnaden för insamlade loggdata. Det finns två alternativ för att fråga tabellen som innehåller dessa egenskaper med sina värden:

Alternativ 1

Anslut andra tabeller för att inkludera dessa egenskapsvärden i resultatet.

Ändra dina frågor så att de ContainerInventory inkluderar Image och ImageTag egenskaper från tabellen genom att ansluta till ContainerID egenskapen. Du kan inkludera Name egenskapen (som den tidigare visades i ContainerLog tabellen) från KubepodInventory tabellens ContainerName fält genom att ansluta till ContainerID egenskapen. Vi rekommenderar det här alternativet.

Följande exempel är ett exempel på en detaljerad fråga som förklarar hur du hämtar dessa fältvärden med kopplingar.

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

Alternativ 2

Återaktiverbar samling för dessa egenskaper för varje containerloggrad.

Om det första alternativet inte är praktiskt på grund av frågeändringar kan du återaktivera insamlingen av dessa fält. Aktivera inställningen log_collection_settings.enrich_container_logs i agentkonfigurationskartan enligt beskrivningen i konfigurationsinställningarna för datainsamling.

Kommentar

Vi rekommenderar inte det andra alternativet för stora kluster som har fler än 50 noder. Den genererar API-serveranrop från varje nod i klustret för att utföra den här berikningen. Det här alternativet ökar också datastorleken för varje loggrad som samlas in.

Jag kan inte uppgradera ett kluster efter registrering

Här är scenariot: Du har aktiverat Containerinsikter för ett Azure Kubernetes Service-kluster. Sedan tog du bort Log Analytics-arbetsytan där klustret skickade sina data. Nu när du försöker uppgradera klustret misslyckas det. Om du vill undvika det här problemet måste du inaktivera övervakningen och sedan återaktivera den genom att referera till en annan giltig arbetsyta i din prenumeration. När du försöker utföra klusteruppgraderingen igen bör den bearbetas och slutföras.

Samlar inte in loggar i Azure Stack HCI-kluster

Om du registrerade ditt kluster och/eller konfigurerade HCI Insights före november 2023 kanske funktioner som använder Azure Monitor-agenten på HCI, till exempel Arc for Servers Insights, VM Insights, Container Insights, Defender för molnet eller Microsoft Sentinel inte samlar in loggar och händelsedata korrekt. Mer information om hur du konfigurerar om agenten och HCI Insights finns i Reparera AMA-agenten för HCI .

Nästa steg

När övervakning är aktiverat för att samla in hälsomått för AKS-klusternoder och poddar är dessa hälsomått tillgängliga i Azure Portal. Mer information om hur du använder containerinsikter finns i Visa Azure Kubernetes Tjänststatus.