cubebeat

Cubebeat

Benutzerdefinierter Beat des Elastic Stack zur Interaktion mit den Polycube-basierten eBPF-Cubes.

---

Inhaltsverzeichnis

• Cubebeat
  • Inhaltsverzeichnis
  • Erste Schritte
    • Anforderungen
    • Laden Sie den Code herunter
    • Bauen
    • Laufen
    • Konfiguration
      • Laden Sie externe Konfigurationsdateien
      • Live-Nachladen

---

Stellen Sie sicher, dass sich dieser Ordner am folgenden Speicherort befindet: ${GOPATH}/src/gitlab.com/astrid-repositories/cubebeat

Erste Schritte

Anforderungen

• Golang 1.7
• Befolgen Sie die Anweisungen unter Einrichten Ihrer Entwicklungsumgebung.

Laden Sie den Code herunter

 mkdir -p ${GOPATH}/src/gitlab.com/astrid-repositories/
cd ${GOPATH}/src/gitlab.com/astrid-repositories
git clone https://gitlab.com/astrid-repositories/cubebeat.git

Bauen

Um die Binärdatei für Cubebeat zu erstellen, führen Sie den folgenden Befehl aus. Dadurch wird im selben Verzeichnis eine Binärdatei mit dem Namen „cubebeat“ generiert.

 chmod +x build.sh
build.sh

Laufen

Um Cubebeat mit aktivierter Debugging-Ausgabe auszuführen, führen Sie Folgendes aus:

 ./cubebeat -c cubebeat.yml -e -d "*"

Um Cubebeat ohne aktivierte Debugging-Ausgabe auszuführen, führen Sie Folgendes aus:

 ./cubebeat -c cubebeat.yml -e

Konfiguration

Cubebeat liest die Konfigurationsdatei (Standard: cubebeat.yml ), die als Argument übergeben wird.

Diese Datei akzeptiert die gängigen Beat-Konfigurationen, wie unter „Konfigurationsdateiformat“ beschrieben.

Darüber hinaus werden bestimmte Konfigurationen akzeptiert, wie im nächsten Beispiel gezeigt:

 cubebeat :
  config.inputs :
    path : config/*.yml
    reload :
      enabled : true
      period : 10s

Die verschiedenen Optionen werden in den folgenden Abschnitten erläutert.

Laden Sie externe Konfigurationsdateien

Cubebeat kann externe Konfigurationsdateien für Eingaben laden, sodass Sie Ihre Konfiguration in mehrere kleinere Konfigurationsdateien aufteilen können.

Auf Systemen mit POSIX Dateiberechtigungen unterliegen alle Konfigurationsdateien einer Eigentums- und Dateiberechtigungsprüfung.
Weitere Informationen finden Sie unter „Config File Ownership and Permissions“ in der Beats Platform Reference .

Sie geben die path im Abschnitt cubebeat.config.inputs der cubebeat.yml an. Zum Beispiel:

 cubebeat :
  config.inputs :
    path : config.d/*.yml

Jede über den path Glob gefundene Datei muss eine Liste mit einer oder mehreren Eingabedefinitionen enthalten.

Die erste Zeile jeder externen Konfigurationsdatei muss eine Eingabedefinition sein, die mit - name beginnt.

Zum Beispiel:

- name : synflood
  enabled : true
  period : 10s
  polycube.api-url : " http://localhost:9000/polycube/v1/synflood/sf/stats/ "

- name : packetcapture
  enabled : true
  period : 5s
  polycube.api-url : " http://localhost:9000/polycube/v1/packetcapture/pc "

Es ist wichtig, dass zwei laufende Eingaben NICHT denselben name haben. Wenn mehrere Personen denselben name eingeben, wird nur die erste akzeptiert; während die anderen verworfen werden.

Wenn die enabled Option true ist, interagiert die spezifische Cube-Eingabe regelmäßig mit dem spezifischen Polycube-Cube in jedem in period definierten Zeitintervall und stellt eine HTTP-Anfrage an die in polycube.api-url definierte URL her.

Wenn der Cube nicht erreichbar ist oder beim Abrufen der Daten ein Fehler auftritt, funktioniert cubebeat weiter und versucht nach einer in period definierten Zeitspanne eine neue Verbindung.

In jedem period sendet der jeweilige Cube-Eingang ein neues Elastic -Ereignis an den Ausgang, wie in der Konfigurationsdatei „ cubebeat.yml definiert

Live-Nachladen

Sie können cubebeat so konfigurieren, dass externe Konfigurationsdateien bei Änderungen dynamisch neu geladen werden. Diese Funktion ist für Eingabekonfigurationen verfügbar, die als externe Konfigurationsdateien geladen werden. Sie können diese Funktion nicht zum Neuladen der Hauptkonfigurationsdatei cubebeat.yml verwenden.

Um diese Funktion zu konfigurieren, geben Sie einen path (Glob) an, der auf Konfigurationsänderungen überwacht werden soll. Wenn sich die vom Glob gefundenen Dateien ändern, werden neue Eingaben entsprechend den Änderungen in den Konfigurationsdateien gestartet und gestoppt.

Diese Funktion ist besonders nützlich in Containerumgebungen, in denen ein Container zum Protokollieren von Diensten verwendet wird, die in anderen Containern auf demselben Host ausgeführt werden.

Um das dynamische Neuladen der Konfiguration zu aktivieren, geben Sie den path und die reload im Abschnitt cubebeat.config.inputs an. Zum Beispiel:

 cubebeat :
  config.inputs :
    path : config/*.yml
    reload :
      enabled : true
      period : 10s

Option	Beschreibung
path	Ein Glob, der die Dateien definiert, die auf Änderungen überprüft werden sollen.
reload.enabled	Bei Festlegung auf „true“ wird das dynamische Neuladen der Konfiguration aktiviert.
reload.period	Gibt an, wie oft die Dateien auf Änderungen überprüft werden. Stellen Sie den period nicht auf weniger als 1s ein, da die Änderungszeit von Dateien häufig in Sekunden gespeichert wird. Wenn Sie den period auf weniger als 1s festlegen, entsteht unnötiger Overhead .

Auf Systemen mit POSIX Dateiberechtigungen unterliegen alle Konfigurationsdateien einer Eigentums- und Dateiberechtigungsprüfung.
Weitere Informationen finden Sie unter „Config File Ownership and Permissions“ in der Beats Platform Reference .