Mesh-Observability: Nützlichste Envoy-Metriken im Incident

Mesh-Observability: Nützlichste Envoy-Metriken im Incident ist in vielen Teams der Unterschied zwischen „wir raten“ und „wir wissen“. Wenn ein Service Mesh auf Envoy-Sidecars basiert, laufen im Incident die meisten Symptome zunächst durch den Proxy: Timeouts, 503er, Retries, Connection-Fehler, TLS-Probleme oder plötzlich steigende Tail Latency. Genau deshalb sind Envoy-Metriken so wertvoll: Sie geben Ihnen innerhalb von Sekunden einen Blick auf Upstream-Erreichbarkeit, Request-Queueing, Connection-Pools, Resets, Overload-Signale und DNS/TLS-Indikatoren – oft klarer als reine App-Logs. Entscheidend ist, im Incident nicht „alle Metriken“ zu betrachten, sondern die wenigen, die Ursachen eingrenzen: Ist es ein Netzwerk-/Connect-Problem, ein Upstream-Saturation-Problem, ein Timeout-Mismatch, ein DNS-Problem oder eine Nebenwirkung von Retries? Dieser Leitfaden zeigt die praktisch nützlichsten Envoy-Metriken, wie Sie sie interpretieren, wie Sie sie in einer Incident-Triage priorisieren und wie Sie daraus schnell Hypothesen, Next Steps und Containment-Maßnahmen ableiten – ohne sich in Metrik-Fluten zu verlieren.

Warum Envoy-Metriken im Incident oft schneller sind als App-Metriken

In Mesh-Topologien sind App-Metriken häufig „zu spät“ oder „zu grob“: Die Anwendung sieht nur den Effekt (Timeout, Fehler, Latenz), nicht aber die Ursache (Connect-Fail, TLS-Handshake, Pool-Exhaustion, Retry-Spikes). Envoy sitzt genau am Übergang und misst beides: Er beobachtet, was rein kommt (Downstream) und was er nach außen schafft (Upstream). Dadurch sind Envoy-Metriken besonders gut geeignet, um folgende Fragen im Incident schnell zu beantworten:

• Ist der Upstream überhaupt erreichbar? (Connect-Fehler, DNS, TLS, Resets)
• Ist es Last/Saturation? (Pending Requests, Pool-Limits, Queueing, Overload)
• Ist es ein Timeout-/Retry-Problem? (Retry-Zähler, Per-Try-Timeouts, Stream-Resets)
• Ist es ein lokales Node-/Sidecar-Problem? (CPU-Pressure, Overload, Listener-Backlog)

Für Terminologie und Metrik-Struktur ist die Referenz zu Envoy-Stats hilfreich: Envoy Statistics Overview.

Grundprinzip: Erst klassifizieren, dann detaillieren

Ein bewährtes Vorgehen ist ein kurzer Klassifizierungs-Loop. Sie starten mit wenigen „High-Signal“-Metriken und entscheiden, in welchen Pfad Sie tiefer gehen. Das verhindert, dass Sie 15 Dashboards öffnen und trotzdem unsicher bleiben.

• Fehlerklasse: Steigen 4xx/5xx, oder sind es primär Timeouts/Client-Abbrüche?
• Ort des Fehlers: Downstream (Client→Proxy) oder Upstream (Proxy→Service)?
• Art des Fehlers: Connect/TLS/DNS vs. Upstream-Reset vs. Timeout vs. Overload/Queueing?

Die „Top 12“ Envoy-Metriken, die Sie im Incident fast immer brauchen

Die folgenden Metriken sind in der Praxis besonders universell. Je nach Mesh-Distribution (z. B. Istio, Consul, Linkerd mit Envoy) können Namen/Labels leicht variieren, das Konzept bleibt jedoch identisch.

1) Upstream Request-Volumen und Erfolg: Basislinie für jede Diagnose

• cluster.upstream_rq_total – Wie viele Requests Envoy an einen Upstream-Cluster sendet.
• cluster.upstream_rq_2xx / upstream_rq_4xx / upstream_rq_5xx – Grobe Erfolg/Fehler-Verteilung.

Interpretation: Wenn upstream_rq_total stabil ist, aber upstream_rq_5xx hochgeht, ist der Upstream entweder instabil oder Envoy klassifiziert viele Fehler als Upstream-Failure. Wenn upstream_rq_total stark steigt, prüfen Sie Retries (siehe weiter unten), denn Retries erhöhen das Upstream-Volumen ohne Nutzermehrwert.

2) Timeouts und „abgebrochene“ Requests: Tail-Latency und Budget-Überschreitungen

• cluster.upstream_rq_timeout – Upstream-Request hat das Timeout erreicht.
• cluster.upstream_rq_cancelled – Request wurde abgebrochen (häufig durch Downstream-Disconnect oder Budget-Überschreitung).

Interpretation: Ein Spike in upstream_rq_timeout ist fast immer ein Signal für „Upstream antwortet zu langsam“ oder „Timeouts sind falsch abgestimmt“. Wenn upstream_rq_cancelled gleichzeitig steigt, deutet das häufig auf Clients hin, die abbrechen, bevor der Upstream fertig wird (z. B. UI/Ingress-Timeout kürzer als Service-Timeout).

3) Pending Requests: Der schnellste Hinweis auf Queueing/Saturation

• cluster.upstream_rq_pending_total (Counter) und/oder cluster.upstream_rq_pending_active (Gauge) – Requests warten, bevor sie gesendet werden.

Interpretation: Steigende Pending-Werte sind ein starkes Signal für Sättigung im Upstream-Cluster oder im Proxy (z. B. zu wenige Connections, zu kleine Pools, CPU-Engpässe). Im Incident ist das einer der zuverlässigsten Indikatoren, dass „es nicht nur ein einzelner Fehler“ ist, sondern systematisches Queueing entsteht.

4) Connection Pool und Auslastung: Wenn das Mesh „zu gut“ pooled

• cluster.upstream_cx_active – Aktive Upstream-Verbindungen.
• cluster.upstream_cx_total – Insgesamt aufgebaute Verbindungen.
• cluster.upstream_cx_connect_fail – Verbindungsaufbau fehlgeschlagen.

Interpretation: Wenn upstream_cx_connect_fail steigt, liegt die Ursache oft in Netzwerkpfaden, Security Policies, DNS oder TLS-Konfiguration. Wenn upstream_cx_active sehr niedrig bleibt, während Pending Requests steigen, kann das auf zu restriktive Pool-Limits oder auf Probleme beim Aufbau neuer Connections hindeuten.

5) Resets und Abbrüche: „Wer hat aufgelegt?“

• cluster.upstream_rq_rx_reset – Reset beim Empfang der Response (Upstream-Seite).
• cluster.upstream_rq_tx_reset – Reset beim Senden (Envoy-Seite).
• cluster.upstream_cx_destroy_remote und cluster.upstream_cx_destroy_local – Wer hat die Connection beendet.

Interpretation: Resets sind im Mesh hochdiagnostisch. Viele rx_reset deuten auf Upstream-Abbrüche (Crash, Connection-Kill, LB, Policy). Viele tx_reset können auf Envoy/Downstream-Abbrüche, Timeout-Policies oder Outlier/CB-Verhalten hindeuten. Die Richtung (local vs. remote destroy) hilft, den Ursprung einzugrenzen.

6) Health und Ejections: Wenn Outlier Detection „leise“ wirkt

• cluster.outlier_detection.ejections_total – Wie oft Hosts aus dem Load Balancing entfernt wurden.
• cluster.membership_total und cluster.membership_healthy – Gesamte vs. gesunde Endpoints.

Interpretation: Wenn Ejections stark steigen oder membership_healthy fällt, hat sich das System bereits selbst stabilisiert – möglicherweise auf Kosten von Kapazität. Dann folgen oft Pending Requests und Timeouts. Das ist ein klassischer „Ketteneffekt“-Pfad im Incident.

7) Retries: Verstärker oder Retter?

• cluster.upstream_rq_retry und cluster.upstream_rq_retry_success – Retry-Volumen und wie oft es geholfen hat.

Interpretation: Wenn Retries hochgehen, aber retry_success niedrig bleibt, verstärken Retries die Last ohne Nutzen. Das ist ein typischer Einstieg in Retry-Storms. Im Incident ist das ein starkes Argument für Containment (Retry-Budget senken, Retry auf kritischen Routen deaktivieren, Backoff erhöhen), aber nur kontrolliert und mit Blick auf User-Impact.

8) Latenz auf Proxy-Ebene: Wo entsteht die Zeit?

• cluster.upstream_rq_time (Histogram) – Zeit, die Envoy für Upstream-Requests beobachtet.
• http.downstream_rq_time (Histogram, je nach Setup) – End-to-End aus Sicht des Proxys.

Interpretation: Ein Auseinanderlaufen von Upstream-Zeit und Downstream-Zeit deutet auf zusätzliche Verzögerung im Proxy, an Gateways oder durch Warteschlangen hin. Das ist besonders wichtig, wenn App-Metriken „normale“ Zeiten zeigen, aber Nutzer trotzdem langsam sind.

9) HTTP/2 und gRPC-Symptome: Streams, nicht nur Requests

• cluster.upstream_cx_http2_total bzw. cluster.upstream_cx_http2_active – HTTP/2-Verbindungen.
• http2.streams_active oder ähnliche Stream-Gauges (abhängig vom Build) – parallele Streams.

Interpretation: Sehr viele aktive Streams auf wenigen Connections erhöhen das Risiko von Tail-Latency-Effekten bei Paketverlust, Flow-Control oder Backpressure. Gerade bei gRPC-Streaming ist das ein häufiger „Hidden Driver“ im Incident.

10) TLS/mTLS Indikatoren: Handshake-Probleme und Zertifikatsfehler

• cluster.ssl.handshake und cluster.ssl.handshake_error (Namensvarianten möglich) – Handshake-Erfolg/Fehler.
• listener.ssl.handshake – Downstream-TLS-Sicht.

Interpretation: TLS-Handshake-Fehler steigen typischerweise bei abgelaufenen Zertifikaten, falschen SANs, inkonsistenten Trust Bundles oder Cipher/Policy-Mismatches. In Mesh-Setups lohnt sich eine schnelle Abgrenzung: Tritt es nur zwischen bestimmten Workloads auf oder clusterweit? Für Kontext und Debug-Ansätze sind Mesh-spezifische Dokumentationen (z. B. Istio mTLS) sinnvoll: Istio Security Konzepte (mTLS).

11) DNS und Cluster Discovery: Wenn „Service nicht gefunden“ in Wahrheit DNS ist

• cluster.….update_attempt und cluster.….update_success (bei DNS-basierten Clustern) – Discovery/Updates.
• dns_query-Metriken (je nach Integration) – DNS-Lookups und Fehler.

Interpretation: DNS-Probleme zeigen sich oft indirekt als Connect-Fails oder plötzliches Absinken gesunder Endpoints. Wenn Sie DNS stark im Verdacht haben, verknüpfen Sie Envoy-Signale mit CoreDNS/Resolver-Metriken und Node-DNS-Telemetrie.

12) Overload und Schutzmechanismen: Wenn Envoy sich selbst schützt

• overload.… (je nach Konfiguration) – Overload-Aktionen, z. B. das Abweisen neuer Requests.
• listener.downstream_cx_overflow – Listener-Overflow/Backlog-Probleme.

Interpretation: Overload-Signale sind „late-stage“ Hinweise. Wenn Envoy aktiv abweist, ist meist bereits Ressourcenknappheit da (CPU, Memory, FD, Buffer). Dann ist der Incident häufig nicht mehr rein „Upstream“, sondern „Proxy/Node ist am Limit“.

Incident-Triage als Ablauf: Welche Metriken in welcher Reihenfolge?

Ein praktischer, wiederholbarer Ablauf spart im Incident Zeit. Die Reihenfolge ist so gewählt, dass Sie schnell die Fehlerklasse finden und danach in den passenden Diagnosezweig abbiegen.

• Schritt 1: Was passiert mit Erfolg/Fehlern? Prüfen Sie upstream_rq_5xx, upstream_rq_timeout, upstream_rq_cancelled.
• Schritt 2: Ist es erreichbar oder saturiert? Prüfen Sie upstream_cx_connect_fail und upstream_rq_pending_active.
• Schritt 3: Wer beendet Verbindungen/Requests? Prüfen Sie Resets (rx_reset/tx_reset) und cx_destroy_local/remote.
• Schritt 4: Verstärkt das Mesh die Situation? Prüfen Sie Retries (upstream_rq_retry) und Ejections (ejections_total).
• Schritt 5: Ist der Proxy selbst unter Druck? Prüfen Sie Overload/Overflow und Sidecar-CPU/Memory außerhalb von Envoy-Stats.

Mapping von Symptomen zu „wahrscheinlichen Ursachen“

Im Incident ist die wichtigste Fähigkeit nicht, jede Metrik zu kennen, sondern Muster zu erkennen. Die folgenden Kombinationen sind in der Praxis besonders aussagekräftig.

Pattern A: Connect-Fails steigen, Pending bleibt niedrig

• Signale: upstream_cx_connect_fail hoch, upstream_rq_pending_active niedrig, ggf. membership_healthy fällt.
• Wahrscheinliche Ursachen: Netzwerkpfad/Policy (SecurityGroup/NetworkPolicy), DNS falsch, TLS-Handshake-Probleme, Upstream-Port nicht erreichbar, Load Balancer Issues.
• Erste Maßnahmen: Scope eingrenzen (nur ein Service? nur eine Zone?), DNS/Service-Discovery prüfen, TLS-Fehlerzähler prüfen, Policy-Änderungen der letzten Minuten finden.

Pattern B: Pending Requests steigen, Latenz steigt, 5xx/Timeouts folgen

• Signale: upstream_rq_pending_active hoch, upstream_rq_time Tail hoch, danach upstream_rq_timeout.
• Wahrscheinliche Ursachen: Upstream-Saturation, zu kleine Connection-Pools, CPU-Limit im Sidecar oder Upstream, Hotspot durch Retry-Last.
• Erste Maßnahmen: Retries prüfen, Kapazität/Autoscaling prüfen, Pooling-Parameter prüfen, kritische Routen separieren, ggf. schrittweise Traffic drosseln.

Pattern C: Retries explodieren, Retry-Success bleibt niedrig

• Signale: upstream_rq_retry stark hoch, upstream_rq_retry_success kaum steigend, parallel Pending/Timeouts.
• Wahrscheinliche Ursachen: Retries feuern auf nicht-transiente Fehler, Retry-Budget fehlt, Backoff zu aggressiv, Upstream instabil.
• Erste Maßnahmen: Containment: Retries reduzieren, Backoff erhöhen, nur idempotente Pfade retryen, Limits pro Route setzen. Hintergrundwissen zu Retry-Mechaniken ist in Envoy-Dokumentation gut beschrieben: Envoy Retry-Verhalten.

Pattern D: Resets steigen ohne klare 5xx-Spikes

• Signale: upstream_rq_rx_reset oder upstream_rq_tx_reset steigt, Error-Codes wirken „diffus“.
• Wahrscheinliche Ursachen: Upstream beendet Verbindungen (Crash, OOM, LB), Idle-Timeouts, Max-Stream-Limits, Proxy-Timeouts, HTTP/2 Stream-Resets.
• Erste Maßnahmen: Richtung bestimmen (rx vs tx, local vs remote), Idle-Timeouts in Gateways/LBs prüfen, Upstream-Ressourcen (OOMKills) prüfen, HTTP/2-Stream-Auslastung prüfen.

Dashboards, die im Incident wirklich funktionieren

Viele Observability-Stacks scheitern im Incident nicht an Daten, sondern an unklaren Dashboards. Für Envoy empfiehlt sich eine strukturierte Darstellung nach „Downstream → Proxy → Upstream“ und zusätzlich eine „Kapazitäts-/Schutz“-Spalte.

• Downstream (Client→Envoy): Downstream-Requests, Downstream-Latenz, Downstream-Disconnects.
• Proxy intern: Pending, Overload/Overflow, CPU/Memory des Sidecars, Listener-Backlog.
• Upstream (Envoy→Service): Upstream-Requests, Connect-Fails, Resets, Timeouts, Upstream-Latenz, Healthy Membership.
• Verstärker: Retries, Ejections/Outlier, Circuit Breaker Events.

Wenn Sie Prometheus nutzen, ist es hilfreich, die Prinzipien von Labels, Countern und Histograms zu beherrschen, weil Envoy viele Histogramme für Latenz liefert: Prometheus Histogramme Best Practices.

Label- und Kardinalitäts-Fallen: Warum manche Envoy-Metriken „unbrauchbar“ wirken

Im Incident brauchen Sie Drilldowns, aber zu hohe Kardinalität kann Dashboards und Queries lahmlegen. Typische Stolperfallen:

• Zu feine Labels: Route/Path/Authority als Label kann explodieren.
• Dynamische Cluster-Namen: Versionierte oder instanzabhängige Cluster-Namen erschweren Aggregationen.
• Histogramme ohne klare Aggregation: Latenzhistogramme müssen konsistent über Service/Route aggregiert werden, sonst entstehen irreführende Quantile.

Praxisregel: Für Incident-Dashboards zuerst auf Service-/Cluster-Ebene aggregieren und nur bei Bedarf auf Route oder Pod drillen. Für tiefe Einzelfallanalyse sind Traces oft besser geeignet – idealerweise über OpenTelemetry: OpenTelemetry Dokumentation.

Runbook-Snippets: „Wenn X steigt, dann prüfe Y“

• Wenn upstream_cx_connect_fail steigt: DNS/Service-Discovery, NetworkPolicy/SecurityGroup, TLS-Handshake-Errors, Endpoint-Health prüfen.
• Wenn upstream_rq_pending_active steigt: Upstream-Kapazität, Connection-Pool, Retries, Sidecar-CPU, Queueing prüfen.
• Wenn upstream_rq_timeout steigt: Timeout-Alignment (Client↔Proxy↔Upstream), Upstream-Latenz (Histogram), Pending/Queueing, Slow DB/Dependency prüfen.
• Wenn outlier ejections_total steigt: Warum werden Hosts ejectet? Error-Spikes, flapping Instances, Canary/Deployments, LB-Healthchecks prüfen.
• Wenn listener downstream_cx_overflow steigt: Node/Proxy Ressourcen, Listener/Backlog, Connection-Spikes, SYN-Flood-artige Muster, Gateways prüfen.

Gateways vs. Sidecars: Warum die gleichen Metriken anders zu lesen sind

Ingress-/Egress-Gateways sind Konzentrationspunkte. Ein Problem dort wirkt wie ein „globaler Ausfall“, obwohl einzelne Services gesund sind. Deshalb gilt:

• Bei Gateways sind Pending/Overflow besonders kritisch: Eine kleine Queue kann viele Nutzer betreffen.
• Retry-Spikes am Gateway sind gefährlicher: Sie vervielfachen Traffic zentral.
• Connection-Pooling muss konservativer sein: Zu wenige Connections bedeuten größerer Blast Radius bei TCP/HTTP2-Effekten.

Praktische Best Practices für „Incident-ready“ Envoy Observability

• Golden Signals pro Upstream-Cluster: Traffic, Errors, Latency, Saturation – jeweils aus Envoy-Sicht.
• Quantile für Tail Latency: Mindestens P95/P99 aus upstream_rq_time (oder äquivalent), nicht nur Durchschnittswerte.
• Retry- und Outlier-Sichtbarkeit: Retries und Ejections als eigene Panels, nicht „irgendwo“ im Dashboard.
• Resets und Connect-Fails prominent: Diese zwei Klassen sind im Mesh extrem diagnostisch.
• Sidecar-Ressourcen als First-Class: CPU-Throttling und Memory/FD-Limits der Sidecars neben Envoy-Metriken zeigen.

Outbound-Links als „Single Source of Truth“ im Incident

Wenn im Incident Diskussionen entstehen („Was bedeutet diese Metrik?“, „Wie funktionieren Retries wirklich?“), helfen kurze, verlässliche Referenzen. Folgende Dokumentationen sind in der Praxis besonders nützlich:

• Envoy Statistics Overview für Metrik-Grundlagen und Namenskonventionen
• Envoy Retries für Retry-Mechanik und Auswirkungen
• Istio Prometheus Integration für typische Mesh-Dashboards und Metrik-Exposition
• Prometheus Histogramme für korrekte Interpretation von Latenzverteilungen

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.