Envoy-Metriken: Welche sind im Incident am nützlichsten?

Red Snapper

1 month ago

Envoy-Metriken sind im Incident häufig das schnellste Mittel, um zwischen Applikationsfehler, Netzwerkproblem, Überlast und Fehlkonfiguration zu unterscheiden. Das gilt besonders in Kubernetes- und Service-Mesh-Umgebungen, in denen Envoy als Sidecar oder Gateway praktisch jeden Request sieht – inklusive Retries, Timeouts, Resets, TLS-Handshakes und Load-Balancing-Entscheidungen. Während App-Logs im Ernstfall oft lückenhaft sind (Sampling, Log-Rate-Limits, fehlende Korrelation), liefern Envoy-Metriken eine konsistente Sicht auf den Datenpfad. Die Herausforderung: Envoy exportiert sehr viele Kennzahlen. Im Incident brauchen Sie jedoch nicht „alles“, sondern ein enges Set an Metriken, die schnell eine Diagnose-Richtung liefern und sich sinnvoll zu Hypothesen bündeln lassen. Dieser Artikel zeigt, welche Envoy-Metriken im Incident am nützlichsten sind, wie Sie sie interpretieren, welche typischen Fehlbilder dahinterstehen und wie Sie aus wenigen Signalen eine belastbare Entscheidung ableiten: Ist der Upstream kaputt, ist der Proxy überlastet, ist das Load Balancing falsch, stimmt das Timeout-Alignment nicht oder verstärken Retries und Connection-Pools gerade das Problem? Ziel ist ein praxistaugliches, wiederholbares Vorgehen, das auch unter Zeitdruck funktioniert.

Warum Envoy im Incident oft „näher an der Wahrheit“ ist als die App

Envoy sitzt im Datenpfad und misst genau dort, wo sich viele Incident-Ursachen manifestieren: Verbindungssättigung, Upstream-Ausfälle, DNS-Probleme, TLS-Fehler, Queueing und Zeitüberschreitungen. Zusätzlich sieht Envoy Effekte, die in der App häufig unsichtbar bleiben:

Retries und Hedge-Requests: Die App zählt „einen Call“, Envoy zählt mehrere Versuche.
Verbindungs- und Handshake-Probleme: Connect-Fails, TLS-Alerts, Resets.
Load-Balancing-Entscheidungen: Welche Endpoints genutzt werden, Outlier-Ejections, „No Healthy Upstream“.
Backpressure und Circuit Breaking: Pending-Queues, Overflow, abgelehnte Requests.
Response Flags: Kompakte Diagnosemarker, warum ein Request scheiterte (Timeout, Reset, no route, etc.).

Wichtig ist: Envoy-Metriken sind stark von Ihrer Namenskonvention (Prometheus, StatsD, OpenTelemetry), Ihrem Mesh und Ihrer Filterkette abhängig. Die Konzepte sind jedoch stabil. Als Referenz lohnt sich die offizielle Übersicht: Envoy Stats Overview.

Incident-Start: Drei Fragen, die Envoy-Metriken schnell beantworten sollen

Eine praktikable Incident-Triage beginnt mit drei einfachen Fragen. Die folgenden Metrikgruppen liefern dafür die schnellsten Antworten.

1) Scheitern Requests oder werden sie nur langsam? (Errors vs. Latency)
2) Ist der Upstream das Problem oder der Proxy selbst? (Upstream Health vs. Proxy Saturation)
3) Ist das Problem lokal (ein Endpoint) oder global (alle Endpoints)? (Load Balancing / Outlier Detection / DNS)

Die wichtigsten Metriken für Fehler: 5xx, Resets, Timeouts und Response Flags

Im Incident ist „Error Rate“ zu grob, wenn Sie nicht wissen, welche Fehlerklasse dominiert. Envoy unterscheidet sehr gut zwischen verschiedenen Fehlertypen, sofern Sie diese Metriken und Log-Felder erfassen.

HTTP/gRPC Fehlercodes: Was sie in Envoy-Kontext bedeuten

5xx (500/502/503/504): Kann Upstream-Fehler, Proxy-Fehler, „No Healthy Upstream“ oder Timeout bedeuten. Ohne Flags ist es schwer.
503: Sehr häufig bei Überlast, Circuit Breaking, Outlier-Ejection oder fehlenden Endpoints.
504: Typisch für Upstream-Timeout oder Timeout-Mismatch.
gRPC UNAVAILABLE / DEADLINE_EXCEEDED: Häufig Proxy/Netzwerk/Timeout-Themen, nicht unbedingt App-Bugs.

Response Flags: Der schnellste Diagnoseschlüssel

Wenn Sie im Access Log oder in Telemetrie die Envoy Response Flags haben, können Sie in Sekunden Hypothesen priorisieren. Typische Flags stehen für:

Upstream-Timeout: Downstream wartet, Upstream antwortet nicht rechtzeitig.
Upstream-Reset: Verbindung wurde vom Upstream oder unterwegs zurückgesetzt.
No Healthy Upstream: Load Balancer findet kein gesundes Ziel.
Local Reply: Envoy antwortet selbst (z. B. wegen Policy, RBAC, Rate Limit).
Overflow/Circuit Breaking: Envoy lehnt ab, weil Limits erreicht sind.

Für Access-Logging und dessen Felder ist diese Referenz besonders nützlich: Envoy Access Log Usage.

Praktische Kennzahl: Fehlerquote als Incident-Schwelle

Im Incident hilft eine klar definierte Schwelle, ab wann Sie von „degradiert“ zu „kaputt“ wechseln. Wenn Sie eine Fehlerquote berechnen, achten Sie darauf, Zähler konsistent zu behandeln (Rate über Zeitfenster, nicht Rohwerte). Als allgemeines Modell:

ErrorRate = Errors TotalRequests

Im Mesh ist es oft sinnvoll, Errors je nach Klasse getrennt zu rechnen (Timeouts separat, Resets separat), weil die Mitigation unterschiedlich ist.

Latenzmetriken: P95/P99, Histogramme und „wo die Zeit verbrannt wird“

Viele Incidents starten nicht mit 5xx, sondern mit steigender Tail-Latency. Envoy kann Latenz auf Proxy-Ebene messen. Trotzdem müssen Sie sauber interpretieren, was Latenz bedeutet: Sie kann durch Upstream-Queueing, Connection-Pools, DNS, TLS oder App-Verarbeitung steigen.

P95/P99: Frühindikator für Queueing und beginnende Überlast.
Aufgesplittete Latenzen: Wenn verfügbar, trennen Sie „upstream service time“ vs. „total time“.
Vergleich Canary vs. Stable: Latenz ist oft relativ aussagekräftiger als absolut, insbesondere bei dynamischer Last.

Wenn Sie Prometheus-Histogramme nutzen, ist das korrekte Verständnis von Buckets entscheidend: Prometheus Histograms and Summaries.

Upstream Health und Load Balancing: „No Healthy Upstream“, Ejections und Hotspots

Wenn Envoy keinen gesunden Upstream findet, erzeugt er häufig 503-Antworten, obwohl die Applikation nicht „crasht“. Im Incident müssen Sie schnell klären: Sind Endpoints wirklich ungesund, oder ist nur die Wahrnehmung (Health Checks, Outlier Detection, DNS) falsch?

Gesundheitszustand der Cluster/Endpoints: Wie viele Endpoints sind verfügbar?
Outlier Detection / Ejections: Werden Endpoints wegen Fehlern entfernt?
Load-Balancing-Verteilung: Gibt es Hotspots (ein Endpoint bekommt zu viel Traffic)?
„Panic Mode“: Wenn zu wenige Endpoints gesund sind, kann Envoy in einen Modus wechseln, der Verteilung verändert.

Konzeptuell ist der Upstream-Teil in der Envoy-Architektur gut beschrieben: Envoy Load Balancing Overview.

Typisches Fehlbild: Ein einzelner schlechter Endpoint

Wenn nur ein Pod/Endpoint fehlerhaft ist, sehen Sie oft:

Spikes in Upstream-Resets oder 5xx, aber nur für Teiltraffic
Ejections steigen, Endpoint-Anzahl sinkt
Latenz steigt unregelmäßig („intermittierend“)

Mitigation ist dann häufig: Endpoint isolieren (Outlier Detection prüfen), Rollout stoppen, Pod/Node untersuchen, Traffic shiften.

Connection Pool und HTTP/2: Wenn Verbindungen der Engpass sind

Ein großer Anteil schwerer Incidents hängt nicht direkt an der App, sondern an Verbindungsmanagement: zu viele neue Connections, erschöpfte Pools, TLS-Handshake-Last oder HTTP/2-Stream-Limits. Envoy-Metriken aus dem Connection-Pool-Umfeld helfen, genau diese Ursachen zu erkennen.

Aktive Verbindungen: Steigen sie plötzlich? Das kann auf fehlendes Keepalive, DNS-Änderungen oder LB-Verhalten hinweisen.
Connection Failures: Connect-Fails deuten auf Netzwerk/Firewall/Endpoint-Churn.
Pending Requests: Requests warten, weil keine Connection oder kein Stream verfügbar ist.
HTTP/2 Stream Exhaustion: Viele parallele Streams können Limits erreichen und Queueing erzeugen.

In Envoy ist die Router-/Connection-Management-Schicht dokumentiert; je nach Einsatz sind HTTP Connection Manager und Router Filter relevant: HTTP Connection Manager.

Circuit Breaking und Overload: Rejections sind manchmal die „richtige“ Antwort

Im Incident sieht eine steigende Zahl abgelehnter Requests zunächst schlimm aus. Tatsächlich kann sie das System stabilisieren, wenn sie kontrolliert ist: Circuit Breaking verhindert, dass sich Pending-Queues und inflight Requests unendlich aufstauen. Der Schlüssel ist, Rejections zu verstehen und zu messen.

Overflow/Rejected: Envoy lehnt ab, weil max_requests, max_pending_requests oder max_connections erreicht sind.
Retry Overflow: Retries werden abgelehnt, weil retry budgets oder Limits greifen.
Proxy Saturation: Der Proxy selbst ist überlastet (CPU/Memory), was sekundäre Fehler erzeugt.

Die konzeptionelle Grundlage dazu ist hier beschrieben: Envoy Circuit Breaking.

Praktische Entscheidungshilfe: Wann Rejections akzeptabel sind

Wenn Rejections steigen, prüfen Sie parallel:

Sinkt Tail-Latency oder stabilisiert sie sich? (Backpressure wirkt)
Sinkt CPU/Memory-Druck auf Upstream/Proxy? (System gewinnt Luft)
Steigt Error Budget-Verbrauch unkontrolliert? (Zu streng oder falsche Schwellen)

Rejections ohne Stabilisierung sind ein Zeichen, dass die Limits zu niedrig sind oder dass Upstream-Kapazität drastisch fehlt.

Retries, Timeouts und Resets: Der Dreiklang, der Incidents eskalieren lässt

Wenn Sie im Incident nur eine Envoy-„Story“ verstehen wollen, dann diese: Timeouts und Resets erhöhen Retries, Retries erhöhen Concurrency, Concurrency erhöht Latenz, Latenz erhöht Timeouts. Envoy-Metriken können diesen Kreislauf sichtbar machen.

Retry Rate: Wie viele zusätzliche Versuche pro Request passieren?
Success-after-Retry: Helfen Retries überhaupt oder erzeugen sie nur Last?
Upstream Timeouts: Steigen sie parallel zu P99, ist Queueing/Überlast wahrscheinlich.
Upstream Resets: Häufig bei Connection-Churn, Idle-Timeout-Mismatch, Netzwerkflaps oder abrupten Restarts.

Für Retry-Policies und deren Auswirkungen ist die Envoy-Referenz hilfreich: Envoy Retry Policy.

DNS und Cluster Discovery: Wenn das Ziel falsch oder instabil ist

Ein unterschätzter Incident-Treiber ist instabiles Discovery: DNS-Flapping, falsche Service-IPs, zu aggressive TTLs oder ein Mesh, das Endpoints unvollständig sieht. Symptome ähneln Netzwerkfehlern, haben aber eine andere Ursache.

Intermittierende Connect-Fails: Oft korreliert mit DNS-Updates oder Endpoint-Churn.
Wechselnde Upstream-IPs: Kann zu Connection-Churn und TLS-Handshake-Last führen.
Kurze Ausfälle bei Rollouts: Wenn Endpoints zu früh „ready“ wirken oder zu spät entfernt werden.

Für die Grundlagen von Cluster/Discovery in Envoy ist der Architekturteil zu xDS/Config besonders nützlich: Envoy xDS Protocol.

Proxy-spezifische Sättigung: Wenn Envoy selbst der Flaschenhals ist

Gerade im Sidecar-Modell kann Envoy zum Bottleneck werden: CPU-Throttling, zu kleine Requests/limits, zu hohe Logging-Last oder TLS-Kosten. Dann sehen Sie Symptome, die wie Upstream-Probleme wirken, aber eigentlich Proxy-Sättigung sind.

CPU/Throttling: Sidecar wird gedrosselt, Latenz steigt, Timeouts steigen.
Memory Pressure: OOM-Risiko, Garbage Collection in App kann zusätzlich triggern.
Queueing im Proxy: Pending steigt, Rejections steigen, obwohl Upstream gesund wäre.

In diesem Fall ist die wichtigste Maßnahme oft banal: Sidecar-Ressourcen realistisch dimensionieren, Telemetrie drosseln, TLS-Resumption/HTTP2 nutzen und Connection-Reuse verbessern.

Ein Incident-Dashboard-Set: Minimal, aber aussagekräftig

Wenn Sie nur ein kleines Set an Panels bauen wollen, das im Incident zuverlässig hilft, dann bündeln Sie Envoy-Metriken in folgende Gruppen. Das reduziert „Dashboard-Scrolling“ und beschleunigt Entscheidungen.

Request Volume: RPS gesamt und nach Route/Cluster, plus InFlight.
Error Breakdown: 5xx/4xx, gRPC Status, dazu Response Flags.
Latency: P95/P99 (idealerweise histogram-basiert), plus Upstream Service Time.
Retries: Retry Rate, Retry Success, Retry Overflow.
Upstream Health: Healthy Endpoints, Ejections, No Healthy Upstream.
Connections: Active connections, connect failures, connection churn (falls verfügbar).
Circuit Breaking: Pending, overflow/rejections, maxed-out indicators.
Proxy Health: Sidecar CPU/Memory/Throttling, ggf. GC/FDs auf Node-Ebene.

Interpretationsfallen: Warum Envoy-Metriken im Incident leicht falsch gelesen werden

„Envoy zeigt 503, also ist der Upstream down“: 503 kann auch Circuit Breaking, Outlier Detection oder Policy bedeuten.
„Keine 5xx, also alles gut“: Retries können Fehler maskieren, Tail-Latency steigt trotzdem.
„Timeout ist ein Netzwerkproblem“: Häufig ist es Überlast/Queueing oder Timeout-Mismatch zwischen App, Proxy und LB.
„Resets sind immer Bugs“: Oft sind es Idle-Timeouts, Connection Draining, Rollouts oder Zwischenkomponenten.
„Eine Metrik reicht“: Im Incident sind Korrelationen entscheidend (z. B. Retry Rate + P99 + Pending).

Outbound-Quellen für vertiefende Informationen

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.