6. Observability#

Beim Core-Router eines Service-Providers fiel über Nacht ein Lüftermodul still aus. Es gab keine Alarme. Das Wärmemanagement-Subsystem auf den Line Cards erkannte steigende Temperaturen und begann, die Weiterleitungs-ASICs zum Schutz der Hardware zu drosseln. Der Durchsatz auf einem produktiven Transit-Link sank um 40%. Das Monitoring-System sah nichts: Die Temperatursensoren, die es abfragte, befanden sich auf dem Chassis-Supervisor, nicht auf den einzelnen Line Cards. Die SNMP-Abfragen liefen alle fünf Minuten und meldeten das Gerät als gesund. Die Interface-Counter zeigten reduzierten Durchsatz, aber für dieses Muster war kein Schwellenwert konfiguriert, weil der Link immer weit unter seiner Kapazität gelaufen war.

Drei Stunden später löste ein Kunden-SLA-Verstoß ein Ticket aus. Der Bereitschaftsingenieur meldete sich per SSH am Router an, bemerkte den Lüfterausfall im lokalen Alarmprotokoll und führte einen Power-Cycle des Lüftermoduls durch. Der Lüfter-Controller startete neu und die thermische Drossel wurde innerhalb von Minuten aufgehoben. Der Datenverkehr erholte sich. Der SLA-Verstoß wurde dokumentiert, der Kunde wurde benachrichtigt, und der Vorfall wurde geschlossen.

Die Ursache wurde nie bestätigt. Als jemand untersuchte, lief der Router seit Stunden normal. Es gab keine Thermaldaten für die Line Cards, keine Aufzeichnung des Drosselungsereignisses und keine Möglichkeit, die Durchsatzreduzierung mit dem Lüfterausfall in einem Monitoring-System zu korrelieren. Der Vorfallbericht lautete: “Vermutetes Hardware-Problem, durch Hardware-Reset behoben.” Sechs Monate später passierte es auf einem anderen Router erneut.

Das Problem war kein fehlender Schwellenwert. Das Team hatte Tausende von Schwellenwerten. Das Problem war unvollständige Abdeckung: Das Monitoring-System sammelte von den Quellen, die immer abgefragt worden waren, nicht von jeder Quelle, die das Geräteverhalten ändern konnte. Thermaldaten von Line Cards waren via gNMI auf allen drei Chassis-Typen der Flotte verfügbar. Niemand hatte den Erfassungspfad konfiguriert, weil niemand ein Runbook für Lüfterausfälle geschrieben hatte.

Traditionelles Netzwerk-Monitoring beobachtet kaputte Dinge: Ist die Schnittstelle oben? Ist die CPU über 90%? Antwortet dieser Dienst? Das ist nützlich, aber reaktiv: Man beobachtet Ausfälle.

Observability ist anders. Es geht darum zu verstehen, warum Dinge kaputt gehen oder es bald werden. Es ist nicht nur “dieses Gerät ist ausgefallen”, sondern “warum ist es ausgefallen, was bricht deswegen, was ist der geschäftliche Einfluss”. Bei der Netzwerkautomatisierung wird Observability zur Rückkopplungsschleife: Man beobachtet etwas, das System erkennt es, entscheidet, wie es reagiert, handelt und überprüft, ob die Korrektur funktioniert hat. Das ist Closed-Loop-Automatisierung.

Dieses Kapitel behandelt alles, was man braucht, um zu sehen, was im Netzwerk passiert: welche Daten gesammelt werden sollen, wie sie gesammelt werden, wie sie gespeichert werden, wie Alarme darauf gesetzt werden und wie sie Menschen auf eine Weise gezeigt werden, die tatsächlich hilft, Entscheidungen zu treffen.

Wir behandeln hier zwei Bausteine: Collector und Observability, weil sie eng miteinander verbunden sind.

Ob man eine traditionelle All-in-one-Plattform (SolarWinds, LibreNMS), einen Cloud-Dienst (Datadog, New Relic) oder einen eigenen Stack aus Open-Source-Teilen (Prometheus, Grafana usw.) verwendet - die zugrunde liegende Architektur ist dieselbe. Das Verständnis dieser Muster hilft, den richtigen Ansatz für die eigene Skalierung und das eigene Team zu wählen.

Dieser Abschnitt ist stark beeinflusst vom Buch Modern Network Observability von Packt, das ich zusammen mit David Flores und Josh Vanderaa verfasst habe. Wenn man praktisch einsteigen und eine Implementierung mit dem TPG-Stack (Telegraf-Prometheus-Grafana) und anderen Werkzeugen lernen möchte, ist es sehr empfehlenswert.

6.1. Grundlagen#

Bevor wir in die Details gehen, etablieren wir hier die Grundlagen der Netzwerk-Observability innerhalb der Netzwerkautomatisierungsstrategie und definieren ihre Ziele, unterstützenden Säulen und den Geltungsbereich.

6.1.1. Kontext#

Wahrscheinlich überwacht man das Netzwerk bereits. Man verwendet Simple Network Management Protocol (SNMP), schaut auf System Logging Protocol (Syslog), hat Dashboards, die die Link-Auslastung zeigen. Das ist Monitoring: Es sagt einem, ob die Dinge funktionieren.

Aber Automatisierung braucht mehr. Wenn das Netzwerk sich ändert (weil Automatisierung es geändert hat), muss man sofort wissen, ob etwas kaputt geht. Wenn man einen Alarm bekommt, braucht man Kontext: Welche Kunden sind betroffen? Welche Dienste sind ausgefallen? Was ist der Auswirkungsradius? Traditionelles Monitoring liefert Alarme. Automatisierung braucht Intelligenz.

Hier ist der wesentliche Unterschied:

• Monitoring: Ist die Schnittstelle oben? Ist die CPU hoch? Einfache Ja/Nein-Fragen.
• Observability: Warum ist die Schnittstelle ausgefallen? Was ist betroffen? Wie kann man es automatisch beheben? Was ist historisch passiert, das dazu geführt hat?

Observability speist die Automatisierung. Das System beobachtet das Netzwerk, erkennt Probleme, entscheidet, was zu tun ist, handelt und überprüft, ob die Korrektur funktioniert hat. Dieses wiederkehrende Prinzip heißt “Closed-Loop-Automatisierung”.

Traditionelle Monitoring-Werkzeuge (die großen monolithischen wie SolarWinds) versuchen, alles in einem Produkt zu tun. Das kann funktionieren, aber man zahlt oft für Funktionen, die man nicht braucht, und ist durch Funktionen eingeschränkt, die man braucht. Die Alternative ist der Aufbau von Observability aus Teilen: Den Collector wählen, der für die Geräte funktioniert, den Speicher, der mit den Daten skaliert, die Alarmierung, die zu den Automatisierungs-Workflows passt. Das ist schwieriger zusammenzustellen, aber viel flexibler.

Dieses Kapitel führt durch beide Ansätze und die Muster, die unabhängig von der Wahl funktionieren.

Eine erste Wahl betrifft das Betriebsmodell der Plattform:

• Monolithisch (SolarWinds, LibreNMS): Ein Produkt macht alles. Installieren, konfigurieren, loslegen. Gut, wenn das Netzwerk unkompliziert ist und man keine DevOps-Erfahrung hat. Schlecht, wenn man Flexibilität möchte oder das Netzwerk ungewöhnlich ist: Man ist an ihr Modell gebunden.

• Cloud-SaaS (Datadog, New Relic, Kentik): Sie betreiben alles. Schnell bereitzustellen, keine Infrastruktur-Kopfschmerzen, schöne Dashboards von Anfang an. Aber man zahlt monatlich basierend auf Volumen, die Daten liegen auf ihren Servern (für manche Compliance-Regime bedeutsam), und wenn man ihre Grenzen erreicht, steckt man fest. Ich habe Teams gesehen, die $50.000/Monat für Observability-SaaS ausgeben und sich fragen, warum der CFO unzufrieden ist.

• Selbst aufbauen (Prometheus + Grafana oder Telegraf-Prometheus-Grafana (TPG)-Stack): Völlige Flexibilität, kein Anbieter-Lock-in, bessere Wirtschaftlichkeit im großen Maßstab. Aber man betreibt jetzt Datenbanken, Message-Queues und Collector-Infrastruktur. Wenn man kein Team hat, das das betreiben kann, verbringt man mehr Zeit damit, Observability zu reparieren als das Netzwerk.

Die eigentliche Frage: Hat man das Team, um es zu betreiben? Wenn ja, selbst aufbauen. Wenn nein, kaufen. Man sollte sich nicht selbst täuschen, in welcher Kategorie man sich befindet.

Nach dieser Wahl kommen zwei weitere Fragen:

• Wo läuft es? Vor Ort (man kontrolliert alles, aber betreibt es selbst), in der Cloud (sie betreiben es, aber die Daten verlassen das Netzwerk) oder hybrid (manche Teile lokal, manche in der Cloud)?
• Was ist das Kostenmodell? Pro Gerät? Pro aufgenommener Metrik? Pauschalabonnement? Diese Entscheidungen summieren sich schnell, wenn Millionen von Datenpunkten pro Minute erfasst werden.

6.1.2. Ziele#

Das Observability-System muss sieben Dinge tun:

1. Alles automatisch beobachten. Neues Gerät verbindet sich? Es sollte anfangen, Daten zu melden, ohne dass jemand es manuell registriert. Neuer Dienst kommt online? Er wird bereits überwacht. Das erfordert die Integration mit dem Source of Truth, damit Observability weiß, was existiert.

2. Heterogene Umgebungen mit guten Daten handhaben. Das Netzwerk hat wahrscheinlich Cisco, Arista, Juniper, Cloud-Provider, Linux-Server und Container. Jedes hat verschiedene Möglichkeiten, Daten zu exponieren. Und vergessen Sie 5-Minuten-Intervalle: Man braucht nahezu Echtzeit-Daten, wenn Automatisierung Änderungen vornimmt.

3. Daten über Schichten hinweg korrelieren. Ein Server ist langsam. Ist das Netzwerk überlastet oder ist es ein Datenbankproblem? Man braucht Daten von Netzwerkgeräten, Servern und Anwendungen, alle in derselben Sprache, um Verbindungen zwischen ihnen herzustellen.

4. Ohne Zusammenbruch skalieren. Netzwerke wachsen. Wenn eine Million Metriken pro Sekunde erfasst werden, brechen traditionelle Architekturen zusammen. Man braucht Systeme, die von Tag eins für Skalierung ausgelegt sind.

5. Menschen ermöglichen, Daten intelligent zu analysieren. Analysten Zugriff auf Abfragen geben - nicht nur vorgefertigte Dashboards, sondern leistungsstarke Abfragen, damit sie ihre eigenen Fragen beantworten können. Und sie brauchen sowohl Echtzeit-Daten als auch Verlauf (Trends, Anomalieerkennung).

6. Probleme erkennen und automatisch beheben. Meistens sollte die Automatisierung auf Probleme reagieren, ohne auf einen Menschen zu warten. Nur wenn die Automatisierung es nicht herausfinden kann, sollte jemand benachrichtigt werden. Und dieser Alarm sollte besser erklären, was falsch ist, nicht nur rohe Zahlen zeigen.

7. Menschen zeigen, was sie sehen müssen. Ein Dashboard ist wertlos, wenn es zu viel oder das Falsche zeigt. Das Netzwerk-Ops-Team bekommt seine Ansicht, das Unternehmen seine Ansicht, die Ingenieure ihre Ansicht. Jede Person bekommt, was ihr bei der Arbeit hilft.

6.1.3. Säulen#

Jedes Ziel braucht spezifische Bausteine zum Funktionieren. Das wird benötigt:

1. Wissen, was zu beobachten ist. Der Source of Truth hat alle Geräte, Dienste und Zugangsdaten. Observability sollte diese Daten automatisch abrufen, damit Collector wissen, was zu überwachen ist. Wenn man ein Gerät im SoT hinzufügt, kommt Monitoring automatisch online.

2. Daten effizient erfassen. Man braucht mehrere Erfassungsmethoden: Simple Network Management Protocol (SNMP) für ältere Geräte, gRPC Network Management Interface (gNMI)-Streaming für moderne Geräte, System Logging Protocol (Syslog) für Ereignisse, Flows (NetFlow, IP Flow Information Export (IPFIX)) für Datenverkehr, vielleicht Paketmitschnitte für tiefgehendes Troubleshooting. Verschiedene Werkzeuge, verschiedene Geschwindigkeiten, verschiedene Datenanreicherung. Die gute Nachricht: Man muss sich nicht für nur eines entscheiden.

3. Alles normalisieren. Arista-Metriken sehen anders aus als Cisco-Metriken, die anders aussehen als Cloud-Provider-Metriken. Das Logging ist unstrukturierter Text, Flows sind binär. Man braucht eine Schicht, die all das in eine gemeinsame Sprache übersetzt und Kontext hinzufügt (welches Gerät, welcher Kunde, welcher Dienst).

4. Daten zuverlässig und in großem Maßstab bewegen. Traditionelle Monitoring-Pipelines sind sequentiell: Collector → Prozessor → Speicher. Im großen Maßstab ist das ein Engpass. Man braucht Message-Busse und Streaming-Plattformen, die jede Stufe entkoppeln, damit sie unabhängig skalieren können.

5. Intelligent speichern. Zeitreihendaten (Metriken) brauchen dafür optimierte Datenbanken. Protokolle brauchen etwas anderes. Man muss über Millionen von Datenpunkten in Millisekunden abfragen können. Nicht alle Datenbanken sind hier gleich.

6. Daten in Aktionen umwandeln. Rohe Metriken lösen keine Automatisierung aus. Man braucht Regeln: “Wenn CPU > 90%, prüfen ob geplante Wartung, wenn nicht, diese Schritte ausführen.” Und diese Regeln fließen in den Automatisierungs-Orchestrator oder das Alarmsystem.

7. Visuell darstellen. Daten sind nutzlos, wenn sie niemand anschaut. Man braucht Dashboards, aber intelligente: verschiedene Ansichten für verschiedene Personen, die Drill-down ermöglichen, Trends und Vergleiche zeigen.

Bevor die sieben Funktionalitäten, die diese Säulen realisieren, detailliert werden, klären wir, was in den Geltungsbereich von Observability fällt.

6.1.4. Geltungsbereich#

Zu den oben eingeführten Zielen gibt es weitere Punkte, die ebenfalls in den Geltungsbereich von Observability fallen:

• Verschiedene Beobachtungsebenen angepasst an Benutzerperspektiven (technisch, operativ, geschäftlich)
• Integration mit CI/CD-Pipelines und Bereitstellung von Feedback für automatisiertes Testen und Validierung
• Observability des Automatisierungssystems selbst (Meta-Monitoring von Collectors, Prozessoren und Alarmsystemen)

Auf der anderen Seite gibt es Funktionen, die zu anderen Komponenten der Architektur gehören:

• Netzwerkabsicht definieren: Wie das Netzwerk aussehen soll (Verantwortung von Intent/SoT)
• Netzwerkänderungen ausführen: Tatsächlich Abhilfemaßnahmen implementieren (Verantwortung des Executor)
• Komplexe Workflows orchestrieren: Mehrstufige Abhilfemaßnahmen über mehrere Systeme koordinieren (Verantwortung des Orchestrator)

Diese klare Grenze stellt sicher, dass Observability sich auf Erkennung und Erkenntnisse konzentriert, während andere Bausteine Absichtsdefinition, Ausführung und Orchestrierung handhaben.

Der Übergang zu moderner Observability erfordert sorgfältige Planung. Betrachten Sie es nicht als etwas so Einfaches wie den Austausch eines Monitoring-Werkzeugs gegen ein anderes; man muss das Denken transformieren. Mit mehr Macht kommt mehr Verantwortung, und es gibt mehr zu wählen und anzupassen.

Nach dieser anfänglichen Einführung, die die Schlüsselkonzepte des Observability-Blocks vorstellt, gehen wir als nächstes auf jede Funktionalität ein.

6.2. Funktionalitäten#

Die sieben Ziele und Säulen werden durch sieben Kernfunktionalitäten realisiert. Jede Funktionalität entspricht einem Ziel und seiner unterstützenden Säule, wodurch eine direkte Kette von Geschäftsanforderungen zur technischen Implementierung entsteht:

1. Inventar: Konsumiert Absicht aus dem SoT und stellt Metadaten, Gerätelisten und Erfassungsziele für alle nachgelagerten Komponenten bereit.
2. Collector: Ruft beobachtete Daten aus dem Netzwerk ab, sowohl pull-basiert (Polling) als auch push-basiert (Streaming), unter Verwendung mehrerer Protokolle und Erfassungsmethoden.
3. Prozessor: Normalisiert heterogene Daten in ein gemeinsames Schema und reichert sie mit kontextuellen Metadaten (Tags, Beziehungen, Geschäftskontext) an, neben anderen Datenoperationen.
4. Distribution: Entkoppelt Datenproduzenten von Konsumenten über verteilte, asynchrone Muster. Bewegt Daten und Ereignisse zuverlässig von Collectors über Prozessoren zu Persistenz- und Alarmsystemen.
5. Persistenz: Speichert normalisierte Daten in Datenbanken, die für effiziente Aufnahme, Aufbewahrung und Abfrage im großen Maßstab optimiert sind.
6. Alarmierung: Analysiert persistierte Daten mit flexiblen Regeln und Schwellenwerten, um interessante Zustände zu erkennen, und generiert Ereignisse, die externe Systeme (Automatisierung oder menschliche Benachrichtigungen) auslösen.
7. Visualisierung: Rendert beobachtete Daten und ausgelöste Ereignisse in Dashboards, Berichte und andere visuelle Schnittstellen, die auf verschiedene Benutzerzielgruppen und Anwendungsfälle zugeschnitten sind.

graph LR

    %% --- Subgraphs ---
    subgraph Goals
        direction TB
        A1[Gesamtes Netzwerk mit minimalem Aufwand beobachten]
        A2[Heterogene Umgebungen mit ausreichend Daten und Genauigkeit unterstützen]
        A3[Daten aus verschiedenen IT-Schichten mit Kontext beobachten]
        A4[Massive Netzwerkszenarien handhaben]
        A5[Zugang zu Observability-Daten für anspruchsvolle Analysen in nahezu Echtzeit]
        A6[Proaktiv Netzwerkprobleme erkennen und Wiederherstellungszeit reduzieren]
        A7[Nutzerorientierte Visualisierungen erstellen]
    end

    subgraph Pillars
        direction TB
        B1[Enge SoT-Integration zum Verständnis, was überwacht werden muss]
        B2[Datenerfassung über verschiedene Protokolle mit häufigen/On-Demand-Updates]
        B3[Normalisierung heterogener Daten mit Kontextmetadaten für reichhaltigere Analysen]
        B4[Skalierbare Datenverteilungssysteme für Scale-out-Architekturen]
        B5[Persistenzschicht für Zeitreihendaten und leistungsstarke Abfragesprachen]
        B6[Flexible Regeldefinitionen und Routing-Szenarien mit externer Systemintegration]
        B7[Benutzerdefinierte Visualisierungen und Integration mehrerer Datenspeicher]
    end

    subgraph Functionalities
        direction TB
        C1[Inventar]
        C2[Collector]
        C3[Prozessor]
        C4[Distribution]
        C5[Persistenz]
        C6[Alarmierung]
        C7[Visualisierung]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

Diese Komponenten können als Datenpipeline oder ETL (Extract, Transform and Load) gesehen werden, mit folgendem Diagramm:

flowchart TB
    A[Netzwerk] --> B[Collector]

    subgraph Observability
       direction LR
       B --> C[Distribution] -->  D[Persistenz]
       B -.-> P[Verarbeitung]
       C -.-> P
       D -.-> P
       D --> E[Alarmierung]
       E -.-> P
       D --> G[Visualisierung]
       X[Inventar] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[Orchestrierung]
    G -.-> H[Präsentation]
    Y[SoT] -.-> X

Abbildung 1: Observability-Pipeline.

6.2.1. Inventar#

Die Inventarkomponente beantwortet eine einfache Frage: Was sollte ich überwachen?

Diese Daten sind bereits irgendwo vorhanden: im Source of Truth. Man hat Gerätenamen, IP-Adressen, was sie sind, ob sie aktiv sind, Zugangsdaten. Diese nicht manuell duplizieren. Automatisch einlesen.

Was man vom SoT braucht:

• Ein eindeutiger Name oder eine ID für jedes Gerät oder jeden Dienst (damit man weiß, dass es das Gerät ist, das man denkt)
• Wie man es erreicht: IP-Adresse, Hostname und Zugangsdaten (wenn man aktiv Daten davon abrufen muss)
• Was es ist: Typ und Anbieter (damit man weiß, welche Collectors damit funktionieren)
• Ob es aktiv ist: ob es geplant, aktiv oder außer Betrieb genommen wird (damit man bei erwarteten Ausfallzeiten keine Alarme auslöst)

Über die Grundlagen hinaus interessiert vielleicht auch:

• OS oder Gerätespezifika: Manche Geräte verwenden verschiedene Protokolle, manche sind alt und brauchen spezielle Behandlung
• Kontext: Wer es besitzt, wo es sich befindet, welche Kunden davon abhängen (nützlich zum Filtern von Alarmen und Dashboards)

Warum das automatisieren statt eine Liste manuell aufzubauen? Weil Menschen vergessen, Listen zu aktualisieren. Geräte werden hinzugefügt, niemand informiert das Monitoring, und plötzlich fehlt die Sichtbarkeit. Aber wenn Observability aus dem SoT liest, wird ein dort hinzugefügtes Gerät automatisch überwacht.

Push vs. Pull?

• Pull: Observability überprüft den SoT regelmäßig auf Updates. Einfach, aber wenn sich etwas mitten im Intervall ändert, verpasst man es.
• Push: Wenn sich der SoT ändert, signalisiert er Observability automatisch (Webhooks, Message-Bus). Schneller und zuverlässiger.

Mit guten Daten im SoT und echter Integration (kein manuelles Kopieren) wird das Inventar automatisch und man verpasst nie die Beobachtung eines neuen Geräts.

6.2.2. Collector#

Die Daten müssen von irgendwo herkommen. Collectors sind die Brücken zwischen dem Netzwerk und der Observability-Plattform. Sie sind verantwortlich für das Abrufen (oder Empfangen) von Daten aus Geräten und deren Einspeisung in die Pipeline. Ohne effektive Collectors ist alles nachgelagerte wertlos.

Es gibt zwei grundlegende Ansätze aus der Perspektive, wer den Datenfluss kontrolliert:

• Passiv oder Push: Die Geräte senden Daten an den Collector. Denken Sie an Syslog-Server, die Log-Nachrichten von Routern empfangen, oder IPFIX-Collector, die auf Flow-Records hören. Das Gerät entscheidet, was und wann es sendet.
• Aktiv oder Poll: Der Collector fragt Geräte nach Daten. Er verbindet sich mit jedem Gerät und zieht Informationen über Simple Network Management Protocol (SNMP), gRPC Network Management Interface (gNMI), Representational State Transfer (REST)-Application Programming Interface (API)s oder abonniert Streaming-Daten. Der Collector hat die Kontrolle: Er entscheidet, was er anfragt und wann.

Collector können auch nach Bereitstellung kategorisiert werden:

• Agentless: Keine Software auf Geräten zu installieren. Ein zentraler Collector-Server (der irgendwo anders läuft) verbindet sich mit jedem Gerät individuell. Einfach zu starten, kann aber bei Skalierung zum Engpass werden.
• Agent-basiert: Einen kleinen Agenten auf jedem Gerät oder Dienst installieren. Agenten pushen Daten an einen zentralen Ort oder ziehen direkt aus lokalen Quellen. Besser verteilt, einfacher zu skalieren, aber mehr bewegliche Teile zu verwalten.

Unabhängig von der Erfassungsmethode ist es wichtig, die verschiedenen Datentypen hervorzuheben, die in der Netzwerkautomatisierungsumgebung von Interesse sein können. Diese werden in vier breite Kategorien eingeteilt:

• Management Plane: Der Zustand des Geräts oder das Lesen von Daten über Konfiguration, Logging oder Netzwerkstatistiken. Protokolle in dieser Gruppe sind Simple Network Management Protocol (SNMP), System Logging Protocol (Syslog), gRPC Network Management Interface (gNMI), NETCONF und RESTCONF.
• Control Plane: Hier laufen die verteilten Protokolle, die die Paketweiterleitung des Netzwerks bestimmen, wie Layer-2- oder Layer-3-Weiterleitungstabellen. Einige Beispiele für Control-Plane-Protokolle sind OSPF, IS-IS und BGP. Diese Ebenen können über Techniken wie Ping oder Traceroute oder Telemetrieprotokolle wie BMP beobachtet werden.
• Forwarding Plane: Diese Ebene ist, wo Pakete bewegt werden (z.B. Netzwerkschnittstellen), und sie ist die anspruchsvollste in Bezug auf Datenvolumen und -geschwindigkeit. Beim Beobachten ist es auch entscheidend, das primäre Ziel der Ebene nicht zu beeinträchtigen, das die Weiterleitung von Paketen ist. Zu dieser Gruppe gehören Werkzeuge wie TcpDump, IPFIX, sFlow, Netflow, Cisco SLA, PSAMP und eBPF.
• Externe Daten: Diese Kategorie umfasst alles, was nicht gerätespezifisch ist. Zum Beispiel könnten Circuit-Provider-Informationen und der Ansprechpartner für eine bestimmte Schnittstelle aus einem externen Asset-Management-System oder physische IoT-Sensoren in dieses breite Feld passen.

flowchart TB
    subgraph Network Device/Service
        direction TB
        A[Management Plane]
        B[Control Plane]
        C[Forwarding Plane]
        A --> B
        B --> C
    end

    D[Externe Daten]

Abbildung 2: Geltungsbereich des Collectors.

Hören Sie auf, Command Line Interface (CLI)-Ausgaben per Screen-Scraping zu erfassen. Ich weiß, dass Sie es tun. Wir alle haben es getan. Aber es ist 2026 und jeder große Anbieter unterstützt jetzt ordentliche Telemetrie.

CLI-Scraping ist fragil (Anbieter ändern das Ausgabeformat), langsam (Screen-Scraping und Text-Parsing ist teuer), unzuverlässig (zufällige Befehls-Timeouts) und skaliert schrecklich. Wenn ein Gerät so alt ist, dass es nur CLI hat, entweder ersetzen oder akzeptieren, dass man begrenzte Observability haben wird. Nicht den gesamten Monitoring-Stack um den kleinsten gemeinsamen Nenner aufbauen.

Es läuft wirklich auf zwei Kernfragen zur Erfassung hinaus:

• Was zu erfassen ist: Metriken? Protokolle? Flow-Records? Jedes hat verschiedene Datenmodelle. SNMP hat MIBs, moderne Geräte sprechen gNMI, Anwendungen verwenden OpenTelemetry. Der Traum ist ein universeller Standard, der die Korrelation von Daten über alles hinweg ermöglicht, aber das existiert noch nicht. Daher muss man möglicherweise eine eigene Übersetzungsschicht aufbauen, die all diese verschiedenen Formate in etwas Konsistentes umwandelt (was die Verarbeitungsschicht als nächstes tut).
• Wie man es bekommt: Welches Protokoll? SNMP ist alt, aber stabil; gNMI ist modern und schiebt Daten kontinuierlich; IPFIX erfasst, was tatsächlich fließt. Es hängt davon ab, was man beobachten möchte.

Diese Tabelle fasst zusammen, was erfasst werden könnte und welche Werkzeuge verfügbar sind:

Tabelle 1: Daten und Protokolle zur Erfassung.

Für ein tieferes Verständnis der verschiedenen Optionen das Buch Modern Network Observability konsultieren.

Netzwerkdatenerfassung gilt für Rechenzentren, ISP-Backbones, Cloud-Netzwerkdienste, Linux-Kernel-Schnittstellen oder Rohpakete. Es hängt von der Umgebung ab.

Hier ist der Schlüssel: Bevor man entscheidet, was zu erfassen ist, mit dem Problem beginnen, das man lösen möchte. Diese Entscheidung treibt alles andere an. Erkennt man Schnittstellensättigung? Überwacht man BGP-Konvergenz? Verfolgt man DDoS-Verkehr? Das Problem bestimmt, welche Daten man braucht und wie oft man sie braucht.

Um die Häufigkeit der erfassten Daten zu erhöhen (in manchen Fällen interessant) oder Erfassungsmethoden zu konvergieren, gibt es einige Muster, die kürzlich mehr Verbreitung gefunden haben:

Streaming-Telemetrie

Geräte pushen Daten kontinuierlich über YANG-Modelle. Man richtet Abonnements ein und Daten fließen in Echtzeit. Zwei Varianten:

• Dial-In: Collector fragt das Gerät, mit dem Streaming zu beginnen (Collector initiiert).
• Dial-Out: Gerät ist vorkonfiguriert, an einen zu streamen (Gerät initiiert).

Viel geringere Latenz als Polling, und das Gerät behält die Kontrolle über den Fluss.

flowchart TB
    A[Collector]
    B[Gerät]
    A -.->|Dial-In| B
    B -->|Streaming| A
    B -.->|Dial-Out| A

Abbildung 3: Streaming-Telemetrie.

Hypertext Transfer Protocol (HTTP)-exponierte Metriken

Hypertext Transfer Protocol (HTTP)-Scraping (pull-basierte Metriken) ist einfach und skaliert gut. Simple Network Management Protocol (SNMP) tut das, aber zunehmend exponieren Netzwerk-OS Metriken direkt über Hypertext Transfer Protocol (HTTP) im Prometheus-Format. Einfacher für Collectors zu konsumieren, kein spezielles Simple Network Management Protocol (SNMP)-Management Information Base (MIB)-Parsing nötig. SONiC, Cumulus, Arista EOS und andere exponieren Metriken auf diese Weise.

Tabelle 2: HTTP-exponierte Metriken.

Der Scraping-Ansatz bietet niedrige Latenz und nahezu Echtzeit-Metriken, reichhaltige Labels und pull-basierte Erfassung (zentrale Kontrolle über Rate/Timeout), verbunden mit Cloud-Scale-Observability.

OpenTelemetry

OpenTelemetry ist ein anbieterneutraler Standard und ein Toolkit zur Erfassung, Verarbeitung und Weitergabe von Telemetriedaten. Denken Sie daran als eine gemeinsame Telemetriesprache und -pipeline, die Metriken, Protokolle und Traces über Netzwerke, Systeme und Anwendungen hinweg vereinheitlicht.

Es ersetzt keine Netzwerkprotokolle wie SNMP, NetFlow, gNMI oder BMP. Stattdessen standardisiert es, wie Telemetrie nach der Erfassung dargestellt und transportiert wird.

Im traditionellen Netzwerk-Monitoring sind die Datenmodelle vielfältig und verwenden anbieterspezifische Schemas und Benennungen, was die Korrelation über Schichten hinweg erschwert (Netzwerk ↔ System ↔ Anwendung). Im Gegensatz dazu hilft OpenTelemetry durch:

• Ein gemeinsames Datenmodell für Metriken, Protokolle und Traces
• Ein Standard-Transportprotokoll (OpenTelemetry Protocol (OTLP)), über gRPC Remote Procedure Call (gRPC) oder Hypertext Transfer Protocol (HTTP)
• Eine einzige Verarbeitungspipeline für mehrere Signal-Typen

Grafana Alloy oder Telegraf sind Beispiele für einen Collector, der OpenTelemetry Protocol (OTLP) implementiert. Er erfasst Daten von verschiedenen Exportern und exportiert in verschiedene Backends wie Metriken (Prometheus-kompatible Time Series Database (TSDB)s), Protokolle (Loki, Elasticsearch, ClickHouse) und Traces (Tempo, Jaeger).

Das führt zu einer abschließenden Überlegung zur gemeinsamen Struktur moderner pluggbarer Collector mit Input-, Prozessor- und Output-Stufen. In Telegraf ist OTLP beispielsweise eine Option für ein Output-Plugin.

OpenTelemetry als Architekturentscheidung

Die Übernahme von OpenTelemetry ist nicht nur eine Tooling-Entscheidung: Es ist eine Architekturentscheidung darüber, wie die Observability-Pipeline vereinheitlicht wird. Die Wahl liegt zwischen zwei Ansätzen:

Protokoll-nativ: Jeder Signal-Typ reist durch sein natives Protokoll von Ende zu Ende (gNMI zu Prometheus, Syslog zu Elasticsearch, NetFlow zu ClickHouse). Jede Pipeline ist für ihr Signal optimiert. Der Preis sind mehrere unabhängige Pipelines ohne gemeinsames Datenmodell, was die Korrelation über Signal-Typen hinweg teuer macht.

OTel-nativ: Signale werden so früh wie möglich in OpenTelemetry Protocol (OTLP) umgewandelt und fließen durch eine einzige Pipeline zu einem einheitlichen Backend. Die Korrelation über Metriken, Protokolle und Traces hinweg ist natürlich, weil sie ein Datenmodell teilen. Der Preis ist, dass OTel-Unterstützung für Netzwerkgeräte noch reift: Die meisten Anbieter emittieren OTLP nicht nativ, was eine Adapterschicht erfordert (gNMI zu OTel, SNMP zu OTel), die Betriebskomplexität hinzufügt.

Die praktische Empfehlung für Netzwerkautomatisierungsumgebungen heute: OTel für anwendungsnahe Signale übernehmen, wo die Anbieterunterstützung stark ist (Automatisierungsplattform-Telemetrie, Dienstgesundheit, strukturierte Anwendungslogs), und protokoll-native Pipelines für traditionelle Netzwerktelemetrie (SNMP-Polling, gNMI-Streaming) fortsetzen, bis die geräteseitige OTel-Unterstützung reift. Die Pipeline so gestalten, dass sie beide Ansätze nebeneinander aufnehmen kann, anstatt eine vorzeitige Standardisierung zu erzwingen, die Adapter für jedes Netzwerkgerät erfordert.

Der Trend ist klar: OpenTelemetry wird schließlich der Standard für alle Observability-Daten werden. Damit für die Automatisierungsplattform selbst zu beginnen (Meta-Monitoring aus Kapitel 5) ist ein risikoarmer erster Schritt, der Vertrautheit aufbaut, bevor es auf Netzwerkgeräte ausgedehnt wird.

Collector-Architektur

Vereinfacht gesagt kann jeder Collector in drei Teile aufgeteilt werden (manchmal sind diese pluggbar, manchmal eher fest kodiert).

flowchart LR
    A[INPUT] --> B[PROCESSOR] --> C[OUTPUT]

Abbildung 4: Collector-Architektur.

• Input: Definiert, was beobachtet werden muss und unter welchen Parametern.
• Prozessor: Obwohl optional, ist er sehr praktisch, sobald Daten in die Datenpipeline eintreten, um die Datenkonsistenz zu gewährleisten. Die Verarbeitung kann sehr komplex werden und die Leistung im großen Maßstab beeinträchtigen, daher muss nicht alle Verarbeitung auf dieser Ebene erfolgen.
• Output: Zeigt, wie der Collector die Daten in die Pipeline bewegt. Er kann sie direkt an andere Blöcke wie Verarbeitung oder Persistenz senden oder die Distributionskomponente zur Skalierung verwenden.

Es gibt viele Collector (jeder mit verschiedenen Fähigkeiten) wie Telegraf, Grafana Alloy, gNMIc, PMACCT, goflow, etc., aber sie verwenden ähnliche Architekturen. Bei der Auswahl eines (manchmal braucht man mehrere) wie folgt vorgehen:

1. Gerätefähigkeiten: Welche Protokolle unterstützen die Geräte?
2. Datenvolumen: Hohe Volumen brauchen Streaming; niedrige Volumen können Polling verwenden.
3. Latenzanforderungen: Nahezu Echtzeit vs. traditionelle Intervalle.
4. Teamkenntnisse und Ökosystem-Passung mit dem Backend.

Alle “vollständigen” Netzwerk-Observability-Lösungen wie Suzieq, Kentik und andere implementieren auch eingebaute Collector für die abgedeckten Observability-Daten.

Nachdem die Daten erfasst wurden, ist ein eingeführter Schritt der Prozessor, der die Daten in verschiedenen Phasen der Pipeline manipuliert.

6.2.3. Prozessor#

Rohdaten von Collector sind unübersichtlich. Verschiedene Geräte exportieren Metriken unterschiedlich, Protokolle sind unstrukturierter Text, Werte könnten in verschiedenen Einheiten sein. Die Prozessorschicht bereinigt das und macht es nützlich.

Ziel: Sobald Daten empfangen werden, müssen sie gemeinsamen Standards entsprechen, um Signale aus mehreren Quellen zu konvergieren, zu korrelieren und mit zusätzlichem Kontext anzureichern. Ohne diesen Verarbeitungsschritt werden Observability-Pipelines schnell fragmentiert, schwer abzufragen und teuer zu betreiben. Es gibt mehrere Möglichkeiten, sie je nach Skalierung, Komplexität und operativen Anforderungen zu verarbeiten.

Die folgenden sind gängige Verarbeitungsaktionen, die auf Observability-Pipelines angewendet werden.

6.2.3.1. Normalisierung/Transformation#

Daten kommen in verschiedenen Formaten. Arista sendet Metriken auf eine Weise, Cisco auf eine andere, Syslog ist Text, NetFlow ist binär. Normalisierung übersetzt all das in ein gemeinsames Format, damit das Backend nicht 50 verschiedene Dialekte verstehen muss.

Strukturierung

Geräte emittieren Daten auf eine für sie sinnvolle Weise. Die Aufgabe ist, das in ein Format zu übersetzen, das für die Analyse funktioniert:

• Log-basiert:

  Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

  zu

  {
  "timestamp": "2025-03-18T14:22:11Z",
  "level": "INFO",
  "device": "leaf01",
  "component": "interface",
  "event": "oper_state_change",
  "interface": "swp1",
  "previous_state": "UP",
  "current_state": "DOWN"
  }

• Metrik-basiert: <Metrikname>{<Labels>} <Wert>

  interface_admin_state{hostname="leaf01", ifname="swp1"} 1
  interface_oper_state{hostname="leaf01", ifname="swp1"} 0
  interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
  interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
  interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

• Tabellenbasiert: Manche Werkzeuge (z.B. Suzieq) organisieren Daten in tabellarische, zeitindexierte Zustandsansichten:

  | hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
  |----------|--------|------------|-----------|-------|----------|-----------|-----------|
  | leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
  | leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

Umbenennung und Ausrichtung

Verschiedene Telemetriequellen beschreiben dasselbe Konzept mit verschiedenen Namen, Pfaden und Label-Konventionen. Zum Beispiel:

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

Normalisierung richtet sie in ein konsistentes Modell aus, einschließlich Objektname, Label-Umbenennung und Wert (mit derselben Einheitenkonvertierung):

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. Anreicherung#

Anreicherung fügt den Observability-Daten zusätzlichen Inhalt hinzu, der über das tatsächlich Beobachtete hinausgeht. Diese zusätzlichen Dimensionen, die den Daten hinzugefügt werden, ermöglichen eine ausgefeiltere Datenkonsumierung. Zum Beispiel kann man verstehen, dass die Metriken zu einem Gerät gehören, das eine bestimmte Rolle im Netzwerk spielt, und entsprechend handeln.

Es gibt zwei Hauptansätze zur Anreicherung:

• Daten erweitern Hinzufügen von zusätzlichen Metadaten oder Labels zu den beobachteten Daten, um sie zu ergänzen. Diese Daten könnten statisch sein (z.B. org=my-company), um alle Daten zu markieren, dynamisch basierend auf dem Erfassungskontext (z.B. collector_id=1234) oder dynamisch basierend auf den beobachteten Daten selbst (z.B. für hostname=rtr-1 ein Label location=BCN-01 durch Korrelation mit dem SoT erstellen).

  intf_oper_state{
      name="swp1", 
      device="leaf01",
      role="leaf",
      location="BCN0001"
  } 1

• Neue Daten erstellen Nach dem Muster “Info-Metriken” des Prometheus-Ökosystems können Metriken generiert werden, die keinen tatsächlichen Zustand darstellen, sondern beabsichtigten Zustand. Diese Metriken sind in späteren Observability-Pipeline-Stufen nützlich, um Analysen mehr Dimensionen hinzuzufügen, wie im Alarmierungsabschnitt entdeckt wird.

  device_info{
      name="leaf1",
      role="leaf",
      vendor="arista",
      model="7050SX3",
      platform="eos",
      os_version="4.29.2F",
      location="BCN0001",
      rack="AB1",
      rack_unit="U32",
      environment="prod"
  } 1

  Info-Metriken sind eine kuriose Art von Daten, die die relevanten Daten nicht im Wert haben (z.B. die 1 in den vorherigen Metriken), sondern in den Labels. Dieser Trick ermöglicht die Wiederverwendung von Time Series Database (TSDB), die bestimmte Wertetypen (wie Strings) nicht unterstützen.

Beide Ansätze fügen Labels und Kontext hinzu. Das ist mächtig für Alarme und Analysen. Aber es gibt Kosten zu bedenken:

• Kardinalität: Jedes neue Label multipliziert die Zeitreihen. Gerät × Schnittstellen × Metriken ist bereits hochkardinäl. Labels unüberlegt hinzufügen und der Speicher explodiert, Abfragen verlangsamen sich. Bedacht vorgehen.
• Aktualisierungsfrequenz: Geräte-Racks und Management-IPs ändern sich nicht jede Sekunde. Keine Anreicherungsdaten wie volatile Metriken abfragen. Ereignisgesteuerte Updates funktionieren besser, weniger Abfragen an den Source of Truth.
• Resilienz: Wenn der Source of Truth offline geht, stoppt die Anreicherung. Cachen, um weiter zu funktionieren, auch wenn degradiert. Die Automatisierung ist auf diese Daten angewiesen, also sollte sie felsenfest sein.

6.2.3.3. Transformation / Ableitung / Aggregation#

Rohe Metriken nehmen und neue davon ableiten. Beispiel: Den gesamten Interface-Eingangsdatenverkehr von Leaf- und Spine-Switches zu einer einzigen “verwendeten Fabric-Bandbreite”-Metrik für Trendbewertung zusammenführen. Man kombiniert vorhandene Daten, um größere Fragen zu beantworten oder Dashboards zu speisen. Prometheus nennt das “Recording Rules”.

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

Im Prometheus-Ökosystem ist das als Recording Rules bekannt.

Eine weitere Verarbeitungsfunktionalität zur Reduzierung der Datenmenge ist Aggregation, durch Reduzierung der Dimensionalität angepasst an die endgültige Nutzung der Daten. Zum Beispiel Interface-Informationen pro Gerät zusammenfassen oder Geräteinformationen pro Standort zusammenfassen. Zum Beispiel können Ratenberechnungen aus Counter-Metriken oder Histogramm-Bucketing für viele Analysen nützlich sein.

6.2.3.4. Filterung#

Den Müll frühzeitig aussondern. Nicht jede Log-Zeile ist es wert, gespeichert zu werden. Nicht jede Interface-Metrik ist wichtig (vielleicht interessieren Loopbacks nicht). Je früher gefiltert wird, desto weniger wird für Speicher und Verarbeitung verschwendet. Erlaubnislisten (nur das behalten) sind sicherer als Verbotslisten (das aussondern).

6.2.3.5. Sampling / Throttling#

Auch nach der Filterung könnte das Volumen noch zu hoch sein. Drosseln. Probabilistisch sampeln (“10% dieser Anfragen behalten”), auf Top-K-Metriken fokussieren (“nur die 100 beschäftigsten Schnittstellen speichern”) oder pro Quelle rate-limiten (“max. 1000 Metriken pro Gerät”). Wenn Daten in der Datenbank altern, sie zusammenfassen (5-Sekunden-Granularität wird zu 5-Minuten-Durchschnitten), um Speicher zu sparen.

Schließlich können alle diese Prozessoren in verschiedenen Phasen der Observability-Pipeline ausgeführt werden, je nach Anwendungsfall:

• Collector: Am besten für leichtgewichtige, frühe Normalisierung und Filterung
• Dedizierter Prozessor: Bei Skalierung für dynamische Anreicherung und komplexe Transformationen erforderlich
• Persistenzschicht: Geeignet für Recording Rules und langfristige Rollups (Normalisierung sollte immer vorher erfolgen)
• Alarmierungsschicht: Leitet Ereignisse aus gespeicherten Daten ab und wendet Geschäftslogik an

In der Praxis verteilen effektive Observability-Pipelines die Verarbeitung über Schichten, abhängig von Tooling, Skalierung und operativen Einschränkungen.

6.2.4. Distribution#

Einfache lineare Pipelines (Collector → Prozessor → Datenbank) skalieren nicht. Wenn die Datenbank langsam wird, staut sich der Collector auf. Wenn der Prozessor aktualisiert werden muss, stoppt die Erfassung. Alles ist eng gekoppelt und fragil.

Hier kommen Message-Broker ins Spiel.

Message-Broker wie Apache Kafka oder NATS sitzen in der Mitte. Produzenten (Collector, Geräte) veröffentlichen in Themen. Konsumenten (Prozessoren, Datenbanken, Alarmierung) ziehen in ihrem eigenen Tempo. Vollständig entkoppelt.

Vorteile:

• Skalierung: Jede Komponente skaliert unabhängig.
• Resilienz: Wenn ein Konsument langsam ist, staut sich die Datenwarteschlange auf, anstatt verworfen zu werden.
• Flexibilität: Dieselben Daten speisen mehrere Backends ohne Duplizierung an der Quelle. Eine Komponente upgraden oder neu starten, ohne andere zu beeinflussen.

Mehr zu Skalierungs- und Zuverlässigkeitsmustern in Kapitel 11.

6.2.5. Persistenz#

Sobald Daten verarbeitet sind, müssen sie irgendwo leben. Die Datenbankschicht speichert alle Observability-Daten. Sie muss riesige Volumen handhaben, schnelle Abfragen unterstützen und die Kosten vertretbar halten.

Gute Datenbanken für Observability teilen gemeinsame Eigenschaften:

• Zeitbewusst: Daten sind inhärent mit Zeitstempeln versehen. Datenbanken optimieren für Bereichsabfragen und zeitfensterbezogene Berechnungen.
• Hoher Schreibdurchsatz: Ständige Metrik-Aufnahme. Datenbanken handhaben es, ohne langsamer zu werden.
• Mehrdimensional: Metriken tragen Labels (Gerät, Schnittstelle, Standort). Effizient abfragen und aggregieren.
• Flexible Abfragen: Ausdrucksstarke Sprachen (PromQL, LogQL) brauchen, um Daten zu erkunden ohne vordefinierte Schemas.
• Lebenszyklusverwaltung: Speicher wächst schnell. Retention, Downsampling, Löschung unterstützen, um Kosten zu kontrollieren.
• Schema-Flexibilität: Neue Metriken erscheinen ständig. Datenbanken handhaben Evolution ohne kostspielige Migrationen.

Welche Datenbanktypen funktionieren?

Keine einzige Datenbank handhabt alle Observability-Workloads perfekt, und wer etwas anderes behauptet, hat etwas zu verkaufen. Was tatsächlich funktioniert:

1. Zeitreihendatenbanken (Time Series Database (TSDB)): Hier fängt man an. Prometheus hat den Metrik-Krieg gewonnen. Sein Datenmodell (Metriken mit Labels) wurde zum De-facto-Standard, und PromQL ist die Abfragesprache, die jeder kennt. Prometheus verwenden, wenn man unter 100 Millionen aktiven Reihen ist. Darüber hinaus VictoriaMetrics ansehen (Prometheus-kompatibel, skaliert besser, verbraucht weniger Speicher). InfluxDB ist in Ordnung, aber die Lizenzierung ändert sich ständig. Anbieter-spezifische Lösungen meiden, außer wenn man bereits in ihr Ökosystem eingesperrt ist.

2. Spalten-Datenbanken: ClickHouse ist hier der König. Es ist absurd schnell für Log-Aggregation und Flow-Analyse. Wenn Milliarden von Zeilen für Berichte oder historische Analysen abgefragt werden müssen, ist das das Werkzeug. InfluxDB v3 versucht, zu konkurrieren, aber ClickHouse hat Jahre der Härtung. Parquet-Dateien funktionieren für Analyse-Workloads, bei denen keine Echtzeit-Schreibvorgänge benötigt werden (wie Suzieq).

3. Volltext-Suchdatenbanken: Elasticsearch wenn nötig, aber ehrlich gesagt sind moderne Alternativen wie Loki (von Grafana) einfacher und günstiger zu betreiben. Splunk ist großartig, wenn jemand anderes dafür bezahlt. Das schmutzige Geheimnis: Die meisten Teams überinvestieren in Log-Suche und unterinvestieren in strukturiertes Logging, das die Suche unnötig machen würde.

Empfehlung: Mit Prometheus (oder ähnlichem) für Metriken beginnen, Loki (oder ähnlichem) für Protokolle. ClickHouse (oder ähnliches) hinzufügen, wenn ernsthafte historische Analysen benötigt werden. Dieser Stack ermöglicht massive Skalierung, bevor etwas Ausgefeilteres benötigt wird.

Diese Klassifizierung ist nicht absolut; die meisten Werkzeuge haben eine primäre Klassifizierung, implementieren dann aber einige Eigenschaften anderer (besonders Zeitreihen).

Zwei wichtige Konzepte beim Speicherdesign: Kardinalität (wie viele eindeutige Werte kann ein Label annehmen) und Dimensionalität (wie viele Labels hat eine Metrik). Hochkardinale Labels multipliziert mit vielen Dimensionen = Explosion gespeicherter Daten und langsame Abfragen. Das ist eine der größten Herausforderungen in Observability. Kapitel 11 für tiefgehende Skalierungsüberlegungen konsultieren.

Nach all dem Datenmanagement gibt es zwei abschließende Schritte:

• Ereignisse für andere Automatisierungen oder menschliche Eingriffe erstellen: Alarmierung
• Daten visualisieren, um Informationen für die Entscheidungsfindung bereitzustellen: Visualisierung

6.2.6. Alarmierung#

Alarme verwandeln Daten in Aktionen. Das Ziel: Sie der Automatisierung zuführen. Menschen benachrichtigen, wenn Automatisierung es nicht beheben kann.

Alarme durchlaufen Phasen:

• Erkennung: Etwas Falsches in Daten finden.
• Verarbeitung: Mit Kontext anreichern. Ist es kritisch? Geringfügig? Falscher Alarm? Verwandte Alarme korrelieren, um Lärm zu reduzieren.
• Routing: An Orchestrierung senden (Workflows ausführen), Teams (Slack) oder Vorfallmanagement (PagerDuty).
• Eskalation: Wenn Automatisierung scheitert, übernehmen Menschen.

flowchart LR
    A[Erkennung] --> B[Prozessor] --> C[Routing] --> D[Eskalation]

Abbildung 5: Alarmphasen.

Das Schwierige ist nicht das Einrichten von Alarmen. Es ist die Verhinderung von Alarm-Müdigkeit. Ich habe NOCs mit 10.000 aktiven Alarmen gesehen, wo niemand mehr irgendwelche davon anschaut. An diesem Punkt hat man kein Monitoring, man hat teuren Lärm.

So behebt man es tatsächlich:

1. 95% der Alarme an Automatisierung routen, nicht an Menschen. Wenn ein Mensch einen Alarm sieht, sollte es sein, weil Automatisierung versucht und gescheitert ist. Schnittstelle flattert? Automatisierung prüft, ob es Wartung ist, startet die Optiken neu, eröffnet ein Ticket beim Anbieter. Menschen werden nur benachrichtigt, wenn Automatisierung es nicht beheben kann.

2. Statische Schwellenwerte abschaffen. “CPU > 80%"-Alarme sind nutzlos. 80% könnte für das Gerät normal sein. Dynamische Baselines verwenden: Alarmieren, wenn etwas von seinem historischen Muster abweicht, nicht von einer beliebigen Zahl.

3. Verwandte Alarme gruppieren. Wenn ein Core-Switch ausfällt, bekommt man 500 Alarme von nachgelagerten Geräten. Einen zeigen: “Core-Switch ausgefallen, 500 Geräte betroffen.” Nicht 500 einzelne Alarme.

4. Ein Runbook für jeden Alarm verlangen. Wenn man nicht aufschreiben kann, was jemand tun sollte, wenn er den Alarm bekommt, den Alarm löschen. Ernsthaft. Wenn die Aktion “untersuchen” ist, ist das keine Aktion, das ist Zeitverschwendung.

5. Alarmqualität messen. False-Positive-Raten verfolgen. Jeder Alarm mit >10% False Positives wird behoben oder gelöscht. Zeit-bis-Bestätigung verfolgen. Wenn Alarme stundenlang unbestätigt bleiben, sind sie nicht wichtig genug, um zu existieren.

Das Ziel ist nicht “umfassendes Monitoring”. Das Ziel ist “Menschen nur für Dinge benachrichtigen, die Menschen beheben müssen”.

6.2.6.1. Die Rolle von KI und AIOps in Observability#

Lassen Sie uns den Hype durchdringen: Die meiste “KI-gestützte Observability” ist nur Anomalieerkennung mit einem Marketing-Budget. Das gesagt, gibt es hier echten Wert, wenn er korrekt eingesetzt wird.

Was tatsächlich funktioniert:

• Anomalieerkennung: ML ist wirklich besser als statische Schwellenwerte darin, “normal” für jedes Gerät zu lernen. CPU bei 85% könnte für Gerät A in Ordnung sein, für Gerät B eine Katastrophe. ML findet das automatisch heraus. Das ist heute Grundvoraussetzung, keine Magie.

• Alarmkorrelation: Wenn 50 Dinge gleichzeitig brechen, kann ML sie gruppieren und vorschlagen “der Core-Switch ist wahrscheinlich die Ursache.” Spart Stunden an Troubleshooting. Aber man braucht immer noch Menschen zur Verifizierung, weil ML in 20% der Fälle falsch liegt.

• Kapazitätsprognose: ML ist passabel bei “basierend auf Trends wird dieser Link in 6 Wochen gesättigt sein.” Besser als Menschen, die auf Graphen starren. Braucht immer noch menschliches Urteil, ob es wichtig ist.

Was übertrieben wird:

• Automatische Ursachenanalyse: Jeder Anbieter verspricht das. Keiner liefert zuverlässig. Man bekommt Vorschläge, manchmal gute, aber “KI hat das Problem diagnostiziert und behoben” ist zu 95% Marketing und zu 5% ausgewählte Beispiele.

• Selbstheilende Netzwerke: Automatisierung kann bekannte Probleme mit bekannten Lösungen beheben. Das ist keine KI, das ist gutes Engineering. Echte “Selbstheilung” bei neuartigen Problemen existiert noch nicht. Wenn Anbieter es demonstrieren, nach den Fehlerfällen fragen.

• “AIOps ersetzt Ihr NOC”: Nein. AIOps hilft dem NOC, effektiver zu sein. Das menschliche Urteil, der Geschäftskontext und die Fähigkeit, Sonderfälle zu handhaben? Das sind immer noch Menschen.

Fazit: ML für Anomalieerkennung und Alarm-Ranking verwenden. Bei allem anderen skeptisch sein, bis es auf dem eigenen Netzwerk getestet wurde, nicht in einer Anbieter-Demo.

6.2.6.2. Die Alarm-zu-Aktion-Schnittstelle#

Ein Alarm, den ein Mensch liest, ist eine Benachrichtigung. Ein Alarm, den Automatisierung konsumiert, ist ein Vertrag. Diese beiden Konsumenten haben verschiedene Anforderungen, und ihr Verwechseln ist einer der häufigsten Gründe, warum Alarmierungs-Pipelines an der Orchestrator-Grenze scheitern.

Wenn ein Alarm für Automatisierung bestimmt ist, muss seine Payload maschinell konsumierbar sein, ohne Parsing. Das bedeutet strukturierte Daten, keine für Menschen lesbare Betreffzeile. Mindestens sollte eine für Automatisierung bestimmte Alarm-Payload enthalten:

• Geräteidentität: Ein kanonischer Bezeichner, der genau mit dem SoT-Datensatz übereinstimmt (kein Hostname, der sich zwischen DNS und dem CMDB unterscheiden kann)
• Alarmklasse: Ein stabiler, aufgelisteter Typ, auf dem der Orchestrator routen kann (keine Freitext-Beschreibung, die sich ändert, wenn jemand die Alarmregel bearbeitet)
• Schweregrad: Eine definierte Aufzählung, kein numerischer Schwellenwert
• Zeitstempel: Die Ereigniszeit in UTC ISO 8601, nicht die Zustellungszeit der Benachrichtigung
• Relevanter Kontext: Die spezifische Metrik oder der Zustand, der den Alarm ausgelöst hat, in einem Feld, das der Orchestrator direkt lesen kann (z.B. "interface": "Ethernet0/1", nicht in der Nachrichtenzeichenkette eingebettet)
• Quelltrace: Ein Link oder eine Referenz zurück zum Rohereignis im Observability-System, damit der Orchestrator für zusätzlichen Kontext erneut abfragen kann

Eine Payload, die diesen Vertrag erfüllt, erlaubt dem Orchestrator, den Alarm an den richtigen Workflow zu routen, die Geräteidentität an die SoT-Abfrage zu übergeben und den Executor mit strukturierten Parametern aufzurufen, ohne String-Parsing. Eine Payload, die diesen Vertrag nicht erfüllt, zwingt den Orchestrator, für Menschen lesbaren Text zu parsen, was bei jeder Änderung der Alarmbeschreibung bricht.

Diesen Vertrag definieren, bevor die Alarmregeln aufgebaut werden, nicht danach. Alarmregel-Autoren, die für menschliche Lesbarkeit schreiben, produzieren Nachrichten, die schwer zu automatisieren sind. Alarmregel-Autoren, die für beide Zielgruppen schreiben, produzieren Nachrichten, die keiner gut dienen. Die sauberste Lösung sind zwei parallele Routing-Pfade: ein Alarmformat für Menschen (Slack, PagerDuty), eines für Automatisierung (Message-Queue, Webhook-Endpunkt). Beide durch dieselbe Erkennungsregel ausgelöst; verschiedene Payload-Vorlagen für verschiedene Konsumenten.

6.2.7. Visualisierung#

Ziel: Alle beobachteten Daten sollten Entscheidungsträgern Wert liefern, daher sollte das Erstellen nutzerorientierter Visualisierungen den Benutzerbedürfnissen entsprechen.

Der abschließende Block ist die Dashboard/Bericht-Schicht. Ich sage es direkt: Die meisten Dashboards sind schrecklich. Sie sind entweder Eitelkeitsmetriken, die Führungskräfte gut aussehen lassen (“99,99% Verfügbarkeit!”), oder sie sind Daten-Erbrochenes (50 Graphen pro Bildschirm, niemand weiß, was irgendeiner davon bedeutet).

Wie man Dashboards aufbaut, die tatsächlich helfen:

• Für Entscheidungen bauen, nicht für Dekoration. Jedes Widget sollte eine spezifische Frage beantworten oder eine spezifische Aktion auslösen. Wenn jemand auf einen Graphen schaut und nicht weiß, was damit zu tun ist, den Graphen löschen.

• Probleme zeigen, nicht nur Daten. Grün/Gelb/Rot-Signale schlagen rohe Zahlen. “Interface-Auslastung: 45%” ist nutzlos. “Interface-Auslastung: normal” oder “Interface-Auslastung: WARNUNG, tendiert zur Sättigung” ist handlungsfähig.

• Hierarchisches Drill-down schlägt ein großes Dashboard. Mit einer globalen Gesundheitsübersicht beginnen (“3 Standorte haben Probleme”). Auf einen Standort klicken, um Gerätegesundheit zu sehen. Auf ein Gerät klicken, um Schnittstellen zu sehen. Fünf fokussierte Dashboards schlagen eine chaotische Katastrophe.

• Auf die Zielgruppe abstimmen. NOC-Mitarbeiter brauchen Echtzeit-Betriebsstatus und Drill-down. Manager brauchen Trend-Zusammenfassungen und Geschäftsauswirkungen. Ingenieure brauchen Rohdatenzugriff und Abfrageschnittstellen. Ein Dashboard, das alle bedienen will, bedient niemanden.

• Interaktiv machen oder nicht der Mühe wert. Statische Dashboards altern schlecht. Filtern, zoomen, Zeitbereiche anpassen lassen. Untersuchungen unterstützen, nicht nur hübsche Bilder zeigen.

Und hier ist die kontroverse Meinung: Die meisten Teams haben zu viele Dashboards. Ich habe Organisationen mit 200+ Dashboards gesehen, wo jede Person 2 davon anschaut. Die Dashboards löschen, die niemand nutzt. Wenn niemand sie 3 Monate lang anschaut, sind sie nicht wichtig.

Die Visualisierungs-/Präsentationsgrenze

Visualisierung sitzt an einer Architekturgrenze, die direkt anzusprechen ist, statt sie in eine Fußnote zu verbannen. Die Präsentationsschicht (Kapitel 8) ist für benutzergerichtete Schnittstellen verantwortlich: Zugangskontrolle, Self-Service-Portale, ITSM-Integration und das UX-Design, wie Menschen Informationen anfordern und konsumieren. Die Visualisierung von Observability-Daten gehört hier in Kapitel 6, weil die Designentscheidungen vollständig von den Daten getrieben werden: welche Metriken verfügbar sind, wie die Alarmierung strukturiert ist, welche Drill-down-Pfade die Persistenzschicht unterstützt. Man kann kein effektives Observability-Dashboard entwerfen, ohne das dahinterliegende Datenmodell zu verstehen.

Die Unterscheidung, die in der Praxis wichtig ist: Dashboards, die direkt auf Observability-Daten für operative Entscheidungen aufgebaut sind (was passiert gerade, ist dieser Dienst gesund), sind eine Observability-Angelegenheit. Wie dieselben Dashboards nicht-technischen Benutzern zugänglich gemacht, in ein Self-Service-Portal eingebettet oder mit Change-Management-Workflows integriert werden, ist eine Präsentationsangelegenheit. Kapitel 8 revisitiert diese Werkzeuge aus dieser Zugangs- und Workflow-Perspektive. Die meisten Visualisierungswerkzeuge (Grafana ist das verbreitetste) verwischen diese Grenze, indem sie beides tun, weshalb die Trennung künstlich wirkt. Das ist sie nicht. Die Anliegen sind wirklich verschieden, auch wenn dasselbe Werkzeug beides bedient.

Die grundlegenden Regeln:

• Klarheit: Leicht zu verstehen. Jedes Element hat einen Zweck.
• Relevanz: Nur Daten zeigen, die Entscheidungen unterstützen. Lärm tötet Erkenntnisse.
• Nutzerfokus: Für die Zielgruppe aufbauen. NOC-Mitarbeiter und Manager brauchen verschiedene Ansichten.
• Interaktiv: Drill-down, Zoom, Zeitanpassung erlauben. Untersuchungen unterstützen.
• Hierarchisch: Globale Übersicht zuerst, dann Drill-down. Viele fokussierte Dashboards schlagen ein chaotisches Dashboard.

flowchart TD
    A[Globale Übersicht] --> B[Standort-Zusammenfassung] --> C[Geräte-Zusammenfassung] --> D[Gerätedetail] --> E[Schnittstellendetail]

Abbildung 6: Hierarchisches Drill-down.

Im Buch Modern Network Observability, Kapitel 11 (“Application of Your Observability Data”), findet man viel mehr Details zur Architektur von Dashboards.

Denken Sie daran, dass dieser Block sehr mit der Benutzerwahrnehmung zusammenhängt, also vergessen Sie nicht, Benutzer zu befragen und in den Prozess einzubeziehen.

6.2.8. Observability des Automatisierungssystems#

Die meisten Teams bauen Observability für das Netzwerk auf. Fast niemand baut Observability für das Automatisierungssystem selbst. Das ist ein bedeutender blinder Fleck: Wenn die Automatisierungspipeline bricht, ist der Ausfall oft still. Kein Alarm feuert, weil das für die Alarmgenerierung verantwortliche System möglicherweise das ist, das gerade aufgehört hat zu funktionieren.

Ein Playbook, das mit Status 0 endet, nachdem es für null Geräte bereitgestellt hat, generiert keinen Fehler. Eine Telegraf-Instanz, die still aufhört, ein anbieterspezifisches Protokoll abzufragen, produziert keinen Fehlende-Daten-Alarm, es sei denn, man instrumentiert speziell dafür. Ein SoT-Sync-Job, der um 2 Uhr morgens fehlschlägt und das Inventar 12 Stunden lang veraltet lässt, wird dazu führen, dass jede nachfolgende Ausführung mit veralteten Gerätelisten läuft, und nichts wird signalisieren, dass das passiert ist.

Was in der Automatisierungsplattform zu überwachen ist

• Ausführungsschicht (AWX, Ansible):

  • Job-Erfolgsrate über die Zeit: eine langsam steigende Fehlerrate ist eine Frühwarnung, dass etwas degradiert
  • Ausführungsdauer: Ein Job, der normalerweise 4 Minuten dauert und 40 Minuten benötigt, signalisiert ein Problem mit der Plattform, dem Netzwerk oder beidem
  • Jobs, die über ihrem erwarteten Fenster im ausstehenden oder laufenden Status stecken
  • Rollback-Frequenz: Eine steigende Rollback-Rate bedeutet normalerweise, dass Intent-Daten oder Vorlagen einen Defekt haben
  • Pro Job erreichte Geräte im Vergleich zu erwarteten: Eine Bereitstellung, die 10 Geräte statt 800 berührt, hat möglicherweise still ihre Inventarsynchronisierung fehlgeschlagen ohne Fehler

• Source-of-Truth-Schicht:

  • API-Antwortzeit und Fehlerrate: Eine langsame SoT-API stoppt jeden Ausführungsjob, der sie abfragt
  • Sync-Job-Gesundheit pro Quelle: Letzter erfolgreicher Sync-Zeitpunkt, Anzahl aufeinanderfolgender Fehler
  • Datenvollständigkeit: Wie viele Gerätedatensätze haben Pflichtfelder, von denen die Ausführung abhängt

• Erfassungsschicht:

  • Letzter erfolgreicher Erfassungs-Zeitstempel pro Gerät: Ein Gerät, das in drei aufeinanderfolgenden Intervallen nicht abgefragt wurde, ist effektiv ein Monitoring-blinder Fleck
  • Erfassungsverzögerung über die Flotte: Wenn das durchschnittliche Datensalter wächst, ist der Collector im Rückstand
  • Verpasste Polling-Zyklen pro Protokoll: SNMP-Fehler und gNMI-Abonnement-Abbrüche sollten separat gezählt und alarmiert werden

Das Problem des stillen Ausfalls

Die am schwierigsten zu erkennenden Automatisierungsausfälle sind Jobs, die erfolgreich abschließen, aber keine bedeutsame Änderung produzieren. Ein Playbook, das aufgrund eines defekten Inventarfilters für null Geräte bereitgestellt hat, wird mit Status 0 beenden. Die einzige Möglichkeit, diese Fehlerklasse zu erkennen, ist die Instrumentierung auf der Ergebnis-Ebene: “Hat die erwartete Anzahl von Geräten den Zustand geändert?” statt “Hat der Job-Prozess sauber beendet?”

Das bedeutet, Ergebnis-Metriken zu Ausführungsjobs hinzuzufügen: einen Zähler für erfolgreich konfigurierte Geräte, eine Gauge für Geräte, die Rollback benötigten, und eine Prüfung, dass der Job mindestens N Geräte berührt hat, bevor er als erfolgreich markiert wird.

Architektonische Empfehlung

Die Automatisierungsplattform in einem separaten, minimalen Observability-Stack überwachen, der nicht vom primären Observability-System abhängt, das er unterstützt. Wenn die primäre Prometheus-Instanz ausfällt, sollte die Alarmierung für die Automatisierungspipeline nicht mit ihr ausfallen. Ein leichtgewichtiger sekundärer Stack (oder ein SaaS-Alarmdienst), der nur die Gesundheit der Kernautomatisierungskomponenten abdeckt (AWX, Telegraf, SoT-API, Sync-Jobs), bietet ein Sicherheitsnetz, das das primäre Observability-System nicht für sich selbst bereitstellen kann.

Das verbindet sich direkt mit Kapitel 7 (Orchestrierung): Ein gesunder Orchestrator sollte seinen eigenen Betriebszustand als erstklassige Angelegenheit melden. Wenn der Orchestrator nicht beobachtet werden kann, kann es auch die von ihm koordinierte Automatisierung nicht.

6.3. Implementierungsbeispiel#

Dieser Abschnitt veranschaulicht, wie die Observability-Funktionalitäten durch einen praktischen Anwendungsfall zusammenwirken, unter Verwendung des Telegraf-, Prometheus- und Grafana-Stacks und anderer Werkzeuge.

Das ist überhaupt keine Werkzeugempfehlung, aber weil es vollständig auf Open-Source-Komponenten aufgebaut ist, kann man es ausprobieren.

6.3.1. Anwendungsfall: Post-Deployment-Validierung und laufendes Monitoring eines Campus-Diensts#

Wir setzen mit dem Campus-Netzwerk aus Kapitel 5 fort. Der neue VLAN-Dienst wurde vom Ausführungsblock über alle Ziel-Switches in Gebäude B bereitgestellt. Jetzt übernimmt Observability: zuerst um zu validieren, dass die Bereitstellung aus einer Netzwerkzustandsperspektive tatsächlich erfolgreich war, dann um die Dienstgesundheit kontinuierlich über das gesamte Campus zu überwachen.

Szenario: Nach der Bereitstellung eines neuen VLAN-Dienstesegments über ~800 Campus-Switches von Cisco, Arista und HPE muss das Betriebsteam bestätigen, dass der Dienst aktiv und konsistent auf allen beabsichtigten Geräten ist, Konfigurationsdrift erkennen, wenn ein Switch das VLAN verliert, und den Dienst-Datenverkehr über die Zeit überwachen, ohne manuelle gerätespezifische Prüfungen.

Anforderungen:

• VLAN-Mitgliedschaft nach der Bereitstellung auf allen Ziel-Switches validieren und Konsistenz sicherstellen
• Konfigurationsdrift alarmieren: VLAN fehlt auf einem Switch, unerwartete Trunk-Mitgliedschaftsänderungen
• Dienst-Datenverkehrsgesundheit überwachen: Auslastungsniveaus und Fehlerraten pro Access-Port
• Plötzliche Datenverkehrsspitzen erkennen (>50% Änderung), die auf fehlgeleitete Flows hinweisen könnten
• 30 Tage Daten bei 30-Sekunden-Auflösung für Compliance und Kapazitätsplanung aufbewahren
• Integration mit Nautobot für Geräteinventar und VLAN-Intent-Daten
• Orchestrierungs-Workflows für automatisierte Behebung auslösen, wenn Drift erkannt wird

6.3.2. Lösungsarchitektur#

Vor der Lösungsanalyse ist eine Schätzung der Skalierung des Szenarios wichtig. Mit ~800 Campus-Switches × 48 Ports × 8 Metriken = ungefähr 307K aktive Zeitreihen. Das liegt gut innerhalb der Kapazität eines einzelnen Prometheus-Knotens (komfortabel bis ~1M Reihen), aber die Collector-Schicht braucht mehrere Telegraf-Instanzen, um die Polling-Last über 800 Geräte bei 30-Sekunden-Intervallen zu verteilen.

Begründung für die Komponentenauswahl:

• Telegraf wurde als Collector gewählt wegen seiner Multi-Protokoll-Unterstützung (SNMP für ältere HPE- und ältere Cisco-Geräte, gNMI für Arista- und neuere Cisco-Plattformen), dem umfangreichen Plugin-Ökosystem und eingebauten Prozessoren für Datennormalisierung. Bei 800-Geräte-Skalierung wäre eine einzelne Telegraf-Instanz bei 30-Sekunden-Polling-Intervallen überstreckt, daher werden zwei oder drei Instanzen mit Consul eingesetzt, das koordiniert, welche Ziele jede besitzt.
• Prometheus dient als Persistenzschicht, optimiert für Zeitreihendaten mit seiner leistungsstarken PromQL-Abfragesprache für komplexe Alarmbedingungen. Bei 32K Reihen operiert es gut innerhalb seiner Komfortzone und bietet native Integration mit Alertmanager.
• Grafana bietet Visualisierung mit Multi-Datasource-Unterstützung, die sowohl Prometheus-Metriken als auch Nautobot-Metadaten gleichzeitig abfragt, um kontextreiche Dashboards für verschiedene Zielgruppen zu erstellen (NOC, Kapazitätsplanung, Management).

Architektur

Auf hoher Ebene zeigt die folgende Abbildung die Hauptkomponenten und Rollen:

flowchart TB
    subgraph Sources["Datenquellen"]
        NB[Nautobot<br/>Source of Truth]
        SW[Netzwerkgeräte<br/>SNMP/gNMI]
    end

    subgraph Collection["Erfassungsschicht"]
        T[Telegraf<br/>Collector]
        SD[Consul<br/>Service Discovery]
    end

    subgraph Storage["Speicher"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["Alarmierung"]
        AM[Alertmanager<br/>Routing]
    end

    subgraph Presentation["Visualisierung"]
        G[Grafana<br/>Dashboards]
    end

    subgraph Integration["Externe Systeme"]
        ORCH[Orchestrator<br/>Automatisierung]
        SLACK[Slack<br/>Benachrichtigungen]
    end

    NB -->|Geräteinventar| SD
    SD -->|Dynamische Ziele| T
    SW -->|Metriken| T
    T -->|HTTP exponieren| P
    P -->|Alarmregeln| AM
    P <-->|Abfragen| G
    NB -->|Metadaten| G
    AM -->|Webhook| ORCH
    AM -->|Alarme| SLACK

Abbildung 7: Observability-Lösungsbeispiel.

Diese vereinfachte Lösungsarchitektur wird im Buch Modern Network Observability ausführlich behandelt. Wenn man einen praktischen Ansatz mit einem Labor-Szenario zum Testen möchte, gibt es die Möglichkeit, es auszuprobieren.

6.3.3. Implementierungsablauf#

Inventarintegration: Nautobot dient als einziger Source of Truth und definiert, welche Geräte mit Monitoring-Profilen und SNMP-Zugangsdaten überwacht werden sollen. Ein leichtgewichtiger Sync-Dienst (z.B. Python-Skript mit Webhooks) aktualisiert kontinuierlich Consuls Service-Registry mit Geräteinformationen und ermöglicht dynamische Erkennung vom Collector.

Datenerfassung: Telegraf verwendet Consul für Service-Discovery und pollt automatisch SNMP von Geräten, sobald sie in Nautobot erscheinen. Telegraf-Prozessoren normalisieren und reichern Daten an (konvertieren Statuscodes in Labels, benennen Felder in Standardnamen um und fügen kontextuelle Informationen aus Nautobot hinzu) und exponieren Metriken im Prometheus-Format auf einem HTTP-Endpunkt.

Persistenz und Analyse: Prometheus scrapt Telegraf-Endpunkte über Consul-Service-Discovery und speichert Metriken in seiner Zeitreihendatenbank. Recording Rules berechnen Interface-Auslastungsprozentsätze und Bandbreitenraten vorab, um die Abfrageleistung zu optimieren.

Alarmierungslogik: Alarmregeln in Prometheus definieren Bedingungen (z.B. Interface-Auslastung >80% für 5 Minuten, Datenverkehrsspitzen >50% Anstieg). Wenn Bedingungen übereinstimmen, handhabt Alertmanager das Routing: Kritische Alarme mit automation: enabled-Labels gehen an den Orchestrator-Webhook, andere werden basierend auf Schweregrad an Slack oder PagerDuty geleitet.

Visualisierung: Grafana-Dashboards bieten mehrere Ansichten: fabric-weite Bandbreitentrends, am stärksten gesättigte Schnittstellen, Geräte-Drill-downs mit Schnittstellen-Heatmaps. Template-Variablen ermöglichen das Filtern nach Standort, Rolle oder Gerät. Dashboards fragen sowohl Prometheus (Metriken) als auch Nautobot (Gerätemetadaten) für kontextuelle Anreicherung ab.

Closed-Loop-Automatisierung: Wenn kritische Sättigungsalarme feuern, sendet Alertmanager Webhooks an die Orchestrierungsplattform, die automatisierte Traffic-Engineering-Workflows auslöst, um Last über verfügbare Pfade umzuverteilen. Wir behandeln diese Komponente in Kapitel 7.

6.3.4. Lösungszusammenfassung#

Operative Vorteile:

• Reduzierter manueller Monitoring-Aufwand durch SoT-Integration
• Proaktive Problemerkennung mit Sub-Minuten-Latenz
• Closed-Loop-Behebung reduziert MTTR von Stunden auf Minuten
• Reichhaltiger Kontext, der Metriken mit Inventardaten kombiniert

Skalierungsüberlegungen:

• Die aktuelle Architektur handhabt ~800 Campus-Switches mit 2-3 verteilten Telegraf-Instanzen hinter Consul; das Hinzufügen weiterer Gebäude oder Geräte bedeutet das Hinzufügen weiterer Collector-Instanzen, keine Neuarchitektur
• Prometheus-Kapazität ist bei ~307K Reihen mit Wachstumsraum ausreichend; ein einzelner Knoten handhabt bis zu ~1M Reihen, bevor Federation oder ein verteiltes Backend benötigt wird

Diese kurze Lösungsübung schließt dieses Kapitel, das die grundlegenden Ziele und Funktionalitäten von Observability innerhalb einer Netzwerkautomatisierungsarchitektur definiert.

6.4. Zusammenfassung#

Observability in der Netzwerkautomatisierung geht weit über traditionelles Monitoring hinaus und bietet die Architekturgrundlage für das Verständnis des Netzwerkverhaltens, die proaktive Problemerkennung und die Ermöglichung automatisierter Behebung im großen Maßstab. Aufgebaut auf sieben Kernzielen - von automatischer Erkennung mit minimalem menschlichen Aufwand bis hin zu anspruchsvollen Echtzeit-Analysen und nutzerorientierten Visualisierungen - transformiert Observability, wie Organisationen auf Netzwerkereignisse reagieren, indem sie vom reaktiven Troubleshooting zu proaktivem, datengetriebenem Betrieb übergehen.

Die Realisierung dieser Ziele erfordert sieben miteinander verbundene Architektur-Säulen und Funktionalitäten: SoT-Integration für automatische Inventarerkennung, Multi-Protokoll-Collector, die nahezu Echtzeit-Datenaufnahme durch Streaming-Telemetrie und moderne Protokolle unterstützen, Prozessoren, die heterogene Daten mit kontextuellen Metadaten normalisieren und anreichern, verteilte Systeme für skalierbare Datenbewegung bei hohen Volumen, zweckgebaute Datenbanken (z.B. Zeitreihen-, spaltenbasierte und Volltext-Suche), die für verschiedene Observability-Workloads optimiert sind, intelligente Alarmierung mit KI/ML-verbesserter Erkennung und Routing an Orchestrierung oder menschliche Responder, sowie maßgeschneiderte Visualisierungen, die Informationen auf angemessenen Abstraktionsebenen für verschiedene Zielgruppen präsentieren.

Die Implementierung von Observability erfordert frühe Architekturentscheidungen im Designprozess. Organisationen müssen zwischen traditionellen On-Premises-Plattformen, Cloud-nativen SaaS-Lösungen, die schnelle Bereitstellung und KI-gestützte Analytik bieten, oder zusammensetzbaren Open-Source-Stacks wählen, die maximale Flexibilität bieten. Jeder Ansatz beinhaltet Abwägungen in Kosten, Kontrolle, Betriebsaufwand und Fähigkeit. Erfolg hängt auch vom Verständnis der Datenverarbeitungsanforderungen ab - von Normalisierung und Anreicherung bis hin zu Filterung und Aggregation - und wie aufkommende AIOps-Fähigkeiten Alarm-Müdigkeit reduzieren und prädiktiven Betrieb ermöglichen können.

Observability ist kein einzelnes Werkzeug, sondern ein kohärentes Architekturmuster. Erfolg hängt davon ab, es als System zu behandeln, bei dem Inventar die Erfassung antreibt, Erfassung die Verarbeitung ermöglicht, Verarbeitung die Distribution speist, Distribution sich mit Persistenz verbindet, Persistenz die Alarmierung informiert und Alarmierung letztendlich Visualisierung und automatisierte Reaktion antreibt. Durch sorgfältiges Design jeder Komponente und ihrer Interaktionen können Organisationen Observability-Systeme aufbauen, die mit ihren Netzwerken skalieren, sich mit modernen Protokollen wie OpenTelemetry und gNMI integrieren und operative Sichtbarkeit in handlungsfähige Intelligenz umwandeln, die Closed-Loop-Automatisierung ermöglicht.

Referenzen und weiterführende Literatur#

• Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): Ein praktischer Ansatz mit Open-Source-Werkzeugen wie Telegraf, Prometheus und Grafana

💬 Found something to improve? Send feedback for this chapter