Konfigurieren eines NETCONF-Proxytelemetriesensors in Junos
Mit Junos Telemetry Streaming können Sie alle verfügbaren Statusinformationen mithilfe der XML-Proxy-Funktionalität in einen Telemetriesensor verwandeln. Das NETCONF XML Management Protocol und junos XML API dokumentieren alle Optionen für jede unterstützte Junos OS Betriebsanforderung vollständig. Nachdem Sie XML-Proxysensoren konfiguriert haben, können Sie über NETCONF Remote Procedure Calls (RPCs) auf Daten zugreifen.
Diese Aufgabe zeigt Ihnen, wie Sie die Ausgabe eines Junos OS-Betriebsmodus-Befehls streamen.
Wir empfehlen, keine YANG-Dateien zu verwenden, die einem Junos OS-Betriebsbefehl mit umfangreichen oder ausführlichen Ausgaben oder einer, die bei der Erstellung der Ausgabe langsam ist, zugeordnet werden. Befehle mit spürbarer Verzögerung sollten in YANG-Dateien vermieden werden. Die Einbeziehung solcher Befehle kann andere xml-proxyd-Sensoren sowie die Leistung von xmlproxyd beeinträchtigen.
Die Ausgabe einiger Betriebsmodusbefehle ist dynamisch und der Grad ihrer Ausführlichkeit hängt von Faktoren wie konfiguration und Hardware ab. Beispiele für solche Befehle sind jede Variation von show interfaces, , show route, show arp, show bfd, show bgpund show ddos-protection.
Um die Ausführlichkeitsebene eines Befehls zu überprüfen, geben Sie den command-nameBefehl | display xml | count aus. Wenn die Zeilenanzahl einen Wert von 4000 Zeilen überschreitet, wird der Befehl für XML-Proxy-Streaming nicht empfohlen. Bei diesem Wert handelt es sich eher um eine Näherung, die auf einer internen Basisauskleidung basiert. Es kann weniger sein, abhängig von verschiedenen Faktoren wie Gerätetyp, Verarbeitungsleistung des Geräts und der vorhandenen CPU-Last. Folglich muss diese Funktion entsprechend der Leistung des Geräts verwendet werden.
Sie können den Befehl command-name| display xml ausstellen, bevor Sie eine YANG-Datei verwenden, die einem Junos OS- oder Junos OS Evolved-Betriebsmodus-Befehl zuordnet wird, um zu überprüfen, ob der Befehl eine 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 zuordnet, führt zu einem oder mehreren der folgenden Ergebnisse:
-
Die xmlproxyd Prozess-CPU-Auslastung bleibt hoch. Wenn xmlproxyd die Tracing aktiviert hat, ist die CPU-Auslastung noch höher.
-
Eine Steigerung der XML-Proxy-Verarbeitungsspeicherauslastung.
-
Der Xmlproxyd-Prozessstatus kann angezeigt
sbwaitwerden, was angibt, dass die Befehlsausgabe ausführlich ist und dass xmlproxyd erheblich mit dem Lesen der REMOTE-Prozeduraufrufe (RPC's) des Befehls verbringt. -
Die xml-Proxy-Sensordaten schließen den Umbruch nicht ab.
-
Der xmlproxyd streamt teilweise oder keine Daten für die Sensoren.
-
Der xmlproxyd versäumt Berichts-Intervall-Zyklen. Die Intervalle beginnen sich aufgrund der ausführlichen Ausgabe eines Befehls zu überschneiden, was dazu führt, dass die Sensor-Streaming-Daten des xmlproxyd langsam oder verzögert sind.
-
Der Prozess oder die Anwendung, die dem RPC des ausführlichen Befehls dient, kann hohe CPU-Zahlen oder Verzögerungen bei der Ausführung der Hauptaufgaben anzeigen. Dieses Verhalten wird verursacht, wenn der Prozess oder die Anwendung ausgelastet ist, um den RPC mit ausführlicher Ausgabe zu bedienen.
Für diese Aufgabe ist Folgendes erforderlich:
-
Ein Router der MX-, vMX- oder PTX-Serie mit Junos OS Version 17.3R2 oder höher.
-
Installation des erforderlichen Network Agent-Pakets ( network-agent-x86–32–17.4R1.16-C1.tgz oder höher).
-
Ein Telemetriedatenempfänger wie OpenNTI, um den korrekten Betrieb Ihres 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)
Neben der erwarteten Liste der aktuell angemeldeten Benutzer liefert die show system users Ausgabe auch die durchschnittliche Systemlast in 1, 5 und 15 Minuten. Sie können die Lastmittelwerte ermitteln, indem Sie den show system users | display xml Befehl verwenden, um die 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 vorhergehenden Ausgabe angezeigte Tag ist ein Container, der Leafs wie date-time, up-time. active-user-countund load-average-1. Nachfolgend finden Sie eine YANG-Beispieldatei 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 weiteren Container, der user-table eine Liste von Benutzereinträgen enthält.
Nachfolgend finden Sie eine YANG-Beispieldatei 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üsselwertpaare, die den übereinstimmenden XML-Tags entnommen werden.
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 wurde. Bestimmte Richtlinien müssen in der Datei enthalten sein, die den XML-Proxy konfiguriert.
Um den xmlproxyd (Daemon)-Prozess zur Übersetzung von Telemetriedaten zu verwenden, erstellen Sie eine render.yang Datei. In dieser Datei ist die dr:command-app datei auf xmlproxyd.
Der XML-Proxy YANG-Dateiname und der Modulname müssen mit xmlproxyd_:
Fügen Sie für den XML-Proxy YANG-Dateiname die Erweiterung
.yanghinzu, z. B.xmlproxyd_sysusers.yangVerwenden Sie für den Modulnamen z. B. den Dateinamen ohne Erweiterung
.yang,xmlproxyd_sysusers
Um die Erstellung einer YANG-Datei zu vereinfachen, ist es am einfachsten, ein Arbeitsbeispiel zu ändern.
Laden Sie die Yang-Datei in Junos
Laden Sie nach Abschluss der YANG-Datei die YANG-Datei hoch und überprüfen Sie, ob das Modul erstellt wurde.
Erfassung von Sensordaten
Verwenden Sie Ihren Lieblingssammler, um die neu erstellten Telemetriesensordaten vom Gerät zu ziehen.
Berücksichtigen Sie Ressourcenbeschränkungen, bevor Sie Sensoren starten:
- Vermeiden Sie die Angabe desselben Berichtsintervalls für mehrere XML-Proxy-Sensoren.
- Für PTX10008-Router mit Junos OS Evolved nicht mehr als 10 Kollektoren pro Router für Telemetrie-RPCs verbinden.
- Da xmlproxyd XML- und Textverarbeitung ausführt, sollte ein Gerät nur XML-Proxysensoren enthalten, die innerhalb des CPU-Auslastungsbereichs ausgeführt werden.
Die folgenden Anweisungen verwenden den Collector jtimon. Informationen zur jtimon-Einrichtung finden Sie unter Junos Telemetry Interface-Client.
Wenn bereits ein Abonnement für einen Sensor vorhanden ist und ein dupliziertes Abonnement konfiguriert ist, wird die Verbindung zwischen dem Kollektor und dem Gerät mit der Fehlermeldung AlreadyExistsgeschlossen.
Installieren einer benutzerdefinierten YANG-Datei
Verwenden Sie den request system yang Satz von Befehlen aus dem Betriebsmodus, um eine benutzerdefinierte YANG-Datei für XML-Proxy für die Junos-Telemetrieschnittstelle hinzuzufügen, zu validieren, zu ändern oder zu löschen:
Siehe auch
Fehlerbehebung bei Telemetriesensoren
Problem
Beschreibung
Verwenden Sie die folgenden Methoden zur Fehlerbehebung bei telemetrie-Sensoren, die benutzerdefinieren:
Führen Sie einen tcpdump für die Schnittstelle aus, von der Ihre gRPC-Anfragen kamen (für diese Aufgabe wurde Schnittstelle
fxp0verwendet).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Aktivieren Sie Traceoptionen 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 aus, 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