Einführung in die Sonden

Probes sind die grundlegende Abstraktionseinheit in Intent-Based Analytics. Im Allgemeinen verbraucht eine bestimmte Sonde einen Datensatz aus dem Netzwerk, führt verschiedene aufeinanderfolgende Aggregationen und Berechnungen durch und gibt optional einige Bedingungen dieser Aggregationen und Berechnungen an, bei denen Anomalien ausgelöst werden.

Probes sind gerichtete azyklische Graphen (Directed Acyclic Graphs, DAGs), bei denen die Knoten des Graphen Prozessoren und Stufen sind. Stufen sind mit Kontext verknüpfte Daten, die vom Bediener überprüft werden können. Prozessoren sind eine Reihe von Vorgängen, die Ausgabedaten aus Eingabedaten erzeugen und reduzieren. Die Eingabe für Prozessoren besteht aus einer oder mehreren Stufen, und die Ausgabe von Prozessoren besteht ebenfalls aus einer oder mehreren Phasen. Die Richtungsabhängigkeit der Kanten in einer Messtasten-DAG stellt diesen Input-to-Output-Fluss dar.

Wichtig ist, dass die anfänglichen Prozessoren in einer Sonde speziell sind und keine Eingangsstufe haben. Sie sind fiktiv Generatoren von Daten. Wir bezeichnen diese als Quellverarbeiter.

Bei der IBA werden Telemetriedaten von Kollektoren in Sonden eingespeist, um Erkenntnisse zu extrahieren (z. B. Anomalien, Aggregationen usw.). Ein bestimmter Collector veröffentlicht Telemetriedaten als eine Sammlung von Metriken, wobei jede Metrik über eine Identität (d. h. eine Gruppe von Schlüssel-Wert-Paaren) und einen Wert verfügt. IBA-Sonden, häufig unter Verwendung von Graphabfragen, müssen die Identität einer Metrik vollständig angeben, um ihren Wert in die Sonde aufzunehmen. Mit dieser Funktion können Sonden mithilfe von Erfassungsfiltern Metriken mit teilweiser Identitätsangabe erfassen und so die Erfassung von Metriken mit unbekannten Identitäten ermöglichen.

Einige Sondierungen werden automatisch erstellt. Diese Sondierungen werden nicht automatisch gelöscht. Dies hält die Dinge operativ und in Bezug auf die Implementierung einfach.

Prozessoren

Die Eingabeprozessoren eines Tests übernehmen die erforderliche Konfiguration, um unformatierte Telemetriedaten in den Test einzuspeisen und die Datenverarbeitungspipeline in Gang zu setzen. Bei diesen Prozessoren ist die Anzahl der Stufenausgabeelemente (eines oder mehrere) gleich der Anzahl der Ergebnisse in den angegebenen Diagrammabfragen. Zum Beispiel, wenn mehrere Graphabfragen angegeben sind. graph_query: [A, B], und Abfrage A stimmt mit 5 Knoten überein und Abfrage B stimmt mit 10 Knoten überein, auf die Ergebnisse von Abfrage A kann mit query_result Indizes von 0 bis 4 und auf die Ergebnisse von Abfrage B mit Indizes von 5 bis 14 zugegriffen werden.

Wenn der Eingabe- und/oder Ausgabetyp eines Prozessors nicht angegeben ist, nimmt der Prozessor eine einzelne Eingabe, die als in aufgerufen wird, und erzeugt eine einzelne Ausgabe, die out genannt wird.

Einige Prozessorfelder werden als Ausdrücke bezeichnet. In einigen Fällen handelt es sich um Graphabfragen und werden so vermerkt. In anderen Fällen handelt es sich um Python-Ausdrücke , die einen Wert ergeben. Beispielsweise kann die Dauer im Accumulate-Prozessor als Ganzzahl mit Sekunden angegeben werden, z. B 900. , oder als Ausdruck, z. B 60 * 15. . . Ausdrücke könnten jedoch nützlicher sein: Es gibt mehrere Möglichkeiten, sie zu parametrisieren.

Ausdrücke unterstützen Zeichenfolgenwerte. Prozessorkonfigurationsparameter, bei denen es sich um Zeichenfolgen und Unterstützungsausdrücke handelt, sollten bei der Angabe des statischen Werts spezielle Anführungszeichen verwenden. Zum Beispiel ist nicht gültig, state: "up" weil es sich auf die Variable "up" bezieht, nicht auf eine statische Zeichenfolge, also sollte es sein: state: '"up"'.

Ein Ausdruck ist immer einer Diagrammabfrage zugeordnet und wird für jede resultierende Übereinstimmung dieser Abfrage ausgeführt. Der Ausführungskontext des Ausdrucks ist so, dass jede in der Abfrage angegebene Variable in einen benannten Knoten im zugeordneten Übereinstimmungsergebnis aufgelöst wird. Weitere Informationen finden Sie unter Beispiel für einen Dienstdatensammler .

Graphbasierte Prozessoren wurden um query_tag_filter erweitert, mit dem Sie Graphabfrageergebnisse nach Tags filtern können. In IBA-Sonden werden Tags nur als Filterkriterien für Server und externe Router verwendet, insbesondere für die ECMP-Imbalance-Sonde (externe Schnittstellen) und die Probe Total East/West Traffic. Spezifische Informationen zum Prozessor finden Sie unter Prüfprozessoren im Abschnitt Referenzen.

Verschluckungsfilter

Mit "Erfassungsfiltern" kann ein Abfrageergebnis mehrere Metriken in eine Sonde aufnehmen. Tabellendatentypen werden verwendet, um mehrere Metriken als Teil eines einstufigen Ausgabeelements zu speichern. Zu den Tabellendatentypen gehören table_ns, table_dss, table_ts -, um den vorhandenen Typen -ns, ts dss, -. zu entsprechen.

IBA-Sammlungsfilter

Erfassungsfilter bestimmen die Metriken, die von den Zielgeräten erfasst werden.

Ein Erfassungsfilter für einen bestimmten Kollektor auf einem bestimmten Gerät ist einfach eine Sammlung von Erfassungsfiltern, die in verschiedenen Sonden vorhanden sind. Sie können es auch als Teil der Aktivierung eines Service außerhalb des Kontexts von IBA oder Sondierungen angeben, aber hier gelten die vorhandenen Rangfolgenregeln für die Serviceaktivierung - nur Filter auf einer bestimmten Rangfolgeebene werden aggregiert. Wenn mehrere Tests einen Erfassungsfilter angeben, der auf einen bestimmten Dienst auf einem bestimmten Gerät abzielt, sind die erfassten Metriken eine Vereinigung, d. h., eine Metrik wird veröffentlicht, wenn sie mit einem der Filter übereinstimmt. Aus diesem Grund werden die Daten auch von der Steuerungskomponente gefiltert, bevor sie in die IBA-Sonden aufgenommen werden.

Dieser Filter wird von Telemetriesammlern ausgewertet, häufig um besser steuern zu können, welche Teilmenge der verfügbaren Metriken vom Betriebssystem des zugrunde liegenden Geräts abgerufen wird (z. B. um nur eine Teilmenge der Routen abzurufen, anstatt alle Routen abzurufen, was eine große Zahl sein kann). In jedem Fall werden nur die Metriken, die dem Sammlungsfilter entsprechen, als unformatierte Telemetriedaten veröffentlicht.

Im Rahmen der Aktivierung eines Dienstes auf einem Gerät können Sie jetzt Erfassungsfilter für Dienste angeben. Dieser Filter wird zu einer zusätzlichen Eingabe, die Kollektoren als Teil von "self.service_config.collection_filters" zur Verfügung gestellt wird.

IBA-Filterformat

Im Folgenden sind die Design-/Usability-Ziele für Filter (Erfassung und Erfassung) aufgeführt:

Einfaches Erstellen - die angegebenen Testautoren sind diejenigen, die dies angeben
- In den meisten Fällen sind Übereinstimmung mit beliebig, Übereinstimmung mit einer gegebenen Liste möglicher Werte, Gleichheitsübereinstimmung und Bereichsprüfung, ob der Schlüssel numerische Werte hat.
Effiziente Auswertung – vorausgesetzt, die Filter werden in den heißen Pfaden der Erfassung oder Aufnahme ausgewertet.
Aggregierbar – Mehrere Filter werden aggregiert, sodass diese Aggregationslogik nicht in die Verantwortung einzelner Kollektoren fallen muss.
Programmiersprachenneutral - Komponenten, die mit Filtern arbeiten, können in Zukunft in Python oder C++ oder einer anderen Sprache vorliegen.
Programmierbar - Konfigurierbar für zukünftige Programmierbarkeit rund um die Filter, durch den Controller selbst und/oder Kollektoren, um Dinge wie Benutzerfreundlichkeit, Leistung usw. zu verbessern.

Unter Berücksichtigung der oben genannten Ziele finden Sie im Folgenden ein vorgeschlagenes und illustratives Schema für filter1. In den Abschnitten zum Erfassungsfilter finden Sie spezifische Beispiele, um dies besser zu verstehen.

Eine Instanz der Filterspezifikation wird als AND aller angegebenen Schlüssel interpretiert (auch bekannt als Einschränkungen pro Schlüssel). Mehrere Filterspezifikationen, die von mehreren Sonden stammen, werden auf Filterebene als OR betrachtet.

Hinweis:

Das hier vorgestellte Schema dient nur zur Kommunikation der Anforderungen. Sie können einen beliebigen Weg wählen, der die angegebenen Anwendungsfälle erfüllt.

Auf Collector-Prozessoren additional_properties die in der Konfiguration der Collector-Prozessoren angegeben sind, kann über den speziellen context. Namespace zugegriffen werden. Wenn z. B. ein Collector eine Eigenschaft system_roledefiniert, kann sie wie folgt verwendet werden:

Hinweis:

Der Elementkontext ist verfügbar, solange der Elementsatz gegenüber dem ursprünglichen Satz, der aus der Collector-Prozessorkonfiguration abgeleitet wurde, unverändert ist. Nachdem Daten einen Prozessor durchlaufen haben, der diesen Satz ändert, sind sie nicht mehr verfügbar (z. B. ein Gruppierungsprozessor).

Navigieren Sie im Blueprint zu Analytics > Probes , um zur Tabellenansicht "Tests" zu wechseln. Um zu den Details einer Sonde zu gelangen, klicken Sie auf ihren Namen. Sie können Sonden instanziieren, erstellen, klonen, bearbeiten, löschen, importieren und exportieren. Der folgende Screenshot zeigt Apstra Version 4.2.0. In Apstra Version 4.2.1 wurden einige Menü-Tabs umbenannt, verschoben und/oder hinzugefügt.

Sie können Stufen in einigen Sonden auf verschiedene Arten anzeigen. Wenn Sie z. B. auf den Test " Gerätesystemintegrität" klicken, wird das folgende Bild angezeigt. Sie können die Datenquelle von Echtzeit in Zeitreihen ändern und dann die Daten auf verschiedene Weise aggregieren. Außerdem können Sie ggf. den auf jeder Sonde verwendeten Speicherplatz anzeigen.

VORSICHT:

Wenn der Apstra-Controller nicht über ausreichend Speicherplatz verfügt, werden ältere Telemetriedatendateien gelöscht. Um ältere Telemetriedaten beizubehalten, können Sie die Kapazität mit Apstra VM-Clustern erhöhen.

Der Aufbau und die Logik von nichtlinearen Tastköpfen mit Dutzenden von Prozessoren ist in der Standardansicht nicht leicht zu unterscheiden. Sie können auf die Schaltfläche "Erweitern" (oben im linken Bereich) klicken, um eine erweiterte Darstellung der Beziehung zwischen den Prozessoren anzuzeigen. Die folgende Abbildung zeigt z. B. einen Teil der erweiterten Ansicht des Tests "Gerätetelemetrieintegrität ".

Datenquellen

In den entsprechenden Phasen können Sie die Quelle angeben, die zum Sammeln von Daten verwendet werden soll, entweder in Echtzeit oder in Zeitreihen. Bei Zeitreihen können Sie die Art und Weise, wie die Daten erfasst werden, wie folgt anpassen:

Aggregationstyp (neu in Apstra Version 4.2.0)
- Nichts
- allOf - boolean - True, wenn wahr für alle Stichproben in der Periode
- anyOf - boolean - True, wenn für mindestens eines der Stichproben in der Periode wahr ist
- Durchschnitt - Durchschnittswert in der Aggregationsperiode
- Letzter - letzter Wert im Aggregationszeitraum
- Max - Maximalwert in der Aggregationsperiode
- Min - Mindestwert im Aggregationszeitraum
Aggregationszeitraum (Aus oder eine festgelegte Anzahl von Sekunden, Minuten, Stunden oder Tagen)
Wie weit die Erfassung zurückliegt (die letzte Anzahl von Minuten, Stunden oder Tagen)

AUF DIESER SEITE