Streaming Telemetry: gNMI Pipelines in Telco Topologien integrieren

Streaming Telemetry mit gNMI (gRPC Network Management Interface) ist für viele Telcos der Schritt von „periodischem Polling“ hin zu echter Observability-by-Design. Statt alle paar Minuten per SNMP nach Zählerständen zu fragen, senden Geräte relevante Daten kontinuierlich an Collector- und Processing-Pipelines. Das klingt nach einem rein technischen Upgrade, ist in Telco-Topologien aber vor allem eine Architekturfrage: Wo laufen die Telemetry-Pfade? Wie werden gNMI-Subscriptions über Access, Metro, Core und Edge sicher und resilient transportiert? Wie verhindern Sie, dass Telemetry im Incident ausfällt oder die Control Plane belastet? Und wie schaffen Sie ein Datenmodell, das Geräte unterschiedlicher Hersteller, Rollen und Softwarestände konsistent abbildet? Eine gNMI-Pipeline ist dabei nicht nur „ein Collector“, sondern eine Kette aus Komponenten: Device Agents, Subscriptions (on-change oder sample), Stream-Transport, Collector/Proxy, Normalisierung (OpenConfig und vendor-spezifische Modelle), Enrichment (Topologie-Labels), Storage/Analytics und Alerting/SLO-Engines. Wenn diese Kette nicht topologisch integriert ist, entstehen typische Probleme: Telemetry-Lücken in der Fläche, zu viele Streams auf dem falschen Interface, unkontrollierte Datenmengen, inkonsistente Namensräume und eine Observability, die im N-1-Betrieb nicht mehr stimmt. Dieser Artikel zeigt, wie Sie Streaming Telemetry und gNMI Pipelines in Telco-Topologien so integrieren, dass sie skalieren, sicher sind und im Betrieb tatsächlich helfen – statt neue Komplexität zu erzeugen.

gNMI in einem Satz: Warum Streaming Telemetry anders ist als Polling

gNMI liefert Telemetry als Stream: Geräte pushen Daten in definierter Granularität oder bei Änderungen. Das bringt drei Vorteile: höhere zeitliche Auflösung (wichtig für Microbursts und kurze Loss-Spikes), weniger Polling-Overhead auf Geräten, und die Möglichkeit, Telemetry dynamisch zu steuern (Subscriptions anpassen, gezielt „hochdrehen“). Gleichzeitig macht Streaming Telemetry die Pipeline selbst zu einer kritischen Infrastruktur – inklusive Backpressure, Buffering und Security.

• Sample: Periodische Werte in hoher Frequenz (z. B. 1s oder 10s), ideal für Queue-Drops und Portauslastung.
• On-change: Events bei Zustandsänderung (z. B. Interface up/down, BFD state), ideal für Korrelation.
• Targeted: Nur relevante Pfade/Modelle streamen, statt „alles“ zu poll-en.
• Bidirektional steuerbar: Subscriptions können je nach Bedarf angepasst werden (normal vs. incident mode).

Leitprinzip: Streaming Telemetry ist ein Service – behandeln Sie ihn wie einen

Wenn Telemetry für Betrieb und SLA relevant ist, muss die Pipeline N-1-fähig, segmentiert und beobachtbar sein. „Best effort Telemetry“ endet oft genau dann, wenn sie gebraucht wird.

Telco-Topologien als Telemetry-Landkarte: Access, Metro, Core, Edge

Eine gNMI-Integration muss die Telco-Hierarchie respektieren. In Access-Standorten sind Bandbreite und Betriebsmöglichkeiten begrenzt, in Metro-Hubs gibt es natürliche Aggregationspunkte, der Core soll state-arm bleiben, und an der Edge sind die wichtigsten „Policy Points“ (Peering, Transit, CGNAT, BNG, DDoS) konzentriert. Daraus folgt: Die Telemetry-Pipeline sollte regionalisiert werden.

• Access: Viele Geräte, geringe lokale Ressourcen; Telemetry-Frequenzen und Pfade müssen effizient sein.
• Metro: Ideale Standorte für regionale Collectors/Proxies, Buffering und Datenaggregation.
• Core: Telemetry wichtig, aber sparsam und standardisiert; Core darf nicht durch Telemetry-Overhead destabilisiert werden.
• Edge: Höchster Nutzen für gNMI: Interconnect-Ports, Queue-Drops, DDoS-Indikatoren, Service-Edges.

Designregel: Telemetry folgt der Topologie – nicht umgekehrt

Wenn Sie alle Geräte zentral streamen lassen, erzeugen Sie WAN-Last, große Failure Domains und hohe Abhängigkeit von zentralen Systemen. Regionale gNMI-Proxies reduzieren Risiko und Kosten.

Pipeline-Bausteine: Von gNMI Target bis Analytics

Eine robuste gNMI-Architektur besteht aus wiederholbaren Komponenten. Der wichtigste Schritt ist, diese Komponenten als Blueprint zu definieren, damit jede Region gleich funktioniert.

• Targets: Router/Switches/CNFs, die gNMI sprechen und OpenConfig bzw. vendor-Modelle liefern.
• Subscriptions: Vordefinierte „Telemetry Profiles“ pro Rolle (Core/Metro/Edge/BNG/CGNAT).
• Collector/Proxy: Nimmt Streams an, terminiert TLS, puffert, normalisiert und leitet weiter.
• Normalization: OpenConfig als Basis, vendor-spezifische Abweichungen werden gemappt.
• Enrichment: Labels (Region, PoP, Rolle, VRF, Linkklasse) aus Inventar/IPAM/CMDB hinzufügen.
• Storage: Time-Series (Metriken), Event-Store, ggf. Data Lake für Langzeit/ML.
• Alerting/SLO: Regeln und SLO-Engines, die aus Telemetry messbare Servicequalität machen.

Die wichtigste Pipeline-Frage: Wo wird normalisiert?

Normalisierung direkt im Collector reduziert Downstream-Komplexität, erhöht aber Collector-Last. Normalisierung zentral vereinfacht Collectors, erhöht aber WAN-Volumen und kann Failure Domains vergrößern. Viele Telcos wählen einen Hybrid: regionales Pre-Processing plus zentrale Konsolidierung.

Telemetry-Pfade und Netzsegmentierung: Management-VRF, OOB und Security Domains

Streaming Telemetry muss sicher und stabil transportiert werden. In Telco-Netzen ist der Standardansatz eine Management-VRF (In-Band) oder OOB, ergänzt durch Jump-Zones und strikte Zugriffskontrollen. Wichtig ist: Telemetry darf nicht an zufälligen Kundendiensten hängen und sollte QoS-priorisiert sein, damit Congestion nicht die Sichtbarkeit zerstört.

• In-Band via Management-VRF: Praktisch und skalierbar, wenn strikt segmentiert und priorisiert.
• OOB in zentralen PoPs: Hohe Resilienz, sinnvoll für Core/Edge-Standorte.
• TLS/mTLS: gNMI sollte über TLS laufen; Zertifikatsmanagement (PKI) ist Teil des Designs.
• RBAC/ABAC: Wer darf welche Geräte/Streams konfigurieren und sehen?
• CoPP/Rate-Limits: Schutz der Control Plane gegen Telemetry-Misconfig (zu viele Streams).

Designregel: Telemetry braucht eine eigene „Trust Boundary“

Gerätezugriffe und Telemetry-Streams sind hochsensibel. Sie sollten in einer klaren Security Domain laufen, getrennt von Customer VRFs und getrennt von Internet/Peering-Zonen.

Subscription-Design: Rollenbasierte Telemetry-Profile statt „alles streamen“

Der häufigste Fehler bei gNMI ist Oversharing: zu viele Pfade, zu hohe Frequenz, zu viele Targets. Das führt zu Datenfluten und belastet Geräte und Pipeline. Besser ist ein rollenbasiertes Profilmodell: Jede Geräteklasse bekommt ein vordefiniertes Set an Subscriptions mit klaren Samplingraten und Prioritäten.

• Core Profile: Interface/optics, IGP/BGP Health, CPU/Memory, wenige Queue-Stats an echten Engpässen.
• Metro Profile: Queue-Drops und Microburst-Indicators, LAG-Member-Sicht, BFD/FRR Events.
• Edge Profile: IXP/PNI/Transit Ports, Queue per Klasse, BGP Session/Prefix-Counts, DDoS-relevante Zähler.
• Service Edge Profile: BNG/CGNAT Session-State, Policy-Hits, Drop-Reasons, Raten (CPS/PPS, je nach Plattform).

Ein praktikabler Ansatz: Normal Mode vs. Incident Mode

Im Normalbetrieb sind Samplingraten moderat und die Pfade fokussiert. Bei Anomalien kann die Pipeline gezielt „hochdrehen“: höhere Frequenz für betroffene Interfaces/Queues, zusätzliche Pfade für kurze Zeitfenster, dann wieder zurück. Das reduziert Kosten und verbessert Detailtiefe im Incident.

Sampling und Granularität: Microbursts sichtbar machen, ohne zu explodieren

Telco-Netze leiden oft unter Microbursts, kurzen Congestion-Spitzen und transienten Drops. Diese Ereignisse verschwinden in 1- oder 5-Minuten-Averages. gNMI ermöglicht deutlich feinere Granularität (Sekundenbereich), aber nicht überall. Deshalb muss Granularität topologieorientiert geplant werden: hoch an Choke Points, moderat im Core, sparsam im Access.

• Choke Points hoch: Edge-Ports, Hub-Uplinks, DCI-Links, Interconnects – hier bringt 1s bis 10s oft echten Mehrwert.
• Core moderat: 10s bis 60s, fokus auf Health und Trends statt auf jede Queue.
• Access sparsam: Gröbere Intervalle, wenige Pfade, da hohe Geräteanzahl sonst Volumen explodiert.
• Event-driven ergänzen: On-change für Zustände (BFD, Link, BGP) statt hohe Poll-Frequenz.

Designregel: Granularität folgt dem Engpassrisiko

Wenn ein Link nie Congestion sieht, ist 1s Queue-Telemetry meist Verschwendung. Wenn ein IXP-Port regelmäßig microburstet, ist 1s oft Gold wert. Diese Priorisierung ist Observability-by-Design.

Datenmodelle: OpenConfig, Vendor-Modelle und Normalisierung

gNMI ist ein Transport- und API-Mechanismus. Der Wert entsteht durch das Datenmodell. In heterogenen Telco-Netzen ist OpenConfig oft der gemeinsame Nenner, aber nicht alles ist dort abgedeckt oder identisch implementiert. Sie brauchen daher ein Normalisierungsmodell, das Unterschiede glättet, Einheiten standardisiert und Namespaces konsistent macht.

• OpenConfig als Baseline: Interface, optics, BGP, System, QoS/Queues (je nach Plattform) – als standardisierte Pfade.
• Vendor Extensions: Ergänzen Lücken (z. B. spezielle Hardware-Counter, MPLS/SR Telemetry, NAT Counters).
• Einheiten/Skalierung: Bytes vs. Bits, Counter Wrap, Poll-Interval-Abhängigkeiten – müssen vereinheitlicht werden.
• Mapping-Layer: Übersetzt vendor-spezifische Pfade in ein internes Kanonisches Modell.

Ohne kanonisches Modell wird Multi-Vendor-Observability teuer

Wenn jedes Dashboard pro Hersteller anders gebaut werden muss, skaliert Betrieb nicht. Ein kanonisches Modell plus Mapping ist der OPEX-Reduzierer.

Enrichment: Telemetry erst durch Labels operativ nutzbar machen

In Telco-Topologien brauchen Sie Kontext: Region, PoP, Rolle, Linkklasse (IXP/PNI/Transit/DCI), VRF/Tenant, Serviceklasse. Diese Metadaten kommen nicht immer aus dem Gerät – sie kommen aus Inventar, IPAM oder CMDB. Deshalb gehört Enrichment als fester Pipeline-Schritt in das Design.

• Topologie-Labels: Region, PoP, Site, Rolle (Core/Metro/Edge/Access), Device-Class.
• Link-Labels: Linkklasse, Provider/Peer, Circuit-ID, SRLG-Gruppe, Port-Geschwindigkeit.
• Service-Labels: VRF/Tenant, Produktklasse (Retail/Wholesale/Enterprise), QoS-Klasse.
• Change-Labels: Change-ID, Deployment-Welle, Maintenance-Window für Vorher/Nachher.

Designregel: Enrichment muss automatisiert sein

Manuelle Tagpflege führt zu Drift. Gute Pipelines ziehen Metadaten aus Systemen of Record und erzwingen Naming-Standards.

Resilienz der Pipeline: Regionalisierung, Buffering und Backpressure

Streaming Telemetry erzeugt kontinuierliche Daten. In großen Netzen sind Collector-Ausfälle, WAN-Probleme oder Storage-Engpässe unvermeidbar. Die Pipeline muss daher degradieren können, ohne komplett auszufallen. Regionale Collectors mit Buffering, klare Backpressure-Regeln und Priorisierung kritischer Streams sind zentrale Designprinzipien.

• Regionale Collector-Cluster: Begrenzen Failure Domains und reduzieren WAN-Abhängigkeit.
• Buffering: Kurzzeitige Storage-/WAN-Probleme überbrücken; definierte maximale Bufferzeit.
• Backpressure-Policy: Was wird bei Überlast gedrosselt? Welche Streams sind „Tier 1“ (Routing/Queue) vs. „Tier 2“ (Detailcounters)?
• Disaster Mode: Im Incident bleiben kritische Streams priorisiert; Detaildaten werden temporär reduziert.

Eine wichtige Erkenntnis: Telemetry hat eigene SLOs

Wenn Ihr Betrieb von gNMI abhängt, brauchen Sie SLOs für die Telemetry-Pipeline selbst: Drop-Raten, Latenz, Verfügbarkeit der Streams, Collector-Health und Datenlücken.

Betriebsimpact: Teams, Runbooks und Change-Governance

gNMI ist nicht nur Technik, sondern ein Betriebsmodell. Sie brauchen klare Zuständigkeiten: Wer definiert Telemetry-Profile? Wer ändert Samplingraten? Wer betreibt PKI/Zertifikate? Und wie werden Changes an Telemetry-Subscriptions getestet, damit nicht aus Versehen tausende Geräte überlastet werden?

• Telemetry Profiles als Code: Versionierte Subscriptions pro Rolle, reviewed und getestet.
• Change-Prozess: Wellen-Rollout, Rollback-Kriterien, Canary-Targets, um Risiko zu minimieren.
• Runbooks: Vorgehen bei Datenlücken, Collector-Ausfall, Template-Drift, Zertifikatsproblemen.
• Cross-Team Alignment: NOC/SOC/NetEng/Platform müssen ein gemeinsames Datenmodell und Begriffe nutzen.

Ein typischer Fehler: Telemetry-Änderungen ohne Tests

Ein „kleines“ Subscription-Update kann die Exportlast verdoppeln. Deshalb müssen Telemetry-Changes wie Netzwerk-Changes behandelt werden: Review, Test, Wellen, Monitoring.

Typische Fallstricke und wie man sie vermeidet

• Zu viele Streams, zu hohe Frequenz: Lösung: Rollenprofile, Prioritäten, Normal/Incident Mode.
• Multi-Vendor Chaos: Lösung: OpenConfig-Baseline, kanonisches Datenmodell, Mapping-Layer.
• Telemetry fällt im Incident aus: Lösung: Management-VRF/OOB/Hybrid, QoS-Priorisierung, regionale Collectors, Buffering.
• Keine Labels, keine Korrelation: Lösung: automatisches Enrichment (Region/PoP/Rolle/Linkklasse/VRF/Change-ID).
• Collector überlastet: Lösung: Kapazitätsplanung, Backpressure-Policy, Tiered Streams.
• Zertifikats-/Auth-Probleme: Lösung: PKI-Prozesse, Rotation, Monitoring und klare Runbooks.

Praktische Leitlinien: gNMI Pipelines in Telco Topologien integrieren

• Topologieorientiert designen: Access sparsam, Metro als Collector-Hub, Edge mit hoher Detailtiefe, Core stabil und standardisiert.
• Telemetry-Domain bauen: Management-VRF/OOB/Hybrid, QoS-Priorisierung und Security Boundary mit mTLS/PKI.
• Rollenbasierte Subscriptions: Telemetry-Profile pro Gerätekategorie, Normal/Incident Mode und klare Prioritäten.
• Datenmodell vereinheitlichen: OpenConfig als Baseline, vendor Extensions gezielt, kanonisches Modell und Mapping.
• Enrichment automatisieren: Region/PoP/Rolle/Linkklasse/VRF/Serviceklasse/Circuit-ID als Pflichtlabels.
• Pipeline regionalisieren: Collector-Cluster pro Region mit Buffering, zentrale Aggregation für Langzeit und Analytics.
• Backpressure definieren: Tiered Streams, klare Regeln bei Überlast, Telemetry-SLOs für die Pipeline selbst.
• Governance etablieren: Profiles-as-Code, Change-Reviews, Canary-Rollouts, Runbooks und Auditability.
• Evidence-by-Design: Pfadqualität, Queue-Drops, Routing-Events und Changes korrelieren; Vorher/Nachher messbar machen.