Telemetrie in Junos für KI/ML-Workloads
Autorin: Shalini Mukherjee

Einführung

Da KI-Cluster-Verkehr verlustfreie Netzwerke mit hohem Durchsatz und geringer Latenz erfordert, ist die Erfassung von Überwachungsdaten ein kritisches Element des KI-Netzwerks. Junos Telemetry ermöglicht eine detaillierte Überwachung wichtiger Leistungsindikatoren, einschließlich Schwellenwerten und Zählern für Überlastungsmanagement und Verkehrslastausgleich. gRPC-Sitzungen unterstützen das Streaming von Telemetriedaten. gRPC ist ein modernes, quelloffenes Hochleistungsframework, das auf HTTP/2-Transport basiert. Es ermöglicht native bidirektionale Streaming-Funktionen und enthält flexible benutzerdefinierte Metadaten in Anforderungsheadern. Der erste Schritt in der Telemetrie besteht darin, zu wissen, welche Daten erfasst werden sollen. Wir können diese Daten dann in verschiedenen Formaten analysieren. Sobald wir die Daten erfasst haben, ist es wichtig, sie in einem Format darzustellen, das einfach zu überwachen, Entscheidungen zu treffen und den angebotenen Dienst zu verbessern ist. In diesem Dokument verwenden wir einen Telemetriestapel, der aus Telegraf, InfluxDB und Grafana besteht. Dieser Telemetriestapel erfasst Daten mithilfe eines Push-Modells. Traditionelle Pull-Modelle sind ressourcenintensiv, erfordern manuelle Eingriffe und können Informationslücken in den von ihnen erfassten Daten enthalten. Push-Modelle überwinden diese Einschränkungen, indem sie Daten asynchron bereitstellen. Sie reichern die Daten durch benutzerfreundliche tags und Namen. Sobald die Daten in einem besser lesbaren Format vorliegen, speichern wir sie in einer Datenbank und verwenden sie in einer interaktiven Visualisierung web Anwendung zur Analyse des Netzwerks. Abbildung 1 zeigt uns, wie dieser Stapel für eine effiziente Datenerfassung, -speicherung und -visualisierung konzipiert ist, von Netzwerkgeräten, die Daten an den Collector senden, bis hin zu den Daten, die zur Analyse auf Dashboards angezeigt werden.

TIG-Stapel

Wir haben einen Ubuntu-Server verwendet, um die gesamte Software einschließlich des TIG-Stacks zu installieren.

Telegraph
Zum Sammeln von Daten verwenden wir Telegraf auf einem Ubuntu-Server mit 22.04.2. Die in dieser Demo verwendete Telegraf-Version ist 1.28.5.
Telegraf ist ein Plugin-gesteuerter Server-Agent zum Sammeln und Melden von Metriken. Es verwendet Prozessor plugins um die Daten anzureichern und zu normalisieren. Die Ausgabe plugins werden verwendet, um diese Daten an verschiedene Datenspeicher zu senden. In diesem Dokument verwenden wir zwei plugins: eine für Openconfig-Sensoren und die andere für native Juniper-Sensoren.
InflluxDB
Um die Daten in einer Zeitreihendatenbank zu speichern, verwenden wir InfluxDB. Das Ausgabe-Plugin in Telegraf sendet die Daten an InfluxDB, das sie auf hocheffiziente Weise speichert. Wir verwenden V1.8, da für V2 und höher kein CLI vorhanden ist.
Grafana
Zur Visualisierung dieser Daten wird Grafana verwendet. Grafana ruft die Daten von InfluxDB ab und ermöglicht Benutzern die Erstellung umfangreicher und interaktiver Dashboards. Hier verwenden wir Version 10.2.2.

Konfiguration auf dem Switch

Um diesen Stack zu implementieren, müssen wir zunächst den Switch wie in Abbildung 2 gezeigt konfigurieren. Wir haben Port 50051 verwendet. Hier kann jeder beliebige Port verwendet werden. Melden Sie sich beim QFX-Switch an und fügen Sie die folgende Konfiguration hinzu.

Notiz: Diese Konfiguration ist für Labore/POCs gedacht, da das Passwort im Klartext übertragen wird. Verwenden Sie SSL, um dies zu vermeiden.

Umfeld

Nginx
Dies ist erforderlich, wenn Sie den Port, auf dem Grafana gehostet wird, nicht freigeben können. Der nächste Schritt besteht darin, nginx auf dem Ubuntu-Server zu installieren, damit es als Reverse-Proxy-Agent fungiert. Sobald nginx installiert ist, fügen Sie die in Abbildung 4 gezeigten Zeilen zur Datei „default“ hinzu und verschieben Sie die Datei von /etc/nginx nach /etc/nginx/sites-enabled.

Stellen Sie sicher, dass die Firewall so eingestellt ist, dass sie vollen Zugriff auf den Nginx-Dienst gewährt, wie in Abbildung 5 dargestellt.

Sobald nginx installiert ist und die erforderlichen Änderungen vorgenommen wurden, sollten wir in der Lage sein, auf Grafana zuzugreifen von einem web Browser, indem Sie die IP-Adresse des Ubuntu-Servers verwenden, auf dem die gesamte Software installiert ist.
Es gibt einen kleinen Fehler in Grafana, der das Zurücksetzen des Standardkennworts nicht zulässt. Führen Sie diese Schritte aus, wenn dieses Problem auftritt.
Auf dem Ubuntu-Server auszuführende Schritte zum Festlegen des Kennworts in Grafana:

• Gehen Sie zu /var/lib/grafana/grafana.db
• Installieren Sie sqllite3
  o sudo apt installiere sqlite3
• Führen Sie diesen Befehl auf Ihrem Terminal aus
  oder sqlite3 grafana.db
•  Die SQLite-Eingabeaufforderung wird geöffnet. Führen Sie die folgende Abfrage aus:
  >Löschen von Benutzer mit Login='admin'
• Starten Sie Grafana neu und geben Sie „admin“ als Benutzernamen und Kennwort ein. Sie werden zur Eingabe eines neuen Kennworts aufgefordert.

Sobald die gesamte Software installiert ist, erstellen Sie die Konfigurationsdatei in Telegraf, mit deren Hilfe die Telemetriedaten vom Switch abgerufen und an InffluxDB gesendet werden können.

Openconfig Sensor Plugin

Bearbeiten Sie auf dem Ubuntu-Server die Datei /etc/telegraf/telegraf.conf, um alle erforderlichen plugins und Sensoren. Für die Openconfig-Sensoren verwenden wir das in Abbildung 6 gezeigte gNMI-Plugin. Fügen Sie zu Demozwecken den Hostnamen als „spine1“, die für gRPC verwendete Portnummer „50051“, den Benutzernamen und das Passwort des Switches sowie die Anzahl der Sekunden für die Wahlwiederholung im Fehlerfall hinzu.
Fügen Sie in der Abonnementstrophe einen eindeutigen Namen, „cpu“, für diesen bestimmten Sensor, den Sensorpfad und das Zeitintervall für das Abrufen dieser Daten vom Switch hinzu. Fügen Sie für alle offenen Konfigurationssensoren dasselbe Plugin inputs.gnmi und inputs.gnmi.subscription hinzu. (Abbildung 6)

Natives Sensor-Plugin

Dies ist ein Juniper-Telemetrie-Schnittstellen-Plugin, das für native Sensoren verwendet wird. Fügen Sie in derselben Datei telegraf.conf das native Sensor-Plugin inputs.jti_openconfig_telemetry hinzu, wobei die Felder fast dieselben sind wie bei openconfig. Verwenden Sie für jeden Sensor eine eindeutige Client-ID. Hier verwenden wir „telegraf3“. Der eindeutige Name, der hier für diesen Sensor verwendet wird, ist „mem“ (Abbildung 7).

Fügen Sie abschließend ein Ausgabe-Plugin outputs.influxdb hinzu, um diese Sensordaten an InfluxDB zu senden. Hier heißt die Datenbank „telegraf“ mit dem Benutzernamen „influx“ und dem Passwort „influxdb“ (Abbildung 8).

Nachdem Sie die Datei telegraf.conf bearbeitet haben, starten Sie den Telegraf-Dienst neu. Überprüfen Sie nun in der InfluxDB-CLI, ob Messungen für alle eindeutigen Sensoren erstellt wurden. Geben Sie „influx“ ein, um die InfluxDB-CLI aufzurufen.

Geben Sie, wie in Abbildung 9 zu sehen, die Eingabeaufforderung influxDB ein und verwenden Sie die Datenbank „telegraf“. Alle den Sensoren zugewiesenen eindeutigen Namen werden als Messungen aufgeführt.
Um die Ausgabe einer beliebigen Messung anzuzeigen und sicherzustellen, dass die Telegraf-Datei korrekt ist und der Sensor funktioniert, verwenden Sie den Befehl „select * from cpu limit 1“, wie in Abbildung 10 gezeigt.

Achten Sie jedes Mal, wenn Änderungen an der Datei telegraf.conf vorgenommen werden, darauf, InfluxDB zu stoppen, Telegraf neu zu starten und dann InfluxDB zu starten.
Melden Sie sich über den Browser bei Grafana an und erstellen Sie Dashboards, nachdem Sie sichergestellt haben, dass die Daten korrekt erfasst werden.
Gehen Sie zu Verbindungen > InfuxDB > Neue Datenquelle hinzufügen.

1. Geben Sie dieser Datenquelle einen Namen. In dieser Demo ist es „test-1“.
2.  Verwenden Sie unter der HTTP-Strophe die Ubuntu-Server-IP und den Port 8086.
   
3. Verwenden Sie in den InfluxDB-Details denselben Datenbanknamen „telegraf“ und geben Sie den Benutzernamen und das Passwort des Ubuntu-Servers an.
4. Klicken Sie auf „Speichern und testen“. Stellen Sie sicher, dass die Meldung „Erfolgreich“ angezeigt wird.
   
5. Sobald die Datenquelle erfolgreich hinzugefügt wurde, gehen Sie zu Dashboards und klicken Sie auf Neu. Lassen Sie uns im Editormodus einige Dashboards erstellen, die für KI/ML-Workloads wichtig sind.

ExampSensordiagramme

Die folgenden sind BeispieleampDateien einiger wichtiger Zähler, die für die Überwachung eines KI/ML-Netzwerks unerlässlich sind.
Prozenttage-Nutzung für eine Ingress-Schnittstelle et-0/0/0 auf Spine-1

• Wählen Sie die Datenquelle als Test-1 aus.
• Wählen Sie im Abschnitt „VON“ die Messung als „Schnittstelle“ aus. Dies ist der eindeutige Name, der für diesen Sensorpfad verwendet wird.
• Wählen Sie im Abschnitt WHERE das Gerät aus::tagund im tag Wert: Wählen Sie den Hostnamen des Switches aus, also spine1.
• Wählen Sie im Abschnitt „SELECT“ den Sensorzweig aus, den Sie überwachen möchten. Wählen Sie in diesem Fall „field(/interfaces/interface[if_name='et-0/0/0']/state/counters/if_in_1s_octets)“. Klicken Sie nun im selben Abschnitt auf „+“ und fügen Sie diese Berechnungsmathematik hinzu (/50000000000 * 100). Wir berechnen im Grunde den ProzentsatztagDie Nutzung einer 400G-Schnittstelle.
• Stellen Sie sicher, dass das FORMAT „Zeitreihe“ ist, und benennen Sie das Diagramm im Abschnitt ALIAS.

Spitzenpufferbelegung für jede Warteschlange

• Wählen Sie die Datenquelle als Test-1 aus.
• Wählen Sie im Abschnitt „VON“ die Messung als „Puffer“ aus.
• Im Abschnitt WHERE müssen drei Felder ausgefüllt werden. Gerät auswählen::tagund im tag value wählt den Hostnamen des Switches (z. B. spine-1); UND wählt /cos/interfaces/interface/@name::tag und wählen Sie die Schnittstelle (also et- 0/0/0); UND wählen Sie auch die Warteschlange aus, /cos/interfaces/interface/queues/queue/@queue::tag und wählen Sie die Warteschlangennummer 4.
• Wählen Sie im Abschnitt „SELECT“ den Sensorzweig aus, den Sie überwachen möchten. Wählen Sie in diesem Fall „field(/cos/interfaces/interface/queues/queue/PeakBufferOccupancy)“.
• Stellen Sie sicher, dass das FORMAT „Zeitreihe“ ist, und benennen Sie das Diagramm im Abschnitt ALIAS.

Sie können Daten für mehrere Schnittstellen im selben Diagramm zusammenfassen, wie in Abbildung 17 für et-0/0/0, et-0/0/1, et-0/0/2 usw. zu sehen.

PFC und ECN bedeuten Ableitung

Um die mittlere Ableitung (die Wertedifferenz innerhalb eines Zeitbereichs) zu ermitteln, verwenden Sie den Rohabfragemodus.
Dies ist die Zuflux-Abfrage, die wir verwendet haben, um die mittlere Ableitung zwischen zwei PFC-Werten auf et-0/0/0 von Spine-1 in einer Sekunde zu finden.
SELECT Ableitung (Mittelwert („/Schnittstellen/Schnittstelle [if_name='et-0/0/0′]/Status/pfc-Zähler/tx_pkts“), 1s) VON „Schnittstelle“ WO („Gerät“::tag = 'Spine-1') UND $timeFilter GRUPPE NACH Zeit($Intervall)

SELECT Ableitung (Mittelwert („/Schnittstellen/Schnittstelle [if_name='et-0/0/8′]/Status/Fehlerzähler/ecn_ce_marked_pkts“), 1s) VON „Schnittstelle“ WO („Gerät“::tag = 'Spine-1') UND $timeFilter GRUPPE NACH Zeit($Intervall)

Fehler bei Eingaberessourcen bedeuten Ableitung

Die Rohabfrage für die Mittelwertableitung von Ressourcenfehlern lautet:
SELECT Ableitung (Mittelwert („/Schnittstellen/Schnittstelle [if_name='et-0/0/0′]/Status/Fehlerzähler/if_in_Resource_errors“), 1s) FROM „Schnittstelle“ WHERE („Gerät“::tag = 'Spine-1') UND $timeFilter GRUPPE NACH Zeit($Intervall)

Tail Drops bedeuten Ableitung

Die Rohabfrage für die Mittelwertableitung von Tail Drops lautet:
SELECT derivative(mean(„/cos/interfaces/interface/queues/queue/tailDropBytes“), 1s) FROM „Buffer“ WHERE („Gerät“::tag = 'Leaf-1' UND „/cos/interfaces/interface/@name“::tag = 'et-0/0/0' UND „/cos/interfaces/interface/queues/queue/@queue“::tag = '4') UND $timeFilter GRUPPE NACH Zeit($__interval) Füllung(null)
 CPU-Auslastung

• Wählen Sie die Datenquelle als Test-1 aus.
• Wählen Sie im Abschnitt „VON“ die Messung als „newcpu“ aus.
• Im WHERE-Feld sind drei Felder auszufüllen. Gerät auswählen::tag und im tag value wählen Sie den Hostnamen des Switches (also spine-1). UND in /components/component/properties/property/name:tag, und wählen Sie cpuutilization-total UND im Namen::tag Wählen Sie RE0.
• Wählen Sie im Abschnitt „SELECT“ den Sensorzweig aus, den Sie überwachen möchten. Wählen Sie in diesem Fall „field(state/value)“.

Die Rohabfrage zum Ermitteln der nicht-negativen Ableitung von Tail Drops für mehrere Switches auf mehreren Schnittstellen in Bits/Sek.
SELECT non_negative_derivative(mean(„/cos/interfaces/interface/queues/queue/tailDropBytes“), 1s)*8 FROM „Buffer“ WHERE (device::tag =~ /^Spine-[1-2]$/) und („/cos/interfaces/interface/@name“::tag =~ /et-0\/0\/[0-9]/ oder „/cos/interfaces/interface/@name“::tag=~/et-0\/0\/1[0-5]/) UND $timeFilter GRUPPE NACH Zeit($__interval),Gerät::tag füllen(null)

Dies waren einige der ExampDateien der Diagramme, die zur Überwachung eines KI/ML-Netzwerks erstellt werden können.

Zusammenfassung

Dieses Dokument veranschaulicht die Methode zum Abrufen von Telemetriedaten und deren Visualisierung durch die Erstellung von Diagrammen. In diesem Dokument geht es speziell um KI/ML-Sensoren, sowohl native als auch Openconfig-Sensoren, aber das Setup kann für alle Arten von Sensoren verwendet werden. Wir haben auch Lösungen für mehrere Probleme aufgenommen, die beim Erstellen des Setups auftreten können. Die in diesem Dokument dargestellten Schritte und Ergebnisse sind spezifisch für die zuvor erwähnten Versionen des TIG-Stacks. Sie können sich je nach Version der Software, der Sensoren und der Junos-Version ändern.

Verweise

Juniper Yang Data Model Explorer für alle Sensoroptionen
https://apps.juniper.net/ydm-explorer/
Openconfig-Forum für Openconfig-Sensoren
https://www.openconfig.net/projects/models/

Unternehmens- und Vertriebszentrale
Juniper Networks, Inc.
1133 Innovationsweg
Sunnyvale, CA 94089 USA
Telefon: 888. JUNIPER (888.586.4737)
oder +1.408.745.2000
Fax: +1.408.745.2100
www.juniper.net
APAC- und EMEA-Zentrale
Juniper Networks International B.V
Boeing Avenue 240
1119 PZ Schiphol-Rijk
Amsterdam, Niederlande
Telefon: +31.207.125.700
Fax: +31.207.125.701
Copyright 2023 Juniper Networks. Inc. Alle Rechte vorbehalten. Juniper Networks, das Juniper Networks-Logo, Juniper, Junos und andere Marken sind eingetragene Marken von Juniper Networks. inc. und/oder seinen Tochtergesellschaften in den Vereinigten Staaten und anderen Ländern. Andere Namen können Marken ihrer jeweiligen Eigentümer sein. Juniper Networks übernimmt keine Verantwortung für Ungenauigkeiten in diesem Dokument. Juniper Networks behält sich das Recht vor, diese Veröffentlichung ohne vorherige Ankündigung zu ändern, zu modifizieren, zu übertragen oder anderweitig zu überarbeiten.
Senden Sie Feedback an: design-center-comments@juniper.net V1.0/240807/ejm5-telemetry-junos-ai-ml

Dokumente / Ressourcen

Juniper NETWORKS Telemetrie in Junos für AI ML Workloads Software [pdf] Benutzerhandbuch Telemetrie in Junos für AI ML Workloads Software, Junos für AI ML Workloads Software, AI ML Workloads Software, Workloads Software, Software

Verweise

• Bedienungsanleitung