Konfigurieren eines NETCONF-Proxy-Telemetriesensors in Junos
Mithilfe des Junos-Telemetrie-Streamings können Sie mithilfe der XML-Proxy-Funktion alle verfügbaren Zustandsinformationen in einen Telemetriesensor umwandeln. Das NETCONF-XML-Verwaltungsprotokoll und die Junos XML-API dokumentieren alle Optionen für jede unterstützte Betriebsanforderung von Junos OS vollständig. Nachdem Sie XML-Proxysensoren konfiguriert haben, können Sie über NETCONF "get" Remote Procedure Calls (RPCs) auf Daten zugreifen.
In dieser Aufgabe erfahren Sie, wie Sie die Ausgabe eines Junos OS-Befehls für den Betriebsmodus streamen.
Es wird empfohlen, keine YANG-Dateien zu verwenden, die einem Junos OS-Betriebsbefehl mit umfangreicher oder ausführlicher Ausgabe oder einem Befehl zugeordnet sind, der nur langsam eine Ausgabe erzeugt. Befehle mit einer merklichen Verzögerung sollten in YANG-Dateien vermieden werden. Das Einfügen solcher Befehle kann sich auf andere xmlproxyd-Sensoren sowie auf die Leistung von xmlproxyd auswirken.
Die Ausgabe einiger Befehle im Betriebsmodus ist dynamisch, und der Grad ihrer Ausführlichkeit hängt von Faktoren wie der Konfiguration und der Hardware ab. Beispiele für solche Befehle sind jede Variation von show interfaces, , , show routeshow arpshow bfd, show bgpund show ddos-protection.
Um den Ausführlichkeitsgrad eines Befehls zu überprüfen, geben Sie den command-nameBefehl | | display xml ein count . Wenn die Zeilenanzahl einen Wert von 4000 Zeilen überschreitet, wird der Befehl nicht für XML-Proxystreaming empfohlen. Bei diesem Wert handelt es sich eher um eine Annäherung, die auf dem internen Base-Lining basiert. Sie kann weniger sein, abhängig von verschiedenen Faktoren wie Gerätetyp, Rechenleistung des Geräts und vorhandener CPU-Last. Folglich muss diese Funktion je nach Leistung des Geräts mit Bedacht verwendet werden.
Sie können den Befehl | display xml absetzen, bevor Sie eine YANG-Datei verwenden, die einem Junos OS- oder Junos OS Evolved-Betriebsmodusbefehl zugeordnet ist, um zu überprüfen, ob der Befehl command-nameeine gültige XML-Ausgabe erzeugt und keine ungültigen Tags, Daten oder Formatierungen enthält.
Die Verwendung einer YANG-Datei, die einem ausführlichen Befehl zugeordnet ist, führt zu einem oder mehreren der folgenden Ergebnisse:
-
Die CPU-Auslastung des xmlproxyd-Prozesses bleibt hoch. Wenn xmlproxyd die Ablaufverfolgung aktiviert hat, ist die CPU-Auslastung sogar noch höher.
-
Eine Erhöhung der Speicherauslastung des xmlproxyd-Prozesses.
-
Der xmlproxyd-Prozessstatus kann angezeigt
sbwaitwerden, was darauf hinweist, dass die Befehlsausgabe ausführlich ist und dass xmlproxyd viel Zeit damit verbringt, die Ausgabe des Remote Procedure Calls (RPC) des Befehls zu lesen. -
Die xmlproxyd-Sensordaten schließen den Wrap nicht ab.
-
Der xmlproxyd streamt teilweise oder keine Daten für die Sensoren.
-
Der xmlproxyd verpasst Berichterstellungsintervallzyklen. Die Intervalle beginnen sich aufgrund der ausführlichen Ausgabe eines Befehls zu überlappen, was dazu führt, dass der Sensor des xmlproxyd-Sensors langsam oder verzögert Daten streamt.
-
Der Prozess oder die Anwendung, die den RPC des ausführlichen Befehls bedient, weist möglicherweise eine hohe CPU-Anzahl oder Verzögerungen bei der Ausführung von Hauptaufgaben auf. Dieses Verhalten wird verursacht, wenn der Prozess oder die Anwendung damit beschäftigt ist, den RPC mit ausführlicher Ausgabe zu bedienen.
Für diese Aufgabe ist Folgendes erforderlich:
-
Router der MX-, vMX- oder PTX-Serie mit Junos OS Version 17.3R2 oder höher.
-
Installation des erforderlichen Administrationsagentenpakets ( network-agent-x86–32–17.4R1.16-C1.tgz oder höher).
-
Einen Telemetriedatenempfänger, z. B. OpenNTI, um den ordnungsgemäßen Betrieb des Telemetriesensors zu überprüfen.
In dieser Aufgabe streamen Sie den Inhalt des Junos OS-Befehls show system users.
Systembenutzer anzeigen (vMX-Serie)
user@switch> show system users USER TTY FROM LOGIN@ IDLE WHAT user1 pts/0 172.31.12.36 12:40PM 39 -cli (cli) user2 pts/1 172,16.03.25 3:01AM - -cli (cli)
Zusätzlich zur erwarteten Liste der aktuell angemeldeten Benutzer liefert die Ausgabe auch die show system users durchschnittliche Systemauslastung als 1, 5 und 15 Minuten. Sie können die Lastdurchschnitte ermitteln, indem Sie den show system users | display xml Befehl verwenden, um das XML-Tagging für die Ausgabefelder anzuzeigen. Siehe <load-average-1>, <load-average-5>und <load-average-15> in der XML-Tagging-Ausgabe unten.
user@switch> show system users | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
<system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos">
<uptime-information>
<date-time junos:seconds="1520170982">1:43PM</date-time>
<up-time junos:seconds="86460">1 day, 40 mins</up-time>
<active-user-count junos:format="2 users">2</active-user-count>
<load-average-1>0.70</load-average-1>
<load-average-5>0.58</load-average-5>
<load-average-15>0.55</load-average-15>
<user-table>
<user-entry>
<user>root</user>
<tty>pts/0</tty>
<from>172.21.0.1</from>
<login-time junos:seconds="1520167202">12:40PM</login-time>
<idle-time junos:seconds="0">-</idle-time>
<command>cli</command>
</user-entry>
<user-entry>
<user>mwiget</user>
<tty>pts/1</tty>
<from>66.129.241.10</from>
<login-time junos:seconds="1520170862">1:41PM</login-time>
<idle-time junos:seconds="60">1</idle-time>
<command>cli</command>
</user-entry>
</user-table>
</uptime-information>
</system-users-information>
<cli>
<banner></banner>
</cli>
</rpc-reply>
Das uptime-information in der vorherigen Ausgabe gezeigte Tag ist ein Container, der Blätter enthält, z. Bdate-time. , , up-timeactive-user-count. und load-average-1. Nachfolgend finden Sie ein Beispiel für eine YANG-Datei für diesen Container:
container uptime-information {
dr:source "uptime-information"; // Exact name of the XML tag
leaf date-time { // YANG model leaf
type string; // Type of value
dr:source date-time; // Exact name of the XML tag
}
leaf up-time { // YANG model leaf
type string; // Type of value
dr:source up-time; // Exact name of the XML tag
}
leaf active-user-count { // YANG model leaf
type int32; // Type of value
dr:source active-user-count; // Exact name of the XML tag
}
leaf load-average-1 { // YANG model leaf
type string; // Type of value
dr:source load-average-1; // Exact name of the XML tag
}
...
Das uptime-information Tag hat auch einen anderen Container namens genannt user-table , der eine Liste von Benutzereinträgen enthält.
Nachfolgend finden Sie ein Beispiel für eine YANG-Datei für diesen Container:
container user-table { // "user-table" container which contains list of user-entry
dr:source "user-table"; // Exact name of the XML tag
list user-entry { // "user-entry" list which contains the users' details in form of leafs
key "user"; // Key for the list "user-entry" which is a leaf in the list "user-entry"
dr:source "user-entry"; // Source of the list "user-entry" which is the exact name of the XML tag
leaf user { // YANG model leaf
dr:source user; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf tty { // YANG model leaf
dr:source tty; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf from { // YANG model leaf
dr:source from; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf login-time { // YANG model leaf
dr:source login-time; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf idle-time { // YANG model leaf
dr:source idle-time; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf command { // YANG model leaf
dr:source command; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
}
}
Erstellen einer benutzerdefinierten YANG-Datei
Die YANG-Datei definiert den auszuführenden Junos CLI-Befehl, den Ressourcenpfad, unter dem die Sensoren platziert werden, und die Schlüssel-Wert-Paare aus den entsprechenden XML-Tags.
Benutzerdefinierte YANG-Dateien für Junos OS entsprechen der YANG-Sprachsyntax, die in RFC 6020 YANG 1.0 YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF) und RFC 7950 The YANG 1.1 Data Modeling Language definiert ist. Bestimmte Direktiven müssen in der Datei vorhanden sein, die den XML-Proxy konfigurieren.
Um den xmlproxyd (Daemon-)Prozess zum Übersetzen von Telemetriedaten zu verwenden, erstellen Sie eine render.yang Datei. In dieser Datei ist die auf xmlproxydgesetztdr:command-app.
Der XML-Proxy-YANG-Dateiname und der Modulname müssen mit xmlproxyd_folgendem beginnen:
Fügen Sie für den YANG-Dateinamen des XML-Proxys die Erweiterung
.yanghinzu, z. B.xmlproxyd_sysusers.yangVerwenden Sie für den Modulnamen den Dateinamen ohne die Erweiterung
.yang, z. B.xmlproxyd_sysusers
Um das Erstellen einer YANG-Datei zu vereinfachen, ist es am einfachsten, mit der Änderung eines funktionierenden Beispiels zu beginnen.
Laden der Yang-Datei in Junos
Laden Sie nach Abschluss der YANG-Datei die YANG-Datei hoch, und überprüfen Sie, ob das Modul erstellt wurde.
Sensordaten erfassen
Verwenden Sie Ihren bevorzugten Collector, um die neu erstellten Telemetriesensordaten aus dem Gerät abzurufen.
Berücksichtigen Sie Ressourcenbeschränkungen, bevor Sie Sensoren initiieren:
- Vermeiden Sie es, dasselbe Berichtsintervall für mehrere XML-Proxysensoren anzugeben.
- Verbinden Sie bei PTX10008-Routern mit Junos OS Evolved nicht mehr als 10 Collectors pro Router für Telemetrie-RPCs.
- Da xmlproxyd XML- und Textverarbeitung durchführt, sollte ein Gerät nur XML-Proxysensoren enthalten, die innerhalb des CPU-Auslastungsbereichs ausgeführt werden.
In den folgenden Anweisungen wird der Kollektor jtimon verwendet. Weitere Informationen zum Einrichten von jtimon finden Sie unter Junos Telemetry Interface Client.
Wenn bereits ein Abonnement für einen Sensor existiert und ein doppeltes Abonnement konfiguriert ist, wird die Verbindung zwischen dem Kollektor und dem Gerät mit der Fehlermeldung AlreadyExistsgeschlossen.
Installieren einer benutzerdefinierten YANG-Datei
Verwenden Sie zum Hinzufügen, Validieren, Ändern oder Löschen einer benutzerdefinierten YANG-Datei für den XML-Proxy für die Junos-Telemetrieschnittstelle die request system yang folgenden Befehle aus dem Betriebsmodus:
Siehe auch
Fehlerbehebung bei Telemetriesensoren
Problem
Beschreibung
Verwenden Sie die folgenden Methoden zur Fehlerbehebung bei benutzerdefinierten Telemetriesensoren:
Führen Sie einen tcpdump für die Schnittstelle aus, von der Ihre gRPC-Anforderungen stammen (für diese Aufgabe wurde die Schnittstelle
fxp0verwendet).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Aktivieren Sie Trace-Optionen mit dem set services analytics traceoptions flag xmlproxy Befehl. Überprüfen Sie die
xmlproxydProtokolldatei, um zu bestätigen, ob der RPC des CLI-Befehls gesendet wurde und ob eine Antwort empfangen wurde:
Geben Sie den show log xmlproxyd Befehl ein, um das xmlproxyd-Protokoll anzuzeigen. Der Wert für das Feld
xmlproxy_execute_cli_command:gibt an, ob der RPC gesendet wurde oder nicht. Der Wert für das Feldxmlproxy_build_contextgibt den Befehl an.
user@switch>show log xmlproxyd Mar 4 18:52:46 vmxdockerlight_vmx1_1 clear-log[52495]: logfile cleared Mar 4 18:52:51 xmlproxy_telemetry_start_streaming: sensor /junos/system-users-information/ Mar 4 18:52:51 xmlproxy_build_context: command show system users merge-tag: Mar 4 18:52:51 <command format="xml">show system users</command> Mar 4 18:52:51 xmlproxy_execute_cli_command: Sent RPC.. Mar 4 18:52:51 <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos" xmlns:junos="http://xml.juniper.net/junos/*/junos"> <uptime-information> <date-time junos:seconds="1520189571"> 6:52PM </date-time> <up-time junos:seconds="107400"> 1 day, 5:50 </up-time> <active-user-count junos:format="1 users"> 1 </active-user-count> <load-average-1> 0.94 </load-average-1> <load-average-5> 0.73 </load-average-5> <load-average-15> 0.65