Freigeben über

Was ist Containernetzwerkmetriken?

Advanced Container Networking Services in Azure Kubernetes Service (AKS) erleichtert die Sammlung umfassender Containernetzwerkmetriken, um Ihnen wertvolle Einblicke in die Leistung Ihrer containerisierten Umgebung zu geben. Die Funktion erfasst kontinuierlich wichtige Metriken auf Knotenebene und Pod-Ebene, einschließlich Datenverkehrsvolumen, verworfene Pakete, Verbindungszustände und DNS-Auflösungszeiten (Domain Name System) zur effektiven Überwachung und Optimierung der Netzwerkleistung.

Die Erfassung dieser Metriken ist unerlässlich, um zu verstehen, wie Container kommunizieren, wie Datenverkehr zwischen Diensten fließt und wo Engpässe oder Unterbrechungen auftreten können. Advanced Container Networking Services integriert sich nahtlos in Überwachungstools wie Prometheus und Grafana, um Ihnen eine vollständige Übersicht über Netzwerkmetriken zu bieten. Verwenden Sie die Metriken für ausführliche Problembehandlung, Netzwerkoptimierung und Leistungsoptimierung.

In einer cloudeigenen Welt ist die Aufrechterhaltung eines gesunden und effizienten Netzwerks in einer dynamischen containerisierten Umgebung von entscheidender Bedeutung, um sicherzustellen, dass Anwendungen erwartungsgemäß ausgeführt werden. Ohne eine ordnungsgemäße Sichtbarkeit des Netzwerkdatenverkehrs und seiner Muster wird die Identifizierung potenzieller Probleme oder Ineffizienzen herausfordernd.

Important

Ab dem 30. November 2025 unterstützt Azure Kubernetes Service (AKS) keine Sicherheitsupdates für Azure Linux 2.0 mehr oder stellt diese bereit. Das Azure Linux 2.0-Knotenimage ist eingefroren bei der Version 202512.06.0. Ab dem 31. März 2026 werden Knotenimages entfernt, und Sie können Ihre Knotenpools nicht skalieren. Migrieren Sie zu einer unterstützten Azure Linux-Version, indem Sie Ihre Knotenpools auf eine unterstützte Kubernetes-Version aktualisieren oder zu osSku AzureLinux3 migrieren. Weitere Informationen finden Sie unter [Stilllegung] von Azure Linux 2.0-Knotenpools in AKS.

Hauptvorteile

  • Tiefe Einblicke in die Netzwerkleistung

  • Verbesserte Problembehandlung und Optimierung

  • Proaktive Anomalieerkennung

  • Bessere Ressourcenverwaltung und Skalierung

  • Kapazitätsplanung und Compliance

  • Filterung von Metriken auf Quellebene für Kostenoptimierung und Rauschreduzierung mit Filterung von Containernetzwerkmetriken

  • Vereinfachte Speicher- und Visualisierungsoptionen für Metriken. Wählen Sie zwischen:

    • Azure managed service for Prometheus and Azure Managed Grafana: Azure verwaltet die Infrastruktur und Wartung, sodass Sie sich auf die Konfiguration von Metriken und die Visualisierung von Metriken konzentrieren können.
    • Verwenden Sie Ihre eigenen (BYO) Instanzen von Prometheus und Grafana: Sie stellen Ihre eigenen Instanzen von Prometheus und Grafana bereit und konfigurieren diese und verwalten die zugrunde liegende Infrastruktur.

Erfasste Metriken

Metriken auf Knotenebene

Das Verständnis der Integrität Ihres Containernetzwerks auf Knotenebene ist entscheidend für die Aufrechterhaltung der optimalen Anwendungsleistung. Diese Metriken bieten Einblicke in das Datenverkehrsvolumen, verworfene Pakete, die Anzahl der Verbindungen und andere Daten nach Knoten. Die Metriken werden im Prometheus-Format gespeichert, sodass Sie sie in Grafana anzeigen können.

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

  • cluster
  • instance (Knotenname)

Für Cilium-Datenebenenszenarien stellt Container Network Observability nur Metriken für Linux bereit. Windows wird derzeit nicht unterstützt. Cilium stellt mehrere Metriken zur Verfügung, darunter die folgenden, die von Container Network Observability verwendet werden.

Metrikname Description Zusätzliche Etiketten Linux Windows
cilium_forward_count_total Gesamtzahl der weitergeleiteten Pakete direction ✅ ❌
cilium_forward_bytes_total Gesamtanzahl weitergeleiteter Byte direction ✅ ❌
cilium_drop_count_total Gesamtzahl der gelöschten Pakete direction, reason ✅ ❌
cilium_drop_bytes_total Gesamtanzahl der gelöschten Byte direction, reason ✅ ❌

Metriken auf Podebene (Hubble-Metriken)

Diese Prometheus-Metriken enthalten Quell- und Ziel-Pod-Informationen, sodass Sie netzwerkbezogene Probleme auf granularer Ebene anheften können. Metriken decken Informationen wie Datenverkehrsvolumen, verworfene Pakete, TCP-Zurücksetzungen und Layer 4/Layer 7-Paketflüsse ab. DNS-Metriken wie DNS-Fehler und FEHLENDE ANTWORTEN von DNS-Anforderungen werden standardmäßig für Nicht-Cilium-Datenebenen erfasst. Für Cilium-Datenebenen ist eine Cilium-FQDN-Netzwerkrichtlinie erforderlich, um DNS-Metriken zu sammeln, oder Kunden können auch Probleme mit DNS mithilfe von Hubble CLI beheben und Echtzeitprotokolle beobachten.

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 wird eine source Bezeichnung, die den Quell-Pod-Namespace und den Namen angibt, angewendet.

    • Bei eingehendem Datenverkehr wird eine destination Bezeichnung, die den Ziel-Pod-Namespace und den Namen angibt, angewendet.

Metrikname Description Zusätzliche Bezeichnungen Linux Windows
hubble_dns_queries_total Gesamtanzahl der DNS-Anforderungen nach Abfrage source oder destination, query, qtypes (Abfragetyp) ✅ ❌
hubble_dns_responses_total Gesamtanzahl der DNS-Antworten nach Abfrage/Antwort source oder destination, query, qtypes (Abfragetyp), rcode (Rückgabecode), ips_returned (Anzahl der IPs) ✅ ❌
hubble_drop_total Gesamtzahl der gelöschten Pakete source oder destination, protocol, reason ✅ ❌
hubble_tcp_flags_total Gesamtzahl der TCP-Pakete nach Flag source oder destination, flag ✅ ❌
hubble_flows_processed_total Gesamte verarbeitete Netzwerkflüsse (Layer 4/Layer 7-Datenverkehr) source oder destination, protocol, verdict, type, subtype ✅ ❌

Filterung von Containernetzwerkmetriken (Vorschau)

Da Sie nun die Möglichkeit haben, umfassende Metriken auf Knoten- und Podebene zu sammeln, können Sie sich mit einem erheblichen Datenvolumen befassen. Um Rauschen zu reduzieren und die Speicherkosten zu optimieren, führt die Containernetzwerkbeobachtbarkeit die Filterung von Containernetzwerkmetriken ein. Mit diesem Feature können Sie Metriken an der Quelle filtern, bevor sie gesammelt und gespeichert werden, sodass Sie steuern können, welche Metriken für Ihre spezifischen Überwachungs- und Problembehandlungsanforderungen am relevantesten sind. Dieses Feature ist nur für Cilium-Cluster verfügbar.

Die Filterung von Containernetzwerkmetriken ist besonders nützlich in großen Produktionsumgebungen, in denen sich das schiere Volumen von Metriken auf die Speicherkosten und die Abfrageleistung auswirken kann. Indem Sie unnötige Metriken frühzeitig im Sammlungsprozess herausfiltern, können Sie sich auf die Daten konzentrieren, die für Ihre Vorgänge am wichtigsten sind, und gleichzeitig die Sichtbarkeit beibehalten, die Sie für eine effektive Netzwerküberwachung benötigen.

Die Filterfunktion unterstützt mehrere Dimensionen, einschließlich namespacebasierter Filterung, um sich auf bestimmte Anwendungen, pod- und bezeichnungsbasierte Filterung für die gezielte Überwachung zu konzentrieren, und metrikspezifische Filterung, um nur die Metriktypen zu sammeln, die für Ihren Anwendungsfall unerlässlich sind. Diese Flexibilität ermöglicht es Ihnen, das richtige Gleichgewicht zwischen umfassender Observierbarkeit und kostengünstigem Betrieb zu finden.

Weitere Informationen zum Aktivieren der Filterung von Containernetzwerkmetriken finden Sie unter Konfigurieren der Filterung von Containernetzwerkmetriken .

Limitations

  • Metriken auf Podebene sind nur unter Linux verfügbar.
  • Die Cilium-Datenebene wird ab Kubernetes Version 1.29 unterstützt.
  • Metrikbeschriftungen weisen subtile Unterschiede zwischen Cilium- und Nicht-Cilium-Clustern auf.
  • Für Cilium-basierte Cluster sind DNS-Metriken nur für Pods verfügbar, die CNP (Cilium Network Policies) auf ihren Clustern konfiguriert haben, oder Kunden können auch Probleme mit DNS mithilfe von Hubble CLI beheben und Echtzeitprotokolle beobachten.
  • Ablaufprotokolle sind derzeit in der Cloud mit Air Gap nicht verfügbar.
  • Hubble-Relay kann abstürzen, wenn einer der Hubble-Knoten-Agents abstürzt, und es kann zu Unterbrechungen bei der Hubble-CLI kommen.
  • Bei Verwendung von Advanced Container Networking Services (ACNS) auf Nicht-Cilium-Datenebenen ist die FIPS-Unterstützung aufgrund von Kerneleinschränkungen auf Ubuntu 20.04-Knoten nicht verfügbar. Um FIPS in diesem Szenario zu aktivieren, müssen Sie einen Azure Linux-Knotenpool verwenden. Diese Einschränkung wird voraussichtlich mit der Veröffentlichung von Ubuntu 22 FIPS behoben. Informationen zu Updates finden Sie in der AKS-Problemverfolgung.
  • Die Filterung von Containernetzwerkmetriken ist nur für Cilium-Cluster verfügbar.

Weitere Informationen finden Sie in der FIPS-Unterstützungsmatrix unten:

Betriebssystem FIPS-Unterstützung
Azure Linux 3.0 Yes
Azure Linux 2.0 Yes
Ubuntu 20.04 No

Diese Einschränkung gilt nicht, wenn ACNS auf Cilium-Datenebenen ausgeführt wird.

Scale

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

Important

Die erweiterten Container-Netzwerkdienste werden in Zukunft ein kostenpflichtiges Angebot sein.

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

Verwandte Inhalte

  • Last updated on