ELK Stack mit Elasticsearch aufbauen

App Cloud

ELK Stack mit Elasticsearch aufbauen

Wir haben unseren brandneuen Elasticsearch-Dienst auf der Swisscom Application Cloud eingeführt (zum Zeitpunkt der Erstellung dieses Artikels in der geschlossenen Beta-Phase, aber die allgemeine Verfügbarkeit wird in Kürze erfolgen). Dieser Dienst ersetzt unser altes ELK-Angebot durch stabilere und flexiblere Optionen. In diesem Beitrag zeigen wir dir, wie du Elasticsearch in Verbindung mit den Logstash- und Kibana-Buildpacks nutzen kannst, um den dir bereits bekannten ELK-Stack zu erhalten. Außerdem geben wir dir einige Ansatzpunkte, wie du die erhöhte Flexibilität des Angebots nutzen kannst, um den Stack an deine Bedürfnisse anzupassen.

Von Mathis Kretz, Former Head of Cloud Empowerment

Erstellen der Service-Instanz

Wir beginnen damit, eine Instanz des neuen Elasticsearch-Dienstes zu erstellen. Wenn du auf unserem Marktplatz nachschaust, wirst du sehen, dass es sechs verschiedene Pläne gibt, aus denen du wählen kannst, von xxsmall* bis xlarge*. Diese T-Shirt-Größen geben den Betrag an RAM an, den deine Elasticsearch-Instanz erhält, und in Abhängigkeit davon den Betrag an Festplattenplatz. Für die Zwecke unseres Tutorials ist xxsmall* ausreichend. Für deinen produktiven ELK-Stack benötigst du natürlich einen größeren Plan. Lass uns also die Instanz erstellen:

Damit wird ein Elasticsearch-Cluster mit drei Knoten bereitgestellt, der sich über drei Standorte erstreckt. Als nächstes werden wir Logstash und Kibana hinzufügen. Unser altes ELK-Angebot beinhaltete Logstash und Kibana mit fest verdrahteten Konfigurationen als Teil der Service-Instanz. Im neuen Ansatz ist das nicht mehr der Fall. Stattdessen installieren wir diese beiden Komponenten selbst mithilfe der Logstash(öffnet ein neues Fenster)- und Kibana(öffnet ein neues Fenster)-Buildpacks. Diese Buildpacks werden verwendet, um beide Komponenten als Apps in Cloud Foundry zu pushen, wobei die jeweilige Konfiguration, die der Nutzer in verschiedenen Konfigurationsdateien angegeben hat, übernommen wird. Die Einrichtung ist zwar etwas aufwändiger, hat aber den Vorteil, dass man auf ganz natürliche Weise individuelle Konfigurationen erstellen kann.

Installieren von Logstash

Bitte beachte: Dieser Abschnitt wird derzeit geändert, um die neue Art der Bereitstellung von Logstash zu beschreiben(öffnet ein neues Fenster).

Richten wir also die minimale Konfiguration ein, die wir brauchen, um Logstash mit dem Logstash-Buildpack(öffnet ein neues Fenster) zu pushen. Wir beginnen in einem neuen Verzeichnis

und wir erstellen die folgenden zwei Dateien

Wie in Cloud Foundry üblich, schreiben wir eine manifest.yml, um der Plattform mitzuteilen, wie sie Logstash als App einrichten soll. Wir nennen die App my-logstash und sie wird natürlich an unsere Elasticsearch-Instanz gebunden. Außerdem weisen wir Cloud Foundry mit der Option buildpack an, das Logstash-Buildpack(öffnet ein neues Fenster) zu verwenden.

Die Logstash-Datei, die wir ebenfalls erstellt haben, enthält Konfigurationseinstellungen für Logstash. Wenn du diese Datei leer lässt, wird Logstash mit den Standardeinstellungen ausgeführt. In unserem Fall wollen wir die Authentifizierung hinzufügen, um unsere Logstash-Instanz vor unbefugtem Zugriff zu schützen. Daher fügen wir die folgenden Zeilen zu Logstash hinzu

Mit diesem Schritt ist unsere Logstash-Instanz bereit für die Bereitstellung, also pushen wir sie.

Sobald der Push abgeschlossen ist, haben wir eine laufende Logstash-Instanz, die mit unserer Elasticsearch-Instanz verbunden ist. Jetzt machen wir das Gleiche für Kibana.

Installation von Kibana

Bitte beachte: Dieser Abschnitt wird derzeit geändert, um die neue Art der Bereitstellung von Kibana(öffnet ein neues Fenster) zu beschreiben.

Beginnen wir also wieder in einem neuen Verzeichnis, um unsere Kibana-Bereitstellung vorzubereiten.

Wir fügen die folgenden zwei Dateien in dieses Verzeichnis ein, um die Minimalkonfiguration bereitzustellen

In der Kibana-Konfigurationsdatei binden wir das X-Pack-Plugin ein. Dieses Plugin bietet Unterstützung für den authentifizierten Zugriff, den wir zum Schutz unserer Kibana-Benutzeroberfläche benötigen. Das Plugin bietet außerdem eine ganze Reihe weiterer Zusatzfunktionen für Kibana und Logstash, die den Rahmen dieses Beitrags sprengen würden.

In der manifest.yml legen wir fest, dass unsere Kibana-Instanz my-kibana heißt, sich mit unserer Elasticearch-Instanz verbindet und 3 GB Speicher für die Installation des X-Pack-Plugins erhält. Im Prinzip kannst du deine Kibana-Instanz nach dem ersten Einsatz auf 2G verkleinern, da der zusätzliche Speicher nach der Installation nicht mehr benötigt wird. Auch hier verwenden wir die Option buildpack, um Cloud Foundry anzuweisen, das Kibana-Buildpack zu verwenden.

Jetzt können wir Kibana weiter vorantreiben.

Wenn der Push abgeschlossen ist, sind wir mit der Einrichtung aller notwendigen Komponenten fertig. Wir können die Einrichtung überprüfen, indem wir Folgendes eingeben

und überprüfe, ob wir die Elasticsearch-Instanz und die App-Bindungen an my-logstash und my-kibana sehen können.

Verbinden des Stacks mit deiner App

Als Nächstes wollen wir die Anwendungsprotokolle an unseren neu erstellten ELK-Stack weiterleiten. Dazu erstellen wir einen benutzerdefinierten Dienst mit der Option -l. Mit dieser Option können Anwendungen, die sich an den Dienst binden, ihre Logs an eine Syslog-kompatible Komponente, in unserem Fall Logstash, weiterleiten.

Im letzten Schritt binden wir diesen vom Benutzer bereitgestellten Dienst an die App, von der wir Logs sammeln wollen, und stellen die App wieder her.

Wir sind nun mit der grundlegenden Einrichtung unserer ELK-Komponenten fertig. Bevor wir mit der weiteren Konfiguration fortfahren, machen wir einen ersten schnellen Test, indem wir uns in Kibana einloggen. Die URL der Kibana-Instanz lautet in diesem Beispiel my-kibana.scapp.io. Die Anmeldedaten erhalten wir aus der Umgebungsvariablen VCAP_SERVICES unserer Kibana-App

und suche nach den Feldern full_access_username undfull_access_password

Nach dem Einloggen werden wir aufgefordert, ein erstes Indexmuster zu erstellen. Im Moment haben wir nur einen Logstash-Index zur Auswahl (stelle sicher, dass du etwas Log-Traffic von deiner App ausgelöst hast, um dies zu sehen).

Wir können ein Muster angeben, um Kibana mitzuteilen, welcher Index oder welche Indizes bei der Anzeige der Daten herangezogen werden sollen. Wenn du * eingibst, werden alle Indizes verwendet. Wenn du logstash-* eingibst, werden Indizes, deren Namen mit logstash- beginnen, verwendet. Wenn wir ein Indexmuster angeben, können wir Kibana auch mitteilen, welches Feld in den Daten für die Sortierung der Datensätze über die Zeit verwendet werden soll. Wir können immer @timestamp wählen, ein Feld, das automatisch von Elasticsearch hinzugefügt wird. Alternativ können wir auch ein geeigneteres Feld wählen, das wir als Teil unserer Logstash-Konfiguration zu unseren Daten hinzufügen. Für dieses Beispiel wählen wir @timestamp.

Wir können jetzt zum Discover-Bildschirm von Kibana navigieren und überprüfen, ob wir Log-Einträge von der App sehen, die wir gebunden haben.

Wenn wir uns die Log-Einträge ansehen, stellen wir jedoch fest, dass sie noch nicht so strukturiert sind, wie wir sie im alten ELK-Dienst hatten. Das Nachrichtenfeld enthält im Grunde die gesamte unanalysierte Nachricht. Als Nächstes werden wir sehen, welche Teile der Konfiguration wir anpassen müssen, um die gleiche Verarbeitung der Logmeldungen zu erreichen wie beim alten ELK.

Konfigurationsoptionen

Der alte ELK-Dienst verfügte über einen Filter, der die Log-Meldungen analysierte und

- Felder gemäß der Syslog-Protokollspezifikation(öffnet ein neues Fenster) extrahierte- Nachrichten, die JSON-Objekte enthalten, entsprechend den JSON
- Attributnamen in Felder aufteilte

Außerdem gab es eine Curator(öffnet ein neues Fenster)-Konfiguration, die dafür sorgte, dass Elasticsearch in regelmäßigen Abständen aufgeräumt wurde. Wir werden die Einzelheiten der Konfiguration von Curator in einem zukünftigen Beitrag beschreiben.

Bevor wir mit der Filterkonfiguration beginnen, solltest du wissen, dass du die Vorlagen für die unten aufgeführten Konfigurationsdateien(öffnet ein neues Fenster) auf Github findest. Es handelt sich um Vorlagen, weil du bestimmte Parameter, wie den Elasticsearch-Hostnamen deiner Instanz und die Zugangsdaten, durch die entsprechenden Werte aus deiner Umgebung ersetzen musst.

Um unseren neuen ELK-Stack so zu konfigurieren, dass er die Logs auf die gleiche Weise verarbeitet wie der alte ELK, müssen wir den gemischten Konfigurationsmodus wählen, der in der Dokumentation des Logstash-Buildpacks(öffnet ein neues Fenster) beschrieben wird. Vor allem müssen wir unsere eigene Filter- und Ausgabekonfiguration festlegen. Zu diesem Zweck fügen wir zwei neue Unterverzeichnisse conf.d und grok-patterns zu dem Verzeichnis hinzu, in dem wir unsere Logstash-Konfiguration eingerichtet haben. Außerdem fügen wir die Dateien filter.conf, output.conf und grok-patterns wie folgt in diese Verzeichnisse ein:

In filter.conf legen wir eine benutzerdefinierte Filterdefinition fest, die das Syslog- und JSON-Parsing durchführt. Diese Datei muss also die folgenden Zeilen enthalten:

Diese Filterdefinition verweist auf ein Grok-Muster, das in der Datei grokpatterns vorhanden sein muss:

Das obige Grok-Pattern trennt das Standard-Präfix einer Cloud Foundry-Logzeile in die entsprechenden Felder der Syslog-Spezifikation.

Wie beim alten ELK wollen wir die Indizierung in zwei separate Indizes aufteilen, einen für geparste Nachrichten und einen für Nachrichten, die vom obigen Filter nicht geparst wurden. Um dies zu erreichen, enthält die Datei output.conf die folgenden Zeilen:

Die Werte HOST, USER und PASSWORD müssen dem Host, full_access_username und full_access_password aus dem elasticsearch-Eintrag in VCAP_SERVICES von my-logstash entsprechen.

Da wir uns im gemischten Konfigurationsmodus des Logstash-Buildpacks befinden und unsere eigenen Filter- und Ausgabedefinitionen angeben, müssen wir in der Datei Logstash explizit auf die Standard-Eingabedefinition verweisen:

Wir müssen Logstash erneut pushen, damit diese Änderungen wirksam werden.

Wenn wir etwas Log-Traffic auslösen und dann zu Kibana zurückkehren, können wir sehen, dass es zwei neue Indizes in Elasticsearch gibt, wenn wir zu Verwaltung > Indexmuster > Indexmuster erstellen gehen. Der Name des ersten beginnt mit parsed-. Dies ist der Index, der alle Nachrichten aufnimmt, die von dem Filter, den wir gerade geschrieben haben, geparst wurden. Der Name des zweiten neuen Index beginnt mit unparsed-. Er enthält alle Nachrichten, die von dem Filter nicht geparst werden konnten. Mit ein paar Konfigurationsschritten haben wir also das Verhalten des alten ELK-Dienstes erreicht. Was ist, wenn du einige Indizes von einer alten ELK-Instanz zum neuen Elasticsearch migrieren willst? Schauen wir uns an, wie man das erreichen kann.

Migration vom alten ELK-Dienst

Wir werden das Dienstprogramm elasticdump(öffnet ein neues Fenster) verwenden, um Indizes von einem alten ELK auf eine neue Elasticsearch-Instanz zu migrieren. Um elasticdump zu installieren, führen wir aus

Als nächstes müssen wir ssh-Tunnel zu unserem alten ELK und zu unserem neuen Elasticsearch einrichten. Wir müssen sicherstellen, dass beide Dienste an mindestens eine App in dem Space gebunden sind, in dem wir arbeiten, damit die entsprechenden Sicherheitsgruppen in Cloud Foundry erstellt werden und der Zugriff auf beide Dienste von diesem Space aus möglich ist. Wenn die Verbindung beim ersten Mal abgelehnt wird, versuche, deine App neu zu starten, damit die neuesten Einstellungen der Sicherheitsgruppen übernommen werden. Jetzt müssen wir eine Reihe von Parametern für die Einrichtung der Tunnel sammeln. Beginnen wir mit der alten ELK-Instanz. Wir untersuchen die Umgebung einer App, an die diese Instanz gebunden ist:

In VCAP_SERVICES finden wir den Host, den Port und die Anmeldedaten für ELK

Fahren wir mit der neuen Elasticsearch-Instanz fort. Wir untersuchen erneut die Umgebung einer App, an die diese Instanz gebunden ist

und wir notieren den Host und die Anmeldedaten aus VCAP_SERVICES.

Jetzt können wir den Tunnel mit einer der Apps in diesem Bereich einrichten (es ist egal, mit welcher).

Da Elasticsearch den Hostnamen bei eingehenden HTTP-Anfragen überprüft und mit den Clusternamen abgleicht, müssen wir eine lokale Namensauflösung in /etc/hosts einrichten, damit sowohl der ELK- als auch der Elasticsearch-Host nach localhost aufgelöst werden. Wir fügen also die folgenden zwei Zeilen in /etc/hosts ein

Sobald der Tunnel und die Namensauflösung eingerichtet sind, können wir mit einer einfachen HTTP-Anfrage prüfen, welche Indizes in der ELK-Instanz vorhanden sind.

Wir erhalten eine Ausgabe in der folgenden Form, die alle Indizes auflistet

Mit elasticdump können wir nun Indizes einzeln in unser neues Elasticsearch migrieren oder ein Skript schreiben, das sie alle migriert. Für Indizes, die in der Vergangenheit erstellt wurden, kann dies während des normalen Betriebs geschehen. Du kannst also nach und nach alte Indizes aus ELK importieren, während dein neues Elasticsearch bereits läuft und neue Logdaten empfängt. Angenommen, du möchtest den Index parsed-2018.04.09 von ELK nach Elasticearch importieren. Dazu würdest du die folgenden zwei Befehle ausführen

Wenn du dich jetzt bei der Kibana-Instanz anmeldest, an die das neue Elasticsearch gebunden ist, siehst du parsed-2018.04.09 als einen deiner Indizes.

Conclusion

So, da hast du es! In diesem Beitrag haben wir dir gezeigt, wie du den ELK-Stack auf der Grundlage des neuen Elasticsearch-Angebots einschließlich der Logstash- und Kibana-Buildpacks einrichtest. Außerdem haben wir gezeigt, wie du die Konfiguration des neuen Logstash-Buildpacks anpasst, um die Einstellungen des alten ELK-Dienstes zu simulieren. Zu guter Letzt haben wir dir gezeigt, wie du Indizes von einem alten ELK auf eine neue Elasticsearch-Instanz migrierst. Diese neue Art, den ELK-Stack einzurichten, ermöglicht es dir übrigens auch, eine ELK-Instanz für mehrere Orgs und Spaces freizugeben. So kannst du Logs aus verschiedenen Projekten und Entwicklungsstadien zusammenfassen (und dabei auch noch Geld sparen). Wir hoffen, dass dir unser neues Elasticsearch-Angebot gefällt. Lass uns wissen, was du davon hältst!

Mathis Kretz

Mathis Kretz

Senior Data and Analytics Consultant

Mehr getIT-Beiträge

Bereit für Swisscom

Finde deinen Job oder die Karrierewelt, die zu dir passt. In der du mitgestalten und dich weiterentwickeln willst.

Was du draus machst, ist was uns ausmacht.

Zu den Karrierewelten

Zu den offenen Security Stellen