Freigeben über

Problembehandlung für Container Insights

  • Artikel

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.

Fehlermeldungen Aktion
Fehlermeldung „Keine Daten für ausgewählte Filter“ Das Einrichten von Überwachungsdatenflüssen für neu erstellte Cluster kann einige Zeit in Anspruch nehmen. Es dauert mindestens 10 bis 15 Minuten, bis Daten für Ihren Cluster angezeigt werden.

Wenn die Daten weiterhin nicht angezeigt werden, überprüfen Sie, ob der Log Analytics-Arbeitsbereich für disableLocalAuth = true konfiguriert ist. Wenn ja, aktualisieren Sie wieder auf 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
Fehlermeldung „Fehler beim Abrufen von Daten“ Während dem Einrichten eines AKS-Clusters für die Integritäts- und Leistungsüberwachung wird zwischen dem Cluster und dem Log Analytics-Arbeitsbereich eine Verbindung hergestellt. Zum Speichern sämtlicher Überwachungsdaten für Ihren Cluster wird ein Log Analytics-Arbeitsbereich verwendet. Dieser Fehler kann auftreten, wenn Ihr Log Analytics-Arbeitsbereich gelöscht wurde. Überprüfen Sie, ob der Arbeitsbereich gelöscht wurde. Wenn dies der Fall ist, aktivieren Sie das Überwachen Ihres Clusters mit Container Insights wieder. Geben Sie dann einen vorhandenen Arbeitsbereich an, oder erstellen Sie einen neuen. Zum nochmaligen Aktivieren müssen Sie das Überwachen für den Cluster deaktivieren und dann mit Container Insights wieder aktivieren.
„Fehler beim Abrufen von Daten“ nach dem Hinzufügen von Container Insights über az aks cli Wenn Sie das Überwachen mithilfe von az aks cli aktivieren, wird Container Insights möglicherweise nicht ordnungsgemäß bereitgestellt. Überprüfen Sie, ob die Lösung bereitgestellt ist. Wechseln Sie zum Überprüfen zu Ihrem Log Analytics-Arbeitsbereich, und wählen Sie im linken Bereich Legacy-Lösungen aus. Dort sehen Sie, ob die Lösung verfügbar ist. Stellen Sie die Lösung nochmals bereit, um dieses Problem zu beheben. Befolgen Sie die Anweisungen unter Aktivieren von Container Insights.
Fehlermeldung „Fehlende Abonnementregistrierung“ Wenn Sie die Fehlermeldung „Abonnementregistrierung für Microsoft.OperationsManagement fehlt“ erhalten, können Sie den Fehler beheben, indem Sie den Ressourcenanbieter Microsoft.OperationsManagement in dem Abonnement registrieren, in dem der Arbeitsbereich definiert ist. Die entsprechenden Schritte finden Sie unter Beheben von Fehlern bei der Ressourcenanbieterregistrierung.
Fehlermeldung: „Die in der Anforderung angegebene Antwort-URL entspricht nicht den für die Anwendung konfigurierten Antwort-URLs: ‚<Anwendungs-ID>‘.“ Diese Fehlermeldung wird möglicherweise angezeigt, wenn Sie Liveprotokolle aktivieren. Die Lösung finden Sie unter Anzeigen von Containerdaten in Echtzeit mit Container Insights.

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.

Hinweis

Die zweite Option wird für große Cluster mit mehr als 50 Knoten nicht empfohlen. Dabei werden von jedem Knoten im Cluster API-Serveraufrufe zur Ausführung dieser Anreicherung generiert. Diese Option erhöht darüber hinaus die Datenmenge für jede erfasste Protokollzeile.

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.