Problembehandlung für Container Insights

Wenn Sie die Überwachung Ihres AKS-Clusters (Azure Kubernetes Service) mit Container Insights konfigurieren, tritt möglicherweise ein Problem auf, das das Erfassen von Daten oder das Melden des Status verhindert. In diesem Artikel werden einige häufige Probleme und Schritte zur Problembehandlung erläutert.

Bekannte Fehlermeldungen

In der folgenden Tabelle sind bekannte Fehler zusammengefasst, die beim Verwenden von Container Insights auftreten können.

Um Sie bei der Diagnose zu unterstützen, haben wir ein Skript zur Problembehandlung bereitgestellt.

Autorisierungsfehler bei Onboarding- oder Updatevorgängen

Wenn Sie Container Insights aktivieren oder einen Cluster aktualisieren, um das Erfassen von Metriken zu unterstützen, wird Ihnen möglicherweise eine Fehlermeldung wie die folgende angezeigt: „Der Client <user's Identity> mit der Objekt-ID <user's objectId> hat keine Berechtigung zum Ausführen der Aktion Microsoft.Authorization/roleAssignments/write über den Bereich“.

Während des Onboarding- oder Updatevorgangs wird versucht, die Rollenzuweisung Überwachungsmetriken veröffentlichen in der Clusterressource zu gewähren. Der Benutzer, der den Prozess zur Aktivierung von Container Insights oder den Aktualisierungsprozess initiiert, damit das Sammeln von Metriken unterstützt wird, muss Zugriff auf die Berechtigung Microsoft.Authorization/roleAssignments/write im Bereich der AKS-Clusterressource haben. Nur Mitglieder der Rollen Besitzer und Benutzerzugriffsadministrator verfügen über Zugriff auf diese Berechtigung. Wenn Sie gemäß Ihrer Sicherheitsrichtlinien detailliertere Berechtigungen zuweisen müssen, lesen Sie benutzerdefinierte Azure-Rollen, und weisen Sie Berechtigungen den Benutzer*innen zu, die sie benötigen.

Sie können diese Rolle auch manuell über das Azure-Portal zuweisen: Weisen Sie dazu die Rolle Herausgeber dem Bereich Überwachungsmetriken zu. Ausführliche Informationen finden Sie unter Zuweisen von Azure-Rollen über das Azure-Portal.

Container Insights ist aktiviert, meldet aber keinerlei Informationen

So ermitteln Sie das Problem, wenn Sie keine Statusinformationen anzeigen können oder keine Ergebnisse aus einer Protokollabfrage zurückgegeben werden:

1. Überprüfen Sie den Zustand des Agent, indem Sie den folgenden Befehl ausführen:

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

   Die Anzahl der Pods sollte gleich der Anzahl der Linux-Knoten im Cluster sein. Die Ausgabe sollte wie im folgenden Beispiel aussehen, was auf eine ordnungsgemäße Bereitstellung hinweist:

   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. Wenn Sie über Windows Server-Knoten verfügen, überprüfen Sie den Status des Agents, indem Sie den folgenden Befehl ausführen:

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

   Die Anzahl der Pods sollte gleich der Anzahl der Windows-Knoten im Cluster sein. Die Ausgabe sollte wie im folgenden Beispiel aussehen, was auf eine ordnungsgemäße Bereitstellung hinweist:

   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. Überprüfen Sie den Bereitstellungsstatus mithilfe des folgenden Befehls:

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

   Die Ausgabe sollte wie im folgenden Beispiel aussehen, was auf eine ordnungsgemäße Bereitstellung hinweist:

   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. Überprüfen Sie mit dem Befehl kubectl get pods --namespace=kube-system den Status des Pods, um festzustellen, ob er ausgeführt wird.

   Die Ausgabe sollte dem folgenden Beispiel mit einem Status von Running für Ama-Protokolle ähneln:

   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. Wenn die Pods aktiv sind, aber keine Daten in Log Analytics angezeigt werden oder die Daten nur während eines bestimmten Teils des Tages gesendet werden, könnte dies ein Hinweis darauf sein, dass die tägliche Obergrenze erreicht wurde. Wenn dieser Grenzwert jeden Tag erreicht wird, werden die Daten nicht mehr in den Log Analytics-Arbeitsbereich aufgenommen und zum Zeitpunkt der Rücksetzung zurückgesetzt. Weitere Informationen finden Sie unter Log Analytics: Tägliche Obergrenze.

6. Wenn Containter Insights mithilfe von Terraform aktiviert wird und msi_auth_for_monitoring_enabled auf truefestgelegt ist, stellen Sie sicher, dass DCR- und DCRA-Ressourcen ebenfalls bereitgestellt wurden, um die Protokollsammlung zu ermöglichen. Eine ausführliche Anleitung finden Sie unter Aktivieren von Container Insights.

ReplicaSet-Pods des Container Insights-Agents sind in anderen Clustern als AKS-Clustern nicht geplant.

ReplicaSet-Pods des Container Insights-Agents sind für die Zeitplanung von den folgenden Knotenselektoren auf den Workerknoten (oder Agent-Knoten) abhängig:

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

Wenn Ihren Workerknoten keine Knotenbezeichnungen angefügt sind, werden ReplicaSet-Pods des Agents nicht geplant. Eine Anleitung zum Anfügen der Bezeichnung finden Sie unter Zuweisen von Bezeichnungsauswahlen in Kubernetes.

Leistungsdiagramme zeigen keine CPU- oder Arbeitsspeicherauslastung für Knoten und Container in einem Nicht-Azure-Cluster

Pods des Container Insights-Agents verwenden den cAdvisor-Endpunkt auf dem Knoten-Agent zum Erfassen der Leistungsmetriken. Vergewissern Sie sich, dass der Container-Agent auf dem Knoten so konfiguriert ist, dass cAdvisor secure port: 10250 oder cAdvisor unsecure port: 10255 auf allen Knoten im Cluster zum Erfassen von Leistungsmetriken geöffnet werden kann. Weitere Informationen finden Sie unter Voraussetzungen für Kubernetes-Hybridcluster.

Andere Cluster als AKS-Cluster werden in Container Insights nicht angezeigt.

Um Nicht-AKS-Cluster in Container Insights anzuzeigen, wird Lesezugriff auf den Log Analytics-Arbeitsbereich benötigt, der diese Einblicke unterstützt, sowie auf die Container Insights-Lösungsressource ContainerInsights (Arbeitsbereich).

Metriken werden nicht erfasst

1. Überprüfen Sie mithilfe des folgenden CLI-Befehls, ob die Rollenzuweisung von Herausgeber für Überwachungsmetriken vorhanden ist:

   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"
   

   Bei Clustern mit MSI ändert sich die benutzerseitig zugewiesene Client-ID für den Azure Monitor-Agent bei jedem Aktivieren und Deaktivieren der Überwachung. Daher sollte die Rollenzuweisung in der aktuellen MSI-Client-ID vorhanden sein.

2. Für Cluster mit aktivierter Microsoft Entra-Pod-Identität und Verwendung von MSI:

   • Überprüfen Sie mithilfe des folgenden Befehls, ob die erforderliche Bezeichnung kubernetes.azure.com/managedby: aks auf den Azure Monitor-Agent-Pods vorhanden ist:

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

   • Überprüfen Sie, ob Ausnahmen aktiviert sind, wenn die Pod-Identität aktiviert ist, indem Sie eine der unterstützten Methoden unter https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity verwenden.

     Führen Sie zur Überprüfung den folgenden Befehl aus:

     kubectl get AzurePodIdentityException -A -o yaml

     Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

     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
     

Fehler beim Installieren der Azure Monitor-Containererweiterung in einem Kubernetes-Cluster mit Azure Arc-Unterstützung

Der Fehler „Manifeste enthalten eine Ressource, die bereits vorhanden ist“ gibt an, dass Ressourcen des Container Insights-Agents bereits im Kubernetes-Cluster mit Azure Arc-Unterstützung bestehen. Dieser Fehler bedeutet, dass der Container Insights-Agent bereits installiert ist. Er wurde entweder über ein Helm-Chart von azuremonitor-containers oder das Überwachungs-Add-On installiert, wenn es sich um einen AKS-Cluster handelt, der über Azure Arc verbunden ist.

Die Lösung dieses Problems besteht darin, sofern vorhanden die vorhandenen Ressourcen des Container Insights-Agents zu bereinigen. Aktivieren Sie dann die Azure Monitor-Containererweiterung.

Für Nicht-AKS-Cluster

1. Führen Sie für den K8s-Cluster mit Azure Arc-Verbindung den folgenden Befehl aus, um zu überprüfen, ob das Helm-Chartrelease azmon-containers-release-1 vorhanden ist:

   helm list -A

2. Wenn die Ausgabe des obigen Befehls darauf hinweist, dass azmon-containers-release-1 vorhanden ist, löschen Sie das Helm-Chartrelease:

   helm del azmon-containers-release-1

Für AKS-Cluster

1. Führen Sie die folgenden Befehle aus, und suchen Sie nach dem Add-On-Profil des Azure Monitor-Agents, um zu überprüfen, ob das AKS-Überwachungs-Add-On aktiviert ist:

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

2. Wenn die Ausgabe eine Profilkonfiguration für das Azure Monitor-Agent-Add-On mit einer Ressourcen-ID für Log Analytics-Arbeitsbereiche enthält, ist das AKS-Überwachungs-Add-On aktiviert und muss deaktiviert werden:

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

Wenn die Probleme bei der Installation von Azure Monitor-Containererweiterungen durch die vorherigen Schritte nicht behoben werden konnten, erstellen Sie ein Ticket für Microsoft, um weitere Untersuchungen zu ermöglichen.

Empfangene doppelte Warnungen

Sie haben möglicherweise Prometheus-Warnungsregeln aktiviert, ohne die von Container Insights empfohlenen Warnungen zu deaktivieren. Weitere Informationen finden Sie unter Migrieren von Empfohlenen Warnungen von Container Insights zu Empfohlenen Warnungsregeln von Prometheus (Vorschau).

Ich sehe das Infobanner „Sie verfügen nicht über die richtigen Clusterberechtigungen, wodurch Ihr Zugriff auf die Container Insights-Funktionen eingeschränkt wird. Wenden Sie sich an Ihren Clusteradministrator bzw. Ihre Clusteradministratorin, um die richtige Berechtigung zu erhalten.“

Container Insights hat Benutzern in der Vergangenheit den Zugriff auf die Azure-Portal-Benutzeroberfläche basierend auf der Zugriffsberechtigung des Log Analytics-Arbeitsbereichs ermöglicht. Jetzt wird die Berechtigung auf Clusterebene überprüft, um Zugriff auf die Azure-Portal-Benutzeroberfläche bereitzustellen. Möglicherweise müssen Sie diese Berechtigung von Ihrem Clusteradministrator zuweisen.

Weisen Sie für den einfachen schreibgeschützten Zugriff auf Clusterebene die Rolle Überwachungsleser für die folgenden Clustertypen zu.

• AKS ohne aktivierte Autorisierung per rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC) in Kubernetes
• AKS-fähig mit Microsoft Entra SAML-basiertem einmaligem Anmelden
• Mit Kubernetes RBAC-Autorisierung aktivierter AKS
• Mit Clusterrollenbindung clusterMonitoringUser konfigurierter AKS
• Kubernetes-Cluster mit Azure Arc-Unterstützung

Ausführliche Informationen zum Zuweisen dieser Rollen für AKS und Zugriffs- und Identitätsoptionen für Azure Kubernetes Service (AKS) finden Sie unter Zuweisen von Rollenberechtigungen zu einem Benutzer oder einer Gruppe.

Die Werte der Eigenschaften „Image“ und „Name“ werden beim Abfragen der ContainerLog-Tabelle nicht aufgefüllt.

Für die Agent-Version ciprod12042019 und höhere Versionen werden diese beiden Eigenschaften standardmäßig nicht für jede Protokollzeile aufgefüllt, um die Kosten für die erfassten Protokolldaten zu minimieren. Es gibt zwei Optionen zum Abfragen der Tabelle, die diese Eigenschaften mit ihren Werten enthalten:

Option 1:

Verknüpfen Sie andere Tabellen, um diese Eigenschaftswerte in die Ergebnisse aufzunehmen.

Ändern Sie Ihre Abfragen so, dass sie die Eigenschaften Image und ImageTag aus der Tabelle ContainerInventory einschließen, indem Sie sie über die ContainerID-Eigenschaft verknüpfen. Sie können die Eigenschaft Name (wie sie zuvor in der Tabelle ContainerLog angezeigt wurde) aus dem Feld ContainerName der Tabelle KubepodInventory einschließen, indem Sie sie über die ContainerID-Eigenschaft verknüpfen. Diese Option wird empfohlen.

Das folgende Beispiel zeigt eine ausführliche Abfrage, die veranschaulicht, wie Sie diese Feldwerte mit Verknüpfungen abrufen:

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

Option 2:

Aktivieren Sie erneut die Erfassung dieser Eigenschaften für jede Containerprotokollzeile.

Wenn die erste Option aufgrund von Abfrageänderungen nicht geeignet ist, können Sie die Erfassung dieser Felder wieder aktivieren. Aktivieren Sie die Einstellung log_collection_settings.enrich_container_logs in der Konfigurationszuordnung des Agents, wie in den Konfigurationseinstellungen für die Datensammlung beschrieben.

Ich kann für Cluster nach dem Onboarding kein Upgrade durchführen.

Dies ist das Szenario: Sie haben Container Insights für einen Azure Kubernetes Service-Cluster aktiviert. Anschließend haben Sie den Log Analytics-Arbeitsbereich gelöscht, in dem der Cluster seine Daten gesendet hat. Wenn Sie nun versuchen, ein Upgrade des Clusters durchzuführen, schlägt dies fehl. Um dieses Problem zu umgehen, müssen Sie die Überwachung deaktivieren und anschließend durch Verweisen auf einen anderen gültigen Arbeitsbereich in Ihrem Abonnement neu aktivieren. Wenn Sie versuchen, das Clusterupgrade erneut auszuführen, sollte es erfolgreich durchgeführt und abgeschlossen werden.

Keine Protokolle im Azure Stack HCI-Cluster sammeln

Wenn Sie Ihren Cluster vor November 2023 registriert und/oder HCI Insights vor November 2023 konfiguriert haben, sammeln Features, die den Azure Monitor-Agent in einer HCI verwenden – z. B. Arc for Servers Insights, VM Insights, Container Insights, Defender for Cloud oder Microsoft Sentinel – möglicherweise keine Protokolle und Ereignisdaten. Die Schritte, mit denen Sie den Agent und HCI Insights neu konfigurieren können, finden Sie unter Reparieren des AMA-Agents für HCI.

Nächste Schritte

Bei aktivierter Überwachung zum Erfassen der Integritätsmetriken für AKS-Clusterknoten wie auch für Pods stehen diese Integritätsmetriken im Azure-Portal zur Verfügung. Informationen zum Erlernen der Verwendung von Container Insights finden Sie unter Anzeigen der Integrität von Azure Kubernetes Service.