Netzwerk-Monitoring, das Traffic mit Services verbindet

Was ist Netzwerk-Monitoring?

Netzwerk-Monitoring ist die kontinuierliche Messung von Verfügbarkeit, Performance und Traffic der Netzwerke, von denen Ihre Anwendungen abhängen. Früher bedeutete das vor allem, Router und Switches nach ihrem Interface-Status abzufragen. Heute gehören auch Cloud-VPCs, Kubernetes-Overlay-Netzwerke, Service Meshes, Load Balancer, DNS und das öffentliche Internet zwischen Ihren Nutzern und Ihren Services dazu.

Modernes Netzwerk-Monitoring kombiniert deshalb mehrere Datenquellen: Gerätemetriken, Flow-Daten, die beschreiben, wer mit wem kommuniziert, Verbindungsmetriken von Hosts und Containern sowie synthetische Tests, die Pfade von außen messen. Ziel ist nicht nur zu wissen, dass eine Leitung aktiv ist, sondern zu verstehen, wie sich das Netzwerkverhalten auf die darüber laufenden Services auswirkt.

Warum Netzwerk-Monitoring wichtig ist

Wird eine Anwendung langsam, steht das Netzwerk oft als Erstes unter Verdacht und lässt sich am schwersten entlasten. Paketverlust auf einem einzelnen Node, ein überlastetes NAT-Gateway, DNS-Timeouts oder eine fehlerhafte Network Policy sehen für Nutzer alle wie Anwendungslatenz aus. Ohne belastbare Daten verbringen Netzwerk- und Anwendungsteams die Zeit im Incident mit Diskussionen statt mit der Behebung.

Verteilte Architekturen verstärken das. Microservices machen aus Funktionsaufrufen Netzwerkaufrufe, und jeder zusätzliche Hop bringt Latenz und neue Fehlerquellen mit sich. Traffic zwischen Zonen und Regionen verursacht zudem bei allen großen Cloud-Anbietern echte Kosten. Netzwerk-Monitoring macht diese Abhängigkeiten, Risiken und Kosten sichtbar und schafft eine gemeinsame Faktenbasis für alle beteiligten Teams.

Auch die Sicherheit profitiert: Abgelehnte Flows und unerwartete ausgehende Verbindungen sind oft das erste Anzeichen für Fehlkonfigurationen oder Missbrauch.

Wichtige Netzwerk-Metriken

Metrik	Was sie aussagt
Latenz und Round-Trip-Time	Wie lange Pakete zwischen zwei Endpunkten brauchen; steigende RTT deutet auf Überlast oder geänderte Routen hin.
Paketverlust und Retransmits	Verlorene Pakete erzwingen TCP-Wiederholungen und erhöhen direkt die Request-Latenz.
Durchsatz und Bandbreitenauslastung	Ob Leitungen, Interfaces oder Gateways nahe an der Sättigung sind.
Verbindungsfehler und Resets	Abgelehnte oder zurückgesetzte Verbindungen weisen oft auf fehlerhafte Services, erschöpfte Ports oder Policy-Sperren hin.
DNS-Auflösungszeit und Fehler	Langsame oder fehlschlagende Lookups verzögern jeden abhängigen Request.
Abgelehnte Flows	Traffic, der von Security Groups, Firewalls oder Network Policies blockiert wird.

So funktioniert Netzwerk-Monitoring mit Obseria

Der Obseria Agent, einmal pro Host oder als DaemonSet in Kubernetes installiert, erfasst Verbindungsmetriken wie Round-Trip-Time, Retransmits und Resets für jeden Prozess und Container. Flow-Logs aus AWS, Azure und Google Cloud werden über Obseria Pipeline übernommen und angereichert, Netzwerkgeräte liefern Daten per SNMP oder Streaming-Telemetrie. Synthetische Checks von über 50 Standorten ergänzen die Außensicht auf DNS-, TLS- und HTTP-Performance.

Obseria TopoGraph ordnet all diese Daten Services und Workloads zu. Statt IP-Adressen zu entziffern, sehen Sie, dass der Checkout-Service in einer Availability Zone erhöhte Retransmits zur Payments-Datenbank hat. Obseria Intelligence korreliert Netzwerk-Anomalien mit Traces und Deployments, sodass eine Analyse mit Belegen klärt, ob die Ursache im Netzwerk liegt oder nicht.

Flow-Daten können sehr umfangreich sein. Obseria Pipeline aggregiert, samplet oder verwirft wenig relevante Flows bereits beim Ingest, und gefilterte Daten kosten nur die Ingestion. So zahlen Sie nur für die Netzwerkdaten, die Sie tatsächlich auswerten. Abgefragt wird alles mit OQL, alternativ mit PromQL oder SQL:

fetch flows
| filter action == "REJECT"
| summarize count(), by:{src.service, dst.port}

Best Practices für Netzwerk-Monitoring

1. Flows Services zuordnen. Traffic mit Service- und Teamnamen lässt sich weit leichter bewerten als rohe IP-Adressen.
2. Normalverhalten lernen. Latenz und Traffic schwanken über den Tag; nutzen Sie Anomalieerkennung statt starrer Schwellwerte.
3. DNS gezielt überwachen. DNS-Fehler sind eine häufige und unterschätzte Ursache für Ausfälle.
4. Innen- und Außensicht kombinieren. Ergänzen Sie interne Verbindungsmetriken um synthetische Checks aus den Regionen Ihrer Nutzer.
5. Zonenübergreifenden Traffic verfolgen. Er beeinflusst sowohl die Latenz als auch Ihre Cloud-Rechnung.
6. Änderungen mitprotokollieren. Erfassen Sie Änderungen an Routing, Firewall-Regeln und Network Policies als Events, damit Sie Störungen direkt einer Konfigurationsänderung zuordnen können.
7. Gemeinsame Sicht schaffen. Netzwerk-, Plattform- und Anwendungsteams sollten mit denselben Daten und Dashboards arbeiten. Das verkürzt die Abstimmung im Incident erheblich.