Model-Driven Telemetry: YANG, Subscriptions und Datenpipelines

Model-Driven Telemetry beschreibt einen modernen Ansatz, Telemetriedaten aus Netzwerkinfrastrukturen strukturiert, automatisierbar und skalierbar zu erfassen. Statt proprietäre OIDs zu pollen oder unstrukturierte Logs zu parsen, basiert Model-Driven Telemetry auf YANG-Datenmodellen: Geräte stellen ihren Zustand als klar definierte Datenbäume bereit, die über standardisierte Protokolle wie gNMI/gRPC, NETCONF oder RESTCONF konsumiert werden können. Der wesentliche Paradigmenwechsel lautet: Telemetrie ist nicht mehr „eine Sammlung einzelner Messpunkte“, sondern ein modellierter Datenraum, der sich konsistent abfragen und – noch wichtiger – als Subscription streamen lässt. Dadurch lassen sich kurze Peaks, schnelle Zustandsänderungen und transient auftretende Fehler wesentlich besser erfassen als mit klassischem Polling. Gleichzeitig ist Model-Driven Telemetry kein „Feature, das man einschaltet“, sondern eine Datenpipeline, die vom Gerät über Transport, Collector, Normalisierung bis zur Zeitreihendatenbank und zum SIEM sauber designt werden muss. Ohne diese Pipeline-Disziplin entstehen typische Probleme: Streams fehlen sporadisch, Daten sind inkonsistent, Metriken sind nicht vergleichbar zwischen Plattformen oder Versionen, und der Collector wird zum Engpass.

Ein professioneller Aufbau von Model-Driven Telemetry beantwortet deshalb drei Fragen sehr konkret: Welche Daten werden erfasst (YANG-Pfade, Modellwahl, Semantik)? Wie werden sie geliefert (Subscriptions, Samplingraten, on-change, Encodings, Transport, Sicherheit)? Und wie werden sie in der Zielumgebung nutzbar (Labels, Normalisierung, Retention, Alarmierung, Ownership)? Dieser Artikel erklärt die Bausteine von Model-Driven Telemetry praxisnah: YANG als Fundament, Subscription-Design als Herzstück und Datenpipelines als operativer Erfolgsfaktor. Der Fokus liegt auf wiederholbaren Mustern, die in Enterprise- und Datacenter-Umgebungen funktionieren und sowohl Betriebs- als auch Security-Anforderungen erfüllen.

Was „model-driven“ bedeutet: Daten mit Struktur statt Messpunkte mit Kontextverlust

„Model-driven“ heißt, dass Telemetriedaten einem formalen Schema folgen. Dieses Schema beschreibt nicht nur Feldnamen, sondern auch Datentypen, Hierarchien, Beziehungen und Constraints. In der Praxis wirkt sich das auf drei Ebenen positiv aus: Erstens wird Telemetrie vergleichbar (gleiche Pfade bedeuten gleiche Semantik). Zweitens wird Telemetrie automatisierbar (Tools können Modelle introspektieren und generisch verarbeiten). Drittens wird Telemetrie skalierbar, weil Streaming-Mechanismen das Polling-Muster (N Geräte × M OIDs × Intervall) durch ein Push-/Subscription-Modell ersetzen können.

• Semantik statt Strings: Ein Zähler ist als „counter64“ modelliert, ein Status als „enumeration“ – Parser müssen weniger raten.
• Hierarchien: Interfaces, VRFs, Routing-Protokolle, QoS-Queues sind als Datenbäume abbildbar.
• Kompatibilität: Standardmodelle (z. B. OpenConfig) fördern Multi-Vendor-Strategien.

YANG-Grundlagen: Wie Datenmodelle Telemetrie definieren

YANG ist die Modellierungssprache, mit der Netzwerkdaten formal beschrieben werden. Ein YANG-Modell definiert Container, Lists, Leafs (Felder), Typen, Constraints und oft auch „state“ vs. „config“. Für Telemetrie ist die Trennung entscheidend: state beschreibt den beobachtbaren Zustand (Counters, oper-status, Sensorwerte), während config die gewünschte Konfiguration repräsentiert. In Model-Driven Telemetry interessieren Sie meist state-Pfade, aber für bestimmte Use Cases (Compliance, Drift Detection) kann config-Telemetrie ebenfalls relevant sein.

Zentrale YANG-Konzepte, die im Betrieb zählen

• Path: Der eindeutige Pfad zu einem Datenpunkt (z. B. /interfaces/interface[name=…]/state/counters).
• List Keys: Schlüsselattribute, die Instanzen identifizieren (z. B. Interface-Name, VRF-Name).
• Data Types: counter, gauge, boolean, enumeration – wichtig für korrekte Metrikverarbeitung.
• Augmentations: Hersteller können Standardmodelle erweitern; das ist nützlich, aber kann Tooling komplexer machen.

Für eine solide YANG-Einordnung sind die YANG 1.1 Spezifikation (RFC 7950) und als praxisorientierte Referenz die OpenConfig Modellübersicht hilfreiche Ausgangspunkte.

Modellwahl: OpenConfig vs. Vendor Native als strategische Entscheidung

In der Praxis existieren zwei Modellwelten parallel: herstellerübergreifende Modelle (typisch OpenConfig) und herstellerspezifische Modelle (Vendor Native). Die Wahl entscheidet über Portabilität, Datenabdeckung und langfristige Wartbarkeit. Ein bewährtes Enterprise-Muster lautet: OpenConfig als Default für Standardmetriken, Vendor Native nur dort, wo OpenConfig nicht ausreicht oder Plattformdetails zwingend sind.

• OpenConfig: Gut für Interfaces, BGP-Grundlagen, Systemzustand, viele Standardmetriken; ideal für Multi-Vendor.
• Vendor Native: Tiefer Zugriff auf Feature-spezifische Details (z. B. plattformspezifische QoS-Queues, Hardware-Sensorik).
• Governance: Dokumentieren, welche Dashboards auf welchen Modellen basieren, um Drift und Tool-Lock-in zu vermeiden.

Subscriptions: Das Herzstück von Streaming Telemetry

Eine Subscription ist ein Abonnement auf einen oder mehrere YANG-Pfade. Der Collector (Subscriber) fordert Daten an, und das Gerät liefert sie als Stream. In gNMI ist Subscription-Design besonders zentral, aber die Grundidee gilt auch für andere MDT-Mechanismen: Sie definieren, welche Pfade, welche Frequenz, welcher Modus und welches Encoding genutzt werden. Ohne klares Subscription-Design passieren zwei Dinge: Entweder fehlen wichtige Signale (zu selten, falscher Modus), oder die Pipeline wird überlastet (zu häufig, zu viele Pfade, zu große Payloads).

Subscription-Modi: Sample, On-Change und Mischmodelle

• Sample: Periodische Lieferung. Ideal für Counters, Auslastung, Sensorwerte und Trends.
• On-Change: Lieferung nur bei Änderung. Ideal für States (Interface up/down, Neighbor up/down), Konfigdrift, Alarmzustände.
• Target-defined: Gerät entscheidet Details. Kann effizient sein, ist aber weniger deterministisch.

Abstufung nach Use Case: Nicht alles braucht 5 Sekunden

Ein professioneller Ansatz definiert Subscription-Profile nach Gerätekategorie und Engpassrelevanz. Beispielhaft:

• Interface-Counters: 10–30 Sekunden (Kapazität), an kritischen Interconnects ggf. 5–10 Sekunden.
• QoS/Queue Drops: 5–15 Sekunden an Engpässen, sonst konservativer.
• CPU/Memory/Temperature: 30–60 Sekunden, meist ausreichend.
• Oper-Status/Adjacencies: On-change, ergänzt durch periodische „state refresh“-Mechanismen, falls Tooling es verlangt.

Datenpipelines: Vom Gerät bis zum Dashboard ist es ein System

Model-Driven Telemetry funktioniert nur, wenn die gesamte Pipeline stabil ist. Ein Gerät kann perfekte Daten liefern, aber wenn der Collector überlastet ist oder Normalisierung fehlt, werden die Daten in Dashboards unzuverlässig. Eine professionelle Pipeline besteht aus klaren Schichten:

• Publisher: Gerät (Router/Switch), das modellierte Daten bereitstellt.
• Transport: gRPC/HTTP2 (oft mit TLS), oder alternative MDT-Transporte je Plattform.
• Collector: gNMI-Client/Telemetry-Agent, der Subscriptions verwaltet und Streams entgegen nimmt.
• Normalization/Enrichment: Labels (Device-ID, Site, Role, VRF, Interface), Einheiten, Counter-Typen.
• Storage: TSDB für Metriken, ggf. zusätzlich Log-/Event-Store für Zustandsänderungen.
• Analytics: Alerts, Anomalieerkennung, Kapazitätsmodelle, Security-Detections.

Der entscheidende Erfolgsfaktor ist Normalization: Ohne konsistente Labels und Namensräume können Sie Daten nicht zuverlässig korrelieren (z. B. „Gi1/0/1“ vs. „Ethernet1/1“ vs. „xe-0/0/1“). Ein Telemetrie-Blueprint definiert daher eine Canonical-Identity pro Device und ein Label-Schema, das in allen Pipelines gilt.

Encodings und Payloads: Effizienz vs. Debugbarkeit

Telemetrie kann in unterschiedlichen Encodings geliefert werden, je nach Protokoll und Plattform. Praktisch relevant sind meist JSON/JSON-IETF und Protobuf-Varianten. Die Wahl ist nicht nur technisch, sondern auch organisatorisch: Debugging, Tool-Kompatibilität, Parser-Qualität und Skalierung spielen zusammen.

• JSON/JSON-IETF: Lesbar und oft einfacher zu debuggen; Payload größer, aber für Piloten ideal.
• Protobuf: Kompakter, effizienter, besser bei großen Deployments; erfordert saubere Schema-/Tool-Unterstützung.

Ein praxistaugliches Muster ist: Starten Sie mit JSON (schneller Einstieg, bessere Transparenz) und migrieren Sie bei Skalierungsdruck auf Protobuf, wenn Collector und Backend das robust unterstützen.

Security: Telemetrie ist Management Traffic und muss entsprechend gehärtet werden

Model-Driven Telemetry ist Teil der Management Plane. Das bedeutet: Sie müssen dieselben Hardening-Prinzipien anwenden wie bei SSH, SNMPv3 oder APIs. Die wichtigsten Punkte sind Transportverschlüsselung, Client-Authentifizierung, Scope-Restriktionen und RBAC.

• TLS als Minimum: Schutz vor Mitschnitt und Manipulation.
• mTLS: Der Collector weist sich mit einem Client-Zertifikat aus; reduziert Credential-Risiken.
• Management-VRF/OOB: Telemetriepfade separat vom User-Traffic führen, um Angriffsfläche und Störanfälligkeit zu reduzieren.
• Allowlist: Nur definierte Collector-Systeme dürfen Sessions aufbauen.
• RBAC: Telemetrie-Accounts minimal berechtigen; keine Admin-Accounts für Collectors.
• Key Lifecycle: Zertifikate rotieren, Ablauf überwachen, Notfallprozesse definieren.

CoPP und Ressourcen: Schutz vor Self-DoS durch zu viel Telemetrie

Ein häufiger Fehler in Telemetrieprojekten ist „Subscription-Sprawl“: Jeder Teamwunsch wird als neue Subscription umgesetzt, die Samplingraten steigen, Pfade werden breiter, und irgendwann ist die Control Plane spürbar belastet. Professionelle Telemetrie braucht deshalb Guardrails:

• Subscription-Budgets: Maximalzahl Subscriptions pro Rolle (Access/Distribution/Edge) und maximale Frequenzen definieren.
• Pfad-Whitelists: Nur standardisierte Pfade dürfen produktiv gestreamt werden; neue Pfade gehen durch Review.
• CoPP: Management- und Telemetrie-Traffic in Control Plane Policing Klassen schützen, damit Peaks nicht Routing/SSH verdrängen.
• Collector Backpressure: Collector muss skalieren; sonst führen Retries/Queues zu künstlicher Last.

Operabilität: Versionierung, Drift und Modellkompatibilität

Ein unterschätztes Thema ist die Veränderung von Modellen über Plattformversionen hinweg. Neue IOS XE/NX-OS Releases können Pfade ergänzen, Felder ändern oder Implementierungen verbessern. Ohne Versionierung und Tests entstehen „still“ ausfallende Streams, die erst Wochen später auffallen. Ein professionelles Betriebsmodell behandelt Telemetrie wie Code:

• Templates in Git: Subscription-Profile, Pfadlisten, Samplingraten versionieren.
• Pre-/Post-Checks: Bei Upgrades prüfen, ob Pfade weiterhin existieren und Werte plausibel sind.
• Schema-Tests: Collector-Parsing und Normalisierung automatisch validieren (CI für Telemetrieprofile).
• Change-Governance: Neue Metriken nur nach Nutzen-/Kostenbewertung produktiv nehmen.

Onboarding: So starten Sie mit Model-Driven Telemetry ohne Überforderung

Der schnellste Weg zu Wert ist ein begrenzter Pilot mit klaren Use Cases. Ein bewährtes Vorgehen ist, zunächst „universelle“ Metriken zu streamen, die überall helfen, und erst dann tiefer in Feature-spezifische Modelle zu gehen.

• Schritt 1: System Health (CPU/Memory/Temperature) + Interface Utilization als Sample.
• Schritt 2: Interface oper-status und kritische Neighbor-States als On-change.
• Schritt 3: QoS/Drops an Engpässen und BGP/OSPF/EVPN-States, abhängig vom Netztyp.
• Schritt 4: Erweiterte Pfade (Fabric-spezifisch, Plattform-Sensorik) nur nach klarer Notwendigkeit.

Troubleshooting: Wenn Telemetrie nicht ankommt oder Werte unplausibel sind

Telemetrieprobleme lassen sich in der Regel auf wenige Kategorien zurückführen: Transport, Authentifizierung, Pfadkompatibilität, Collector-Überlast oder Normalisierung. Eine strukturierte Fehlersuche spart enorm Zeit:

• Transport: Ist die Session aufgebaut (gRPC/TLS)? Sind Ports/ACLs/Firewalls korrekt? Gibt es MTU/PMTUD-Probleme?
• Zertifikate: Abgelaufen? CA nicht vertraut? CN/SAN falsch? mTLS schlägt fehl?
• VRF/Reachability: Läuft die Telemetrie über die richtige VRF? Ist der Collector von dort erreichbar?
• Path validity: Existiert der abonnierte Pfad auf dieser Plattform/Version wirklich? Ist er implementiert oder liefert er „leer“?
• Collector health: Dropped Samples, Queue-Overflows, Parser-Fehler, Storage-Limits?
• Units/Counter resets: Counters können resetten; Normalisierung muss Counter-Typen korrekt interpretieren.

Best Practices: Ein wiederholbarer MDT-Blueprint

• Modellstrategie: OpenConfig als Default, Vendor Native gezielt; Mapping dokumentieren.
• Subscription-Profile: Rollenbasierte Samplingraten; on-change für State; keine „alles 1s“-Setups.
• Labeling: Device-ID, Site, Role, VRF, Interface als konsistente Labels; Normalisierung als Pflicht.
• Security: TLS/mTLS, Allowlist, Management-VRF/OOB, RBAC; Zertifikatsrotation planen.
• Stabilität: CoPP/Guardrails, Subscription-Budgets, Collector-Skalierung, Backpressure vermeiden.
• Operabilität: Templates versionieren, Upgrade-Tests, Monitoring auf „stille“ Datenlücken.
• Koexistenz: SNMP/Logs ergänzend behalten, bis Telemetrie alle kritischen Use Cases abdeckt.

Outbound-Referenzen

• RFC 7950 (YANG 1.1) als formale Grundlage für YANG-Datenmodelle.
• OpenConfig für herstellerübergreifende YANG-Modelle und langfristig stabile Standardpfade.
• gNMI Spezifikation als praktische Referenz für Subscriptions, Pfade und Streaming-Mechanik.
• gRPC für Grundlagen zu HTTP/2-basiertem Streaming und Transportverhalten.
• Cisco IOS XE Configuration Guides für plattformspezifische Implementierung von Model-Driven Telemetry, gNMI und Zertifikatsmanagement.
• Cisco Nexus NX-OS Configuration Guides für NX-OS-spezifische Telemetriepfade, Datacenter-Modelle und Betriebsdetails.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.