NetOpsCoding Adventskalender 2016 12/8 Minuten Eintrag.
Bei einer Veranstaltung namens "Juniper Cloud Builder Community" von Juniper am 1. Dezember Ich hielt einen Vortrag unter dem Titel "Winnig with Monitoring".
Zum Glück erhielt ich während der Veranstaltung einige Stimmen, die sagten: "Bitte geben Sie mir Präsentationsmaterial." Ich möchte diese Gelegenheit nutzen, um sie öffentlich zu machen.
Die Vorlesungszeit der Veranstaltung war mit 25 Minuten relativ kurz und ich musste ungefähr die Hälfte der von mir erstellten Materialien rasieren. Da es sehr viel ist, werde ich nur die Zusammenfassung in diesem Eintrag veröffentlichen.
Der Inhalt der Vorlesung auf der Veranstaltung Telemetriefunktion, über die in den letzten Jahren in der Kategorie Überwachung häufig gesprochen wird (Im Gegensatz zu SNMP sendet das Netzwerkgerät selbst Metriken) ist eine Implementierung. Überprüfen Sie, was als [OpenNTI] bezeichnet wird (https://github.com/Juniper/open-nti) (kein Ersatz für die offizielle Unterstützung durch Juniper). Es soll die Nützlichkeit der Telemetriefunktion bestätigen.
Zur Überprüfung die Überwachungsarchitektur
Beim Pull-Typ sendet der Kollektor eine Anforderung an ein Ziel, z. B. einen Netzwerkknoten, um Informationen zu sammeln. Andererseits gibt das Ziel eine Antwort zurück.
Andererseits ist das Ziel beim Push-Typ einseitig ein Kollektor wie SNMP Trap und SYSLOG. Es ist ein Typ, der Informationen sendet.
Wie Sie sehen können, im Gegensatz zum Pull-Typ mit Anfrage / Antwort Ich denke, der Push-Typ ist eine Architektur mit starken Echtzeit-Eigenschaften.
Ich persönlich möchte jedoch nicht darüber sprechen, was besser ist, Pull-Typ oder Push-Typ, daher denke ich, dass dies eine gute Wahl ist. (Beispielsweise kann der Pull-Typ Verzögerungen nach Anforderung / Antwort messen und ist für die Überwachung von Leben und Tod geeignet.)
Das Folgende ist die Klassifizierung des Überwachungssystems, aber da es nicht möglich ist, eine eindeutige Klassifizierung vorzunehmen Ich hoffe, Sie können es nur als Beispiel nehmen.
In der Realität gibt es verschiedene Kombinationen, und die Backend-Datenquelle kann ausgewählt werden. Selbst in der Architektur kann die Existenz von SNMP nicht ignoriert werden. Ich denke, dass die meisten Push-Typen den Pull-Typ mit Plug-Ins usw. unterstützen.
SNMP Ich denke, dass das Protokoll namens SNMP bei der Überwachung unvermeidlich ist. Nachfolgend sind die Stärken und Probleme aufgeführt.
Ich habe zu viel über SNMP zu reden, deshalb werde ich es weglassen.
■Cisco ・ Die Telemetriefunktion wurde in IOS XR 6.X implementiert (Das kürzeste Intervall zum Überspringen der Metrik scheint bisher 5 Sekunden zu betragen.)
・ Implementierungsbeispiel IOS XR 6.X + Streaming Telemetry Collector Stacks
■Arista ・ Telemetriefunktionen wie LANZ wurden schon früh implementiert.
・ Implementierungsbeispiel NetDB + CloudVision EOS Splunk Extension + Splunk Apps LANZ + CorvilNet
■Juniper ・ Von QFX5100 zu Insight Technology (in diesem Eintrag als Analyticsd bezeichnet) Erzielen Sie Telemetrie mit einer Funktion namens ・ Implementiert mit einer Funktion namens JTI (Junos Telemetry Interface) auch in MX usw.
・ Implementierungsbeispiel Analyticsd + Cloud Analytics Engine + Network Director Analyticsd + Contrail docker-junos-datadog junos-telemetry-splunk NetReflex BizReflex
** OpenNTI ⇒ ** Vorlesungsunterlagen
P.6 In OpenNTI gibt es einen Prozess namens "Data Streaming Collector" Dies ist die Verarbeitung mit der Telemetriefunktion des Netzwerkgeräts (Push-Typ). Es gibt auch einen Prozess namens "Data Collection Agent" Dies ist ein Prozess zum Abrufen von Daten über Netconf (Pull-Typ). Das letzte "SYSLOG" sendet nicht das Protokoll aller Netzwerkgeräte Ich versuche nur bestimmte Ereignisse zu senden (z. B. Commit abgeschlossen) (die später für die Analyse verwendet werden können).
P.8 Dies ist eine Beispieleinstellung für Analyticsd, aber der Wert des Tiefenschwellenwerts für das Einstellungselement ist ziemlich niedrig. In einigen Fällen kann es erforderlich sein, den Wert zu ändern.
P.9 Was kann mit der Telemetriefunktion erreicht werden? ・ Überwachung des Paketpuffers und der Kommunikationsverzögerung ・ Microburst-Überwachung ・ Broad / Multicast-PPS-Überwachung
Aber diese Vorteile sind Szenen, die als Dienstanbieter wahrscheinlich Probleme verursachen, z. B. das Verhindern von Dienstauswirkungen, das sofortige Erkennen und das Aufnehmen von Beweisen (Beispielsweise treten Kommunikationsverzögerungen auf, Kommunikationsnachweise, die das Band vorübergehend füllen, werden unterdrückt, Stürme werden erkannt usw.) Es ist wirksam in.
P.11 Jvision kann andere als Interface als Ressource für Einstellungselemente angeben und [startet verschiedene Vorgänge unter JUNOS 16.1R3](http://www.juniper.net/techpubs/en_US/junos16.1/information-products/topic- Sammlungen / Versionshinweise / 16.1 / topic-105380.html # jd0e6650) Es scheint, dass verschiedene Informationen erhalten werden können (Vorgang nicht verifiziert).
P.17 Wenn OpenNTI gestartet wird, können Sie auf die Web-GUI zugreifen und die gesammelten Daten anzeigen. "Data Streaming Collector Dashboard" sind die von der Telemetriefunktion erfassten Daten. Es wird das anzuzeigende Dashboard sein.
Bitte seien Sie vorsichtig, wenn Sie versuchen, OpenNTI so zu verwenden, wie es ist. Es gibt einen kleinen Fehler. Beispielsweise ist "Daten-Streaming" auch für diesen Dashboard-Namen korrekt. Der Buchstabe "r" fehlt und wird zu "Data Steaming", oder die angezeigten Daten sind tatsächlich Es sollte die Broadcast-Daten der Schnittstelle anzeigen, aber es werden die Multicast-Daten angezeigt. Es gibt einige Fehler.
P.18 "Data Collection Agent Dashboard" kann die über Netconf erfassten Daten anzeigen. Es kann verwendet werden, um zu überwachen, ob ein bestimmter Prozess von JUNOS einen Speicherverlust aufweist.
P.20 Die erste Grafik wird von Kakteen in Intervallen von 1 Minute überwacht. Wenn Datenverkehr von ca. 9,4 Gbit / s 30 Sekunden, 20 Sekunden und 10 Sekunden lang übertragen wird Es fließen jeweils nur 4,5 Gbit / s, 2,5 Gbit / s und 1,5 Gbit / s. Tatsächlich fließen 9,4 Gbit / s Verkehr, aber dies ist die Grenze, die Cacti erkennen kann. (Natürlich gibt es auch Informationen, die mit dem Echtzeit-Plug-In von Cacti usw. ermittelt werden können.) Das folgende Diagramm wurde von der Telemetriefunktion erfasst, und genaue Informationen können sogar für 10 Sekunden erfasst werden.
Wenn die Leitung mit kurzfristigem DDoS usw. gefüllt ist und der Dienst nicht mehr verfügbar ist Ob die Zeile wirklich von DDoS usw. gefüllt wurde Es gibt viele Fälle, in denen es zu einem Problem für den Benutzer wird, und ich denke, dass es nur wenige Fälle gibt, in denen das erste Cacti-Diagramm überzeugt. Normalerweise werden das Verkehrsdiagramm und die xFlow-Informationen kombiniert, um das Problem zu lösen. In vielen Fällen kann das Feuer nicht in ein oder zwei Tagen gelöscht werden. Ich denke, dass es ein großer Vorteil ist, die tatsächliche Verkehrssituation mit hoher Genauigkeit überwachen und speichern zu können.
P.25 Das obere Diagramm zeigt den Datenverkehr, der von Benutzern generiert wurde, die QoS angewendet haben. Die Grafik unten zeigt die Kommunikation, die aufgrund der Einschränkungen der QoS unterbrochen wurde. Normalerweise wird der Verkehr über physische und logische Schnittstellen usw. überwacht. Regelbasierte Überwachung ist möglich.
P.27 Die Datenerfassung über Netconf ist in der Regel ein Engpass Selbst wenn Sie versuchen zu optimieren, verwendet die SSH-Verarbeitung von PyEZ Paramiko, und Sie können den ControlMaster usw. einstellen. Da es nicht geändert werden kann, ist es nicht möglich, SSH-Sitzungen zu bündeln. Daher können wir uns nur mit der Erhöhung der Vielzahl der SSH-Verarbeitung befassen (mehrfache Cron-Registrierung durchführen).
Wir haben OpenNTI verifiziert, erwarten jedoch nicht, OpenNTI wie in der Produktionsumgebung zu verwenden. Wir planen, ein Überwachungssystem auf einem Bare-Metal-Server aufzubauen, indem wir nur den Mechanismus umleiten.
Der Grund ist, dass es (jetzt) physiologisch unangenehm ist, eine DB im Docker-Container zu haben. Mit dem Docker-Container müssen Sie jetzt den Container selbst überwachen. (Jetzt) gibt es viele Lösungen für die Containerverwaltung und -überwachung. Es ist ein vager Grund, warum ich die Situation für eine Weile sehen möchte.
Natürlich ist auch nicht nur der Visualisierungsteil, sondern auch das Warnsystem miteinander verbunden. Ursprünglich wurde Kapacitor angenommen, da es einfach ist, sich mit InfluxDB zu verbinden. Obwohl es sich um eine Beta-Version von Grafana 4.0 handelt, wurde die Warnfunktion implementiert. Dies wird auch ein Kandidat sein.
Recommended Posts