Freigeben über

Überwachen von Azure Kubernetes Service

  • Artikel

Dieser Artikel beschreibt Folgendes:

  • Die Arten von Überwachungsdaten, die Sie für diesen Dienst sammeln können
  • Möglichkeiten zum Analysieren dieser Daten.

Hinweis

Wenn Sie bereits mit diesem Dienst und/oder Azure Monitor vertraut sind und nur wissen möchten, wie Überwachungsdaten analysiert werden, lesen Sie den Abschnitt Analysieren am Ende dieses Artikels.

Wenn Sie über unternehmenskritische Anwendungen und Geschäftsprozesse verfügen, die auf Azure-Ressourcen basieren, müssen Sie diese überwachen und Warnungen für Ihr System abrufen. Der Azure Monitor-Dienst sammelt und aggregiert Metriken und Protokolle aus jeder Komponente Ihres Systems. Azure Monitor bietet Ihnen eine Übersicht über Verfügbarkeit, Leistung und Resilienz und benachrichtigt Sie über Probleme. Sie können das Azure-Portal, PowerShell, die Azure CLI, die REST-API oder Clientbibliotheken verwenden, um Überwachungsdaten einzurichten und anzuzeigen.

Wichtig

Kubernetes ist ein komplexes verteiltes System mit vielen beweglichen Teilen. Hierfür ist eine Überwachung auf mehreren Ebenen erforderlich. AKS ist zwar ein verwalteter Kubernetes-Dienst, erfordert aber dennoch eine ebenso strenge Überwachung auf mehreren Ebenen. Dieser Artikel enthält allgemeine Informationen und bewährte Methoden für die Überwachung eines AKS-Clusters.

Erkenntnisse

Einige Dienste in Azure verfügen über ein integriertes Überwachungsdashboard im Azure-Portal, das einen Ausgangspunkt für die Überwachung Ihres Diensts bietet. Diese Dashboards werden als Erkenntnisse bezeichnet, und Sie finden sie im Erkenntnishub von Azure Monitor im Azure-Portal.

Azure Monitor-Container Insights erfasst benutzerdefinierte Metriken für Knoten, Pods, Container und persistente Volumes. Informationen dazu finden Sie unter Von Container Insights gesammelte Metriken.

Azure Monitor Application Insights wird für die Anwendungsleistungsüberwachung (APM) verwendet. Informationen zum Aktivieren von Application Insights mit Codeänderungen finden Sie unter Aktivieren von Azure Monitor OpenTelemetry. Informationen zum Aktivieren von Application Insights ohne Codeänderungen finden Sie unter AKS Autoinstrumentation. Weitere Informationen zur Instrumentierung finden Sie unter Grundlagen der Datensammlung.

Überwachungsdaten

AKS generiert dieselben Arten von Überwachungsdaten wie andere Azure-Ressourcen, die unter Überwachen von Daten aus Azure-Ressourcen beschrieben sind. Ausführliche Informationen zu den von AKS erstellten Metriken und Protokollen finden Sie in der Referenz zur Überwachung von AKS-Daten. Weitere Azure-Dienste und -Features sammeln zusätzliche Daten und ermöglichen weitere Analyseoptionen, wie in der folgenden Abbildung und Tabelle dargestellt.

Diagramm zur Erfassung von Überwachungsdaten von AKS.

Quelle Beschreibung
Plattformmetriken Plattformmetriken werden für AKS-Cluster automatisch kostenlos erfasst. Sie können diese Metriken mit dem Metrik-Explorer analysieren oder sie für Metrikwarnungen verwenden.
Prometheus-Metriken Wenn Sie für Ihren Cluster Metrik-Scraping aktivieren, erfasst der verwaltete Azure Monitor-Dienst für Prometheus die Prometheus-Metriken und speichert sie in einem Azure Monitor-Arbeitsbereich. Analysieren Sie diese mit vorgefertigten Dashboards in Azure Managed Grafana und mit Prometheus-Warnungen.
Aktivitätsprotokolle Das Aktivitätsprotokoll wird für AKS-Cluster automatisch kostenlos erfasst. Diese Protokolle verfolgen Informationen nach, z. B. wenn ein Cluster erstellt wird oder eine Konfigurationsänderung vorgenommen wird. Senden Sie das Aktivitätsprotokoll an einen Log Analytics-Arbeitsbereich, um es zusammen mit anderen Protokolldaten zu analysieren.
Ressourcenprotokolle Protokolle der Steuerungsebene für AKS sind als Ressourcenprotokolle implementiert. Erstellen Sie eine Diagnoseeinstellung, um sie an den Log Analytics-Arbeitsbereich zu senden, in dem Sie sie anhand von Protokollabfragen in Log Analytics analysieren und Benachrichtigungen dazu senden können.
Container Insights Container Insights sammelt verschiedene Protokolle und Leistungsdaten aus einem Cluster, einschließlich stdout/stderr-Datenströmen, und speichert sie in einem Log Analytics-Arbeitsbereich sowie Azure Monitor-Metriken. Analysieren Sie diese Daten mit Ansichten und Arbeitsmappen, die in Container Insights enthalten sind, oder mit Log Analytics und Metrik-Explorer.
Application Insights Azure Monitor Application Insights erfasst Protokolle, Metriken und verteilte Ablaufverfolgungen. Diese Telemetrie wird in einem Log Analytics-Arbeitsbereich zur Analyse im Azure-Portal gespeichert.

Ressourcentypen

Azure verwendet das Konzept von Ressourcentypen und IDs, um alles in einem Abonnement zu identifizieren. Ressourcentypen sind auch Teil der Ressourcen-IDs für jede Ressource, die in Azure ausgeführt wird. Beispiel: Ein Ressourcentyp für eine VM ist Microsoft.Compute/virtualMachines. Eine Liste der Dienste und ihrer zugehörigen Ressourcentypen finden Sie unter Ressourcenanbieter.

Ähnliche organisiert Azure Monitor die Kernüberwachungsdaten in Metriken und Protokollen basierend auf Ressourcentypen, die auch als Namespaces bezeichnet werden. Für unterschiedliche Ressourcentypen stehen unterschiedliche Metriken und Protokolle zur Verfügung. Ihr Dienst ist möglicherweise mehr als einem Ressourcentyp zugeordnet.

Weitere Informationen zu den Ressourcentypen für AKS finden Sie unter Azure Kubernetes Service – Überwachungsdatenreferenz.

Datenspeicher

For Azure Monitor:

  • Metrikdaten werden in der Azure Monitor-Metrikendatenbank gespeichert.
  • Protokolldaten werden im Azure Monitor-Protokollspeicher gespeichert. Log Analytics ist ein Tool im Azure-Portal zum Abfragen dieses Speichers.
  • Das Azure-Aktivitätsprotokoll ist ein separater Speicher mit eigener Schnittstelle im Azure-Portal.

Optional können Sie Metrik- und Aktivitätsprotokolldaten an den Azure Monitor-Protokollspeicher weiterleiten. Anschließend können Sie Log Analytics verwenden, um die Daten abzufragen und mit anderen Protokolldaten zu korrelieren.

Viele Dienste können Diagnoseeinstellungen verwenden, um Metrik- und Protokolldaten an andere Speicherorte außerhalb von Azure Monitor zu senden. Beispiele umfassen Azure Storage, gehostete Partnersysteme und Nicht-Azure-Partnersysteme, die Event Hubs verwenden.

Detaillierte Informationen dazu, wie Azure Monitor Daten speichert, finden Sie unter Azure Monitor-Datenplattform.

Azure Monitor-Plattformmetriken

Azure Monitor stellt Plattformmetriken für die meisten Dienste bereit. Diese Metriken sind:

  • Einzeln für jeden Namespace definiert.
  • In der Azure Monitor-Datenbank für Zeitreihenmetriken gespeichert.
  • Einfach strukturiert und in der Lage, Warnmeldungen in Quasi-Echtzeit zu unterstützen.
  • Verwendet zum Nachverfolgen der Leistung einer Ressource im Zeitverlauf.

Erfassung: Azure Monitor sammelt Plattformmetriken automatisch. Es ist keine Konfiguration erforderlich.

Routing: Sie können Plattformmetriken normalerweise auch an Azure Monitor-Protokolle/Log Analytics weiterleiten, damit Sie diese mit anderen Protokolldaten abfragen können. Weitere Informationen finden Sie in der Diagnoseeinstellung „Metriken“. Informationen zum Konfigurieren von Diagnoseeinstellungen für einen Dienst finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor.

Eine Liste aller Metriken, die für alle Ressourcen in Azure Monitor gesammelt werden können, finden Sie unter Unterstützte Metriken in Azure Monitor.

Eine Liste der verfügbaren Metriken für AKS finden Sie unter Azure Kubernetes Service – Überwachungsdatenreferenz.

Metriken spielen eine wichtige Rolle bei der Clusterüberwachung, der Identifizierung von Problemen und der Optimierung der Leistung in den AKS-Clustern. Plattformmetriken werden mithilfe des vorgefertigten Metrikservers erfasst, der im Namespace „kube-system“ installiert ist und Metriken regelmäßig von allen Kubernetes-Knoten ausliest, die von Kubelet bereitgestellt werden. Darüber hinaus sollten Sie Azure Managed Prometheus-Metriken aktivieren, um Containermetriken und Kubernetes-Objektmetriken (etwa den Objektstatus von Bereitstellungen) zu sammeln. Weitere Informationen finden Sie im Artikel zum Sammeln von Prometheus-Metriken aus einem AKS-Cluster.

AKS macht auch Metriken aus wichtigen Komponenten der Steuerungsebene verfügbar, z. B. API-Server, ETCD, Scheduler über Azure Managed Prometheus. Diese Funktion befindet sich derzeit in der Vorschau. Weitere Informationen finden Sie im Artikel zum Überwachen von AKS-Steuerungsebenenmetriken (Azure Kubernetes Service) (Vorschau).

Nicht-Azure Monitor-basierte Metriken

Dieser Dienst stellt andere Metriken bereit, die nicht in der Azure Monitor-Metrikdatenbank enthalten sind.

Die folgenden Azure-Dienste und -Features von Azure Monitor können für die zusätzliche Überwachung Ihrer Kubernetes-Cluster verwendet werden. Sie können diese Features während der Erstellung von AKS-Clustern über die Registerkarte „Integrationen“ im Azure-Portal, die Azure CLI, Terraform, Azure Policy aktivieren oder später in Ihren Cluster integrieren. Jedes dieser Features kann Kosten verursachen. Lesen Sie daher die Preisinformationen für die einzelnen Features, bevor Sie sie aktivieren.

Dienst/Funktion Beschreibung
Container Insights Verwendet eine containerisierte Version des Azure Monitor-Agents zum Sammeln von stdout-/stderr-Protokollen und Kubernetes-Ereignissen von jedem Knoten in Ihrem Cluster. Das Feature unterstützt eine Vielzahl von Überwachungsszenarien für AKS-Cluster. Die Überwachung für einen AKS-Cluster kann bei der Erstellung des Clusters mithilfe der Azure CLI, mit Azure Policy, dem Azure-Portal oder Terraform aktiviert werden. Wenn Sie Container Insights beim Erstellen Ihres Clusters nicht aktivieren, finden Sie unter Aktivieren von Container Insights für Azure Kubernetes Service-Cluster (AKS) weitere Optionen zum Aktivieren des Clusters.

Container Insights speichert die meisten Daten in einem Log Analytics-Arbeitsbereich, und Sie verwenden in der Regel denselben Log Analytics-Arbeitsbereich wie die Ressourcenprotokolle für Ihren Cluster. Unter Entwerfen einer Log Analytics-Arbeitsbereichsarchitektur finden Sie Anleitungen dazu, wie viele Arbeitsbereiche Sie verwenden und wo Sie sie speichern sollten.
Verwalteter Azure Monitor-Dienst für Prometheus Prometheus ist eine cloudnative Metriklösung von der Cloud Native Compute Foundation. Es ist das am häufigsten verwendete Tool zum Sammeln und Analysieren von Metrikdaten aus Kubernetes-Clustern. Der verwaltete Azure Monitor-Dienst für Prometheus ist eine vollständig verwaltete Prometheus-kompatible Überwachungslösung in Azure. Wenn Sie verwaltetes Prometheus nicht beim Erstellen Ihres Clusters aktivieren, finden Sie Informationen zu weiteren Optionen zum Aktivieren unter Sammeln von Prometheus-Metriken aus einem AKS-Cluster.

Der verwaltete Azure Monitor-Dienst für Prometheus speichert seine Daten in einem Azure Monitor-Arbeitsbereich, der mit einem Grafana-Arbeitsbereich verknüpft ist, sodass Sie die Daten mit Azure Managed Grafana analysieren können.
Von Azure verwaltetes Grafana Vollständig verwaltete Implementierung von Grafana, einer Open-Source-Plattform zur Datenvisualisierung, die häufig zum Präsentieren von Prometheus-Daten verwendet wird. Mehrere vordefinierte Grafana-Dashboards stehen für die Überwachung von Kubernetes und die umfassende Problembehandlung zur Verfügung. Wenn Sie verwaltetes Grafana beim Erstellen Ihres Clusters nicht aktivieren, lesen Sie Verknüpfen eines Grafana-Arbeitsbereichs. Sie können dies mit Ihrem Azure Monitor-Arbeitsbereich verknüpfen, damit er auf Prometheus-Metriken für Ihren Cluster zugreifen kann.

Überwachen von AKS-Steuerungsebenenmetriken (Vorschau)

In diesem Abschnitt erfahren Sie, wie Sie die Metriken der Steuerungsebene (Vorschau) verwenden. Sie können Metriken aus der Steuerungsebene sammeln und die Telemetrie in Azure Monitor anzeigen. Die Metrikfunktion für die Steuerungsebene ist vollständig kompatibel mit Prometheus und Grafana. Das Feature bietet mehr Einblicke in die Verfügbarkeit und Leistung der Komponenten der Steuerungsebene, z. B. API-Server, ETCD, Scheduler, Autoskalierung und Controller-Manager. Sie können diese Metriken verwenden, um die Einblicke insgesamt zu maximieren und operative Exzellenz für Ihren AKS-Cluster aufrechtzuerhalten.

Voraussetzungen und Einschränkungen

Installieren der Erweiterung „aks-preview“

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

  • Installieren oder aktualisieren Sie die Azure CLI-Erweiterung aks-preview mithilfe des Befehls az extension add oder az extension update.

    # Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension
az extension update --name aks-preview

Registrieren des AzureMonitorMetricsControlPlanePreview-Flags

  1. Registrieren Sie das Featureflag AzureMonitorMetricsControlPlanePreview mithilfe des Befehls az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

    Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird.

  2. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

  3. Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register.

    az provider register --namespace "Microsoft.ContainerService"

Aktivieren von Steuerelementebenenmetriken auf Ihrem AKS-Cluster

Sie können Metriken der Steuerungsebene mit dem verwalteten Azure Monitor-Dienst für das Prometheus-Add-On aktivieren, wenn Sie einen neuen Cluster erstellen oder einen vorhandenen aktualisieren.

Aktivieren Sie Metriken der Steuerungsebene für einen neuen AKS-Cluster:

Um Prometheus-Metriken aus Ihrem Kubernetes-Cluster zu sammeln, lesen Sie Aktivieren von Prometheus und Grafana für AKS-Cluster, und führen Sie die Schritte auf der Registerkarte CLI für einen AKS-Cluster aus.

Aktivieren von Metriken der Steuerungsebene für einen vorhandenen AKS-Cluster

  • Wenn Ihr Cluster bereits über das Prometheus-Add-On verfügt, aktualisieren Sie den Cluster mithilfe des Befehls az aks update, um sicherzustellen, dass er mit der Erfassung von Metriken der Steuerungsebene beginnt.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

Hinweis

Im Gegensatz zu den Metriken, die von Clusterknoten gesammelt werden, werden Steuerelementebenenmetriken von einer Komponente gesammelt, die nicht Teil des ama-metrics-Add-Ons ist. Durch Aktivieren des Feature-Flags AzureMonitorMetricsControlPlanePreview und des verwalteten Prometheus-Add-Ons wird sichergestellt, dass Metriken der Steuerungsebene erfasst werden. Nach dem Aktivieren der Metriksammlung kann es mehrere Minuten dauern, bis die Daten im Arbeitsbereich angezeigt werden.

Abfragen von Metriken der Steuerungsebene

Metriken der Steuerungsebene werden in einem Azure Monitor-Arbeitsbereich in der Region des Clusters gespeichert. Sie können die Metriken direkt aus dem Arbeitsbereich oder über die Azure Managed Grafana-Instanz abfragen, die mit dem Arbeitsbereich verbunden ist.

Zeigen Sie die Metriken der Steuerungsebene im Azure Monitor-Arbeitsbereich mit den folgenden Schritten an:

  1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

  2. Wählen Sie unter Überwachung die Option Erkenntnisse aus.

    Screenshot des Azure Monitor-Arbeitsbereichs.

Hinweis

AKS bietet Dashboardvorlagen, mit denen Sie Telemetriedaten der Steuerungsebene in Echtzeit anzeigen und analysieren können. Wenn Sie Azure Managed Grafana zum Visualisieren der Daten verwenden, können Sie die folgenden Dashboards importieren:

Anpassen von Metriken der Steuerungsebene

AKS enthält einen vordefinierten Satz von Metriken, die für jede Komponente erfasst und gespeichert werden sollen. API server und etcd sind standardmäßig aktiviert. Sie können diese Liste über ama-settings-configmap anpassen.

Die Standardziele umfassen die folgenden Werte:

controlplane-apiserver = true
controlplane-cluster-autoscaler = false
controlplane-kube-scheduler = false
controlplane-kube-controller-manager = false
controlplane-etcd = true

Alle ConfigMaps sollten für jeden Cluster auf den Namespace kube-system angewendet werden.

Weitere Informationen zu minimal-ingestion-Profilmetriken finden Sie unter Minimales Erfassungsprofil für Metriken der Steuerungsebene in verwaltetem Prometheus.

  • Erfassen nur minimaler Metriken von Standardzielen

    Beim Festlegen von default-targets-metrics-keep-list.minimalIngestionProfile="true" werden nur die minimalen Metriken für jedes der Standardziele erfasst: controlplane-apiserver und controlplane-etcd.

  • Aufnehmen aller Metriken aus allen Zielen

    Führen Sie die folgenden Schritte aus, um alle Metriken von allen Zielen im Cluster zu erfassen:

    1. Laden Sie die ConfigMap-Datei ama-metrics-settings-configmap.yaml herunter und benennen Sie sie in configmap-controlplane.yaml um.

    2. Legen Sie minimalingestionprofile = false fest.

    3. Überprüfen Sie unter default-scrape-settings-enabled, ob die Ziele, die Sie auslesen möchten, auf true festgelegt sind. Die einzigen Ziele, die Sie angeben können, sind: controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler, controlplane-kube-controller-manager und controlplane-etcd.

    4. Wenden Sie die ConfigMap mithilfe des Befehls kubectl apply an.

      kubectl apply -f configmap-controlplane.yaml

      Nachdem die Konfiguration angewendet wurde, dauert es mehrere Minuten, bis die Metriken der angegebenen Ziele aus der Kontrollebene im Azure Monitor-Arbeitsbereich angezeigt werden.

  • Aufnehmen einiger anderer Metriken zusätzlich zu den Mindestmetriken

    Mit der Einstellung minimal ingestion profile können Sie das Erfassungsvolumen von Metriken reduzieren, da nur Metriken erfasst werden, die von Standarddashboards, Standardaufzeichnungsregeln und Standardwarnungen verwendet werden. Führen Sie die folgenden Schritte aus, um diese Einstellung anzupassen:

    1. Laden Sie die ConfigMap-Datei ama-metrics-settings-configmap herunter und benennen Sie sie in configmap-controlplane.yaml um.

    2. Legen Sie minimalingestionprofile = true fest.

    3. Überprüfen Sie unter default-scrape-settings-enabled, ob die Ziele, die Sie auslesen möchten, auf true festgelegt sind. Die einzigen Ziele, die Sie angeben können, sind: controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler, controlplane-kube-controller-manager und controlplane-etcd.

    4. Geben Sie unter default-targets-metrics-keep-list die Liste der Metriken für die true-Ziele an. Zum Beispiel:

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. Wenden Sie die ConfigMap mithilfe des Befehls kubectl apply an.

      kubectl apply -f configmap-controlplane.yaml

    Nachdem die Konfiguration angewendet wurde, dauert es mehrere Minuten, bis die Metriken der angegebenen Ziele aus der Kontrollebene im Azure Monitor-Arbeitsbereich angezeigt werden.

  • Aufnehmen nur bestimmter Metriken aus einigen Zielen

    1. Laden Sie die ConfigMap-Datei ama-metrics-settings-configmap herunter und benennen Sie sie in configmap-controlplane.yaml um.

    2. Legen Sie minimalingestionprofile = false fest.

    3. Überprüfen Sie unter default-scrape-settings-enabled, ob die Ziele, die Sie auslesen möchten, auf true festgelegt sind. Die einzigen Ziele, die Sie hier angeben können, sind controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler,controlplane-kube-controller-manager und controlplane-etcd.

    4. Geben Sie unter default-targets-metrics-keep-list die Liste der Metriken für die true-Ziele an. Zum Beispiel:

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. Wenden Sie die ConfigMap mithilfe des Befehls kubectl apply an.

      kubectl apply -f configmap-controlplane.yaml

      Nachdem die Konfiguration angewendet wurde, dauert es mehrere Minuten, bis die Metriken der angegebenen Ziele aus der Kontrollebene im Azure Monitor-Arbeitsbereich angezeigt werden.

Behandeln von Problemen mit Steuerelementebenenmetriken

Stellen Sie sicher, dass das Feature-Flag AzureMonitorMetricsControlPlanePreview aktiviert ist und die ama-metrics-Pods ausgeführt werden.

Hinweis

Die Problembehandlungsmethoden für den verwalteten Azure Prometheus-Dienst werden hier nicht direkt übersetzt, da die Komponenten, welche die Steuerungsebene auslesen, nicht im verwalteten Prometheus-Add-On vorhanden sind.

  • ConfigMap-Formatierung

    Stellen Sie sicher, dass Sie die richtige Formatierung in der ConfigMap verwenden und dass die Felder, insbesondere default-targets-metrics-keep-list, minimal-ingestion-profile und default-scrape-settings-enabled, ordnungsgemäß mit ihren beabsichtigten Werten aufgefüllt werden.

  • Isolieren der Steuerungsebene von der Datenebene

    Legen Sie zunächst einige der knotenbezogenen Metriken auf true fest und überprüfen Sie, ob die Metriken an den Arbeitsbereich weitergeleitet werden. Dies hilft zu ermitteln, ob das Problem spezifisch für das Auslesen von Steuerelementebenenmetriken ist.

  • Aufgenommene Ereignisse

    Nachdem Sie die Änderungen angewendet haben, können Sie den Metrik-Explorer über die Übersichtsseite von Azure Monitor oder über den Abschnitt Überwachung des ausgewählten Clusters öffnen und auf eine Zunahme oder Abnahme der Anzahl von Ereignissen prüfen, die pro Minute erfasst werden. So können Sie ermitteln, ob eine bestimmte Metrik fehlt oder ob alle Metriken fehlen.

  • Eine bestimmte Metriken ist nicht verfügbar

    Es gibt Fälle, in denen Metriken dokumentiert werden, aber nicht vom Ziel verfügbar gemacht und nicht an den Azure Monitor-Arbeitsbereich weitergeleitet werden. In diesem Fall muss überprüft werden, ob andere Metriken an den Arbeitsbereich weitergeleitet werden.

  • Kein Zugriff auf den Azure Monitor-Arbeitsbereich

    So könnten Sie beim Aktivieren des Add-Ons einen vorhandenen Arbeitsbereich angeben, auf den Sie keinen Zugriff haben. In diesem Fall könnte es so aussehen, als würden die Metriken nicht erfasst und weitergeleitet. Stellen Sie sicher, dass Sie beim Aktivieren des Add-Ons oder beim Erstellen des Clusters einen neuen Arbeitsbereich erstellen.

Deaktivieren von Steuerelementebenenmetriken auf Ihrem AKS-Cluster

Sie können Metriken der Steuerungsebene jederzeit deaktivieren, indem Sie das verwaltete Prometheus-Add-On deaktivieren und die Registrierung des Feature-Flags AzureMonitorMetricsControlPlanePreview aufheben.

  1. Führen Sie den Befehl az aks update aus, um das Metrik-Add-On zu entfernen, das Prometheus-Metriken ausliest.

    az aks update --disable-azure-monitor-metrics --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

  2. Deaktivieren Sie das Auslesen der Metriken der Steuerungsebene im AKS-Cluster, indem Sie die Registrierung des Feature-Flags AzureMonitorMetricsControlPlanePreview mithilfe des Befehls az feature unregister aufheben.

    az feature unregister "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

Häufig gestellte Fragen

  • Kann ich Metriken der Steuerungsebene mit selbst gehostetem Prometheus auslesen?

    Nein, gegenwärtig können Sie Metriken der Steuerungsebene nicht mit selbst gehostetem Prometheus auslesen. Selbst gehostetes Prometheus kann nur die einzelne Instanz je nach Lastenausgleich auslesen. Die Metriken sind nicht zuverlässig, da es häufig mehrere Replikate der Metriken der Steuerungsebene gibt, die nur über verwaltetes Prometheus sichtbar sind.

  • Warum ist der Benutzer-Agent nicht über die Metriken der Steuerebene verfügbar?

    Metriken der Steuerungsebene in Kubernetes verfügen nicht über den Benutzer-Agent. Der Benutzer-Agent ist nur über die Protokolle der Steuerungsebene in den Diagnoseeinstellungen verfügbar.

Azure Monitor-Ressourcenprotokolle

Ressourcenprotokolle bieten Einblicke in Vorgänge, die von einer Azure-Ressourcen ausgeführt wurden. Protokolle werden automatisch generiert, aber Sie müssen sie an Azure Monitor-Protokolle weiterleiten, um sie zu speichern oder abzufragen. Protokolle sind in Kategorien organisiert. Ein bestimmter Namespace verfügt möglicherweise über mehrere Ressourcenprotokollkategorien.

Sammlung: Ressourcenprotokolle werden erst gesammelt und gespeichert, nachdem Sie eine Diagnoseeinstellung erstellt und die Protokolle an mindestens einen Speicherort weitergeleitet haben. Wenn Sie eine Diagnoseeinstellung erstellen, legen Sie fest, welche Kategorien von Protokollen gesammelt werden sollen. Es gibt mehrere Möglichkeiten zum Erstellen und Verwalten von Diagnoseeinstellungen, u. a. das Azure-Portal, programmgesteuert und über Azure Policy.

Routing: Der vorgeschlagene Standard besteht darin, Ressourcenprotokolle an Azure Monitor-Protokolle weiterzuleiten, damit Sie diese mit anderen Protokolldaten abfragen können. Andere Speicherorte wie z. B. Azure Storage, Azure Event Hubs und bestimmte Microsoft-Überwachungspartner sind ebenfalls verfügbar. Weitere Informationen finden Sie unter Azure-Ressourcenprotokolle und Ressourcenprotokollziele.

Ausführliche Informationen zum Sammeln, Speichern und Weiterleiten von Ressourcenprotokollen finden Sie unter Diagnoseeinstellungen in Azure Monitor.

Eine Liste aller verfügbaren Ressourcenprotokollkategorien in Azure Monitor finden Sie unter Unterstützte Ressourcenprotokolle in Azure Monitor.

Alle Ressourcenprotokolle in Azure Monitor enthalten dieselben Headerfelder, gefolgt von dienstspezifischen Feldern. Das allgemeine Schema wird in Azure Monitor-Ressourcenprotokollschema beschrieben.

Die verfügbaren Kategorien von Ressourcenprotokollen mit ihren zugehörigen Log Analytics-Tabellen und die Protokollschemas für AKS finden Sie unter Azure Kubernetes Service – Überwachungsdatenreferenz.

AKS-Steuerungsebene/-Ressourcenprotokolle

Protokolle der Steuerungsebene für AKS-Cluster sind in Azure Monitor als Ressourcenprotokolle implementiert. Ressourcenprotokolle werden erst erfasst und gespeichert, nachdem Sie eine Diagnoseeinstellung erstellt haben, um die Protokolle an mindestens einen Speicherort weiterzuleiten. Sie senden sie in der Regel an einen Log Analytics-Arbeitsbereich, in dem die meisten Daten für Container Insights gespeichert werden.

Ausführliche Informationen zum Erstellen einer Diagnoseeinstellung über das Azure-Portal, die Befehlszeilenschnittstelle oder PowerShell finden Sie unter Erstellen von Diagnoseeinstellungen. Wenn Sie eine Diagnoseeinstellung erstellen, legen Sie fest, welche Kategorien von Protokollen gesammelt werden sollen. Die Kategorien für AKS sind in der AKS-Überwachungsdatenreferenz aufgeführt.

Wichtig

Beim Sammeln von Ressourcenprotokollen für AKS können erhebliche Kosten anfallen, insbesondere für Kube-Audit-Protokolle. Berücksichtigen Sie die folgenden Empfehlungen, um die Menge der gesammelten Daten zu reduzieren:

  • Deaktivieren Sie die kube-audit-Protokollierung, wenn sie nicht erforderlich ist.
  • Aktivieren Sie die Sammlung von kube-audit-admin – dabei werden die Überwachungsereignisse „get“ und „list“ ausgeschlossen.
  • Aktivieren Sie ressourcenspezifische Protokolle, wie hier beschrieben, und konfigurieren Sie die AKSAudit-Tabelle als Basisprotokoll.

Unter Überwachen von Kubernetes-Clustern mithilfe von Azure-Diensten und cloudnativen Tools finden Sie weitere Empfehlungen, und unter Kostenoptimierung und Azure Monitor finden Sie weitere Strategien zur Senkung der Überwachungskosten.

AKS unterstützt entweder den Azure-Diagnosemodus oder den ressourcenspezifischen Modus für Ressourcenprotokolle. Mit diesem Modus werden die Tabellen in dem Log Analytics-Arbeitsbereich angegeben, an den die Daten gesendet werden. Der Azure Diagnosemodus sendet alle Daten an die Tabelle AzureDiagnostics, während der ressourcenspezifische Modus Daten an AKS Audit, AKS Audit Admin und AKS Control Plane sendet, wie in der Tabelle unter Ressourcenprotokolle dargestellt.

Der ressourcenspezifische Modus wird aus folgenden Gründen für AKS empfohlen:

  • Daten lassen sich einfacher abfragen, da sie sich in einzelnen Tabellen befinden, die speziell für AKS gelten.
  • Die Konfiguration als Basisprotokoll wird unterstützt, um erhebliche Kosteneinsparungen zu erzielen.

Weitere Informationen zum Unterschied zwischen den Sammlungsmodi, einschließlich Informationen zum Ändern einer vorhandenen Einstellung, finden Sie unter Auswählen des Sammlungsmodus.

Hinweis

Es ist auch möglich, Diagnoseeinstellungen über die CLI zu konfigurieren. In diesen Fällen ist der Erfolg nicht garantiert, da nicht der Bereitstellungsstatus des Clusters überprüft wird. Vergewissern Sie sich, dass Sie die Diagnoseeinstellungen des Clusters überprüfen, um sie nach der Konfiguration widerzuspiegeln.

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

Beispielprotokollabfragen

Wichtig

Wenn Sie im Menü für einen AKS-Cluster Protokolle auswählen, wird Log Analytics geöffnet, wobei der Abfragebereich auf den aktuellen Cluster festgelegt ist. Dies bedeutet, dass Protokollabfragen nur Daten aus dieser Ressource umfassen. Wenn Sie eine Abfrage ausführen möchten, die Daten aus anderen Clustern oder Daten aus anderen Azure-Diensten enthält, wählen Sie im Menü Azure Monitor die Option Protokolle aus. Ausführliche Informationen finden Sie unter Protokollabfragebereich und Zeitbereich in Azure Monitor Log Analytics.

Wenn die Diagnoseeinstellung für Ihren Cluster den Azure-Diagnosemodus verwendet, werden die Ressourcenprotokolle für AKS in der Tabelle AzureDiagnostics gespeichert. Mit der Spalte Kategorie können Sie verschiedene Protokolle unterscheiden. Eine Beschreibung der einzelnen Kategorien finden Sie in den AKS-Referenzressourcenprotokollen.

Beschreibung Protokollabfrage
Zählen von den Protokollen für jede Kategorie
(Azure-Diagnosemodus)		 AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
Alle API-Serverprotokolle
(Azure-Diagnosemodus)		 AzureDiagnostics
| where Category == "kube-apiserver"
Alle kube-audit-Protokolle in einem Zeitbereich
(Azure-Diagnosemodus)		 let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
Alle Überwachungsprotokolle
(ressourcenspezifischer Modus)		 AKSAudit
Alle Überwachungsprotokolle mit Ausnahme der Überwachungsereignisse für „get“ und „list“
(ressourcenspezifischer Modus)		 AKSAuditAdmin
Alle API-Serverprotokolle
(ressourcenspezifischer Modus)		 AKSControlPlane
| where Category == "kube-apiserver"

Informationen zum Zugreifen auf eine Reihe vordefinierter Abfragen im Log Analytics-Arbeitsbereich finden Sie in der Log Analytics-Abfrageoberfläche. Wählen Sie dort den Ressourcentyp Kubernetes Services aus. Eine Liste der häufig verwendeten Abfragen für Container Insights finden Sie unter Container Insights-Abfragen.

Protokolle der AKS-Datenebene/Protokolle für Containererkenntnisse

„Containererkenntnisse“ sammelt verschiedene Arten von Telemetriedaten aus Containern und Kubernetes-Clustern, die Ihnen helfen, Ihre containerisierten Anwendungen, die in Ihren AKS-Clustern ausgeführt werden, zu überwachen, eine Problembehandlung für sie auszuführen und Erkenntnisse zu ihnen zu gewinnen. Eine Liste der Tabellen und deren ausführliche Beschreibungen, die von Container Insights verwendet werden, finden Sie in der Azure Monitor Tabellenreferenz. Alle diese Tabellen sind für Protokollabfragen verfügbar.

Die Kostenoptimierungseinstellungen ermöglichen es Ihnen, die über den Agent für Containererkenntnisse gesammelten Metrikdaten anzupassen und zu steuern. Dieses Feature unterstützt die Datensammlungseinstellungen für die Auswahl einzelner Tabellen, Datensammlungsintervalle und Namespaces, um die Datensammlung über Azure Monitor-Datensammlungsregeln (Data Collection Rules, DCR) auszuschließen. Diese Einstellungen steuern das Erfassungsvolumen und reduzieren die Überwachungskosten für Container Insights. In Container Insights gesammelte Daten können über das Azure-Portal mithilfe der folgenden Optionen angepasst werden. Die Auswahl anderer Optionen als Alle (Standard) führt dazu, dass die Container Insights-Benutzeroberfläche nicht mehr verfügbar ist.

Gruppierung Tabellen Hinweise
Alle (Standard) Alle Container Insights-Standardtabellen Zum Aktivieren der Container Insights-Standardvisualisierungen erforderlich
Leistung Perf, InsightsMetrics
Protokolle und Ereignisse ContainerLog oder ContainerLogV2, KubeEvents, KubePodInventory Empfohlen, wenn Sie verwaltete Prometheus-Metriken aktiviert haben
Workloads, Bereitstellungen und HPAs InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices
Persistent Volumes InsightsMetrics, KubePVInventory

Die Gruppierung Protokolle und Ereignisse erfasst die Protokolle aus den Tabellen ContainerLog oder ContainerLogV2, KubeEvents, KubePodInventory, aber nicht die Metriken. Der empfohlene Pfad zum Sammeln von Metriken besteht darin, den verwalteten Azure Monitor-Dienst für Prometheus über Ihren AKS-Cluster zu aktivieren und Azure Managed Grafana für die Datenvisualisierung zu verwenden. Weitere Informationen finden Sie unter Verwalten eines Azure Monitor-Arbeitsbereichs.

ContainerLogV2-Schema

Die Containererkenntnisse von Azure Monitor stellen ein Schema für Containerprotokolle bereit, die als ContainerLogV2 bezeichnet werden. Dies ist die empfohlene Option. Dieses Format enthält die folgenden Felder, um allgemeine Abfragen zum Anzeigen von Daten im Zusammenhang mit AKS- und Azure Arc-fähigen Kubernetes-Clustern zu erleichtern:

  • ContainerName
  • PodName
  • PodNamespace

Darüber hinaus ist dieses Schema mit dem Datenplan Basisprotokolle kompatibel, was eine kostengünstige Alternative zu den standardmäßigen Analyseprotokollen bietet. Mit dem Basic-Protokolldatenplan können Sie die Kosten für das Erfassen und Speichern von ausführlichen Protokollen mit hohem Volumen sparen, die Sie in Ihrem Log Analytics-Arbeitsbereich zum Debuggen, zur Problembehandlung und Überwachung verwenden. Dies wirkt sich nicht auf die Kosten für Analysen und Warnungen aus. Weitere Informationen finden Sie unter Verwalten von Tabellen in einem Log Analytics-Arbeitsbereich.

ContainerLogV2 ist der empfohlene Ansatz und das Standardschema für Kunden, die das Onboarding der Containererkenntnisse mit Authentifizierung per verwalteter Identität über ARM, Bicep, Terraform, Policy und das Azure-Portal durchführen. Weitere Informationen zum Aktivieren von ContainerLogV2 über die Datensammlungsregel des Clusters oder ConfigMap finden Sie unter Aktivieren des ContainerLogV2-Schemas.

Azure-Aktivitätsprotokoll

Das Aktivitätsprotokoll enthält Ereignisse auf Abonnementebene, die Vorgänge für jede Azure-Ressource nachverfolgen, so wie sie von außerhalb dieser Ressource gesehen werden, z. B. das Erstellen einer neuen Ressource oder das Starten einer VM.

Sammlung: Aktivitätsprotokollereignisse werden automatisch generiert und in einem separaten Speicher für die Anzeige im Azure-Portal gesammelt.

Routing: Sie können Aktivitätsprotokolldaten an Azure Monitor-Protokolle senden, damit Sie diese zusammen mit anderen Protokolldaten analysieren können. Andere Speicherorte wie z. B. Azure Storage, Azure Event Hubs und bestimmte Microsoft-Überwachungspartner sind ebenfalls verfügbar. Weitere Informationen zum Weiterleiten von Aktivitätsprotokollen finden Sie unter Übersicht über das Azure-Aktivitätsprotokoll.

Anzeigen von Protokollen, Ereignissen und Podmetriken für AKS-Container (Azure Kubernetes Service) in Echtzeit

In diesem Artikel erfahren Sie, wie Sie das Feature Livedaten in Container Insights verwenden, um Protokolle, Ereignisse und Podmetriken von AKS-Containern (Azure Kubernetes Service) in Echtzeit anzuzeigen. Dieses Feature bietet direkten Zugriff auf kubectl logs -c, kubectl get-Ereignisse und kubectl top pods, um Sie bei der Problembehandlung in Echtzeit zu unterstützen.

Hinweis

AKS verwendet Protokollierungsarchitekturen auf Kubernetes-Clusterebene. Die Containerprotokolle befinden sich auf dem Knoten in /var/log/containers. Weitere Informationen zum Zugreifen auf einen Knoten finden Sie unter Herstellen einer Verbindung mit AKS-Clusterknoten (Azure Kubernetes Service).

Hilfe zum Einrichten des Livedatenfeatures finden Sie unter Konfigurieren von Livedaten in Container Insights. Dieses Feature greift direkt auf die Kubernetes-API zu. Weitere Informationen zum Authentifizierungsmodell finden Sie unter der Kubernetes-API.

Anzeigen von Liveprotokollen zu AKS-Ressourcen

Hinweis

Um auf Protokolle von einem privaten Cluster zuzugreifen, müssen Sie einen Computer im gleichen privaten Netzwerk wie der Cluster verwenden.

  1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

  2. Wählen Sie unter Kubernetes-Ressourcen die Option Workloads aus.

  3. Wählen Sie die Bereitstellung, den Pod, die Replikatgruppe, das StatefulSet, den Auftrag oder den Cronjob aus, für den/die/das Sie Protokolle anzeigen möchten, und wählen Sie dann Liveprotokolle aus.

  4. Wählen Sie die Ressource aus, für die Protokolle angezeigt werden sollen.

    Das folgende Beispiel zeigt die Protokolle für eine Ressource vom Typ Pod an:

    Screenshot: Bereitstellung von Liveprotokollen

Anzeigen von Liveprotokollen

Sie können Echtzeitprotokolldaten, während diese von der Container-Engine generiert werden, unter Cluster, Knoten, Controller oder Container anzeigen.

  1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

  2. Wählen Sie unter Überwachung die Option Erkenntnisse aus.

  3. Wählen Sie die Registerkarte Cluster, Knoten, Controller oder Container und dann das Objekt aus, für das Sie Protokolle anzeigen möchten.

  4. Wählen Sie in der Übersicht der Ressource Liveprotokolle aus.

    Hinweis

    Um Daten aus Ihrem Log Analytics-Arbeitsbereich anzuzeigen, wählen Sie Protokolle in Log Analytics anzeigen aus. Weitere Informationen zum Anzeigen von Verlaufsprotokollen, Ereignissen und Metriken finden Sie unter Abfragen von Protokollen von Container Insights.

    Wenn Daten nach erfolgreicher Authentifizierung abgerufen werden können, werden sie zur Registerkarte „Liveprotokolle“ gestreamt. Protokolldaten können hier in einem fortlaufenden Stream angezeigt werden. Die folgende Abbildung zeigt die Protokolle für eine Ressource vom Typ Container:

    Screenshot der Option „Daten anzeigen“ für Liveprotokolle eines Containers

Anzeigen von Liveereignissen

Sie können Echtzeitereignisdaten, während diese von der Container-Engine generiert werden, unter Cluster, Knoten, Controller oder Container anzeigen.

  1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

  2. Wählen Sie unter Überwachung die Option Erkenntnisse aus.

  3. Wählen Sie die Registerkarte Cluster, Knoten, Controller oder Container und dann das Objekt aus, für das Sie Ereignisse anzeigen möchten.

  4. Wählen Sie auf der Seite Übersicht der Ressource die Option Liveereignisse aus.

    Hinweis

    Um Daten aus Ihrem Log Analytics-Arbeitsbereich anzuzeigen, wählen Sie Ereignisse in Log Analytics anzeigen aus. Weitere Informationen zum Anzeigen von Verlaufsprotokollen, Ereignissen und Metriken finden Sie unter Abfragen von Protokollen von Container Insights.

    Wenn Daten nach erfolgreicher Authentifizierung abgerufen werden können, werden sie zur Registerkarte „Liveereignisse“ gestreamt. Die folgende Abbildung zeigt die Ereignisse für eine Ressource vom Typ Container:

    Screenshot der Option „Daten anzeigen“ für Liveereignisse eines Containers

Anzeigen von Metriken

Sie können Echtzeitmetrikdaten, während diese von der Container-Engine generiert werden, unter Knoten oder Controller anzeigen, indem Sie eine Ressource vom Typ Pod auswählen.

  1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

  2. Wählen Sie unter Überwachung die Option Erkenntnisse aus.

  3. Wählen Sie die Registerkarte Knoten oder Controller und dann das Pod-Objekt aus, für das Sie Metriken anzeigen möchten.

  4. Wählen Sie auf der Seite Übersicht der Ressource die Option Livemetriken aus.

    Hinweis

    Um Daten aus Ihrem Log Analytics-Arbeitsbereich anzuzeigen, wählen Sie Ereignisse in Log Analytics anzeigen aus. Weitere Informationen zum Anzeigen von Verlaufsprotokollen, Ereignissen und Metriken finden Sie unter Abfragen von Protokollen von Container Insights.

    Wenn Daten nach erfolgreicher Authentifizierung abgerufen werden können, werden sie zur Registerkarte „Livemetriken“ gestreamt. Die folgende Abbildung zeigt die Metriken für eine Ressource vom Typ Pod:

    Screenshot der Option „Daten anzeigen“ für Livemetriken eines Pods

Analysieren von Überwachungsdaten

Es gibt viele Tools zum Analysieren von Überwachungsdaten.

Azure Monitor-Tools

Azure Monitor unterstützt die folgenden grundlegenden Tools:

Zu den Tools, die eine komplexere Visualisierung ermöglichen, gehören:

  • Dashboards, mit denen Sie verschiedene Typen von Daten in einen einzelnen Bereich im Azure-Portal kombinieren können.
  • Arbeitsmappen, anpassbare Berichte, die Sie im Azure-Portal erstellen können. Arbeitsmappen können Text, Metriken und Protokollabfragen enthalten.
  • Grafana, ein Tool auf einer offenen Plattform, das für operationale Dashboards ideal ist. Sie können Grafana verwenden, um Dashboards zu erstellen, die Daten aus mehreren anderen Quellen als Azure Monitor enthalten.
  • Power BI ist ein Geschäftsanalysedienst, der interaktive Visualisierungen für verschiedene Datenquellen bereitstellt. Sie können Power BI für den automatischen Import von Protokolldaten aus Azure Monitor konfigurieren, um diese Visualisierungen zu nutzen.

Exporttools für Azure Monitor

Sie können Daten aus Azure Monitor in andere Tools abrufen, indem Sie die folgenden Methoden verwenden:

Informationen zu den ersten Schritten mit der REST-API für Azure Monitor finden Sie in der exemplarischen Vorgehensweise für die Azure-Überwachungs-REST-API.

Übersichtsseite zur Überwachung im Azure-Portal

Die Registerkarte Überwachung auf der Seite Übersicht Ihres AKS-Clusters bietet einen schnellem Einstieg in die Anzeige von Überwachungsdaten im Azure-Portal. Diese Registerkarte enthält Diagramme mit allgemeinen Metriken für den Cluster getrennt nach Knotenpool. Wählen Sie eines dieser Diagramme aus, um die Daten im Metrik-Explorer genauer zu analysieren.

Die Registerkarte Überwachung enthält auch Links zu Managed Prometheus und Container Insights für den Cluster. Wenn Sie diese Tools aktivieren müssen, können Sie sie hier aktivieren. Möglicherweise wird oben auf dem Bildschirm auch ein Banner angezeigt, auf dem Ihnen empfohlen wird, weitere Features zu aktivieren, um die Überwachung Ihres Clusters zu verbessern.

Tipp

Sie können auf Überwachungsfeatures für alle AKS-Cluster in Ihrem Abonnement zugreifen, indem Sie auf der Startseite des Azure-Portals Azure Monitor auswählen.

Kusto-Abfragen

Sie können Überwachungsdaten im Azure Monitor Logs / Log Analytics Store mithilfe der Kusto-Abfragesprache (KQL) analysieren.

Wichtig

Wenn Sie Protokolle im Menü des Diensts im Portal auswählen, wird Log Analytics geöffnet, wobei der Abfragebereich auf den aktuellen Dienst festgelegt ist. Dieser Bereich bedeutet, dass Protokollabfragen nur Daten aus diesem Ressourcentyp umfassen. Wenn Sie eine Abfrage durchführen möchten, die Daten aus anderen Azure-Diensten enthält, wählen Sie im Menü Azure Monitor die Option Protokolle aus. Ausführliche Informationen finden Sie unter Protokollabfragebereich und Zeitbereich in Azure Monitor Log Analytics.

Eine Liste häufiger Abfragen für alle Dienste finden Sie unter Log Analytics-Abfrageschnittstelle.

Alerts

Azure Monitor-Warnungen informieren Sie proaktiv, wenn bestimmte Bedingungen in Ihren Überwachungsdaten auftreten. Warnungen ermöglichen Ihnen, Probleme in Ihrem System zu identifizieren und zu beheben, bevor Ihre Kunden sie bemerken. Weitere Informationen finden Sie unter Azure Monitor-Warnungen.

Es gibt viele Quellen allgemeiner Warnungen für Azure-Ressourcen. Beispiele für häufige Warnungen für Azure-Ressourcen finden Sie in den Beispielabfragen für Protokollwarnungen. Die Website Azure Monitor-Baselinewarnungen (Azure Monitor Baseline Alerts, AMBA) stellt eine halbautomatisierte Methode für die Implementierung wichtiger Metrikwarnungen der Plattform, Dashboards und Richtlinien bereit. Die Website gilt für eine fortlaufend erweiterte Teilmenge von Azure-Diensten, einschließlich aller Dienste, die Teil der Azure-Zielzone (Azure Landing Zone, ALZ) sind.

Mit dem allgemeinen Warnungsschema wird die Benutzeroberfläche für Warnungsbenachrichtigungen in Azure Monitor standardisiert. Weitere Informationen finden Sie unter Allgemeines Warnungsschema.

Warnungstypen

Sie können zu jeder Metrik oder Protokolldatenquelle der Azure Monitor-Datenplattform Warnungen erhalten. Es gibt viele verschiedene Typen von Warnungen, abhängig von den Diensten, die Sie überwachen, und den Überwachungsdaten, die Sie sammeln. Verschiedene Typen von Warnungen haben jeweils ihre Vor- und Nachteile. Weitere Informationen finden Sie unter Auswählen des richtigen Warnungsregeltyps.

In der folgenden Liste werden die Typen von Azure Monitor-Warnungen beschrieben, die Sie erstellen können:

  • Metrikwarnungen bewerten Ressourcenmetriken in regelmäßigen Abständen. Metriken können Plattformmetriken, benutzerdefinierte Metriken, in Metriken konvertierte Protokolle aus Azure Monitor oder Application Insights-Metriken sein. Metrikwarnungen können auch mehrere Bedingungen und dynamische Schwellwerte anwenden.
  • Protokollwarnungen ermöglichen es Benutzern, eine Log Analytics-Abfrage zum Auswerten von Ressourcenprotokollen in vordefinierten Frequenz zu verwenden.
  • Aktivitätsprotokollwarnungen werden ausgelöst, wenn ein neues Aktivitätsprotokollereignis eintritt, das definierte Bedingungen erfüllt. Resource Health- und Service Health-Warnungen sind Aktivitätsprotokollwarnungen, die über die Dienst- und Ressourcenintegrität berichten.

Einige Azure-Dienste unterstützen auch intelligente Erkennungswarnungen, Prometheus-Warnungen oder empfohlene Warnungsregeln.

Einige Dienste können Sie im großen Stil überwachen, indem Sie dieselbe Metrikwarnungsregel auf mehrere Ressourcen desselben Typs anwenden, die sich in derselben Azure-Region befinden. Für jede überwachte Ressource werden einzelne Benachrichtigungen gesendet. Unterstützte Azure-Dienste und -Clouds finden Sie unter Überwachen mehrerer Ressourcen mit einer Warnungsregel.

Für einige Azure-Dienste können Sie empfohlene sofort einsatzbereite Warnungsregelnaktivieren.

Das System kompiliert eine Liste der empfohlenen Warnungsregeln basierend auf:

  • Das Wissen des Ressourcenanbieters über wichtige Signale und Schwellenwerte zur Überwachung der Ressource.
  • Daten, die uns erklären, weshalb Kunden häufig Warnungen für diese Ressource erhalten.

Hinweis

Empfohlene Warnungsregeln stehen zur Verfügung für:

  • Virtuelle Computer
  • Azure Kubernetes Service (AKS) Ressourcen
  • Log Analytics-Arbeitsbereiche

Auf Prometheus-Metriken basierende Warnungen

Wenn Sie die Sammlung von Prometheus-Metriken für Ihren Cluster aktivieren, können Sie eine Sammlung der empfohlenen Prometheus-Warnungsregeln herunterladen. Der Download umfasst die folgenden Regeln:

Ebene Alerts
Clusterebene KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Knotenebene KubeNodeUnreachable
KubeNodeReadinessFlapping
Podebene KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

Weitere Informationen finden Sie unter Erstellen von Protokollwarnungen auf der Grundlage von Containererkenntnissen und Abfragen von Protokollen aus Containererkenntnissen. Protokollwarnungen können zwei verschiedene Dinge messen, die zum Überwachen in verschiedenen Szenarien verwendet werden können:

  • Ergebnisanzahl: Erfasst die Anzahl der von der Abfrage zurückgegebenen Zeilen und kann zum Arbeiten mit Ereignissen wie Windows-Ereignisprotokollen, Syslog und Anwendungsausnahmen verwendet werden.
  • Berechnung eines Werts: Führt eine Berechnung basierend auf einer numerischen Spalte durch und kann verwendet werden, um eine beliebige Anzahl von Ressourcen einzuschließen. Ein Beispiel ist die prozentuale CPU-Auslastung.

Abhängig vom erforderlichen Warnungsszenario müssen Protokollabfragen erstellt werden. Diese Abfragen vergleichen mithilfe des Operators now einen DateTime-Wert mit der aktuellen Uhrzeit und gehen um eine Stunde zurück. Informationen zum Erstellen von protokollbasierten Warnungen finden Sie unter Erstellen von Protokollwarnungen auf der Grundlage von Containererkenntnissen.

AKS-Warnungsregeln

In der folgenden Tabelle sind einige vorgeschlagene Warnungsregeln für AKS aufgeführt. Diese Warnungen sind nur Beispiele. Sie können Warnungen für alle Metriken, Protokolleinträge und Aktivitätsprotokolleinträge festlegen, die in der Überwachungsdatenreferenz für Azure Kubernetes Service aufgeführt sind.

Condition Beschreibung
Prozentuale CPU-Auslastung > 95 Wird ausgelöst, wenn die durchschnittliche CPU-Auslastung auf allen Knoten den Schwellenwert überschreitet.
Arbeitssatz für Arbeitsspeicher (Prozent) > 100 Wird ausgelöst, wenn der durchschnittliche Arbeitssatz auf allen Knoten den Schwellenwert überschreitet.

Advisor-Empfehlungen

Wenn in einigen Diensten während eines Ressourcenvorgangs kritische Bedingungen oder unmittelbar bevorstehende Änderungen auftreten, wird auf der Dienstseite Übersicht im Portal eine Warnung angezeigt. Weitere Informationen und empfohlene Korrekturen für die Warnung finden Sie in Advisor-Empfehlungen unter Überwachung im linken Menü. Während des normalen Betriebs werden keine Advisor-Empfehlungen angezeigt.

Weitere Informationen zu Azure Advisor finden Sie unter Azure Advisor – Übersicht.

Hinweis

Wenn Sie eine Anwendung erstellen oder ausführen, die in Ihrem Dienst ausgeführt wird, stellt Azure Monitor Application Insights möglicherweise andere Warnungstypen zur Verfügung.

Netzwerkeinblick

Network Observability ist ein wichtiger Bestandteil der Aufrechterhaltung eines fehlerfreien und leistungsfähigen Kubernetes-Clusters. Durch das Sammeln und Analysieren von Daten zum Netzwerkdatenverkehr können Sie Einblicke in den Betrieb Ihres Clusters gewinnen und potenzielle Probleme identifizieren, bevor sie zu Ausfällen oder Leistungseinbußen führen.

Wenn das Network Observability-Add-On aktiviert ist, sammelt und konvertiert es nützliche Metriken in das Prometheus-Format, das in Grafana visualisiert werden kann. Wenn diese Option aktiviert ist, werden die gesammelten Metriken automatisch im verwalteten Azure Monitor-Dienst für Prometheus erfasst. Ein Grafana-Dashboard ist im öffentlichen Repository mit Grafana-Dashboards verfügbar, um die von Prometheus gesammelten Network Observability-Metriken zu visualisieren. Ausführliche Anweisungen finden Sie unter Einrichten von Network Observability.

Zugehöriger Inhalt