Multi-Hop-Observability: Spans mit Network-Signalen verknüpfen

Multi-Hop-Observability: Spans mit Network-Signalen verknüpfen ist der Unterschied zwischen „wir sehen, dass es langsam ist“ und „wir wissen, warum es langsam ist“. In verteilten Systemen bestehen Requests selten aus einem einzigen Hop. Stattdessen wandern sie durch Ingress, Service Mesh Sidecars, Gateways, mehrere Microservices, Datenbanken und manchmal über Cluster- oder Regionsgrenzen. Tracing zeigt dabei die zeitliche Abfolge in Form von Spans – aber ohne Netzwerksignale bleibt oft unklar, ob die Zeit in der Applikation verbrannt wird oder im Transportpfad verloren geht (Retransmits, Queueing, DNS, MTU/Fragmentierung, Conntrack, TLS-Handshakes, HTTP/2-Flow-Control). Genau hier setzt Multi-Hop-Observability an: Sie verknüpfen die semantischen Spans eines Traces mit messbaren Network-Signalen pro Hop. Das Ergebnis ist eine konsistente Sicht auf Latenz, Fehler und Durchsatz entlang des tatsächlichen Datenpfads – inklusive Proxy- und Underlay-Anteilen. Dieser Artikel zeigt praxisnah, welche Signale Sie benötigen, wie Sie die Korrelation sauber aufbauen und welche typischen Stolpersteine Sie vermeiden sollten, damit Debugging im Incident nicht in Vermutungen endet.

Warum reine Spans oft nicht ausreichen

Distributed Tracing beantwortet hervorragend die Frage „Welche Komponenten waren beteiligt und wie lange hat jede Komponente gebraucht?“. Häufig scheitert es aber an der nächsten Frage: „Warum hat eine Komponente so lange gebraucht?“. Ein Span, der 500 ms dauert, kann drei völlig unterschiedliche Ursachen haben:

• Applikationszeit: CPU, Locks, Garbage Collection, Threadpool-Queueing, langsame Abhängigkeiten.
• Proxy-/Middlewarezeit: mTLS-Handshake, Connection Pool Warteschlange, Circuit Breaking, Retries.
• Netzwerkzeit: DNS-Delay, Paketverlust, Retransmissions, Queueing am Node oder Top-of-Rack, MTU-Probleme.

Ohne Netzwerksignale bleibt der Span „monolithisch“. Multi-Hop-Observability zerlegt diese Zeit in messbare Anteile und macht sichtbar, wo der Hop tatsächlich „hängt“.

Begriffe: Hop, Span, Signal und Korrelation

Damit das Thema greifbar bleibt, ist ein gemeinsames Begriffsverständnis hilfreich.

• Hop: Ein konkreter Transportabschnitt zwischen zwei Punkten, z. B. Client-Sidecar → Server-Sidecar, Gateway → Service, Node → Node.
• Span: Eine Zeitspanne im Trace, die eine Operation beschreibt (Client-Span, Server-Span, Proxy-Span).
• Network-Signale: Messwerte aus OSI-Layern 3/4/7, z. B. RTT, Retransmits, Drops, Conntrack-Events, TCP-Resets, TLS-Handshakes, HTTP/2-Stream-Resets.
• Korrelation: Das Zuordnen eines Netzwerksignals zu einem konkreten Span oder Hop über gemeinsame Schlüssel (Zeitfenster, 5-Tuple, Trace-ID, Pod/Node-Identität).

Die zentrale Herausforderung ist nicht das Sammeln von Daten, sondern die eindeutige, reproduzierbare Zuordnung: Welche Netzwerksymptome gehören zu welchem Request und zu welchem Hop?

Die minimalen Bausteine für Multi-Hop-Observability

In der Praxis funktioniert Multi-Hop-Observability am besten, wenn Sie drei Datenquellen bewusst kombinieren. Jede Quelle beantwortet eine andere Klasse von Fragen.

• Traces: End-to-end Sicht pro Request (Trace/Span), idealerweise mit Proxy-Spans oder zumindest Client/Server-Spans.
• Proxy-Telemetrie: L7- und L4-nahe Sicht (Upstream/Downstream-Routen, Resets, Timeouts, Connection Pools, TLS).
• Node-/Kernel-Signale: Drops, Retransmits, Conntrack, Queueing, IRQ/CPU-Saturation, eBPF-Flow-Events.

Als Standard für Tracing ist OpenTelemetry eine solide Basis, weil es Trace-Kontext, Attribute und Exporter einheitlich macht: OpenTelemetry Dokumentation. Für die Propagation im HTTP-Kontext ist W3C Trace Context die gängige Referenz: W3C Trace Context.

Span-Design: Welche Spans Sie wirklich brauchen

Viele Tracing-Setups erfassen nur „App-Client“ und „App-Server“. Für Netzwerk-Korrelation ist das oft zu grob. Sie profitieren deutlich, wenn Sie zusätzliche Spans oder zumindest zusätzliche Attribute anlegen, die den Transportpfad abbilden.

• Client-Span: Start beim Aufruf, Ende nach Response. Wichtig: Zielhost, Port, Protokoll, Peer-Service.
• Server-Span: Empfang der Anfrage bis Response-Write. Wichtig: lokale Service-Identität, Statuscode.
• Proxy-Span (optional, aber sehr wertvoll): Downstream → Upstream, getrennt nach „request headers received“, „upstream connected“, „first byte“, „response complete“.

Wenn Sie in einem Service Mesh mit Envoy arbeiten, können Sie häufig Proxy-Metriken und -Logs nutzen, um Latenzphasen zu unterscheiden (z. B. Connect Time vs. Request Time). Ein guter Einstieg für Envoy-Statistiken ist: Envoy Stats Overview.

Die Zuordnungsschlüssel: Wie Sie Netzwerk und Spans zusammenbringen

Es gibt vier praxistaugliche Korrelationstechniken. Welche Sie wählen, hängt davon ab, wie tief Sie in den Datenpfad integrieren können.

Trace-ID als „Join Key“ über Logs und Proxy-Daten

Wenn Gateways/Sidecars Trace-Header (z. B. traceparent) in Access Logs schreiben, können Sie Netzwerksignale indirekt über Proxy-Logs korrelieren. Voraussetzung ist, dass Logs genug Kontext enthalten (Pod/Node, Upstream, Downstream, Timing).

• Vorteil: Sehr präzise pro Request, gut für Incident-Forensik.
• Nachteil: Log-Volumen, Sampling-Strategien, mögliche Lücken bei TLS-Passthrough.

5-Tuple (src/dst IP, src/dst Port, Protocol) plus Zeitfenster

Netzwerksignale auf Kernel-Ebene sind oft flow-basiert. Wenn Sie den Flow (5-Tuple) aus dem Span ableiten oder ergänzen können, ist eine Zuordnung über Zeitfenster möglich. Das ist besonders wirksam für TCP-Retransmits, Drops, Resets.

• Vorteil: Funktioniert auch ohne vollständige Trace-ID-Durchleitung in jedem Hop.
• Nachteil: NAT, Sidecars und Connection Reuse können 5-tuple-Zuordnung erschweren.

Pod/Node-Identität und Hop-Mapping

Wenn Sie den Hop als „Proxy A auf Node X → Proxy B auf Node Y“ modellieren, können Sie node-spezifische Signale (IRQ/CPU-Saturation, Drops auf bestimmten Interfaces) an den betroffenen Hop heften. Das ist weniger request-genau, aber sehr effektiv für systemische Probleme.

• Vorteil: Perfekt für Muster wie „nur bestimmte Nodes droppen“.
• Nachteil: Weniger geeignet für einzelne, isolierte Requests.

eBPF-Events als Brücke zwischen L7 und L4

eBPF-basierte Observability kann Flows und teilweise auch L7-Informationen erfassen, ohne überall zu instrumentieren. In Kubernetes ist Cilium/Hubble ein verbreitetes Beispiel für Flow-Observability: Cilium Hubble Observability. Die Idee: Sie erhalten Flow-Events mit Pod-Metadaten und können diese Events mit Spans zeitlich und über Service-Identitäten korrelieren.

Welche Network-Signale pro Hop am meisten bringen

Für Multi-Hop-Observability ist nicht „alles sammeln“ sinnvoll, sondern ein Fokus auf Signale, die Ursachen schnell eingrenzen. Die folgende Liste ist ein praxistauglicher Startpunkt.

• Latenz/RTT: RTT-Schätzungen, Handshake-Dauer, Connect-Time (insbesondere bei kurzlebigen Verbindungen).
• Retransmissions: TCP Retransmits, Dup ACKs, Out-of-Order – starke Indikatoren für Paketverlust oder Überlast.
• Drops: Interface-Drops, qdisc-Drops, conntrack-Drops, RX/TX-Errors.
• Resets/Timeouts: TCP RST, SYN-Retries, Connect-Failures, Idle-Timeouts am Proxy oder Load Balancer.
• DNS: Query-Latenz, NXDOMAIN-Rate, Timeouts, Cache Hit/Miss (CoreDNS/Stub Resolver).
• Conntrack: conntrack_full, insert_failed, state table pressure – oft Ursache für „random“ Drops und Resets.
• MTU/Fragmentierung: ICMP „Fragmentation Needed“, PMTUD-Probleme, „small works, large fails“.

Wichtig ist, diese Signale nicht isoliert zu betrachten, sondern entlang eines konkreten Hops. Ein Retransmit ist erst aussagekräftig, wenn Sie wissen, welcher Hop ihn produziert.

Latenz zerlegen: Von einem Span zu messbaren Teilzeiten

Ein effektives Modell ist die Zerlegung der End-to-end Zeit eines Hop-Transfers in Komponenten. Das ist keine perfekte Physik, aber ein praktisches Debugging-Werkzeug.

$T=\mathrm{T\_dns}+\mathrm{T\_connect}+\mathrm{T\_tls}+\mathrm{T\_request}+\mathrm{T\_server}+\mathrm{T\_response}+\mathrm{T\_retrans}$

Wenn Sie in Ihren Spans und Signalen zumindest eine Teilmenge dieser Größen messen können, gewinnen Sie eine klare Richtung. Beispielsweise: Steigt T_connect an, ist die Ursache häufig in Connection Pools, SYN-Retries, NAT/Firewall oder DNS. Steigt T_retrans, ist Paketverlust oder Queueing wahrscheinlicher.

Praktischer Aufbau: Schrittweise Korrelation in einer Mesh-Umgebung

Ein stabiler Implementierungsweg ist, Multi-Hop-Observability iterativ aufzubauen. Der Versuch, alles auf einmal zu instrumentieren, führt oft zu Datenchaos.

• Schritt 1: Trace Context überall sicher propagieren (Ingress/Gateway, Mesh, Services). Grundlage ist konsistente Header-Weitergabe nach W3C Trace Context.
• Schritt 2: Proxy-Metriken pro Hop etablieren (Upstream/Downstream, Connect, TLS, Resets). In Envoy-Setups sollten Sie Resets, Timeouts und Connection Pool Metriken priorisieren.
• Schritt 3: Node-Signale pro Node/Interface aufzeichnen (Drops, Retransmits, conntrack). Diese Signale sind besonders wertvoll, wenn nur bestimmte Nodes betroffen sind.
• Schritt 4: Eine Korrelationsebene definieren (Trace-ID über Logs oder Flow-Korrelation über 5-tuple) und die Daten in einer Abfrage zusammenführen.
• Schritt 5: Dashboards und Incident-Views bauen, die pro Trace „Hop-Layer“ zeigen: App-Span + Proxy-Signale + Kernel-Signale.

Typische Failure Modes und wie Korrelation die Diagnose verkürzt

Multi-Hop-Observability ist besonders wertvoll bei Fehlerbildern, die ohne Netzwerksignale leicht in die falsche Richtung führen.

P99 steigt, aber CPU ist normal

• Ohne Korrelation: Verdacht auf Applikationsproblem, Profiling startet, aber findet nichts.
• Mit Korrelation: Retransmissions und Drops steigen auf bestimmten Nodes; Proxy-Spans zeigen erhöhte Connect-Time; Ursache liegt im Underlay oder Node-Queueing.

Intermittierende gRPC UNAVAILABLE

• Ohne Korrelation: Verdacht auf Server-Bug oder falsches Retry-Verhalten.
• Mit Korrelation: Proxy zeigt Stream-Resets und Idle-Timeouts; Network-Signal zeigt NAT/conntrack pressure oder LB-Idle-Timeout; Maßnahmen fokussieren auf Timeouts und Connection Reuse.

„Small works, large fails“

• Ohne Korrelation: Verdacht auf Applikations-Limits oder Payload-Parsing.
• Mit Korrelation: MTU/PMTUD-Signale (Fragmentation Needed) und Drops bei großen Paketen; Fix liegt in MTU-Alignment und Tunnel-Overhead.

Welche Attribute und Tags Sie in Spans ergänzen sollten

Damit die Verknüpfung in Abfragen zuverlässig funktioniert, brauchen Spans mehr Kontext als nur „operation.name“ und „duration“. Sinnvolle Attribute sind:

• Netzwerk-Basis: peer.service, net.peer.name, net.peer.port, net.transport, http.flavor bzw. rpc.system.
• Hop-Identität: k8s.namespace.name, k8s.pod.name, k8s.node.name (sowohl clientseitig als auch serverseitig, wenn möglich).
• Proxy-Kontext: upstream_cluster, downstream_protocol, tls.version, tls.sni (wenn terminierend).
• Routing-Kontext: route, virtual_service, gateway, zone/region (für Multi-Cluster und Failure Domains).

OpenTelemetry stellt Konventionen für Attribute bereit, damit Auswertungen konsistent bleiben: OpenTelemetry Semantic Conventions.

Sampling, Cardinality und Kosten: Wie Sie nicht an Ihrer eigenen Telemetrie scheitern

Multi-Hop-Observability kann teuer werden, wenn Sie jede Anfrage vollständig mit Logs, Spans und Flow-Events erfassen. Ein praxistaugliches Modell kombiniert Sampling und „On-Demand“-Detailtiefe.

• Trace Sampling: Konservatives Basissampling plus dynamisches Upsampling bei Fehlern oder hoher Latenz.
• Log Sampling: Access Logs nur für ausgewählte Routen oder bei Anomalien; ansonsten Metriken bevorzugen.
• Flow-Events: eBPF/Flow-Daten aggregieren oder nur für betroffene Nodes/Namespaces aktivieren.
• Cardinality-Management: Keine unkontrollierten Labels (z. B. vollständige URLs, User-IDs) in Metriken; bei Bedarf in Traces/Logs halten.

Für Metriken ist Prometheus ein verbreiteter Standard; wichtig ist dabei das Verständnis für Label-Cardinality und Aggregation: Prometheus Overview.

Query- und Dashboard-Design: So wird Korrelation im Incident nutzbar

Der größte Mehrwert entsteht, wenn SREs im Incident nicht „zwischen Tools springen“ müssen. Gute Incident-Views kombinieren:

• Trace-Ansicht: Top N langsamste Traces, mit Hop-Aufschlüsselung.
• Hop-Panel: Pro Hop: Proxy-Resets, Connect-Time, TLS-Handshakes, Retry-Rate.
• Node-Panel: Drops, Retransmits, conntrack pressure, CPU/IRQ, Interface-Queueing – gefiltert auf die Nodes der betroffenen Pods.
• DNS-Panel: CoreDNS-Latenz, Fehlerquote, Cache-Metriken; Korrelation zu Trace-Spans mit DNS-Anteilen.

Praktisch ist außerdem eine „Diff“-Sicht: betroffener Hop vs. gesunder Hop im gleichen Zeitraum. So sehen Sie schneller, ob ein Problem systemisch (Underlay) oder service-spezifisch (App/Proxy) ist.

Multi-Cluster und Multi-Region: Korrelation über Failure Domains hinweg

Sobald Requests Regionen oder Cluster überqueren, steigt die Komplexität. Hier sind zwei Maßnahmen besonders wirksam:

• Failure-Domain-Tags: Zone/Region/Cluster als Span-Attribute und als Metrik-Dimension (kontrolliert) führen.
• Hop-Klassifikation: Hops in Kategorien einteilen (Intra-Node, Intra-Cluster, Inter-Cluster, Inter-Region), damit Sie Erwartungen an RTT und Verlustprofile sauber ableiten können.

Viele Teams profitieren davon, Inter-Cluster-Traffic über definierte Gateways zu führen, weil sich damit Observability und Security konsistenter abbilden lassen. In Kubernetes kann die Gateway API als Boundary-Konzept dienen: Kubernetes Gateway API.

Checkliste: Umsetzung in der Praxis ohne Overengineering

• Trace Context überall konsistent propagieren (Ingress, Mesh, Services).
• Spans mit minimalen Netzwerkattributen anreichern (peer.service, node/pod, protocol).
• Proxy-Metriken pro Hop erfassen (Resets, Timeouts, Connect, TLS, Retries).
• Node-Signale pro Node/Interface sammeln (Drops, Retransmits, conntrack pressure).
• Eine klare Korrelationstechnik wählen (Trace-ID über Logs oder Flow+Zeitfenster).
• Incident-Dashboards bauen, die pro Trace Hops und Netzwerksignale nebeneinander zeigen.
• Sampling- und Cardinality-Regeln festlegen, bevor Telemetrie skaliert.

Outbound-Quellen für vertiefende Informationen

• OpenTelemetry Dokumentation: Tracing- und Telemetrie-Bausteine
• OpenTelemetry Semantic Conventions: Attribute für konsistente Korrelation
• W3C Trace Context: Standard für Trace-Header und Propagation
• Envoy Stats Overview: Proxy-Signale für Hops, Resets und Timeouts
• Prometheus Overview: Metriken, Aggregation und Label-Strategien
• Cilium Hubble Observability: eBPF-Flow-Signale für Kubernetes
• Kubernetes Gateway API: Boundaries für Traffic und Observability

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.