Was sind Containernetzwerkmetriken?

Containernetzwerkmetriken in Advanced Container Networking Services für Azure Kubernetes Service (AKS) helfen Ihnen, Paketabbrüche zu identifizieren, Netzwerkaktivitäten nachzuverfolgen und DAS DNS-Verhalten zu untersuchen. Beginnen Sie mit Metriken auf Knotenebene, um ein Netzwerkintegritätsproblem zu finden, und verwenden Sie dann Pod-Level-Metriken, um die beteiligten Workloads zu identifizieren.

Die Metriksammlung ist für unterstützte Cilium- und nicht-Cilium-Datenebenen verfügbar. Pod-Level-Metriken erfordern Linux; die Referenztabellen zeigen, welche Metriken auf Knotenebene auch für Windows verfügbar sind.

Metriksammlung auf einen Blick

Verwenden Sie diese Tabelle, um die Unterstützung der Metriksammlung für Datenebenen zu überprüfen:

Befolgen Sie für die anfängliche Sammlung Containernetzwerkmetriken einrichten. Verwenden Sie für Aufzeichnungen einzelner Netzwerkverkehrsdetails anstelle von Zählern Container-Netzwerkprotokolle.

Hauptvorteile

• Granularität auf Knoten- und Podebene. Nachverfolgen von Datenverkehrsvolumen, Dropraten und Verbindungszuständen auf Knotenebene für den Infrastrukturstatus. Um die genaue Arbeitslast zu ermitteln, die ein Problem verursacht, können Sie sich anhand der Quell- und Zielbezeichnungen bis zu den einzelnen Pods vorarbeiten.

• Schnellere Problembehandlung. Wenn ein Dienst Pakete verwirft oder DNS-Abfragen fehlschlagen, helfen Ihnen Metriken auf Podebene, das Problem auf einen bestimmten Pod, Namespace oder ein bestimmtes Protokoll einzugrenzen.

• Integrierte Visualisierung. Speichern Sie Metriken im verwalteten Azure Monitor-Dienst für Prometheus, und öffnen Sie Netzwerkdashboards direkt im Azure-Portal mit Dashboards mit Grafana. Die Dashboardoberfläche ist kostenlos und erfordert keine Azure Managed Grafana Instanz; für ACNS sowie die Aufnahme und Speicherung von Metriken fallen weiterhin Gebühren an. Sie können auch eine separate Grafana-Bereitstellung verwenden.

So funktioniert es

Der Agentstapel auf jedem Knoten hängt von der Datenebene ab, wie im Diagramm dargestellt.

Linux-Cilium-Knoten verwenden einen mehrschichtigen eBPF-basierten Stapel: eBPF-Kernel-Hooks erfassen Rohdaten, Cilium verarbeitet sie und Hubble macht ihn als Prometheus-Formatmetriken verfügbar.

Linux-Nicht-Cilium-Knoten verwenden eBPF-Kernel-Hooks, die in Microsoft Retina eingespeist werden, mit einer darüberliegenden Hubble-Schicht zur Flussinspektion. Microsoft Retina verarbeitet metrische Sammlung und exportiert Metriken auf Knotenebene und Pod-Level-Metriken im Prometheus-Format.

Aus allen Pfaden rufen Sie Metriken im Prometheus-Format ab und speisen sie in den verwalteten Azure Monitor-Dienst für Prometheus oder Ihr eigenes Prometheus-Back-End ein. Öffnen Sie für den verwalteten Pfad Ihren AKS-Cluster im Azure-Portal, und wählen Sie Monitoring> aus, um Netzwerkdashboards anzuzeigen. Azure Managed Grafana und Ihre eigene Grafana-Bereitstellung sind optionale Alternativen. Siehe Dashboards mit Grafana und AKS verwenden.

Um zu beginnen, richten Sie Containernetzwerkmetriken ein.

Wann man Container-Netzwerkmetriken verwenden sollte

Containernetzwerkmetriken sind für Teams konzipiert, die fokussierte, umsetzbare Netzwerkdaten anstelle von unformatierter Telemetrie benötigen. Zu den gängigen Szenarien gehören:

• Debuggen einer bestimmten Arbeitsauslastung. Verwenden Sie Pod-Level-Metriken, um Paketabbrüche, TCP-Zurücksetzungen oder DNS-Fehler für einen bestimmten Dienst zu isolieren.
• Überwachen von Multitenantclustern. Verwenden Sie Pod-Level-Metriken, um den Netzwerkzustand nach Namespace zu verfolgen und die Datenverkehrsmuster jedes Teams zu verstehen.
• Kapazitätsplanung. Verfolgen Sie die Anzahl der weitergeleiteten und verworfenen Bytes pro Knoten, um ausgelastete Verbindungen oder eine unausgewogene Arbeitslastverteilung zu identifizieren.
• Überwachung der DNS-Gesundheit. Erkennen von DNS-Abfragefehlern und langsamen Auflösungszeiten, um Probleme zu identifizieren, bevor sie zu Anwendungsfehlern führen.

Bevor Sie die Metriktabellen überprüfen

Beachten Sie Folgendes:

• Metriken auf Knotenebene sind in unterstützten Cilium- und nicht-Cilium-Datenebenen verfügbar.
• Pod-Level-Metriken sind unter Linux verfügbar.
• Für Cilium-Cluster erfordern DNS-Metriken eine Cilium-FQDN-Netzwerkrichtlinie.

Metrikenreferenz

Metriken auf Knotenebene

Metriken auf Knotenebene bieten aggregierte Datenverkehrsstatistiken pro Knoten – weitergeleitete und verworfene Pakete, Byteanzahl und Verbindungszustände. Diese Metriken werden im Prometheus-Format gespeichert und können in Grafana visualisiert werden.

Die folgenden Metriken werden pro Knoten aggregiert. Alle Metriken enthalten die folgenden Bezeichnungen:

• cluster
• instance (Knotenname)

Cilium

Bei Cilium-Datenebenenclustern sind Metriken auf Knotenebene nur unter Linux verfügbar. Cilium macht die folgenden Metriken verfügbar, die von Containernetzwerkmetriken verwendet werden:

Nicht-Cilium

Für Szenarien mit nicht-Cilium-Datenebenen stehen Containernetzwerkmetriken sowohl für Linux als auch für Windows zur Verfügung.

Metriken auf Podebene (Hubble-Metriken)

Metriken auf Pod-Ebene umfassen Quell- und Ziel-Pod-Informationen, sodass Sie Netzwerkprobleme auf der Ebene der einzelnen Workloads identifizieren können. Diese Metriken decken das Datenverkehrsvolumen, verworfene Pakete, TCP-Zurücksetzungen und Layer 4/Layer 7-Flüsse ab.

DNS-Metriken (Abfrageanzahl, Antwortcodes und Fehler) werden standardmäßig auf Nicht-Cilium-Datenebenen erfasst. Auf Cilium-Datenebenen erfordern DNS-Metriken eine Cilium-FQDN-Netzwerkrichtlinie. Sie können DNS-Probleme auch in Echtzeit beheben, indem Sie die Hubble CLI verwenden.

In der folgenden Tabelle werden die Metriken beschrieben, die pro Pod aggregiert werden (Knoteninformationen bleiben erhalten).

Alle Metriken enthalten Bezeichnungen:

• cluster

• instance (Knotenname)

• source oder destination

  • Bei ausgehendem Datenverkehr gibt ein source Label den Quell-Pod-Namespace und den Namen an.

  • Bei eingehendem Datenverkehr gibt eine destination Bezeichnung den Ziel-Pod-Namespace und den Namen an.

Wählen Sie aus, welche Metriken in Cilium-Clustern gesammelt werden sollen.

Verwenden Sie auf Cilium-Clustern die Filterung auf Quellebene , um auszuwählen, welche Beobachtungen zu einzelnen Hubble-Metriken beitragen, bevor sie Ihr Monitoring-Back-End erreichen. Diese Filterung unterscheidet sich von der Filterung eines Grafana-Dashboards, wodurch nur das geändert wird, was Sie sehen. Die Sammlung auf eine Anwendung einschränken und dann selektiv externe IP- oder Zielportmetriken aktivieren, wenn eine Untersuchung dieses Details benötigt.

Die Filterung kann unnötige Erfassungs- und Erfassungskosten reduzieren. Zusätzliche Metriken können die Anzahl und Kosten der Zeitreihen erhöhen. Überprüfen Sie daher den Nutzen und das Volumen, bevor Sie sie ausweiten. Zuvor erstellte Serien und historische Beispiele können sichtbar bleiben; Einsparungen hängen von Ihrem Datenverkehr und Ihrer Konfiguration ab.

Wenn Sie die Beobachtbarkeit des Containernetzwerks aktivieren, machen die Agents die Standardnetzwerkmetriken des Diensts verfügbar. Verwenden Sie in Cilium-Clustern eine ContainerNetworkMetric benutzerdefinierte Ressource, um Datenverkehr für einzelne Metriktypen auszuwählen.

Das Bereitstellen einer Metrik im Cluster macht sie nicht automatisch im von Azure Monitor verwalteten Dienst für Prometheus verfügbar. Standardmäßig stellen die Cluster-Agents hubble_flows_processed_total bereit, aber Managed Prometheus schließt sie von der Erfassung aus, da sie eine große Anzahl von Zeitreihen erzeugen kann. Verwaltetes Prometheus schließt hubble_flows_to_world_total und hubble_port_distribution_total standardmäßig auch dann aus, wenn Sie sie im Cluster aktivieren. Um eine dieser Metriken zu sammeln und abzufragen, fügen Sie seinen Namen zur Hubble-Zulassungsliste in der ama-metrics-settings-configmap ConfigMap hinzu. Schritte finden Sie unter Metrikfamilien in Managed Prometheus zulassen.

Pro Cluster gibt es eine freigegebene ContainerNetworkMetric Ressource mit dem Namen container-network-metric. Koordinieren Sie Updates mit anderen Administratoren, und bewahren Sie die von anderen Teams verwendeten Metrikeinstellungen auf.

Beginnen Sie mit den Filtern zum Auswählen des Datenverkehrs für eine Anwendung oder ein Ziel. Ausschlussfilter sind optional: Verwenden Sie sie, um eine Teilmenge des ausgewählten Datenverkehrs auszulassen, oder verwenden Sie Nur-Ausschluss-Filter, um eine umfassende Erfassung mit bestimmten Ausnahmen beizubehalten. Ein Ausschluss hat Vorrang vor einem übereinstimmenden Einschluss.

Die Filterung ist nicht auf die optionalen Welt- und Zielportmetriken beschränkt. Verwenden Sie die folgenden Konfigurationsnamen für vorhandene Metriken:

Diese Filter gelten, wenn die Metrik in der Basiskonfiguration des Diensts vorhanden ist. Die Filterkonfiguration und die Beobachtungsgenerierung sind getrennt: DNS-Metrikbeobachtungen erfordern eine angewendete DNS-Inspektionsrichtlinie und DNS-Datenverkehr. HTTP-Metrikbeobachtungen erfordern die Aktivierung von L7 auf Clusterebene, eine HTTP-Inspektionsrichtlinie, die auf die Workload angewendet wird, und HTTP-Datenverkehr über diese Richtlinie. Der Filterstatus verifiziert diese Voraussetzungen nicht. Die Filterung aktiviert keine Überprüfung oder Entschlüsselung von HTTPS-Datenverkehr. Verwenden Sie für HTTP den Namen httpV2, nicht http.

Beispiele finden Sie unter DNS-, TCP-, HTTP- und Dropfilterung.

Verwenden Sie beispielsweise Include-Filter, um Flussmetriken für TCP-Datenverkehr aus dem production Namespace zu Endpunkten auszuwählen, die von Cilium als world klassifiziert werden. Dies ändert die Erfassung der Flow-Metrik, ohne die Erfassung anderer Metriktypen zu ändern. Filter unterstützen Namespace- und Podnamen, Labels, IP-Adressen, Cilium-Sicherheitsidentitäten, Protokolle und Urteile.

Die Filterung steuert, welche Beobachtungen zu einer Metrik beitragen. Es werden keine Metrikbeschriftungen hinzugefügt oder entfernt. Im Gegensatz zu zusätzlichen Aggregationsfeldern für Protokolle bleiben Metrikdimensionen vom Dienst verwaltet.

Das Filtern wirkt sich auf neue Metrikbeobachtungen an der Quelle aus. Wenn Sie einen Workload in Grafana auswählen, werden die angezeigten Ergebnisse und nicht die Sammlungskonfiguration geändert. Zuvor gesammelte Daten verbleiben im Metrik-Back-End.

Zusätzliche Metriken

Um eine der folgenden Metriken zu sammeln, fügen Sie einen Eintrag zur Ressource des ContainerNetworkMetric Clusters hinzu, der Filter enthält, die den datenverkehr auswählen, den Sie überwachen möchten. Wenn die Metrik noch nicht aktiviert ist, aktiviert die Option sie für den ausgewählten Datenverkehr. Wenn sie bereits aktiviert ist, filtert der Eintrag, welcher Datenverkehr dazu beiträgt, ohne die vorhandenen Bezeichnungen oder Optionen zu ändern.

Für Metriken, die über diese Ressource neu aktiviert wurden, konfiguriert der Dienst Quell-Pod- und Ziel-IP-Bezeichnungen für flows-to-world. Für port-distributiondiese Konfiguration werden Quell- und Ziel-Pod-Bezeichnungen und Datenverkehrsrichtung konfiguriert. Protokoll- und Bewertungsbezeichnungen sind für flows-to-world enthalten; Protokoll- und Zielportbezeichnungen sind für port-distribution enthalten. Mit diesen vom Dienst bereitgestellten Optionen zählt die globale Metrik weder den UDP-Datenverkehr noch nicht richtlinienbedingte Paketverluste.

Diese Metriken zählen beobachtete Netzwerkereignisse, keine eindeutigen Verbindungen oder Anwendungsanforderungen. Wenn ein Client z. B. ein TCP SYN-Paket sendet und es dann beim Herstellen einer Verbindung erneut überträgt, kann hubble_flows_to_world_total beide Beobachtungen zählen, auch wenn sie zum gleichen Verbindungsversuch gehören. Bezeichnungen wie Podnamen werden nur ausgefüllt, wenn diese Informationen für den beobachteten Datenverkehr verfügbar sind.

Eine vollständige benutzerdefinierte Ressource und Screenshots beider Metriken, die von einer Testworkload gesammelt wurden, finden Sie unter Beispielkonfiguration und erfasste Ergebnisse.

Verwalten von Datenrelevanz und Rauschen

Verwenden Sie Filterung, um Metriken auf die Workloads und den Datenverkehr zu konzentrieren, der für Ihre Überwachung oder Untersuchung relevant ist. Wenn Sie nicht zusammenhängenden Datenverkehr ausschließen, wird das Datenrauschen reduziert und hilft Ihnen, sich auf die wichtigen Netzwerksignale zu konzentrieren.

Ziel-IP-Adressen, Podnamen und Ports können viele Zeitreihen erzeugen. Dieses Detail kann nützlich sein, aber das Sammeln für nicht zusammengehörigen Datenverkehr führt zu mehr Rauschen und kann die Ingestionskosten erhöhen. Beginnen Sie mit einer bestimmten Workload oder einem bestimmten Namespace, überprüfen Sie, ob die Metriken Ihre Fragen beantworten, und überprüfen Sie das resultierende Datenvolume, bevor Sie die Sammlung erweitern.

Die benutzerdefinierte Ressource meldet eine Warnung für jede aktivierte zusätzliche Metrik. Die Warnung weist auf einen möglichen Kostenanstieg hin; sie prognostiziert Ihre Rechnung nicht und gibt nicht an, dass ein Grenzwert überschritten wurde. Der Dienst verwaltet Metrikbeschriftungen, und Sie können sie nicht über diese Ressource ändern.

Durch das Entfernen eines Eintrags wird die Metrik nur deaktiviert, wenn dieser Eintrag dies aktiviert hat. Wenn der Dienst die Metrik bereitstellt, bleibt sie ohne Filter dieses Eintrags aktiviert. Durch das Löschen der freigegebenen Ressource werden alle zugehörigen Filter entfernt und die vom Dienst bereitgestellte Sammlung wiederhergestellt, wodurch der in diesen Metriken enthaltene Datenverkehr erweitert und das Datenrauschen und das Aufnahmevolumen erhöht werden kann.

YaML-Beispiele, Überprüfungsabfragen und Bereinigungsschritte finden Sie unter Konfigurieren der Filterung von Containernetzwerkmetriken.

Limitations

Plattform- und Datenebene:

• Metriken auf Podebene sind nur unter Linux verfügbar.
• Die Cilium-Datenebene wird ab Kubernetes Version 1.29 unterstützt.
• Metrikfilter auf Quellebene sind nur für Cilium-Cluster verfügbar.
• Filtereinträge können flows-to-world und port-distribution aktivieren, wenn der Dienst sie noch nicht bereitstellt. Der Dienst verwaltet ihre Bezeichnungen; Diese Ressource macht keine benutzerdefinierten Metrikabmessungen verfügbar.
• Metrikbeschriftungen weisen subtile Unterschiede zwischen Cilium- und Nicht-Cilium-Clustern auf.

DNS-Metriken:

• Bei Cilium-Clustern benötigen DNS-Metriken eine Cilium-FQDN-Netzwerkrichtlinie, oder Sie können die Hubble CLI für die Dns-Problembehandlung in Echtzeit verwenden.

Bekannte Probleme:

• Wenn ein Hubble-Knotenagent ausfällt, kann das Hubble-Relay abstürzen, was Hubble-CLI-Sitzungen unterbrechen kann.

FIPS-Unterstützung (Datenebenen, die nicht auf Cilium basieren):

• FIPS ist aufgrund von Kerneleinschränkungen nicht auf Ubuntu 20.04-Knoten verfügbar. Verwenden Sie stattdessen einen Azure Linux- oder Ubuntu 22.04-Knotenpool. Diese Einschränkung gilt nicht für Cilium-Datenebenen.

Skala:

• Der verwaltete Dienst für Prometheus in Azure Monitor und Azure Managed Grafana erzwingt dienstspezifische Skalierungseinschränkungen. Weitere Informationen finden Sie unter Scrape Prometheus-Metriken im großen Stil in Azure Monitor.

Pricing

Weitere Informationen zu den Preisen finden Sie unter Erweiterte Container-Netzwerkdienste – Preise.

Verwandte Inhalte

• Einrichten von Containernetzwerkmetriken
• Konfigurieren der Filterung von Containernetzwerkmetriken
• Erweiterte Containernetzwerkdienste für AKS
• Beobachtbarkeit von Containernetzwerken in fortgeschrittenen Container-Netzwerkdiensten
• Containernetzwerksicherheit in fortschrittlichen Container-Netzwerkdiensten