Was sind Containernetzwerkprotokolle?

Die Containernetzwerkprotokolle in Advanced Container Networking Services für Azure Kubernetes Service (AKS) geben Ihnen Einblicke in jeden Netzwerkfluss innerhalb Ihres Clusters. Metriken sagen Ihnen , was in Ihrem Netzwerk passiert (Bandbreitennutzung, Fehlerraten). Protokolle teilen Ihnen mit, warum: Wer eine Verbindung initiiert hat, welche Protokolle verwendet wurden und ob Datenverkehr zulässig oder blockiert wurde.

Diese Protokolle erfassen Metadaten für jeden Netzwerkfluss:

  • Quell- und Ziel-IP-Adressen, Podnamen und Dienstnamen
  • Namespaces, Ports und Protokolle
  • Verkehrsrichtung und Richtlinienentscheidungen

In diesem Kontext können Sie das Netzwerkverhalten mit bestimmten Workloads korrelieren, Konnektivität beheben, Sicherheitsrichtlinien überprüfen und forensische Analysen durchführen. Containernetzwerklogs decken den Datenverkehr auf Layer 3 (IP), Layer 4 (TCP/UDP) und Layer 7 (HTTP/gRPC/Kafka) ab.

Zum Verwalten des Datenvolumens und der Kosten unterstützen Containernetzwerkprotokolle die Flussprotokollaggregation, die ähnliche Flüsse in zusammengefasste Datensätze gruppiert, anstatt einen Datensatz pro Verbindungsereignis zu speichern. Sie behalten die betrieblichen Muster bei, die Sie benötigen, während Sie die Speicher- und Aufnahmekosten senken. Weitere Informationen finden Sie unter Datenflussprotokollaggregation.

Containernetzwerkprotokolle bieten zwei Modi:

  • Gespeicherte Protokolle – Kontinuierliche Sammlung mit benutzerdefinierten Filtern und Flussaggregation. Am besten geeignet für langfristige Überwachung und Analyse.
  • On-Demand-Protokolle – Echtzeiterfassung über die Hubble CLI und hubble UI. Am besten geeignet für ad-hoc-Problembehandlung.

Verwenden Sie gespeicherte Protokolle, wenn Sie dauerhafte Datensätze für Compliance, Trendanalyse oder automatisierte Warnungen benötigen. Verwenden Sie On-Demand-Protokolle, wenn Sie aktiv ein Verbindungs- oder Leistungsproblem debuggen und sofortige Einblicke in den Livedatenverkehr benötigen.

Gespeicherte Protokolle

Der Modus für gespeicherte Protokolle wird automatisch aktiviert, wenn advanced Container Networking Services auf einem Cluster aktiviert ist. Die Funktion ist vorhanden, aber es werden keine Protokolle generiert, bis Sie ACNS mitteilen, was erfasst werden soll.

Um mit dem Sammeln von Protokollen zu beginnen, definieren Sie ContainerNetworkLog benutzerdefinierte Ressourcen, die angeben, welcher Datenverkehr überwacht werden soll: auf Basis von Namespaces, Pods, Diensten, Protokollen oder Urteilen. Sobald eine CRD angewendet wurde, beginnt der Cilium-Agent mit dem Generieren von Datenströmen, die ihren Filtern entsprechen, und schreibt sie auf jeden Knoten. Die Sammlung bleibt aktiv, bis Sie die CRDs entfernen oder ACNS deaktivieren.

Da Sie genau steuern, welcher Datenverkehr über CRD-Filter protokolliert wird, können Sie sich auf die Flüsse konzentrieren, die wichtig sind, und das Sammeln unnötiger Daten vermeiden. In Kombination mit der Flussprotokollaggregation sorgt dieser Ansatz dafür, dass Die Speicherkosten vorhersagbar und analyseorientiert bleiben.

Funktionsweise des gespeicherten Protokollmodus

Advanced Container Networking Services verwendet die eBPF-Technologie mit Cilium, um Netzwerkflüsse auf jedem Knoten zu erfassen. Sobald ACNS aktiviert ist und eine ContainerNetworkLog benutzerdefinierte Ressource angewendet wird, sammelt der Cilium-Agent Datenverkehr, der dem Filter entspricht, und schreibt Protokolle im JSON-Format auf /var/log/acns/hubble/events.log jeden Host. Die Protokollgenerierung wird vollständig im Cluster ausgeführt und hängt nicht von Azure Monitor ab.

Für die Produktionsverwendung empfehlen wir, das Azure Monitor-Add-On zu aktivieren. Wenn aktiviert, sammeln die Container Insights-Agenten hostlokale Logs, setzen Drosselungsgrenzwerte und senden sie an einen Log Analytics-Arbeitsbereich, in dem Sie Langzeitaufbewahrung, KQL-Abfragen sowie die integrierten Dashboards des Azure Portals und von Grafana erhalten. Dies ist der am besten integrierte Weg, und den sollten die meisten Kunden wählen.

Wenn Ihr Team über eine vorhandene Observability-Pipeline verfügt, können Sie stattdessen die gleichen hostlokalen Protokolle an jeden openTelemetry-kompatiblen Sammel- oder Protokollierungsdienst weiterleiten – entweder neben Azure Monitor oder anstelle davon.

Diagramm, wie Containernetzwerkprotokolle funktionieren.

Weitere Informationen zur Drosselung und Container Insights finden Sie in der Container Insights-Dokumentation.

Verwenden von Container-Netzwerkprotokollen mit oder ohne Azure Monitor

Sie können die Containernetzwerkprotokolle auf zwei verschiedene Weisen abrufen. Die richtige Wahl hängt davon ab, ob Sie eine integrierte Azure native Erfahrung wünschen oder bereits über eine Observability-Pipeline verfügen, die Sie weiterhin verwenden möchten.

Pfad Was Sie bekommen Wann man sie auswählen sollte
Azure Monitor-Add-On (empfohlen) Container Insights sammelt host-lokale Protokolle in einem Log-Analytics-Arbeitsbereich. Sie erhalten langfristige Speicherung, KQL, die integrierten Azure Portal-Dashboards und verwaltete Grafana-Dashboards, die von Anfang an verfügbar sind. Sie möchten die integriertste, produktionsbereitste Erfahrung auf AKS mit minimalem Setup.
Gehostete lokale Dateien mit Ihrer eigenen Pipeline ACNS schreibt JSON-Protokolle auf jedem Knoten /var/log/acns/hubble/events.log. Sie leiten sie an jeden openTelemetry-kompatiblen Sammel- oder Protokollierungsdienst weiter – neben Azure Monitor oder anstelle davon. Sie verfügen bereits über eine zentrale Observability-Plattform und möchten, dass Netzwerkprotokolle dort landen.

Für die meisten Kunden empfehlen wir, Azure Monitor zu aktivieren. Es ist die schnellste Möglichkeit, Aufbewahrungs-, Abfrage- und Dashboardfunktionen zu erhalten, ohne Ihre eigene Pipeline zu erstellen.

Wichtige Funktionen des gespeicherten Protokollmodus

  • Anpassbare Filter. Definieren Sie ContainerNetworkLog benutzerdefinierte Ressourcen, um nach Namespace, Pod, Dienst, Port, Protokoll, Urteil oder Verkehrsrichtung zu filtern. Nur übereinstimmenden Datenverkehr wird protokolliert, sodass Sie präzise Kontrolle darüber erhalten, was gesammelt wird und was es kostet.

  • Flussprotokollaggregation. Ähnliche Abläufe werden automatisch alle 30 Sekunden in zusammengefasste Datensätze gruppiert, wodurch das Datenvolumen gekürzt wird, während Betriebssignale wie Dienstkommunikationsmuster, Fehlerraten und Sicherheitsbewertungen erhalten bleiben. In Kombination mit gezielten Filtern ermöglicht die Aggregation eine umfassende Sichtbarkeit, ohne übermäßige Aufnahmekosten zu verursachen. Weitere Informationen finden Sie unter Flussprotokollaggregation.

  • Protokollspeicheroptionen. ACNS schreibt immer Protokolle lokal auf jedem Knoten. Von dort aus können Sie auswählen, wie Sie sie nutzen:

    • Host-lokale Dateien (immer aktiviert): Protokolle werden auf Host-Knoten unter /var/log/acns/hubble. Dateien werden bei einer Größe von 50 MB automatisch rotiert, und ältere Protokolle werden überschrieben. Verwenden Sie dies direkt für die kurzfristige, Echtzeitüberwachung oder Weiterleitung der Dateien an einen beliebigen openTelemetry-kompatiblen Sammel- oder Protokollierungsdienst für die zusätzliche Protokollverwaltung.

    • Azure Monitor (empfohlen): Aktivieren Sie das Azure Monitor-Add-On zum Sammeln und Speichern von Protokollen in einem Log Analytics Arbeitsbereich. Sie erhalten sicheren, kompatiblen Speicher mit langfristiger Aufbewahrung, KQL-Abfragen, Anomalieerkennung, historischer Analyse und Warnung durch den verwalteten Dienst für Prometheus. Die Protokollgenerierung läuft weiterhin über den Cilium-Agent und den ContainerNetworkLog CRD; Azure Monitor fügt die Verbrauchsschicht oben hinzu.

      Die ContainerNetworkLogs Tabelle verwendet standardmäßig die Analyseebene . Sie können zur Stufe "Basic " wechseln, um niedrigere Aufnahme- und Aufbewahrungskosten zu erhalten und gleichzeitig eine ähnliche Beobachtbarkeit zu gewährleisten. Jede Ebene verfügt über ein dediziertes Azure Portaldashboard, das für seine Abfragefunktionen optimiert ist. Weitere Informationen zu Tabellenplänen finden Sie unter Log Analytics Tabellenpläne. Informationen zum Festlegen des Tabellenplans finden Sie unter "Festlegen des Tabellenplans".

  • Visualisierung im Azure-Portal. Abfragen und analysieren Sie Protokolle direkt in Log Analytics oder verwenden Sie die integrierten Azure Portal-Dashboards. Ein dediziertes Dashboard ist für jede Tabellenebene verfügbar, sodass Sie unabhängig davon, welche Ebene Sie auswählen, die gleiche Observability-Erfahrung erhalten. Weitere Informationen finden Sie unter Visualize-Protokolle im Azure Portal.

Visualisieren von Protokollen im Azure-Portal

Sie können Ablaufprotokolle im Azure Portal im Log Analytics Arbeitsbereich für Ihren Cluster visualisieren, abfragen und analysieren.

Screenshot von Containernetzwerkprotokollen in einem Log Analytics workspace.

Containernetzwerkprotokolle enthalten integrierte Azure Portaldashboards zum Visualisieren von Flussdaten. Für jede Log Analytics Tabellenebene steht ein separates Dashboard zur Verfügung:

Dashboard Pfad Tabellenebene
Ablaufprotokolle – Standardebene (ID: 23155) Azure>Insights>Containers>Networking>Flow Logs - Basic Tier Grundlegend
Ablaufprotokolle – Analyseebene (ID: 23156) Azure>Insights>Containers>Networking>Flow Logs - Analytics Tier Analytik (Standard)

Beide Dashboards zeigen, welche AKS-Workloads miteinander kommunizieren, einschließlich Netzwerkanfragen, -antworten, -verluste und -fehler. Verwenden Sie das Dashboard, das der für Ihre ContainerNetworkLogs Tabelle konfigurierten Tabellenebene entspricht.

Tip

Die ContainerNetworkLogs Tabelle ist standardmäßig auf der Analyseebene. Wenn Sie Kosten reduzieren möchten, können Sie zur Stufe "Einfach" wechseln und das entsprechende Dashboard "Basic Tier" verwenden, ohne die Beobachtbarkeitsabdeckung zu verlieren. Weitere Informationen finden Sie unter Log Analytics Tabellenpläne.

Die Azure Portaldashboards verfügen über die folgenden Hauptkomponenten:

  • Übersicht über die Netzwerkgesundheit. Im oberen Abschnitt werden Zusammenfassungsmetriken (Gesamtflussprotokolle, eindeutige Anforderungen, verworfene Anforderungen und weitergeleitete Anforderungen) angezeigt, damit Sie Anomalien schnell erkennen können. Statistiken werden nach Protokoll aufgeschlüsselt: verworfene DNS-Anfragen, HTTP 2xx-Antworten, Layer 4-Anforderungs- und Antwortraten und Drop-Zahlen. Ein Dienstabhängigkeitsdiagramm zeigt, welche Dienste miteinander kommunizieren, wodurch Engpässe und unerwartete Datenverkehrspfade leichter identifiziert werden können.

    Screenshot der Ablaufprotokollstatistiken und eines Dienstabhängigkeitsdiagramms.

  • Ablaufprotokolle und Fehlerprotokolle. Das Dashboard trennt Ablaufprotokolle von Fehlerprotokollen in unterschiedliche Ansichten, sodass Sie sich auf Fehler konzentrieren können, ohne den normalen Datenverkehr zu durchsuchen. Verwenden Sie die integrierten Filter, um Ergebnisse nach Protokoll, Namespace oder Bewertung einzugrenzen. Um z. B. DNS-Auflösungsfehler zu beheben, filtern Sie Fehlerprotokolle nach dem DNS-Protokoll.

    Screenshot der Ablaufprotokolle und Fehlerprotokolle.

    Jeder Protokolleintrag enthält Bezeichnungen, Zeitstempel und Quell-/Zieldetails, mit denen Sie bestimmte Ereignisse während einer Untersuchung anheften können.

    Screenshot der verfügbaren Filter in den Azure Portaldashboards.

  • Die wichtigsten Namespaces, Workloads und DNS-Fehler. In diesem Abschnitt werden die aktivsten Namespaces, Workloads mit dem höchsten Datenverkehr, die Portverwendung und die häufigsten DNS-Fehler angezeigt. Verwenden Sie sie, um zu ermitteln, welche Workloads den meisten Datenverkehr generieren, verworfene Anforderungen erkennen und die Protokollverteilung vergleichen (z. B. TCP im Vergleich zu UDP). Ungewöhnliche Muster, z. B. unerwartete Spitzen oder unbekannte Ziele, können auf Fehlkonfigurationen oder Sicherheitsbedenken hinweisen.

    Screenshot der wichtigsten Namespaces und Pod-Metriken.

Datenflussprotokollaggregation

Netzwerkflüsse nehmen schnell zu. Ein Cluster mit 200 Microservices kann alle 30 Sekunden Hunderte von Tausend Flussdatensätzen generieren. Das Speichern aller Rohdaten wird teuer.

Beispielsweise sprechen client-1 und client-2 beide mit einem server Pod über TCP. Über ein 30-Sekunden-Fenster sehen rohe Flussdatensätze auf dem Knoten wie folgt aus:

Source Quellport Destination Zielport Protokoll Flag
Client-1 12345 server 80 TCP SYN
server 80 Client-1 12345 TCP SYN-ACK
Client-1 12345 server 80 TCP ACK
Klient-1 12345 server 80 TCP PSH
server 80 Kunde-1 12345 TCP ACK
Kunde-2 23456 server 80 TCP SYN
server 80 Client-2 23456 TCP SYN-ACK
Client-2 23456 server 80 TCP ACK
Kunde-2 23456 server 80 TCP PSH
server 80 Client-2 23456 TCP ACK

Bei der Aggregation werden diese 10 Datensätze zu zwei:

Source Quellport Destination Zielport Protokoll Gesendete Flüsse Empfangene Flüsse
Klient-1 12345 server 80 TCP 4 6
Client-2 23456 server 80 TCP 4 6

Die Flussprotokollaggregation behandelt dies, indem ähnliche Flüsse in zusammengefasste Datensätze gruppiert werden. Während jedes 30-Sekunden-Fensters werden Datenströme, die dieselben Aggregationsschlüsselfelder aufweisen, in einem einzelnen Datensatz zusammengeführt, mit einer Zählung, wie viele Datenströme dieser repräsentiert.

Die folgenden Felder bilden den Aggregationsschlüssel:

Feld Description
verdict WEITERGELEITET, VERWORFEN oder FEHLER
is_reply Gibt an, ob es sich bei dem Fluss um eine Anforderung (false) oder eine Antwort (true) handelt.
drop_reason_desc Grund für das Verwerfen von Paketen
source.namespace Quell-Pod-Namespace
destination.namespace Ziel-Pod-Namespace
source.workloads Quell-Workload (Deployment, StatefulSet oder DaemonSet)
destination.workloads Zielarbeitslast (Deployment, StatefulSet oder DaemonSet)
source.identity Quellsicherheitsidentität (immer als Fallback vorhanden)
destination.identity Zielsicherheitsidentität (immer als Rückfallebene vorhanden)
l4.TCP.destination_port TCP-Zielport
l4.UDP.destination_port UDP-Zielport
l7.http.code HTTP-Antwortcode (200, 404, 500 usw.)
l7.dns.rcode DNS-Antwortcode (NOERROR, NXDOMAIN usw.)
IP.ipVersion IPv4 oder IPv6
IP.encrypted Gibt an, ob der Fluss verschlüsselt ist (WireGuard/IPsec)
source.cluster_name Quellclustername
destination.cluster_name Zielclustername

Flüsse, die in allen diesen Feldern innerhalb eines 30-Sekunden-Fensters übereinstimmen, werden in einem Datensatz zusammengeführt. Dadurch bleiben die benötigten Signale erhalten (welche Dienste kommunizieren, wie oft, welche Fehler auftreten, ob Datenverkehr zulässig oder blockiert wurde), während das Datenvolumen erheblich reduziert wird. Im Gegensatz zum Sampling, das zufällig Datenflüsse verwirft und seltene Sicherheitsereignisse übersehen kann, behält die Aggregation 100 % der Muster-Informationen bei.

Wichtige Punkte:

  • Aggregation ist standardmäßig aktiviert und konfiguriert. Dies reduziert die Protokollspeicher- und Erfassungskosten ohne manuelle Optimierung.
  • Sie steuern, welcher Datenverkehr durch includeFilters in der ContainerNetworkLog CRD erfasst wird.
  • Schmalere Filter (bestimmte Namespace- oder Dienstpaare) erzielen in der Regel eine bessere Komprimierung, da die erfassten Flüsse ähnlicher sind.
  • Aggregierte Protokolle ignorieren hohe Kardinalitäts- und pro-Fluss-Attribute (z. B. einzelne Zeitstempel, Pod-IPs, HTTP-URLs, DNS-Abfragenamen), um das Ingestionsvolumen und die Speicherkosten zu minimieren. Sie sind für die Erkennung von hochrangigen Problemen konzipiert. Verwenden Sie On-Demand-Protokolle für eine detaillierte Flow-Analyse und -Untersuchung.

Hinweis

Die tatsächliche Speicherreduzierung variiert je nach Filterkonfiguration, Workloadvielfalt und Datenverkehrsmustern.

On-Demand-Protokolle

Mithilfe von On-Demand-Protokollen können Sie Ablaufprotokolle in Echtzeit ohne vorherige Konfiguration oder beständigen Speicher erfassen und prüfen. Verwenden Sie On-Demand-Protokolle, wenn Sie aktiv ein Verbindungs- oder Leistungsproblem behandeln und sofortige Sichtbarkeit benötigen.

ACNS bietet zwei Tools für die On-Demand-Erfassung. Informationen zum Einrichten eines der Tools finden Sie im Modus "On-Demand-Protokolle konfigurieren".

Hubble CLI

Mit der Hubble CLI können Sie Flussprotokolle direkt von Ihrem Terminal aus abfragen, filtern und analysieren. Es ist besonders nützlich, wenn Sie während einer aktiven Debugsitzung fein abgestimmte Filter benötigen, z. B. den Datenverkehr nach Namespace, Pod-Bezeichnung oder Bewertung isolieren.

Screenshot der Hubble CLI.

Hubble-Benutzeroberfläche

Die Hubble-Benutzeroberfläche bietet eine grafische Ansicht der Dienst-zu-Dienst-Kommunikation. Es eignet sich gut, wenn Sie Datenverkehrspfade visuell nachverfolgen möchten, identifizieren, welche Dienste kommunizieren, und Anomalien erkennen, ohne CLI-Befehle zu schreiben.

Screenshot der Hubble-Benutzeroberfläche.

Wichtige Vorteile von On-Demand-Protokollen

  • Keine vorherige Konfiguration erforderlich. Beginnen Sie sofort mit der Erfassung von Flüssen, ohne benutzerdefinierte Ressourcen zu definieren oder Speicher einzurichten.
  • Echtzeitsichtbarkeit. Überprüfen Sie den Livedatenverkehr, und zeigen Sie Paketmetadaten an, wenn Probleme auftreten.
  • Schnelle Problembehandlung. Filtern sie interaktiv über die Hubble CLI oder zeigen Sie Dienstzuordnungen visuell auf der Hubble-Benutzeroberfläche an.
  • Geringer Aufwand. Kein dauerhafter Speicher erforderlich, sodass keine laufenden Kosten für Ad-hoc-Untersuchungen anfallen.

Empfehlungen für gespeicherte Protokolle

  1. Beginnen Sie mit breiten Filtern, und schränken Sie sie ein. Wenn Sie die Flow-Protokolle zum ersten Mal aktivieren, verwenden Sie breite Filter, um den Datenverkehr über die wichtigsten Namespaces hinweg zu erfassen. Führen Sie die Konfiguration einige Tage aus, und überprüfen Sie die gesammelten Daten in Log Analytics. Überprüfen Sie das Datenvolumen, die Kosten und ob die erfassten Datenströme dem entsprechen, was Sie tatsächlich benötigen. Ziehen Sie includeFilters fest, um sich auf hochwertigen Daten-Traffic zu konzentrieren und das Rauschen zu eliminieren.

  2. Verwenden Sie zuerst die vordefinierten Dashboards. Die integrierten Azure Portaldashboards decken häufige Anwendungsfälle wie Dienstkommunikationsmuster, Fehlerraten und DNS-Fehler ab. Beginnen Sie dort. Fügen Sie benutzerdefinierte Panels oder Log Analytics Abfragen nur hinzu, wenn Sie eine Sichtbarkeit benötigen, die die vordefinierten Dashboards nicht bereitstellen.

  3. Überprüfen Sie regelmäßig. Wenn Sich Workloads und Datenverkehrsmuster ändern, müssen Ihre Filter möglicherweise aktualisiert werden. Überprüfen Sie die Datenvolumen- und Flussabdeckung regelmäßig, um sicherzustellen, dass Sie immer noch den richtigen Datenverkehr zu angemessenen Kosten erfassen.

Einschränkungen

Datenebene und Featureanforderungen:

  • Der Modus für gespeicherte Protokolle funktioniert nur mit der Cilium-Datenebene.
  • Ablaufprotokolle der Ebene 7 werden nur erfasst, wenn die Unterstützung von Layer 7-Richtlinien aktiviert ist. Weitere Informationen finden Sie unter Konfigurieren einer Layer 7-Richtlinie.
  • DNS-Flüsse und Metriken werden nur erfasst, wenn eine vollqualifizierte Cilium Domain Name (FQDN)-Netzwerkrichtlinie angewendet wird. Weitere Informationen finden Sie unter Konfigurieren einer FQDN-Richtlinie.

Aggregationskompromisse:

  • Die Flussprotokollaggregation behält keine einzelnen Flusszeitstempel, IP-Adressen pro Pod oder Felder mit hoher Kardinalität wie HTTP-URLs und DNS-Abfragenamen bei. Verwenden Sie protokolle auf Anfrage für die Untersuchung pro Datenfluss.

Speicher und Plattform:

  • Die host-lokale Datei bei /var/log/acns/hubble/ ist auf 50 MB pro Knoten begrenzt und wird automatisch rotiert. Wenn Sie eine langfristige Aufbewahrung benötigen, aktivieren Sie Azure Monitor (empfohlen) oder leiten Sie die Datei an Ihren eigenen Protokollierungsdienst weiter.
  • Der Tabellenplan für Hilfsprotokolle wird nicht unterstützt.

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.