Site icon bintorosoft.com

Monitoring SLOs: Verfügbarkeit und Latenz topologisch messbar machen

Red Snapper

Engineer looking to work in the electrical control room. Neural network AI generated art

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).

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.

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.

Ein praktikables Availability-SLI

Availability= good_minutes 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.

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.

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.

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.

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.

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.

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).

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

Praktische Leitlinien: Verfügbarkeit und Latenz topologisch messbar machen

Exit mobile version