Grundlegendes zur Junos-Telemetrie

Netzwerk-Telemetrie

Netzwerktelemetrie ist der Prozess der Erfassung, Übertragung und Analyse von Daten von Netzwerkgeräten. Diese Daten können Informationen über Verkehrsmuster, Gerätestatus, Fehlerraten und andere Metriken enthalten, die Einblicke in den Zustand und das Verhalten des Netzwerks geben. Aus diesen Daten können Sie nützliche Erkenntnisse ziehen und diese Informationen anwenden, um die Netzwerkleistung und -sicherheit effektiv zu überwachen und zu verwalten. Netzwerkadministratoren können Telemetriedaten nutzen, um Netzwerkprobleme zu beheben, Anomalien zu erkennen und die Ressourcennutzung im gesamten Netzwerk zu optimieren. Einer der wichtigsten Vorteile der Netzwerktelemetrie ist die Möglichkeit, Einblicke in Echtzeit in den Netzwerkbetrieb zu gewähren.

Auch die Netzwerktelemetrie spielt eine entscheidende Rolle bei der Verbesserung der Netzwerksicherheit. Durch die Analyse von Telemetriedaten können Sicherheitsteams ungewöhnliche Muster erkennen, die auf einen Cyberangriff oder andere Sicherheitsbedrohungen hinweisen könnten, und so eine schnellere Erkennung und Reaktion auf potenzielle Sicherheitsvorfälle ermöglichen und zum Schutz des Netzwerks und seiner Daten beitragen.

Junos Telemetrie

Junos Telemetry ist die Telemetrielösung von Juniper, die für das Streamen von Telemetriedaten entwickelt wurde. Es ist hochgradig skalierbar und kann die Fernüberwachung mehrerer Geräte in einem Netzwerk unterstützen. Darüber hinaus trägt es dazu bei, die Fehlerbehebung zu verbessern, das Netzwerk proaktiv zu verwalten und die Betriebskosten zu senken.

Junos Telemetry kann in einer Vielzahl von Netzwerkszenarien angewendet werden:

• Leistungsüberwachung: Überwachen Sie wichtige Kennzahlen wie Schnittstellenauslastung, Latenz und Paketverluste, um eine optimale Netzwerkleistung zu gewährleisten.

• Sicherheitsüberwachung: Verfolgen Sie Sicherheitsereignisse, analysieren Sie Datenverkehrsmuster und identifizieren Sie potenzielle Sicherheitsbedrohungen.

• Application Performance Management: Gewinnen Sie Einblicke in die Anwendungsleistung, indem Sie Netzwerkdaten mit Anwendungsdaten korrelieren.

• Planung der Netzwerkkapazität: Analysieren Sie historische und Echtzeitdaten, um potenzielle Engpässe zu identifizieren und für zukünftige Kapazitätsanforderungen zu planen.

Andere Anwendungen von Juniper nutzen ebenfalls Junos Telemetry, um Echtzeitdaten bereitzustellen und die Synchronisierung des Betriebszustands zwischen Netzwerkelementen und einem externen Controller zu unterstützen, wie z. B. Mist von Juniper, Routing Director von Juniper und Apstra.

Modellgesteuerte Telemetrie

Junos Telemetry nutzt eine MDT-Architektur (Model Driven Telemetry). Ein modellgesteuertes Netzwerktelemetriesystem ist ein fortschrittlicher Ansatz für die Netzwerküberwachung, der Datenmodelle nutzt, um Telemetriedaten von Netzwerkgeräten zu definieren und zu sammeln. In diesem System werden Datenmodelle mithilfe einer YANG-Sprache (Yet Another Next Generation) definiert, um die Struktur und die Art der zu sammelnden oder zu streamenden Daten zu spezifizieren.

Juniper unterstützt derzeit zwei verschiedene Datenmodelle:

• Natives Datenmodell von Juniper

• OpenConfig-Datenmodell

Beide Modelle verwenden YANG, um die Datenstruktur und die Datentypen anzugeben, die gestreamt werden sollen. Weitere Informationen finden Sie unter Datenmodelle.

Sensoren und Sensorwege

Telemetriesensoren sind ein wichtiger Bestandteil einer Telemetrielösung. Sie messen verschiedene physikalische, Umgebungs- und Leistungsparameter und wandeln sie in Daten um, die über gNMI- oder UDP-Verbindungen zur Fernüberwachung und -analyse an den Kollektor übertragen werden. Einige Beispiele sind Temperatursensoren, Trennschichtsensoren, Durchflusssensoren usw. Ein Telemetriesensorpfad ist eine bestimmte Route innerhalb eines Datenmodells, die mithilfe von YANG definiert wird und die genauen Daten angibt, die von einem Netzwerkgerät erfasst und gestreamt werden sollen. Juniper unterstützt sowohl Openconfig als auch native Sensoren. Openconfig-Sensoren verfolgen zähler- oder zustandsbasierte Metriken, während native Sensoren effektiv ereignisgesteuerte Metriken verfolgen, da diese Sensoren Zugriff auf detaillierte Gerätedaten haben. Sie können Openconfig-basierte Sensorpfade konfigurieren, um Sensorinformationen in einem herstellerneutralen Format abzurufen, oder native Sensorpfade konfigurieren, um proprietäre Informationen von Juniper in einem nativen Format abzurufen. Weitere Informationen finden Sie unter Untersuchen von Sensorpfaden.

Telemetriedatensammler

Der Telemetriesammler ist ein spezielles Tool oder eine spezielle Software, die die Datenerfassung, -verarbeitung, -übertragung und -speicherung von Telemetriedaten durchführt. Es fungiert als Vermittler zwischen den Junos-Geräten, die Telemetriedaten generieren, und den Backend-Systemen, die diese Daten speichern, analysieren und visualisieren.

Funktionen eines Datensammlers:

• Datenerfassung: Der Datensammler empfängt Telemetriedaten von Juniper Geräten über gRPC-, gNMI- oder UDP-Verbindungen.
• Datenverarbeitung: Der Collector verarbeitet die gesammelten Daten, indem er sie aggregiert und normalisiert, um unnötige Informationen herauszufiltern, Metriken zu aggregieren und eine erste Analyse durchzuführen. Diese Verarbeitung trägt dazu bei, das Datenvolumen zu reduzieren und sich auf die wichtigsten Metriken zu konzentrieren.
• Datenübertragung: Es sorgt für eine zuverlässige Datenübertragung und geringe Latenz.
• Datenspeicherung: Die verarbeiteten Daten werden dann zur weiteren Analyse, Visualisierung und Speicherung in verschiedene Backend-Systeme exportiert. Sie können in Data Lakes für langfristige Analysen und historische Vergleiche gespeichert werden. Der Kollektor unterstützt mehrere Datenformate und Protokolle und ist daher mit verschiedenen Überwachungs- und Analysetools kompatibel. Die analysierten Daten können über interaktive Dashboards und Berichte dargestellt werden, die Netzwerkadministratoren umsetzbare Erkenntnisse liefern.

Telemetriemodi

Die Junos Telemetrie unterstützt Telemetriesitzungen in zwei Modi:

• Einwahl-Modus
• Dial-Out-Modus

Juniper Geräte können sowohl im Einwahl- als auch im Dial-Out-Modus betrieben werden. Sie können das Juniper Gerät in beiden Modi basierend auf der Topologie Ihres Netzwerks konfigurieren. Beide Modi verwenden die gleichen Datenmodelle und streamen dieselben Telemetriedaten über das Netzwerk. Der Unterschied zwischen den beiden Modi hängt davon ab, ob der Kollektor oder das Gerät von Juniper die Verbindung initiiert und aufrechterhält.

Abonnementtypen

Junos Telemetry unterstützt verschiedene Abonnementmodi und ermöglicht so eine maßgeschneiderte Datenerfassung auf der Grundlage spezifischer Anforderungen und Bedingungen. Die Abonnementmodi werden auf dem Gerät konfiguriert und diktieren das Verhalten des Datenstroms. Die Implementierung von Abonnementmodi hängt davon ab, ob Sie eine Dial-Out- oder eine Dial-In-Verbindung verwenden. Streaming-Intervalle bestimmen die Häufigkeit der Telemetrie-Datenübertragung zwischen dem Gerät und dem Kollektor. Datenerfassung und Streaming werden ausgelöst, wenn bestimmte Bedingungen erfüllt sind oder Ereignisse eintreten, die die Erfassung und das Streaming von Telemetriedaten initiieren. Diese Trigger stellen sicher, dass Daten erfasst werden, wenn bestimmte Kriterien erfüllt sind. So können beispielsweise Telemetriedaten gesammelt und gestreamt werden, wenn ein Paketverlust erkannt wird. Sowohl die Einwahl- als auch die Abwahltelemetrie unterstützen die folgenden Abonnementmodi:

• Einmal: Hierbei handelt es sich um eine einmalige Anforderung von Telemetriedaten. Sie können diesen Modus konfigurieren, wenn ein Snapshot des aktuellen Status der abonnierten Daten erforderlich ist. Es wird sowohl in Einwahl- als auch in DFÜ-Verbindungen unterstützt, wird aber hauptsächlich in Einwahlverbindungen verwendet. Das Gerät sendet die Daten einmal an den Kollektor und stoppt für eine Dial-Out-Verbindung. Der Collector fordert Einwahlverbindungen über einen "Subscribe"-RPC mit ONCE-Modus an. In einer Dial-Out-Verbindung müssen Sie einen Sensor und ein Abonnement so konfigurieren, dass sie nur einmal ausgelöst werden, was nicht häufig der Fall ist. Bei einer Einwahlverbindung handelt es sich um einen "Get"-RPC, der jedoch als Abonnement gekennzeichnet ist.
• Umfrage: Periodischer On-Demand-Abruf von Telemetriedaten. Diese Konfiguration eignet sich für die Überwachung von Sensoren in bestimmten Intervallen. POLL wird in einem Einwahlszenario unterstützt, in dem der Collector die Verbindung mit dem gNMI-Server des Geräts initiiert. Es handelt sich nicht um einen typischen Dial-Out-Streaming-Modus, da das Junos Telemetry-Streaming gerätegesteuert ist. Es erfordert, dass auf dem Gerät ein gNMI-Server ausgeführt wird. Der Collector abonniert POLL und fragt dann bei Bedarf ab.
• Stream: Dieses laufende Abonnement streamt kontinuierlich Daten, wenn konfigurierte Auslöser auftreten.

Anmerkung: Nicht alle Sensoren (OpenConfig oder nativ) unterstützen alle Modi.

Diese Form des Abonnements hat drei Untermodi:

• ON_CHANGE: Das Gerät sendet nur dann Aktualisierungen, wenn sich die überwachten Daten ändern (z. B. wenn sich ein Schnittstellenzähler erhöht oder ein Zustand umgedreht wird). Dieser Modus eignet sich eher für ereignisgesteuerte als für zeitgesteuerte Metriken. Native Sensoren haben im Kontext von ereignisgesteuerten Metriken einen Vorteil gegenüber Openconfig-Sensoren.
• PROBE: Telemetrieaktualisierungen werden in regelmäßigen Abständen basierend auf dem konfigurierten Intervall gestreamt. Dieser Modus eignet sich für Metriken wie die Anzahl der Pakete oder die übertragenen Bytes, die im Laufe der Zeit abgetastet werden.
• TARGET_DEFINED: Das Gerät entscheidet anhand des überwachten Sensors oder der überwachten Ressource über den besten Modus (SAMPLE oder ON_CHANGE). Die Implementierung von Juniper kann standardmäßig auf SAMPLE gesetzt werden, es sei denn ON_CHANGE wird für den Sensor explizit unterstützt.
  • ANMERKUNG: Die TARGET_DEFINED Abonnementanforderungen für Konfigurationspfade werden nur als ON_CHANGE Anforderungen behandelt.

Ermitteln der geeigneten Telemetriekonfiguration für Ihr Netzwerk

Beachten Sie die folgenden Richtlinien, bevor Sie die für Ihre Netzwerktopologie geeigneten Telemetriesensoren, die Verbindungsmethode (Ein- oder Auswahl) und den Abonnementmodus auswählen:

• Eine Kombination aus OpenConfig-Sensoren und dem Subskriptionsmodus SAMPLE ist ideal für standardisiertes, periodisches Monitoring (z.B. Multivendor-Dashboards).
• Eine Kombination aus nativen Sensoren und ON_CHANGE Abonnementmodus eignet sich für Juniper spezifische und ereignisgesteuerte Erkenntnisse (z. B. Fehlerbehebung bei Hardware).

Um die geeignete Telemetriesitzung für Ihr Netzwerk zu ermitteln, fassen die folgenden Informationen einen Vergleich zwischen Einwahl- und Ausgangstelemetriemodi zusammen:

Einwahl vs. Ausgangswahl

• Bei der Einwahl (gRPC mit gNMI) werden Snapshots von einem der beiden Sensortypen (Openconfig oder nativ) abgerufen.

  Beispiel: Collector verwendet gNMI über gRPC, um OpenConfig-Statistiken (/interfaces) oder native PFE-Statistiken (/junos/system/linecardabzurufen.

• Dial-out (gRPC mit gNMI oder UDP) streamt Aktualisierungen, wobei gNMI/gRPC die Struktur und UDP die native Simplizität bevorzugt.

  Beispiel: Das Gerät streamt OpenConfig-BGP-Statistiken über gNMI über gRPC oder native Firewall-Zähler über UDP.

Telemetrieprotokolle

Junos Telemetry unterstützt die gNMI- und UDP-Protokolle zum Erfassen und Streamen von Telemetriedaten von Juniper Geräten an den Datensammler.

Datenmodelle

Die Junos Telemetry Datenmodelle definieren die Struktur der Telemetriedaten, die von Netzwerkgeräten unter Verwendung von YANG (Yet Another Next Generation) erfasst werden. YANG ist eine standardbasierte, erweiterbare Datenmodellierungssprache, die in Junos Telemetry verwendet wird, um Konfiguration, Betriebszustandsdaten und Remote Procedure Calls (RPCs) für Netzwerkgeräte zu definieren. In Junos Telemetry ermöglichen YANG-Modelle die Bereitstellung von Sensoren zum Erfassen und Exportieren von Telemetriedaten, wie z. B. Schnittstellenstatistiken, mithilfe nativer oder OpenConfig-Datenmodelle. Der YANG-Standard ist in RFC 6020 und RFC 7950 definiert.

Juniper Networks veröffentlicht YANG-Module für Junos-Geräte, die aus dem Juniper GitHub-Repository heruntergeladen oder auf dem Gerät generiert werden können.

Die OpenConfig-Arbeitsgruppe definiert das OpenConfig-Datenmodell. Es handelt sich um ein herstellerneutrales Datenmodell für die Konfiguration und Verwaltung des Netzwerks. Das OpenConfig-Datenmodell generiert Daten als GPB-Nachrichten (Google Protocol Buffers) in einem universellen Schlüssel/Wert-Format. Junos Telemetry ermöglicht es Ihnen, OpenConfig-Modelle für eine umfassendere, anbieterunabhängige Ansicht Ihres Netzwerks zu nutzen. Openconfig-Sensorpfade werden verwendet, um Sensorinformationen von Sensoren abzurufen, die auf dem Openconfig-Datenmodell basieren. Ausführliche Informationen zu Openconfig-Ressourcenpfaden finden Sie unter Junos YANG-Datenmodell-Explorer.

Das native Datenmodell von Juniper ist ein offenes und erweiterbares Framework, das von Juniper entwickelt wurde. Dieses Modell wird verwendet, um Telemetriedaten über die einzigartigen Funktionen von Juniper Geräten zu streamen. Dazu gehören Schnittstellenstatistiken, Routing-Informationen, Sicherheitsmetriken und so weiter. Darüber hinaus ermöglicht das native Modell die Definition von unternehmensspezifischen Sensoren. Um auf Informationen von Juniper oder unternehmensspezifischen Sensoren zuzugreifen, abonnieren Sie Juniper Native Sensoren. Native Sensorpfade werden verwendet, um Sensorinformationen von Sensoren basierend auf dem nativen Datenmodell abzurufen. Die YANG-Module von Juniper für native Sensoren sind im GitHub-Repository für Telemetrie von Juniper verfügbar.

Erkunden von Sensorpfaden

Ein Telemetriesensorpfad beschreibt den hierarchischen Pfad zu den Datenpunkten oder Metriken, die überwacht werden müssen. Um die benötigten Sensordaten zu streamen und den Sensor zu aktivieren und den entsprechenden Sensorpfad zu identifizieren. Junos Telemetry unterstützt sowohl Openconfig-Sensorpfade als auch native Sensorpfade:

• Openconfig-Sensorpfade

  Um die Datenerfassung von Openconfig-Sensoren zu konfigurieren, definieren Sie z. B /interfaces/interface/state/counters. die Abonnements und Sensorpfade, richten Sie den Datensammler ein und laden Sie die Junos Telemetry-Protokollpufferdateien von der Support-Seite von Juniper Networks herunter. Erfassen und decodieren Sie die erfassten Daten auf dem Kollektor.

• Native Sensorpfade

  Native Sensorpfade sind spezifisch für Junos OS (z. B /junos/system/line card/interface/. ) und bieten granularen, für Juniper optimierten Zugriff auf gerätespezifische Metriken.

  Um die Datenerfassung von nativen Sensoren zu konfigurieren, verwenden Sie die Junos CLI, um native Sensoren für die Erfassung bestimmter Daten bereitzustellen. Konfigurieren Sie Junos Telemetry für das Streamen von Daten mithilfe von gRPC oder UDP. Verwenden Sie die Dateien des Protokollpuffers, um die gestreamten Daten auf dem Kollektor zu decodieren.

Beide Pfadtypen ermöglichen die strukturierte Ausgabe von Daten in Formaten wie JSON oder XML und gewährleisten so die Kompatibilität mit externen Kollektoren für eine effiziente Überwachung und Analyse.

• Sensorpfad-Explorer
• Auswählen von Telemetrie-Sensorpfaden
• Wichtige Richtlinien für die Auswahl von Sensorpfaden

Der Junos YANG-Datenmodell-Explorer von Juniper Networks ist ein Online-Tool zum Anzeigen aller unterstützten Ressourcenpfade, ihrer entsprechenden Leaves und der sie unterstützenden Geräteplattformen. Es ermöglicht Ihnen, verschiedene OpenConfig- und native Datenmodellattribute zu untersuchen oder zu vergleichen. Verwenden Sie die Filteroption basierend auf der Softwareversionsnummer oder dem Produkt, um die Liste der Ressourcenpfade und Sensoren auf jeder Plattform anzuzeigen.

Die Junos-Telemetrie unterstützt zwei Möglichkeiten zum Exportieren von Daten im gpb-Format (Protocol Buffers). In diesem Abschnitt wird das Datenformat beschrieben, das von nativen Sensoren beim Exportieren von Telemetriedaten über UDP verwendet wird. Die Daten werden in einen UDP-Header eingekapselt, der wiederum in der IPv4-Nutzlast eingekapselt ist. Dieses Telemetriemodell folgt einer verteilten Architektur, bei der die von konfigurierten Sensoren erzeugten Daten direkt aus der Datenebene exportiert werden. Durch das Umgehen der Steuerungsebene trägt dieser Ansatz dazu bei, Ressourcen der Steuerungsebene für andere kritische Funktionen zu sparen.

Ein nativer Sensor exportiert Daten mithilfe von UDP nah an der Quelle. Es können verschiedene Arten von Telemetriedaten exportiert werden, z. B. Statistiken zu physischen Schnittstellen, Firewall-Filterzählerstatistiken oder Statistiken für Label-Switched-Pfade (LSPs). Ein Sensor beginnt mit der Ausgabe von Daten, sobald er aktiviert ist.

Die Sensordaten werden als einzelne strukturierte Protokollpuffernachricht mit dem Namen TelemetryStreamdargestellt. Die Nachricht oder .proto Datei, wie unten dargestellt, enthält mehrere Attribute, die die Datenquelle identifizieren, z. B. eine Linecard, eine Packet Forwarding Engine oder eine Routing-Engine. Der Name des konfigurierten Sensors ist ebenfalls enthalten. Weitere Informationen zum Konfigurieren von Sensoren finden Sie unter Untersuchen von Sensorpfaden. Eine Liste der unterstützten nativen Sensoren finden Sie unter sensor (Junos Telemetry Interface).

Außerdem müssen Sie die .proto Dateien für alle unterstützten Sensoren auf einen Streaming-Server oder -Collector herunterladen. Navigieren Sie in einem Webbrowser auf der Juniper Networks Seite zur Download-URL für die Software All Junos Platforms: https://www.juniper.net/support/downloads/. Nachdem Sie den Namen der Junos OS-Plattform und die Versionsnummer ausgewählt haben, wechseln Sie zum Abschnitt "Tools", und laden Sie das Paket "Junos Telemetry Interface Data Model Files" herunter. Weitere Informationen zum Konfigurieren eines Streaming-Servers finden Sie unter Streaming-Server (Junos Telemetry Interface).

Native Protokollpuffer (protobuf) Nachrichtenstruktur

Die Informationen, die an den Kollektor gestreamt werden, werden mithilfe der Nachrichtenstruktur der obersten Ebene (TelemetryStreamtelemetry_top.proto-Datei) gesendet. Die Nachricht enthält die Metadaten der Sensordaten, die gestreamt werden (z. B. Sensorpfad, das System, von dem Daten gesendet werden, der Knoten, von dem Daten gesendet werden, usw.). Die eigentlichen Sensordaten werden als Erweiterung zur Top-Level-Meldung gesendet. Für die Sensordaten wird eine separate Proto-Datei gesendet. Die telemetry_top.proto-Datei und die Sensor-Proto-Datei werden verwendet, um die Sensordaten am Kollektor zu dekodieren.

Struktur der telemetry_top.proto-Datei

Struktur der Sensor-Proto-Datei

Diese Datei beginnt mit der extension Nachricht.

Die TelemetryStream Nachricht enthält auch optionale geschachtelte Strukturen, die verschiedene Datentypen enthalten. Die verschachtelten Strukturen können auch privat definierte Sensordaten tragen, wie z. B EnterpriseSensors. . Siehe folgendes Beispiel:

Einzelne Unternehmen, wie z. B. Juniper Networks, definieren und pflegen die von Unternehmenssensoren generierten Attribute. Jedem Unternehmen wird eine eindeutige Attributkennung zugewiesen. Die aktuelle Konvention sieht vor, IANA-zugewiesene Enterprise MIB-IDs für jedes Attribut zu verwenden. Für Juniper Networks lautet diese zugewiesene Kennung 2636.

In Tabelle 2 finden Sie Beschreibungen der einzelnen Elemente, die von Sensordaten erfasst werden, einschließlich Semantik und entsprechendem Schema.

Unterstützte Datentypen

Eine GetRequest wird gesendet, wenn ein Collector-Client einen Get RPC zum Empfangen von Telemetriedaten initiiert. In GetRequest werden die Datenelemente angegeben, mit denen das Ziel Daten an den Collector zurückgeben soll, einschließlich des Datentyps. Der Datentyp ist die Variable, die die Form angibt, in der Daten übermittelt werden sollen.

Tabelle 3 listet die Datentypen auf, die von Junos Telemetry unterstützt werden. Sofern nicht anders angegeben, wird der Datentyp für den Export von Junos Telemetry-Daten mithilfe von gRPC-Services (Remote Procedure Call), gRPC-Netzwerkmanagementschnittstellen-Services (gNMI) oder über UDP unterstützt.

message Decimal64 {
  int64 digits = 1;         // Set of digits.
  uint32 precision = 2;     // Number of digits following the decimal point.

 1-bit  sign
        8-bit  exponent
        23-bit fraction
      The floating point value is calculated using:
        (-1)**S * 2**(Exponent-127) * (1+Fraction)";

Weitere Informationen zu Datentypen finden Sie unter github und http://www.openconfig.net/.

Leistungsüberwachung mit Junos Telemetry

Eine Hauptfunktion von Junos Telemetry ist die Leistungsüberwachung. Durch das Streamen von Daten in ein Performance-Management-System können Netzwerkadministratoren Trends in der Verbindungs- und Knotenauslastung messen und Probleme wie Netzwerküberlastungen in Echtzeit beheben.

In einer typischen Bereitstellung streamt das Netzwerkelement oder das Gerät doppelte Daten an zwei Zielserver, die als Collectors für das Performance-Management-System fungieren. Das Streamen von Daten an zwei Kollektoren sorgt für Redundanz. In Abbildung 1 wird veranschaulicht, wie die Leistungsverwaltungssystem-Collectors Daten anfordern und wie das Gerät Daten streamt. Das Gerät stellt Sensoren zum Erfassen und Exportieren von Daten mithilfe der Befehlszeilenschnittstelle (CLI), der Konfiguration über NETCONF oder gRPC-Abonnementaufrufen bereit. Die Datensammler fordern Daten an, indem sie ein Telemetrieabonnement initiieren. Daten werden nur einmal angefordert und regelmäßig gestreamt.

Abbildung 1: Telemetrie-Streaming für die Leistungsverwaltung

Ab Junos OS Version 18.1R1 ist ein neuer Sensor verfügbar, mit dem Syslog-Daten an Netzwerk-Telemetrie-Collector-Systeme gestreamt werden können. Mithilfe des /junos/events/ Sensors und eines Exportprofils mit dem Wert reporting-rate 0 können Sie jetzt Ereignisdaten zusammen mit statistischen Daten an Ihre Telemetrieerfassungssysteme streamen.

Weitere Anwendungen von Junos Telemetry umfassen die Bereitstellung von Echtzeitdaten zur Unterstützung der Synchronisierung des Betriebszustands zwischen einem Netzwerkelement und einem externen Controller, wie z. B. dem Northstar Controller, der die Erstellung von Traffic-Engineering-Pfaden im gesamten Netzwerk automatisiert. Der NorthStar-Controller kann Telemetriedaten zu bestimmten Netzwerkelementen abonnieren, wie z. B. LSP-Statistiken (Label Switched Path).