OSI-basierte Observability: Pflicht-Metriken für Infra + App

OSI-basierte Observability ist ein praktischer Ansatz, um Telemetrie nicht nach Tool-Silos („APM“, „Netzwerk“, „Logs“), sondern nach Ursachebenen zu strukturieren. Statt im Incident hektisch zwischen Dashboards zu springen, ordnen Sie Signale konsequent den OSI-Layern zu – von physischer Infrastruktur bis zur Anwendungssemantik. Das schafft eine gemeinsame Sprache zwischen Infra-, Plattform-, Netzwerk-, Security- und App-Teams und reduziert die typische Diskussion „Ist es das Netzwerk oder die App?“. Gleichzeitig verhindert OSI-basierte Observability blinde Flecken: Viele Organisationen messen HTTP-Latenz und CPU, aber nicht DNS-Fehler, Retransmissions, TLS-Handshake-Zeiten oder Queueing-Effekte. Genau dort entstehen jedoch häufig Tail-Latency-Spitzen, sporadische Timeouts und vermeintlich „flaky“ Fehler. In diesem Artikel erhalten Sie eine praxiserprobte Liste von Pflicht-Metriken für Infrastruktur und Anwendungen – sauber nach OSI-Layern gemappt, inklusive typischer Fallstricke, sinnvoller Dimensionswahl (Labels/Tags) und Hinweisen, wie Sie die Signale in Runbooks und SLOs übersetzen. Ziel ist nicht „mehr Metriken“, sondern die richtigen Kernsignale, die schnelle Diagnose, belastbare Root-Cause-Analysen und messbare Verbesserungen ermöglichen.

Warum OSI als Struktur für Observability funktioniert

Das OSI-Modell liefert eine stabile mentale Landkarte: Es trennt Übertragung, Routing, Transport, Session, Verschlüsselung und Anwendungssicht. Für Observability bedeutet das: Sie definieren pro Layer wenige, aber aussagekräftige Signale, die sowohl Symptome (z. B. Latenz) als auch Mechanismen (z. B. Retransmissions, Queueing, Handshake-Zeiten) abdecken. Dadurch entstehen klare Diagnosepfade: Wenn Layer-7-Fehler steigen, prüfen Sie zuerst, ob Layer 3/4/6 stabil ist – und umgekehrt. Für einheitliche Telemetrie-Standards lohnt sich ein Blick auf OpenTelemetry, weil es Metriken, Logs und Traces konsistent zusammenführt und die Korrelation zwischen Layern erleichtert.

Grundprinzipien: Was „Pflicht-Metriken“ auszeichnet

Nicht jede Metrik ist eine Pflicht-Metrik. Pflicht-Metriken erfüllen drei Kriterien: Sie sind (1) dauerhaft verfügbar, (2) interpretationsstabil und (3) direkt handlungsrelevant. Eine gute Pflicht-Metrik lässt sich in Runbooks in konkrete Fragen übersetzen („Ist Paketverlust vorhanden?“), und sie ist robust gegenüber Implementationsdetails.

• Goldene Signale plus Mechanismen: Latenz, Traffic, Errors, Sättigung sind wichtig, aber ohne Mechanismen (DNS, Retransmissions, Handshakes, Queues) bleiben Ursachen oft verborgen.
• End-to-End und Hop-by-Hop: Sie benötigen Sicht von Client bis Service (End-to-End) und zusätzlich pro Übergang (z. B. Ingress, Sidecar, Node).
• Tail statt Durchschnitt: Pflicht sind Quantile (p95/p99) oder Histogramme, nicht nur Mittelwerte.
• Kontext durch Dimensionen: Pflicht-Labels sind z. B. Region/AZ, Cluster, Service, Endpoint/Route, Error-Klasse, Dependency.

Layer 1: Physik/Unterlay – auch in der Cloud relevant

Layer 1 ist in der Cloud „nicht Ihr Kabel“, aber er ist Ihr Risiko. Sie brauchen Signale, die Underlay-Störungen plausibel machen, auch wenn Sie sie nicht direkt beheben können. Pflicht-Metriken auf Layer 1 kommen typischerweise aus Host/VM, NIC-Treiber, Hypervisor-Expose, Provider-Telemetrie oder Netzwerkgerät-Metriken (On-Prem).

• NIC-Fehlerzähler: CRC-Errors, Symbol Errors, Drops am Interface, Carrier Changes.
• Link-Status/Flaps: Up/Down-Events, Negotiation-Probleme, Duplex/Speed-Mismatch (on-prem relevant).
• Host/Node-Packet-Drops: Drops auf vNIC, virtio/vmxnet, SR-IOV-Queues.
• CPU-Steal/Ready-Time (virtualisiert): Indirektes Signal, dass Paketverarbeitung oder Interrupts leiden können.

Praxis-Tipp: Layer 1 wird selten isoliert betrachtet. Seine Pflicht-Metriken sind wertvoll, wenn sie zeitlich mit Layer-3/4-Symptomen (Retransmissions, Jitter) korrelieren. Für Metrik-Scraping und Standardisierung ist Prometheus ein verbreiteter Baustein, insbesondere in Kubernetes-Umgebungen.

Layer 2: Data Link/Overlay – ARP, ND und „unsichtbare“ Broadcast-Effekte

In virtualisierten Netzwerken treten Layer-2-Effekte oft als Overlay-Phänomene auf: ARP/Neighbor Discovery, MAC-Tabellen, virtuelle Switches, Bridge- oder VXLAN-Segmente. Pflicht-Metriken helfen, „Policy wirkt korrekt, aber Traffic droppt“ schneller zu entwirren.

• ARP/ND-Fehlerraten: Unresolved ARP, Neighbor Unreachable, ND Cache Misses.
• MAC/Neighbor-Table-Pressure: Table Size, Evictions, Aging Events (falls verfügbar).
• Bridge-/vSwitch-Drops: Drops auf Linux Bridge/OVS, Forwarding-Failures, MTU-Drops im Overlay.
• Broadcast/Multicast-Rate (on-prem/Overlay): Ungewöhnliche Peaks als Indikator für Storms.

Für Kubernetes ist besonders wichtig, ob das CNI L2-Bridge-Mechanismen nutzt oder strikt routed. L2-Drops sehen häufig wie „random“ aus, wenn sie nur bei bestimmten Pods/Nodes auftreten.

Layer 3: IP/Routing – Reachability, Pfade und Fehlkonfigurationen

Layer 3 ist die Basis für „kommt Traffic an?“. In Cloud- und Hybrid-Setups sind CIDR-Design, Routing-Tables, Peering, Transit-Gateways, Firewalling und Anycast relevante Quellen für systemische Probleme. Pflicht-Metriken sollten sowohl Reachability als auch Pfadinstabilität abdecken.

• ICMP/Reachability: Erfolgsrate von synthetischem Ping/Traceroute (kontrolliert und rate-limited).
• Route-Table-Hits/Misses (sofern messbar): Drops aufgrund fehlender Route, Blackhole-Routen.
• Packet Drops auf IP-Ebene: rp_filter-Drops, TTL-Expired (falls relevant), Fragmentation Needed (DF gesetzt).
• NAT-Signale (L3/L4-Grenze): NAT-Gateway Throughput, Error Counters, Port Allocation Failures.
• Anycast/Global LB Indicators: Region-Shift, ungewöhnliche Client-Geo-Verteilung, Route Changes.

Wenn Sie Anycast oder globales Load Balancing einsetzen, sind Routing-Instabilitäten häufige Ursachen für Tail-Latency-Spitzen. Eine gute Orientierung zu Routing-Konzepten bietet die Dokumentation Ihres Cloud-Providers, ergänzt durch Grundlagen zu BGP und IP. Für Protokollkontext ist die RFC-Landschaft hilfreich; die zentrale HTTP-Semantik finden Sie in RFC 9110, auch wenn das formal Layer 7 betrifft – für Observability ist die Protokollkette entscheidend.

Layer 4: Transport – TCP/UDP, Retransmissions und Timeouts

Layer 4 ist die häufigste Quelle für „es wirkt wie die App, ist aber Transport“. Pflicht-Metriken auf Transportebene sind nicht verhandelbar, wenn Sie Tail Latency ernst nehmen. Besonders bei Microservices, Service Mesh und hohem Ost-West-Traffic entscheiden Retransmissions und Queueing über p99.

• TCP Retransmissions: Rate und Anteil (Retransmits/Segments), getrennt nach Source/Dest, Node, Service.
• TCP Connection Errors: SYN timeouts, RST rate, handshake failures, connection refused.
• Handshake-Dauer: TCP connect latency (SYN->ACK->ESTABLISHED), ideal als Histogramm.
• Congestion/Queue Signals: RTT, RTT-Varianz, cwnd (wenn verfügbar), Socket Queue Length.
• UDP Loss/Jitter (falls UDP/QUIC): Loss-Estimates, reordering, jitter (voip/streaming/HTTP3).
• Conntrack-Sättigung (Linux/Kubernetes): conntrack count, conntrack max, insert failures, drops.

Viele Teams messen nur „HTTP-Latenz“ und übersehen, dass p99-Latenz von TCP-Wiederholungen oder conntrack-Drops dominiert sein kann. Gerade auf Kubernetes-Nodes ist conntrack ein klassischer Engpass, der sich als sporadische 5xx/timeout-Fehler zeigt, obwohl App-CPU „grün“ ist.

Layer 5: Session – Keepalive, Connection Pooling und Sticky-Effekte

Layer 5 ist im Web-Stack weniger „klassisch“, aber operativ hochrelevant: Session-Verhalten entsteht aus Connection Reuse, Keepalives, Load-Balancer-Policies, gRPC-Channels, WebSockets oder Long Polling. Pflicht-Metriken helfen, „random disconnects“ und Retry-Stürme zu entwirren.

• Connection Pool Utilization: offene Verbindungen, Idle vs. Busy, Pool Exhaustion Events.
• Keepalive/Idle-Timeout Events: Disconnects nach Idle, Reset by peer, LB idle timeouts.
• Session Affinity/Stickiness: Anteil sticky Sessions, Hotspot-Backends, Imbalance-Indikatoren.
• WebSocket/Long-Poll Metriken: Concurrent Sessions, Abbruchraten, Reconnect Rate, Heartbeat Misses.

Ein typisches Muster: Falsch konfiguriertes Connection Pooling führt zu Connection Churn. Das sieht dann wie Layer-4-Degradation aus (mehr Handshakes, mehr SYNs, höhere Tail Latency), obwohl die Root Cause in Layer 5 liegt.

Layer 6: Presentation/Security – TLS, Zertifikate und Handshake-Kosten

TLS-Probleme werden oft fälschlich als „Netzwerk“ eingeordnet, weil sie sich als Timeouts, Verbindungsabbrüche oder sporadische Fehler äußern. Pflicht-Metriken auf Layer 6 sind entscheidend, um Security-Controls und Reliability zusammenzubringen.

• TLS Handshake Latency: vollständiger Handshake, Resumption, getrennt nach Client/Region/Endpoint.
• Handshake Failure Rate: Gründe wie cert expired, unknown CA, bad certificate, protocol version mismatch.
• Zertifikats-Expiry Window: Tage bis Ablauf (min/avg), pro Zertifikat/Service/Ingress.
• Cipher/ALPN/SNI-Metriken: Negotiated protocol (h2/h1/h3), SNI mismatch events, ALPN fallback rate.
• mTLS-Signale (Service Mesh): AuthN/AuthZ Denies, SAN/Spiffe-ID mismatch, rotation errors.

Für TLS-Grundlagen und Fehlertypen sind sowohl Provider-Dokumentationen als auch Standardwerke hilfreich; für eine systematische Betrachtung von SRE-Praktiken lohnt sich Site Reliability Engineering (Google SRE Book), insbesondere rund um Monitoring, Incident Response und Fehlerbudgets.

Layer 7: Anwendung – HTTP-Semantik, Fehlerklassen und Business-Sicht

Layer 7 ist der Bereich, in dem Nutzerwirkung sichtbar wird: Latenz, Fehlerraten und Funktionsfähigkeit. Pflicht-Metriken müssen hier sowohl technische als auch produktnahe Perspektiven abdecken, ohne in reine „Vanity Metrics“ abzudriften.

• Request Rate: pro Route/Endpoint, Methode, Tenant, Region (mit sinnvollem Sampling/Labeling).
• Error Rate: getrennt nach 4xx/5xx, plus interne Fehlerklassen (Validation/Auth/Dependency/Timeout).
• Latency Histogramme: p50/p95/p99 oder Histogramm-Buckets, getrennt nach Route und Response-Code.
• Dependency Latency: Downstream-Calls (DB, Cache, IdP, Payment), inklusive Fehler- und Timeout-Raten.
• Retry Rate: Anzahl Retries pro Request, Retry-Gründe, Backoff/Jitter-Wirksamkeit.
• Queueing/Backpressure: Queue Depth, Work In Progress, Reject/Drop Rate, Saturation.
• Cache Metrics: Hit Rate, Stale-Serve Rate, Evictions, Revalidation Times.

Wenn Sie HTTP/2 oder gRPC nutzen, sind zusätzlich streambezogene Metriken sinnvoll (z. B. h2 resets, stream errors), weil Head-of-Line- und Flow-Control-Effekte Tail Latency verschieben können.

Cross-Layer-Pflichtsignale: Korrelation statt Einzelsicht

OSI-basierte Observability funktioniert erst dann gut, wenn Sie die Layer nicht nur einzeln messen, sondern miteinander verbinden. Drei Cross-Layer-Signale sind besonders hilfreich, weil sie häufige Fehlinterpretationen verhindern.

End-to-End-Latenz-Breakdown

Eine Pflichtsicht ist der Latenzaufschlüsselungspfad: DNS → TCP connect → TLS handshake → Request processing → Response. Selbst wenn Sie nicht jedes Segment perfekt messen können, sollten Sie mindestens die kritischen Übergänge instrumentieren. Viele Störungen zeigen sich zuerst als Anstieg in einem Segment (z. B. TLS-Handshakes), während „App-Latenz“ scheinbar stabil bleibt.

Fehlerketten: Von 429/503 bis Retry Storm

Pflicht ist eine Sicht auf Fehleramplifikation: Steigen 429/5xx, steigen oft auch Retries und neue Verbindungen, was Layer 4/5 belastet. Ohne Retry-Rate und Connection-Churn-Metriken interpretieren Teams 429 gerne als „Client zu laut“ statt als systemische Kaskade.

Tail-Latency-Korrelation mit Transport-Signalen

Eine zuverlässige Regel: Wenn p99-Latenz steigt, prüfen Sie zwingend Retransmissions, RTT-Varianz, Queueing und Handshake-Zeiten. Dafür müssen die Metriken im selben Zeitraster verfügbar sein und über gemeinsame Dimensionen (Service, Node, Region) korreliert werden.

Pflicht-Dimensionen: Welche Labels/Tags Sie brauchen

Selbst die beste Metrik ist wertlos, wenn sie nicht segmentierbar ist. Gleichzeitig zerstören zu viele Labels die Kardinalität. Pflicht-Dimensionen sind jene, die Diagnosen in Minuten statt Stunden ermöglichen.

• service: eindeutiger Servicename
• environment: prod/stage/dev
• region und az: für Fault-Domain-Analyse
• cluster und node: besonders in Kubernetes
• endpoint/route: normalisiert, ohne dynamische IDs
• status_code bzw. error_class: z. B. timeout, dependency, auth, validation
• dependency: Name des Downstream-Systems

Für Traces ist eine saubere Semantik der Attribute zentral. Nutzen Sie möglichst konsistente Konventionen (z. B. OpenTelemetry Semantic Conventions), damit Infra- und App-Telemetrie zusammenpasst.

Von Metriken zu Runbooks: OSI-basierte Diagnosefragen

Pflicht-Metriken entfalten ihren Wert, wenn sie in wiederholbare Diagnosepfade übersetzt werden. Ein OSI-basiertes Runbook arbeitet mit Fragen pro Layer, die Sie in Dashboards direkt beantworten können.

• Layer 3: Gibt es Reachability-Verlust oder Pfadinstabilität? Ist nur eine Region/AZ betroffen?
• Layer 4: Steigen Retransmissions, SYN timeouts oder RSTs? Ist conntrack nahe am Limit?
• Layer 6: Steigen TLS-Handshake-Zeiten oder Handshake-Failures? Gibt es Zertifikatsabläufe?
• Layer 7: Welche Routes sind betroffen? Steigen 4xx/5xx gleichmäßig oder nur für bestimmte Clients?
• Cross-Layer: Korrelieren Tail Latency und Transport-Signale? Steigt Retry Rate parallel?

Verknüpfung mit SLOs: Welche Layer-Signale in Ziele gehören

SLOs sollten Nutzerwirkung abbilden (meist Layer 7), aber sie profitieren von Layer-3/4/6-Grenzwerten als „Guardrails“. Beispiel: Wenn Ihr Availability-SLO verletzt wird, möchten Sie wissen, ob DNS/TLS/Transport die Ursache war. Pflicht ist daher, dass SLO-Dashboards mindestens die wichtigsten OSI-Signale als Kontext anzeigen: Retransmissions, Handshake-Latenz, DNS-Fehler, conntrack-Drops, Dependency-Latenzen. Für die SLO-Systematik und Error Budgets ist die Google-SRE-Perspektive ein bewährter Referenzrahmen, etwa über das SRE Workbook.

Minimaler OSI-Pflichtkatalog: Eine kompakte Checkliste

Wenn Sie pragmatisch starten möchten, hilft dieser Minimal-Katalog. Er ist bewusst knapp gehalten und deckt die häufigsten Ursachen in Produktion ab.

• L1: Interface drops/errors, link flaps, CPU-steal/ready-time (virtualisiert)
• L2: ARP/ND failures, vSwitch/bridge drops, neighbor-table pressure
• L3: Reachability synthetics, route-related drops/blackholes (sofern sichtbar), NAT error/throughput signals
• L4: TCP retransmissions, connect latency, RST/SYN timeout rate, RTT/variance, conntrack saturation
• L5: connection pool utilization, keepalive/idle-timeout disconnects, reconnect rate
• L6: TLS handshake latency, handshake failure reasons, cert expiry window, ALPN/SNI anomalies
• L7: request rate, error rate (4xx/5xx + error_class), latency histograms, dependency latency/errors, retry rate

Typische Anti-Patterns: Warum „wir haben Metriken“ trotzdem nicht reicht

• Nur Durchschnittswerte: p50 sieht gut aus, p99 brennt; ohne Histogramme bleibt Tail-Latency unsichtbar.
• Keine Mechanismen: HTTP-Latenz ohne Retransmissions/Handshake/Queueing ist Diagnose ohne Ursache.
• Keine Korrelation: Metriken existieren, aber ohne gemeinsame Dimensionen und ohne Trace-IDs sind sie isoliert.
• Kardinalitäts-Falle: Zu viele Labels (User-ID, full URL) machen Metriken teuer und unbenutzbar.
• Security ohne Telemetrie: WAF/Policies blocken, aber ohne Decision-Reason und Rule-IDs ist 403 ein Rätsel.

Praktische Umsetzung: So bauen Sie OSI-basierte Dashboards

Ein funktionales OSI-Dashboard ist nicht „ein riesiges Board“, sondern ein Satz von Sichten: (1) End-to-End-Übersicht, (2) Layer-3/4-Transportgesundheit, (3) TLS/Auth-Sicht, (4) App/Dependency-Sicht. Wichtig ist, dass jede Sicht eine klare Frage beantwortet und nicht nur Zahlen zeigt. Ergänzend sollten Sie synthetische Checks (DNS, TLS, HTTP) so betreiben, dass sie die Segmentierung nach Region/AZ ermöglichen. Viele Teams nutzen dafür Kombinationen aus Prometheus/Grafana, OpenTelemetry und einem Trace-Backend. Entscheidend ist weniger das Tooling als die OSI-Struktur: Die Pflicht-Metriken pro Layer müssen überall gleich benannt, gleich segmentierbar und im Incident schnell auffindbar sein.

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.