Observability-by-Design bedeutet, Netzwerke so zu entwerfen, dass sie von Anfang an messbar, erklärbar und auditierbar sind – nicht erst, wenn ein Incident passiert. In Provider- und Telco-Umgebungen ist das besonders wichtig: Topologien sind groß, Traffic ist dynamisch, Failoverpfade sind komplex, und viele Störungen sind „teilweise“ (Congestion, Microbursts, Route-Churn, asymmetrische Pfade, fehlerhafte Policies) statt „alles down“. Klassisches Monitoring (Up/Down, SNMP-Graphs) reicht dafür nicht aus. Moderne Observability kombiniert Telemetry-Pfade (wie Daten aus dem Netz herauskommen), Sampling (wie man Datenmengen kontrolliert, ohne blind zu werden) und Datenmodelle (wie man Metriken, Events, Logs und Flows konsistent beschreibt). Wenn diese drei Bausteine nicht zusammen geplant werden, entsteht ein typisches Chaos: zu viele Daten ohne Aussage, zu wenige Daten an der falschen Stelle, inkonsistente Namensräume, fehlende Korrelation zwischen Routing-Events und Performance, und damit lange MTTR (Mean Time to Repair). Ein professionelles Design behandelt Observability wie eine Netzfunktion: eigene Security Domain, eigene Kapazitätsplanung, standardisierte Labels/Tags, klare SLOs/SLAs und eine Architektur, die auch bei Störungen weiter Daten liefert. Dieser Artikel zeigt praxisnah, wie Sie Observability-by-Design umsetzen – mit durchdachten Telemetry-Pfaden, sinnvollen Sampling-Strategien und Datenmodellen, die Betrieb, Engineering und Audit gleichermaßen unterstützen.
Warum Observability-by-Design mehr ist als Monitoring
Monitoring beantwortet häufig die Frage: „Ist etwas up oder down?“ Observability beantwortet: „Warum ist es so?“ Dafür müssen Sie Zustands-, Pfad- und Ursacheninformationen kombinieren. Gerade in modernen Provider-Netzen treten viele Probleme als Qualitätsdegradation auf: Latenz steigt nur in einer Region, Loss betrifft nur eine Queue, ECMP verteilt Flows ungleich, oder eine BGP-Policy verändert Inbound-Pfade. Diese Effekte sieht man nur, wenn Telemetry bewusst so gebaut ist, dass sie Pfade und Policies sichtbar macht.
- Pfadtransparenz: Welcher Traffic nahm welchen Pfad und warum (Policy, ECMP, SR-TE, Failover)?
- Qualitätsmetriken: Latenz/Loss/Jitter, Queue-Drops, Microbursts, Reordering, MTU-Probleme.
- Control-Plane-Sicht: BGP/IGP-Events, Konvergenz, RR-Health, Prefix-Counts, Flap-Rate.
- Kontext: Änderungen (Change Events), Wartungen, Releases und Konfigurationsdrift als erklärende Dimension.
Leitprinzip: Wenn Sie es nicht messen können, können Sie es nicht betreiben
Carrier-Grade bedeutet nicht nur Redundanz, sondern Nachweisbarkeit: Was passiert im N-1? Welche Queue droppt? Welche Policy wirkt? Observability-by-Design macht das belegbar.
Die Observability-Architektur: Telemetry-Pfade als eigene Netzfunktion
Telemetry-Daten müssen zuverlässig aus dem Netz heraus transportiert, verarbeitet und gespeichert werden. Das ist ein Pfadproblem: Geräte senden Daten an Collector, diese aggregieren, normalisieren und leiten weiter an Time-Series DB, Logsysteme oder Data Lakes. Wenn dieser Pfad nicht redundant und abgesichert ist, verlieren Sie im Incident genau die Daten, die Sie brauchen. Deshalb gehört Telemetry in eine eigene Domain – mit eigener Kapazitäts- und Security-Logik.
- Telemetry Sources: Router/Switches/Firewalls/CNFs, die Metriken, Events, Logs oder Flows erzeugen.
- Collectors: Regional oder zentral; sammeln, puffern, normalisieren und leiten weiter.
- Storage/Processing: Time-Series, Logs, Flow-Analytics, Trace-Backends, Correlation Engines.
- Access Layer: Dashboards, Alerting, SLO-Engine, Reporting und Audit-Exports.
Designregel: Telemetry muss im Störfall weiter funktionieren
Wenn Telemetry über denselben Pfad läuft wie Kundentraffic und im Congestion-Fall droppt, verlieren Sie Sichtbarkeit genau dann, wenn sie entscheidend ist. Management- und Telemetry-Pfade sollten daher priorisiert, segmentiert und redundant sein.
Telemetry-Pfade: In-Band, Out-of-Band und Hybrid
Es gibt drei grundlegende Ansätze, Telemetry aus dem Netz zu transportieren. Welcher richtig ist, hängt von Netzgröße, Security-Anforderungen, Standortrealität und Betriebsreife ab.
- Out-of-Band (OOB): Separates Managementnetz für Telemetry. Sehr robust, aber teuer und nicht überall verfügbar.
- In-Band: Telemetry läuft über das Produktionsnetz, typischerweise in einer Management-VRF. Günstig und flexibel, aber muss QoS- und Security-seitig abgesichert werden.
- Hybrid: OOB in kritischen PoPs/DCs, In-Band in Feldstandorten; konsistente Security und Priorisierung sind Pflicht.
Ein praktischer Kompromiss
Viele Provider nutzen Hybrid: In zentralen Standorten OOB für maximale Resilienz, in der Fläche In-Band über eine strikt getrennte Management-VRF mit QoS-Priorisierung und klaren Guardrails.
Welche Telemetry-Arten Sie wirklich brauchen: Metriken, Logs, Flows, Ereignisse
Observability-by-Design setzt auf mehrere Datenarten, weil jede andere Fragen beantwortet. Nur Metriken zeigen Trends, aber selten Ursachen. Logs zeigen Ursachen, aber sind teuer. Flows zeigen Verkehrsmuster, aber nicht unbedingt Paketqualität. Ereignisse (Events) verbinden Zustandsänderungen (z. B. BGP-Withdraw) mit Zeitpunkten. Ein gutes Design definiert pro Use Case die minimal nötige Datenkombination.
- Metriken: Interface/Queue-Auslastung, Drops, CPU/Memory, Session-Counts, Sensorwerte.
- Logs: Control-Plane-Logs, Policy-Hits, Security-Events, AAA/BNG/CGNAT-Logs.
- Flows: NetFlow/IPFIX/sFlow-ähnliche Daten, Traffic-Mix, Top Talkers, DDoS-Indikatoren.
- Events: Link up/down, BFD down/up, BGP session reset, IGP SPF, FRR activation.
Designregel: Erst Use Cases, dann Datenquellen
Wenn Sie Daten sammeln, „weil es geht“, explodieren Kosten und Komplexität. Starten Sie mit 5–10 klaren Betriebsfragen (z. B. „Warum ist Region X langsam?“) und leiten Sie daraus Datenquellen und Sampling ab.
Sampling-Strategien: Weniger Daten, mehr Aussage
Sampling ist nicht nur ein Kostenwerkzeug, sondern ein Qualitätswerkzeug: Es entscheidet, welche Signale sichtbar bleiben. In großen Netzen ist „alles immer“ praktisch unmöglich. Stattdessen braucht es eine mehrstufige Strategie: breite, günstige Signale (Metriken) immer, mittelteure Signale (Flows) adaptiv, teure Signale (Packet Captures/Full Logs) selektiv und zeitlich begrenzt.
- Deterministisches Sampling: Feste Raten (z. B. 1:1000) für Flows; gut für Trends, schlecht für seltene Events.
- Adaptive Sampling: Samplingrate steigt bei Anomalien (z. B. DDoS, Congestion, Routing-Churn).
- Trigger-basiert: Packet Capture oder detaillierte Logs nur bei definierten Triggern (Queue Drops, BGP Flaps).
- Stratified Sampling: Kritische Klassen (Management, VoIP, Timing) bekommen höhere Sichtbarkeit als Bulk-Traffic.
Sampling muss Topologie kennen
Wenn Sie überall gleich sampeln, übersehen Sie oft die Engpässe: Edge-Ports, Hub-Uplinks, DCI-Links, BNG/CGNAT-Knoten. Sampling sollte an „choke points“ dichter sein als im Core.
Telemetry für Pfade: Wie Sie Latenz, Loss und Pfadwechsel sichtbar machen
Viele Incidents sind Pfadprobleme: Traffic nimmt unerwartete Exits, Failover schaltet auf einen überlasteten Link, oder ECMP verteilt ungleich. Dafür brauchen Sie Path Observability – idealerweise als Kombination aus aktiven Messungen (synthetische Probes) und passiven Daten (Queue/Flow/Events).
- Aktive Probes: Regelmäßige Messungen zwischen Regionen/PoPs zu Referenzzielen (Latenz/Loss/Jitter).
- Queue-Telemetry: Drops pro Klasse, Microburst-Indikatoren, Buffer-Auslastung an Engpässen.
- Routing-Events: BGP/IGP-Events zeitlich korrelieren mit Path-KPIs.
- ECMP-Visibility: Member-Auslastung pro LAG/ECMP-Pfad, um Hotspots zu erkennen.
Ein Anti-Pattern: Nur Durchschnittswerte betrachten
Microbursts und kurze Loss-Spikes können Nutzer stark beeinträchtigen, tauchen aber in 5-Minuten-Averages kaum auf. Observability-by-Design braucht ausreichend Granularität an kritischen Stellen.
Datenmodelle: Ohne konsistente Labels wird Observability unbrauchbar
Ein Datenmodell definiert, wie Sie Telemetry beschreiben: Namensräume, Labels/Tags, Einheiten, Geräte- und Topologiezuordnung. Ohne konsistentes Modell sind Dashboards und Alerts nicht wiederverwendbar, und Korrelation wird zur manuellen Arbeit. Ein gutes Modell ist topologieorientiert: Region, PoP, Rolle, VRF/Tenant, Serviceklasse, Interfaceklasse und Owner sind Standardlabels.
- Topologie-Labels: Region, PoP, Site, Rolle (Core/Metro/Edge/Access), Device-Class.
- Service-Labels: VRF/Tenant, Produktklasse (Retail/Wholesale/Enterprise), QoS-Klasse.
- Pfad-Labels: Linkklasse (DCI, IXP, Transit), Provider/Peer, Circuit-ID, SRLG-Gruppe.
- Change-Labels: Version, Deployment-Welle, Maintenance-Window, Change-ID.
Designregel: Labels sind Teil der Architektur, nicht Deko
Wenn ein Incident eintritt, müssen Sie mit wenigen Filtern den betroffenen Scope isolieren können (z. B. „Region=West, Role=Edge, LinkClass=IXP“). Das gelingt nur, wenn Labels konsistent sind.
Normalisierung und Korrelation: Events, Metriken und Logs zusammenführen
Observability wird wertvoll, wenn Datenquellen zusammengeführt werden: Link down führt zu BGP withdraw, führt zu Pfadwechsel, führt zu Queue-Drops, führt zu Kundentickets. Ohne Korrelation bleibt jede Quelle isoliert. Ein Design sollte daher festlegen, welche IDs und Zeitstempel konsistent sind und wie Daten aufeinander gemappt werden.
- Zeitkonsistenz: NTP/PTP für Collector, Geräte und Logsysteme; sonst sind Korrelationen unzuverlässig.
- Gemeinsame Identitäten: Circuit-ID, Interface-ID, VRF-ID, Peer-AS, Change-ID als Join-Keys.
- Event-Taxonomie: Einheitliche Severity und Eventtypen (Link, Routing, Policy, Security, Platform).
- Topologie-Graph: Abbildung, welche Interfaces zu welchen Services/Peeringports gehören.
Ohne Zeitquellen gibt es keine Wahrheit
Viele „mysteriöse“ Incidents sind in Wirklichkeit Zeitprobleme: Logs sind versetzt, Events erscheinen in falscher Reihenfolge. Eine robuste Zeitarchitektur ist ein Kernbaustein von Observability-by-Design.
Security und Governance: Telemetry ist sensibel
Telemetry kann sensitive Informationen enthalten: Kundenbeziehungen, Traffic-Muster, IPs, Security-Events. Deshalb muss Observability-Architektur Security-by-Design enthalten: Segmentierung, Zugriffskontrollen, Datenminimierung, Retention und Audit. Außerdem muss geregelt sein, wer welche Daten sehen darf – insbesondere in Multi-Tenant-Umgebungen.
- Segmentierung: Telemetry-Pfade in Management-VRF/OOB, getrennt von Kundentraffic.
- Access Control: RBAC/ABAC, least privilege, getrennte Sichten für NOC/SOC/Engineering.
- Retention: Unterschiedliche Aufbewahrung für Metriken, Flows und Logs; Kosten und Compliance berücksichtigen.
- Auditability: Zugriffe und Exporte protokollieren; Änderungen an Alerting/Policies versionieren.
Ein häufiger Fehler: „Wir speichern alles für immer“
Das ist teuer und erhöht Risiko. Besser: klare Retention-Strategien pro Datentyp und pro Kritikalität, kombiniert mit Sampling und Triggern.
Observability in großen Netzen: Regionalisierung und Collector-Topologien
Wie bei BNG oder CGNAT skaliert Observability oft besser, wenn Collectors regionalisiert werden. Regionale Collectors reduzieren WAN-Last, begrenzen Failure Domains und ermöglichen lokales Buffering. Zentrale Systeme können dann konsolidieren und für Reporting/Analytics genutzt werden.
- Edge Collectors: Sammeln nahe an Routern/PoPs, puffern Peaks und kurzzeitige WAN-Störungen.
- Zentrale Aggregation: Konsolidiert und normalisiert, stellt Dashboards und langfristige Trends bereit.
- Backpressure-Strategie: Definieren, was bei Überlast passiert (drop, throttle, degrade), ohne Datenpfad zu gefährden.
- Disaster Mode: Im Incident sollen kritische Telemetry-Klassen priorisiert bleiben (Routing, Queue, Security).
Designregel: Observability-Domain braucht eigene Kapazitätsplanung
Collector und Storage sind Systeme mit Throughput und State: Events pro Sekunde, Flow-Records, Log-Bytes, Query-Last. Diese Kapazität muss wie ein Netzwerkservice dimensioniert werden.
Typische Fallstricke und wie man sie vermeidet
- Zu viele Daten, keine Aussage: Lösung: Use Cases priorisieren, Sampling-Strategien, klare SLOs.
- Telemetry bricht im Incident: Lösung: separate Pfade, QoS-Priorisierung, regionale Collectors und Buffering.
- Inkonsistente Labels: Lösung: Datenmodell mit Topologie-/Service-Labels, verpflichtend in Templates.
- Keine Korrelation: Lösung: Zeitkonsistenz, Join-Keys, Event-Taxonomie und Topologie-Graph.
- Microbursts unsichtbar: Lösung: höhere Granularität an Engpässen, Queue-Telemetry, gezielte Trigger-Captures.
- Security/Compliance ignoriert: Lösung: RBAC, Retention, Audit, Datenminimierung und Multi-Tenant-Sichten.
Praktische Leitlinien: Observability-by-Design mit Telemetry-Pfaden, Sampling und Datenmodellen
- Use Cases definieren: 5–10 Kernfragen (Pfadqualität, Congestion, Routing-Churn, DDoS, MTU) als Design-Driver.
- Telemetry-Pfade bauen: Management-VRF/OOB/Hybrid, priorisiert und redundant, damit Daten im Störfall verfügbar bleiben.
- Sampling mehrstufig: Metriken immer, Flows adaptiv, Logs selektiv/triggerbasiert, kritische Klassen bevorzugen.
- Engpässe fokussieren: DCI, IXP, Transit, Hub-Uplinks, BNG/CGNAT/Edge – dort höhere Granularität.
- Datenmodell standardisieren: Region/PoP/Rolle/VRF/Serviceklasse/Linkklasse/Owner als Pflichtlabels.
- Korrelation ermöglichen: Zeitarchitektur (NTP/PTP), gemeinsame IDs, Event-Taxonomie, Topologie-Graph.
- Regionalisieren: Edge Collectors mit Buffering, zentrale Aggregation für Langzeit-Analytics.
- Security by design: Segmentierung, RBAC/ABAC, Retention-Strategien, Audit und Multi-Tenant-Sichten.
- Evidence-by-Design: SLOs definieren, Vorher/Nachher messen, Changes mit Telemetry korrelieren.
