Hinweis: Dies ist ein Demo-Beitrag als Platzhalter für den Blog-Aufbau. Er kann jederzeit gelöscht werden.
SNMP begleitet Netzwerkbetrieb seit über drei Jahrzehnten und ist in den meisten NOCs immer noch das Rückgrat des Monitorings. Doch mit wachsender Portdichte, Overlay-Netzen, softwaredefinierten Fabrics und dem Anspruch auf Echtzeit-Sichtbarkeit stößt das klassische Poll-Modell an harte Grenzen. Streaming-Telemetrie verspricht den nächsten Schritt: Geräte senden Zustandsdaten proaktiv, statt auf Nachfrage zu warten. Dieser Artikel ordnet ein, was sich technisch ändert, wo der Umstieg lohnt und wo SNMP noch lange seinen Platz behält.
Grenzen von SNMP-Polling
SNMP arbeitet nach dem Pull-Prinzip: Ein Manager fragt in festen Intervallen – meist 30 bis 300 Sekunden – Werte per GET oder GETBULK ab. Für Interface-Zähler, CPU-Last oder Fanstatus reicht das oft aus, für Mikro-Bursts, kurzlebige Queue-Drops oder transiente BGP-Flaps aber nicht. Alles, was zwischen zwei Polling-Zyklen passiert, ist schlicht unsichtbar.
Hinzu kommt die Skalierungsfrage: Je mehr Geräte, Interfaces und OIDs überwacht werden, desto mehr Polling-Last erzeugt das gleichzeitig auf Manager und Agent-CPU. MIB-Walks sind teuer, GETBULK-Antworten werden bei großen Tabellen fragmentiert, und viele Boxen drosseln SNMP bewusst, um die Control-Plane zu schützen. Das Ergebnis ist ein strukturell limitiertes Auflösungsvermögen, das sich nicht beliebig durch kürzere Intervalle kompensieren lässt.
Streaming-Telemetrie: Das Push-Prinzip
Streaming-Telemetrie dreht das Modell um: Das Netzwerkgerät sendet Daten selbstständig und kontinuierlich an einen oder mehrere Collector, sobald sich Werte ändern oder ein definiertes Zeitfenster abläuft. Es gibt keine Request-Response-Runde mehr pro Datenpunkt, sondern einen dauerhaften, effizienten Datenstrom. Das reduziert Overhead auf beiden Seiten und macht Subsekunden-Auflösung praktikabel, ohne die Control-Plane des Geräts zu überlasten.
Für den Netzwerkbetrieb bedeutet das eine fundamentale Verschiebung von reaktivem „Nachschauen“ hin zu kontinuierlicher Beobachtung – die Grundlage für alles, was danach an Automatisierung und Anomalie-Erkennung aufgebaut wird.
gRPC, gNMI und YANG: Model-Driven Telemetry
Technisch basiert moderne Streaming-Telemetrie meist auf gRPC als Transport und gNMI (gRPC Network Management Interface) als Management-Protokoll. gNMI vereint dabei Konfiguration, State-Abfrage und Subscription für kontinuierliche Datenströme in einer einzigen Schnittstelle – ein deutlicher Unterschied zur SNMP-Welt mit getrennten Mechanismen für Config (oft CLI/NETCONF) und Monitoring.
gNMI als Transportprotokoll
gNMI nutzt Protocol Buffers statt ASN.1/BER, was kompaktere, schneller zu parsende Nachrichten erzeugt. Subscriptions lassen sich als „Sample“ (periodisch), „On-Change“ (nur bei Änderung) oder „Target-Defined“ konfigurieren – der Collector bekommt also genau die Granularität, die er braucht, und nicht mehr.
YANG-Datenmodelle als gemeinsame Sprache
Model-Driven Telemetry bedeutet, dass Datenstrukturen über YANG-Modelle definiert sind – standardisiert (OpenConfig, IETF) oder herstellerspezifisch. Das schafft eine maschinenlesbare, versionierbare Struktur statt der oft kryptischen, herstellerspezifischen OID-Bäume von SNMP, und erleichtert Automatisierung erheblich.
Höhere Auflösung, geringere Latenz
Wo SNMP typischerweise Minuten-Granularität liefert, sind bei Streaming-Telemetrie Intervalle im Sekunden- oder sogar Subsekundenbereich realistisch, ohne die Geräte-CPU nennenswert zu belasten. Für Kapazitätsengpässe, Microbursts auf 100G/400G-Links oder kurzzeitige Queue-Überläufe ist das der entscheidende Unterschied zwischen „wir sehen es“ und „wir sehen es nicht“.
Auch die Latenz bis zur Sichtbarkeit sinkt spürbar: On-Change-Subscriptions liefern Zustandsänderungen quasi in Echtzeit an die Pipeline, während SNMP-Traps als Ergänzung oft unzuverlässig und verlustbehaftet sind, weil sie typischerweise auf UDP ohne Zustellgarantie beruhen.
Die Pipeline: Kafka, Telegraf, TSDB und Grafana
Die schiere Datenmenge aus Streaming-Telemetrie erfordert eine andere Verarbeitungsarchitektur als klassisches SNMP-Polling mit RRDtool oder einfachen Cron-Jobs. Ein verbreitetes Muster: Collector wie Telegraf oder pmgrpc nehmen gNMI-Streams entgegen, normalisieren sie und schreiben sie in eine Time-Series-Datenbank wie InfluxDB, Prometheus (via Remote Write) oder TimescaleDB. Bei sehr hohem Durchsatz oder mehreren Consumern – etwa Alerting, Langzeit-Storage und Streaming-Analytics parallel – puffert Kafka als Message-Broker dazwischen und entkoppelt Erzeuger und Verbraucher.
Visualisiert wird meist über Grafana, das sich sowohl mit Prometheus als auch InfluxDB nativ versteht und Dashboards für NOC-Wände ebenso bedient wie Ad-hoc-Analysen für Troubleshooting-Sessions.
Migration und Koexistenz: SNMP bleibt für Legacy
Ein kompletter Rip-and-Replace ist in den seltensten Fällen sinnvoll oder überhaupt möglich. Ältere Switches, Access-Points, USVs oder Industrial-Networking-Komponenten unterstützen häufig gar kein gNMI und werden es auch nie tun. Realistisch ist daher ein hybrider Betrieb: Kernrouter, Spine-Leaf-Fabrics und neuere Plattformen wandern auf Streaming-Telemetrie, während Legacy-Geräte weiterhin per SNMP abgefragt werden – idealerweise in dieselbe TSDB und dasselbe Dashboard-Layer eingespeist, damit NOC-Teams nicht zwischen zwei Werkzeugen wechseln müssen.
Der Migrationsaufwand steckt weniger im Protokoll selbst als in Collector-Betrieb, YANG-Modell-Mapping je Hersteller und dem Aufbau einer skalierbaren Pipeline. Wer bereits eine gepflegte Prometheus- oder InfluxDB-Landschaft betreibt, kann Streaming-Telemetrie schrittweise auf priorisierten Kernsegmenten einführen, statt alles auf einmal umzustellen.
Anwendungsfälle in der Praxis
Der Mehrwert zeigt sich konkret in mehreren Betriebsbereichen, in denen Minuten-Granularität schlicht zu grob ist:
- Kapazitätsplanung: Hochauflösende Interface- und Queue-Metriken zeigen Trends und Sättigungspunkte deutlich früher als 5-Minuten-Mittelwerte es könnten.
- Anomalie-Erkennung: Kontinuierliche Datenströme sind Grundlage für Baseline-Modelle und automatisierte Ausreißer-Erkennung, ohne dass kurzzeitige Effekte im Polling-Rauschen untergehen.
- Fehlersuche (Troubleshooting): Bei intermittierenden Problemen – flatternden Links, sporadischem Paketverlust – liefert Sekunden-Auflösung oft den entscheidenden Hinweis, den ein SNMP-Poll-Intervall schlicht verpasst hätte.
Wichtig ist dabei ein realistischer Blick auf Aufwand und Nutzen: Nicht jedes Netzwerksegment braucht Subsekunden-Telemetrie. Für Edge-Switches im Verwaltungsnetz ist SNMP mit fünf Minuten Intervall meistens völlig ausreichend – der Invest in Streaming-Pipelines lohnt dort, wo Geschwindigkeit und Auflösung tatsächlich betrieblichen Mehrwert schaffen, etwa im Core, bei kritischen Peering-Punkten oder in latenzsensitiven Umgebungen.
Fazit
Streaming-Telemetrie löst SNMP nicht ab, sie ergänzt es dort, wo Auflösung, Latenz und Skalierung an ihre Grenzen stoßen. Wer gNMI, YANG-Modelle und eine moderne TSDB-Pipeline aus Telegraf, Kafka, InfluxDB/Prometheus und Grafana gezielt auf kritische Netzsegmente ansetzt, gewinnt spürbar an Sichtbarkeit und Reaktionsgeschwindigkeit – ohne die bewährte SNMP-Basis für Legacy-Komponenten sofort über Bord zu werfen. Der pragmatische Weg ist die Koexistenz, nicht der große Sprung.