Freigeben über

Übersicht über Containernetzwerkmetriken

Advanced Container Networking Services in Azure Kubernetes Service (AKS) erleichtert die Sammlung umfassender Containernetzwerkmetriken und bietet wertvolle Einblicke in die Leistung von containerisierten Umgebungen. Diese Funktion erfasst kontinuierlich wichtige Metriken auf Knoten- und Podebenen, einschließlich Datenverkehrsvolumen, verworfene Pakete, Verbindungszustände und DNS-Auflösungszeiten, wodurch eine effektive Überwachung und Optimierung der Netzwerkleistung ermöglicht wird.

Die Möglichkeit, diese Metriken zu erfassen, ist unerlässlich, um zu verstehen, wie Container kommunizieren, wie der Datenverkehr zwischen Diensten fließt und wo Engpässe oder Unterbrechungen auftreten können. Advanced Container Networking Services lässt sich nahtlos in Überwachungstools wie Prometheus und Grafana integrieren und bietet Benutzern eine vollständige Übersicht über Netzwerkmetriken, die für ausführliche Problembehandlung, Netzwerkoptimierung und Leistungsoptimierung verwendet werden können.

In der heutigen Cloud-nativen Welt ist die Aufrechterhaltung eines gesunden und effizienten Netzwerks in einer dynamischen containerisierten Umgebung von entscheidender Bedeutung, um sicherzustellen, dass Anwendungen wie erwartet funktionieren. Ohne eine ordnungsgemäße Sichtbarkeit des Netzwerkdatenverkehrs und seiner Muster wird die Identifizierung potenzieller Probleme oder Ineffizienzen herausfordernd.

Hauptvorteile

  • Tiefe Einblicke in die Netzwerkleistung
  • Verbesserte Problembehandlung und Optimierung
  • Proaktive Anomalieerkennung
  • Bessere Ressourcenverwaltung und Skalierung
  • Kapazitätsplanung und Compliance
  • Vereinfachte Speicher- und Visualisierungsoptionen für Metriken: * Azure Managed Prometheus und Grafana: Azure verwaltet die Infrastruktur und Wartung, sodass benutzer sich auf die Konfiguration von Metriken und die Visualisierung von Metriken konzentrieren können.* Bring Your Own (BYO) Prometheus und Grafana: Benutzer stellen ihre eigenen Instanzen bereit und konfigurieren sie und verwalten die zugrunde liegende Infrastruktur.

Erfasste Metriktypen

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 usw. nach Knoten. Die Metriken werden im Prometheus-Format gespeichert und können daher in Grafana angezeigt werden. Die folgenden Metriken werden pro Knoten aggregiert. Alle Metriken enthalten 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 BESCHREIBUNG Zusätzliche Bezeichnungen Linux Fenster
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 umfassen Quell- und Ziel-Pod-Informationen, mit denen Sie netzwerkbezogene Probleme auf granularer Ebene anheften können. Metriken decken das Datenverkehrsvolumen, verworfene Pakete, TCP-Resets, L4/L7-Paketflüsse usw. ab. Es gibt auch DNS-Metriken (derzeit nur für Nicht-Cilium-Datenebenen), die DNS-Fehler und fehlende Antworten auf DNS-Anfragen abdecken. Die folgenden Metriken werden pro Pod aggregiert (Knoteninformationen bleiben erhalten). Alle Metriken enthalten Bezeichnungen:

  • cluster
  • instance (Knotenname)
  • source oder destination

Für ausgehenden Datenverkehr gibt es eine source-Bezeichnung mit dem Namespace/Namen des Quellpods. Für eingehenden Datenverkehr gibt es eine destination-Bezeichnung mit dem Namespace/Namen des Zielpods.

Metrikname BESCHREIBUNG Zusätzliche Bezeichnungen Linux Fenster
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 Verarbeitete Netzwerkdatenflüsse insgesamt (L4/L7-Datenverkehr) source oder destination, protocol, verdict, type, subtype ✅ ❌

Einschränkungen

  • 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 Cilium-Netzwerkrichtlinien (Cilium Network Policy, CNP) auf ihren Clustern konfiguriert haben.
  • 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.

Maßstab

Für von Azure verwaltete Prometheus- und Grafana-Instanzen gelten dienstspezifische Skalierungseinschränkungen. Weitere Informationen finden Sie unter Scrape Prometheus-Metriken im großen Stil in Azure Monitor.

Preisgestaltung

Von Bedeutung

Die erweiterten Container-Netzwerkdienste werden in Zukunft ein kostenpflichtiges Angebot sein. Weitere Informationen zu den Preisen finden Sie unter Erweiterte Container-Netzwerkdienste – Preise.

Nächste Schritte