Monitoring SLOs: Verfügbarkeit und Latenz topologisch messbar machen

Monitoring SLOs (Service Level Objectives) machen aus „wir überwachen das Netz“ eine belastbare Aussage darüber, ob ein Service die erwartete Qualität liefert. Besonders in Telco- und Provider-Topologien reicht es nicht, nur Geräte- oder Linkstatus zu prüfen. Ein Link kann „up“ sein und trotzdem schlecht performen, weil Congestion, Microbursts, asymmetrische Pfade oder fehlerhafte Route Policies Latenz und Loss verschlechtern. Gleichzeitig sind SLOs nur dann sinnvoll, wenn sie topologisch definiert sind: Verfügbarkeit und Latenz müssen entlang realer Servicepfade messbar werden – über Access, Metro, Core, Edge und Interconnect hinweg, inklusive Failoverpfaden. Genau hier scheitern viele Ansätze: SLOs werden zu global und zu abstrakt („99,9% Netzverfügbarkeit“), oder zu technisch („SNMP Interface up/down“), ohne Bezug zum Kundenerlebnis. Ein professionelles Design übersetzt SLOs in Messpunkte und Datenmodelle: Welche Pfade bilden einen Service? Wo liegt die Servicekante (BNG/PE/Internet Edge)? Welche Linkklassen (IXP/PNI/Transit/DCI) sind involviert? Welche Regionen/PoPs gehören dazu? Und wie unterscheiden sich Normalbetrieb und N-1? Dieser Artikel zeigt praxisnah, wie Sie Verfügbarkeit und Latenz topologisch messbar machen – mit klaren SLI-Definitionen, sinnvoller Probe-Platzierung, robusten Telemetry-Pfaden und einer SLO-Governance, die Betrieb und Engineering wirklich steuert.

SLO, SLI, SLA: Die Begriffe sauber trennen, bevor man misst

Damit Monitoring nicht in Diskussionen endet, müssen die Begriffe klar sein. Ein SLO ist ein Zielwert, ein SLI ist die Messgröße, und ein SLA ist ein vertraglicher Rahmen, der oft zusätzliche Regeln (Messfenster, Ausschlüsse) enthält. Ohne diese Trennung werden SLOs schnell entweder „zu weich“ (Marketing) oder „zu hart“ (technische Einzelmetriken ohne Servicebezug).

• SLI (Indicator): Messgröße, z. B. Paketverlustrate auf einem Pfad, Round-Trip-Latenz, Erfolgsrate einer DNS-Query.
• SLO (Objective): Ziel, z. B. „99,95% Erreichbarkeit pro Monat“ oder „p95 Latenz < 20 ms regional“.
• SLA (Agreement): Vertraglich zugesicherte Ziele inklusive Messmethode, Wartungsfenster, Force-Majeure-Regeln.
• Error Budget: Erlaubte Abweichung vom SLO; ein Steuerungsinstrument für Changes und Risiko.

Leitprinzip: SLOs brauchen einen klaren Service-Scope

„Das Netz“ ist kein Service. Ein Service ist z. B. „Retail Internet Region X“, „Enterprise L3VPN Kunde Y“, „Mobile Backhaul Cluster Z“ oder „IXP Peering Region West“. Der Scope bestimmt, welche Topologie und welche Messpunkte relevant sind.

Topologie als Grundlage: Servicepfade definieren, bevor man SLOs baut

Ein SLO ist nur so gut wie sein Pfadmodell. In Telco-Topologien gibt es selten „den einen Pfad“. Es gibt Pfadsets: Normalpfade, ECMP-Pfade, TE-Pfade, Failoverpfade. SLO-Design beginnt daher mit einer topologischen Zerlegung in Rollen und Linkklassen. Erst wenn Sie diese Bausteine sauber modellieren, können Sie sinnvolle Messpunkte definieren.

• Rollen: Access, Metro, Core, Edge, Service Edge (BNG/CGNAT/PE), Interconnect (IXP/PNI/Transit).
• Linkklassen: Access-Uplink, Metro-Uplink, DCI, IXP-Port, PNI, Transit-Uplink, Cross-Region.
• Failure Domains: Ringsegment, Hub-Cluster, PoP, Region, Provider, Facility, Shared Risk (SRLG).
• Servicekanten: Wo endet „der Service“? Beispielsweise am BNG (Subscriber Edge) oder am Internet Edge.

Designregel: SLOs folgen der Topologiehierarchie

Ein sinnvoller SLO-Satz ist hierarchisch: Komponenten-SLOs (Links/PoPs) speisen Pfad-SLOs (Region->Edge), und diese speisen Service-SLOs (Kunde/Produkt). So bleibt die Ursachenanalyse möglich.

Verfügbarkeit messbar machen: „Up“ ist nicht gleich „available“

Verfügbarkeit im SLO-Sinn bedeutet typischerweise: „Kann der Kunde den Service nutzen?“ Das ist mehr als Interface-Status. Ein Router kann erreichbar sein, aber Routing kann falsch sein. BGP kann „established“ sein, aber Prefixe fehlen. Ein IXP-Port kann up sein, aber die Fabric droppt. Deshalb ist Verfügbarkeit als SLI oft eine Kombination aus Zustands- und Funktionsprüfungen.

• Control-Plane Availability: BGP/IGP Nachbarschaften stabil, erwartete Prefix-Counts innerhalb Grenzen, keine Leak-Indikatoren.
• Data-Plane Availability: Synthetische Probes erreichen Ziele (ICMP/UDP/TCP), ohne ungewöhnlichen Loss.
• Service-Funktion: DNS-Resolution, HTTP(S) Handshake, PPPoE/DHCP Erfolgsrate, je nach Service.
• Path Continuity: Failover funktioniert; N-1 Pfade sind erreichbar und nicht blackholed (MTU/Policy).

Ein praktikables Availability-SLI

$\mathrm{Availability}=\frac{\mathrm{good\_minutes}}{\mathrm{total\_minutes}}$

„Good minutes“ sind Minuten, in denen definierte Data-Plane-Probes erfolgreich sind und die wichtigsten Control-Plane-Guardrails (z. B. Prefix-Count nicht massiv abweichend) erfüllt sind. Damit wird „up aber kaputt“ sichtbar.

Latenz-SLOs definieren: Mittelwerte vermeiden, Perzentile nutzen

Latenz in Telco-Topologien ist selten konstant. Routingänderungen, Congestion, Queueing und Pfadwechsel erzeugen Spikes. Ein Durchschnittswert kann „gut“ aussehen, obwohl Nutzer regelmäßig Probleme erleben. Deshalb sollten Latenz-SLOs mit Perzentilen (p95/p99) und mit klaren Messfenstern definiert werden. Außerdem muss zwischen Round-Trip (RTT) und One-Way (OWD) unterschieden werden, je nach Use Case und Timing-Infrastruktur.

• p95/p99 statt Average: Spikes werden sichtbar; SLOs spiegeln Nutzererlebnis besser.
• Regionale Budgets: Latenzbudgets hängen von Geografie und Topologie ab; ein globaler Wert ist oft unrealistisch.
• One-Way vs. RTT: One-Way erfordert saubere Zeitquellen; RTT ist einfacher, aber weniger diagnostisch.
• Jitter als Ergänzung: Für Echtzeitdienste ist Jitter oft wichtiger als reiner Mittelwert.

Designregel: Latenz-SLOs müssen Pfadklassen berücksichtigen

Ein IXP-Pfad hat andere Eigenschaften als ein Transitpfad, ein regionaler Pfad andere als ein cross-country Pfad. Definieren Sie SLOs pro Pfadklasse oder Serviceklasse, nicht als Einheitswert.

Messpunkt-Platzierung: Wo Probes und Telemetry-Sensoren sitzen sollten

Damit SLOs topologisch messbar sind, brauchen Sie Messpunkte an den richtigen Orten. In Telco-Topologien sind das typischerweise: an den Servicekanten (BNG/PE/Internet Edge), in regionalen PoPs, an Interconnect-Ports und an kritischen Engpässen (Hub-Uplinks, DCI). Messpunkte können aktiv (synthetische Probes) oder passiv (Queue-Drops, Interface-Stats, Streaming Telemetry) sein. Der Schlüssel ist, Messpunkte so zu platzieren, dass sie Pfadwechsel und Failure Domains abbilden.

• Edge-Probes: Von Internet Edge zu Referenzzielen (Content/CDN/DNS) und zwischen Regionen, um Exit-Qualität zu messen.
• PoP-Probes: Zwischen Metro-Hubs, um regionale Pfadqualität zu erfassen und Hairpinning zu erkennen.
• Service-Edge-Probes: BNG/CGNAT/Firewall-Kanten, um Serviceketten-Effekte sichtbar zu machen.
• Interconnect-Sensoren: Queue-Drops und Portauslastung auf IXP/PNI/Transit; hier entstehen viele Nutzerprobleme.

Anti-Pattern: Probes nur im Core

Core-Messpunkte zeigen oft nicht, ob ein Problem im Peering, Transit oder in einer Servicekette liegt. Für Service-SLOs sind Edge- und Interconnect-Messpunkte meist wertvoller.

SLI-Design: Welche Messgrößen Verfügbarkeit und Latenz wirklich erklären

Ein SLO wird operativ nützlich, wenn der SLI nicht nur misst, sondern auch diagnostisch ist. Für Verfügbarkeit und Latenz haben sich bestimmte SLIs bewährt, die sich gut auf Topologie und Failure Domains mappen lassen.

• Probe Success Rate: Erfolgsrate synthetischer Checks (ICMP/UDP/TCP/DNS/HTTP) pro Pfadklasse und Region.
• RTT p95/p99: Perzentile pro Pfadklasse und Zeitfenster (z. B. 5-min Buckets für Spikes).
• Packet Loss: Loss pro Pfad/Probe, korrelierbar mit Queue-Drops und Congestion.
• Queue Drop Rate: Drops pro Klasse an Engpässen; trennt „Kapazitätsproblem“ von „Routingproblem“.
• Routing Health: BGP Session Health, Prefix-Counts, Withdraw-Rate, FRR-Aktivierungen.

Designregel: Ein SLO braucht ein „Why“-Signal

Wenn ein SLO verletzt wird, müssen Sie schnell sehen, ob es ein Pfadwechsel (Routing), ein Engpass (Queue), ein Servicekettenproblem (Firewall/CGNAT) oder ein Interconnect-Problem (IXP/Transit) ist. Das gelingt durch die Kombination aus Probes und Telemetry.

Normalbetrieb vs. N-1: SLOs müssen Failoverpfade einschließen

Viele Netze sind redundant, aber die Messung ist es nicht. Ein klassischer Fehler: SLOs werden nur im Normalpfad geprüft. Im Failover entstehen dann überraschende Probleme: Umwege erhöhen Latenz, ein Backup-Link ist überlastet, MTU ist kleiner, oder Policies sind anders. Observability-by-Design bedeutet, SLOs explizit für N-1 zu validieren.

• Failover-Szenarien definieren: Link down, PoP down, IXP-Fabric-Problem, Transit-Ausfall, DCI-Ausfall.
• Failover-Probes: Messpunkte, die Pfadwechsel erkennen und separat als „Failover Mode“ taggen können.
• N-1 Headroom: Kapazitätsreserven müssen SLO-konform sein, sonst ist Redundanz nur „up“.
• MTU/PMTUD Checks: Blackhole Prevention als Teil der Availability-SLIs, besonders in Overlays.

Ein praktisches Vorgehen

Planen Sie regelmäßige Failover-Tests (geplante Wartungsdrains) und messen Sie dabei die SLO-SLIs. So wird Failover zu einer kontrollierten Übung statt zu einer Überraschung.

Datenmodelle und Labels: Topologisch auswertbare SLOs brauchen Kontext

Damit SLOs nicht nur „eine Zahl“ sind, müssen SLIs mit Metadaten versehen werden: Region, PoP, Rolle, Linkklasse, VRF/Serviceklasse, Provider/Peer. Ohne diese Labels können Sie nicht schnell segmentieren, welche Kunden/Regionen betroffen sind oder welcher Interconnect die Ursache ist.

• Topologie-Labels: Region, PoP, Site, Rolle (Edge/Metro/Core/Service Edge).
• Link-Labels: Linkklasse (IXP/PNI/Transit/DCI), Circuit-ID, SRLG-Gruppe.
• Service-Labels: Produktklasse (Retail/Wholesale/Enterprise), VRF/Tenant, QoS-Klasse.
• Change-Labels: Change-ID, Maintenance-Window, Deployment-Welle für Vorher/Nachher-Analysen.

Designregel: Labels müssen automatisch erzeugt werden

Manuelle Tagpflege skaliert nicht. Nutzen Sie Inventar/IPAM/CMDB und Naming-Konventionen, um Labels konsistent und auditierbar zu erzeugen.

Error Budgets: SLOs als Steuerungsinstrument für Changes und Risiko

SLOs entfalten ihren Nutzen, wenn sie Entscheidungen steuern: Wann kann ein riskanter Change ausgerollt werden? Wann muss Kapazität erweitert werden? Wann ist eine Region zu instabil für zusätzliche Umbauten? Error Budgets übersetzen SLO-Abweichungen in operative Regeln. Das ist besonders in Telco-Topologien wichtig, weil viele Änderungen in Wellen erfolgen und weil „kleine“ Policy-Änderungen große Effekte haben können.

• Change Guardrails: Wenn Error Budget fast verbraucht ist, werden riskante Changes gebremst oder verschoben.
• Kapazitäts-Trigger: Wiederkehrende Latenz-/Loss-Verletzungen an Linkklassen (IXP/Transit) triggern Upgrades.
• Priorisierung: Regionen/Services mit schlechtem SLO bekommen Engineering-Fokus und Root-Cause-Initiativen.
• Kommunikation: SLOs schaffen eine gemeinsame Sprache zwischen NOC, Engineering und Management.

Ein häufiger Fehler: SLOs ohne Konsequenzen

Wenn SLO-Verletzungen keine Entscheidungen beeinflussen, werden sie zu Dashboards ohne Wirkung. Definieren Sie deshalb klare Regeln, wie Error Budgets Changes und Kapazitätsplanung beeinflussen.

Alerting: Von Symptomen zu sinnvollen Alarmen

Alerting sollte SLO-orientiert sein: nicht jeder einzelne Link-Error, sondern SLO-relevante Auswirkungen. Gleichzeitig brauchen Sie diagnostische Alerts, die Ursachen liefern: Queue-Drops, BGP-Flaps, Interconnect-Congestion. Eine gute Praxis ist zweistufig: SLO-Alerts (Impact) plus Root-Cause-Alerts (Ursache).

• SLO-Alerts: Probe Success Rate unter Schwelle, RTT p95/p99 über Budget, regionale Anomalien.
• Root-Cause-Alerts: Queue-Drops, Interface Errors, BGP Session Resets, Prefix-Count Anomalien.
• Dedup/Korrelation: Ein Incident soll nicht 500 Alarme erzeugen; Korrelation nach Region/PoP/Linkklasse.
• Runbook-Verknüpfung: Jeder Alert hat eine klare Handlung: messen, umleiten, drosseln, eskalieren, testen.

Designregel: Alerts müssen topologisch gruppieren

Wenn ein IXP-Fabric Problem 200 Ports betrifft, brauchen Sie einen „IXP Region West degraded“-Alert mit Drilldown – nicht 200 einzelne Port-Alarme.

Typische Fallstricke und wie man sie vermeidet

• „Up/Down“ als Availability: Lösung: Data-Plane-Probes + Control-Plane-Guardrails als Availability-SLI.
• Durchschnittslatenz: Lösung: p95/p99, kurze Buckets an Engpässen, Jitter ergänzen.
• Keine Failover-Messung: Lösung: N-1 Tests, Failover-Probes, MTU/PMTUD Checks, Headroom-Regeln.
• Keine Labels/Scope: Lösung: Topologie-Labels, Linkklassen, Serviceklassen, automatische Enrichment-Pipeline.
• Alert-Sturm: Lösung: SLO-First Alerting, Korrelation, Dedup, klare Runbooks.
• SLOs ohne Governance: Lösung: Error Budgets mit Change- und Kapazitätsregeln verbinden.

Praktische Leitlinien: Verfügbarkeit und Latenz topologisch messbar machen

• Service-Scope definieren: SLOs pro Produkt/Region/VRF statt „Netz insgesamt“.
• Pfadmodell bauen: Rollen, Linkklassen, Failure Domains und Servicekanten dokumentieren und versionieren.
• SLIs kombinieren: Probes (Data Plane) + Routing Health (Control Plane) + Queue/Port Telemetry (Engpässe).
• Messpunkte richtig platzieren: Edge/Interconnect/Service-Edges priorisieren, Core nur ergänzend.
• Perzentile nutzen: p95/p99 Latenz statt Mittelwerte; Jitter und Loss als Ergänzung.
• N-1 einbeziehen: Failoverpfade messen, Headroom und MTU/PMTUD validieren, regelmäßige Tests.
• Datenmodell standardisieren: Region/PoP/Rolle/Linkklasse/Serviceklasse/Change-ID als Pflichtlabels, automatisiert.
• Error Budgets etablieren: SLOs als Steuerung für Changes, Wartungen und Kapazitätsentscheidungen nutzen.
• Alerting zweistufig: Impact (SLO) + Ursache (Queue/BGP/Port) mit topologischer Korrelation und Runbooks.