Select Page

NETWAYS Blog

Mermaid zum Visualisieren von Graphen

Gerade im Umfeld von Logstash-Pipelines steht man oft vor dem Problem, wie die einzelnen Code Teile zusammenhängen. Dafür hat sich für mich Mermaid bewährt.

Was mir an Mermaid besonders gefällt ist, dass man mit einer relativ einfachen Syntax Graphen definieren kann, die dann in verschiedenen Systemen gerendert werden können. Das kommt meiner Arbeitsweise beim Schreiben von Doku entgegen. Bietet aber auch die Möglichkeit, Konfiguration einfacher automatisch generieren zu lassen. Die Erstellung solcher Abhängigkeiten gestaltet sich damit einfacher als z.B. mit Graphviz. Klar sind die Möglichkeiten etwas eingeschränkt, aber wenn sie genau das bieten, was man braucht, dann stört das auch gar nicht.

Ich nutze den Mermaid Live Editor mittlerweile auch gern während unserer Elastic Stack Logmanagement Schulungen um interaktiv zu zeigen, wie sich eine Pipelinekonstruktion entwickeln kann. Natürlich kann man damit auch den Zusammenhang zwischen Komponenten eines Elastic Stack oder ähnliches wunderbar visualisieren.

Als einfaches Beispiel sei hier ein Setup gezeigt, das in einer Pipeline sowohl syslog als auch journald Events annimmt. Der Header und das Format unterscheiden sich, aber der eigentliche Inhalt ist gleich. Ausserdem sind hier noch zwei Pipelines, die Secure-Log und Cron Lognachrichten weiter zerlegen. Alle anderen Nachrichten werden nur vom Header befreit und gehen vorerst direkt weiter an Elasticsearch.

graph TD
    A[shipper] -->|syslog| B[syslog]
    A --> C[journald]
    B --> D[secure]
    C --> D 
    D --> E[forwarder]
    A --> E
    B --> E
    C --> E
    B --> F[Cron]
    C --> F
    F --> E

Direkt gerendert sieht das dann so aus:

Für die ganz Neugierigen sei noch gesagt, dass die Pfeile hier jeweils eine Übergabe per Redis-Key symbolisieren sollen. Der Übersicht halber wurde hier nur der syslog Key beschriftet. Man kann sich aber vorstellen, dass das entsprechend einfach auch mit den anderen funktionieren würde. Mermaid kümmert sich dann dabei darum, dass der Graph immer wieder so umgebogen wird, dass alles schön lesbar ist.

Die Namen der einzelnen Pipelines, bzw. deren Beschriftung, muss nur einmal angegeben werden. Der Mermaid-interne Name, hier immer nur ein Buchstabe, kann dann immer wieder verwendet werden, ohne den Namen jedesmal wieder anzugeben. Natürlich kann man sich auch die Zeit nehmen, die internen Namen sprechender zu gestalten, was durchaus für Übersicht sorgt.

Mermaid ist ein JS Projekt, das sich auch in andere Tools wie Wikisoftware integrieren lässt.

Und, Spoiler Alert!, Pipelines, die hier dargestellt werden, befinden sich auch recht aktiv in Entwicklung und sind für die Veröffentlichung geplant. Es gibt jetzt mit dem Elastic Common Schema endlich eine Nomenklatur für Felder, die es erlaubt, wiederverwendbare Pipelines zu bauen. Bei früheren Versionen war ja immer das das große Problem. Wenn jedes Setup ein Feld für den selben Inhalt beliebig benennen kann, wird’s schwierig mit dem wiederverwenden von Code. Das ist jetzt vorbei und wir versuchen, entsprechend Code zu produzieren.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

NETWAYS Webinar Plan 2022 – Phase 1

Es ist wieder soweit: In 2022 starten wir wieder voll durch mit neuen Webinaren rund um unsere angebotenen Dienstleistungen von Icinga, über Graylog bis hin zu Elastic. Den Fokus legen wir dabei auch wie üblich auf einen einfachen Einstieg und im späteren Verlauf auf komplexere Themen.

Anfangen werden wir mit einigen Webinaren für Icinga for Windows – die Lösung von Icinga, um Windows Systeme und Microsoft Produkte zu überwachen. Die folgenden Termine stehen dabei schon fest:

Für Icinga selbst werden im Laufe des Jahres dann noch eigene Webinare zum Icinga Director, der vSphereDB sowie dem Reporting Modul folgen – daher am besten direkt unseren YouTube Kanal abonnieren und die Glocke aktivieren.

Darüber hinaus, haben wir noch eine Webinar-Serie zu jeweils Elastic und Graylog geplant, welche die Grundfunktionalitäten sowie Erstinstallation, aber auch spätere Integrationen, Dashboard Erstellung und Auswertungen aufzeigt. Hierzu folgen in den nächsten Wochen weitere Informationen.

Wie immer freuen wir uns über eine rege Teilnahme sowie Input für Themen, welche wir vorstellen können!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Warum OpenSearch? Was ist OpenSearch? OpenSearch VS. Elastic

Es fing bereits 2015 an zu brodeln, als AWS seinen neuen SaaS-Dienst „AWS Elasticsearch Services“ veröffentlichte und später dann 2019 das Produkt OpenDistro erschien. Bei zuletzt genanntem Produkt erschließt sich mir bis heute nicht, warum ich dieses der X-Pack Basic von Elastic vorziehen sollte. So lange ich natürlich ein Elasticsearch oder den Elastic Stack nicht als SaaS-Dienst vermarkten möchte. Denn dann bleibt mir nur die bis vor kurzem verfügbare OSS-Variante, welche natürlich entsprechende Features, welche im X-Pack Basic integriert sind, vermissen lässt.

2017 auf der ElasticON in San Francisco wurde das neue offene Lizenz-Modell auf Basis der Apache-2.0-Lizenz und der daraus entstandenen OSS-Variante, so wie die Veröffentlichung einer X-Pack Basic Variante bekannt gegeben. Dieser Weg wird jetzt teilweise verlassen.

Anfang des Jahres war der Höhepunkt einer langen gerichtlichen Auseinandersetzung wohl erreicht. Elastic kündigte im Januar, wohl als letztes Mittel gegen Amazon, dass Ende der OSS mit Version Elasitc Stack 7.11 und den Wechsel zu einem dualen Lizenzmodell aus Server Side Public License (SSPL, wie z.b MongoDB) oder Elastic-Lizenz an. Amazon reagierte darauf und brachte die Community zum kochen, dass Ergebnis ist der Fork von Amazon „OpenSearch“, welcher auf Elastic Stack v 7.10 aufbaut.

Jetzt wollen wir aber mal alles im Detail betrachten und wie es weitergeht.

Spieler 1: Elastic

Was bedeutet dies jetzt für die Nutzer von Elastic Stack Produkten (IMHO):

  1. Die OSS Varianten welche Elasticsearch, Kibana und Beats unter APLv2 frei nutzbar und auch als SaaS-Dienst verkaufbar machten wurden abgekündigt mit Version 7.10
  2. Die X-Pack Basic bleibt bestehen und ist weiterhin frei Verfügbar und nutzbar mit allen Features, die darin enthalten sind
  3.  Lediglich die Vermarktung des Elastic Stack als SaaS-Dienst ist nicht mehr möglich

IMHO: Bisher für mich in der Wertung alles noch kein Beinbruch und viele Reaktionen unverständlich, denn von irgendwas muss ja als Firma gelebt werden. Zudem darf man nicht vergessen, dass mit den Werkzeugen des Elastic Stack, hervorragende Standards für ein modernes Event und Informations-Managment geschaffen wurden.

Was mich aber wirklich aufregt an der ganzen Sache ist der Fakt, dass mit der Filebeat Version 7.13, die Beats nur noch mit Elasticsearch und Kibana mit Versionen ältere als 7.10 sprich 7.11 zusammen spielen. Breaking Change lesen hier.
Dies könnte es schwierig machen die aktuellen Beats bzw. Filebeat mit anderen Werkzeugen wie z.B. Graylog zu nutzen. Aber dies werden wir für euch testen und berichten.

Spieler 2: OpenSearch

Als Antwort auf die Veränderungen des Elastic Stack wurde die Community unter anderem um AWS OpenDistro laut und es brodelte weiter bis es zum Ausbruch kam und Amazon AWS den Fork von Elastic Stack OSS 7.10 bekannt gab. Dies zunächst in Form von „OpenSearch“ als Fork von Elasticsearch und OpenDashboard als Fork von Kibana. Beide kommen bereits mit einer Vielzahl an Plugins und Integrationen, wie Sie es im Elastic Stack gibt. Hier ist schon mal ein guter Grundstock vorhanden.

Am 25.5.2021 wurde die Roadmap veröffentlicht  welche besagt, dass der aktuelle RC1 am 12.07.2021 als v1.0 veröffentlicht wird.

Jetzt wollen wir aber auch die Gegenseite Stellung beziehen lassen:

  1.  Am 21.01.2021 wurde der Fork ausgerufen und der heldenhafte Einsatz für ein ehrliches und quelloffenes Elasticsearch erklärt
  2.  Am 12.04.2021 wurde der Fork „OpenSearch“ öffentlich vorgestellt und gestartet.

Was bedeutet das für neue Nutzer oder Nutzer von OpenDistro oder von Nutzern des AWS Saas-Dienstes (IMHO):

  1. Abwarten ist hier angesagt der RC1 welchen wir uns natürlich für euch bereits ansehen und auch demnächst vorstellen werden ist „nur“ ein RC.
  2. Nutzer von OpenDistro sollten mit der Veröffentlichung von Version 1.0 umsteigen. Dennn OpenDistro wird mit Version 1.13 eingestellt!
  3.  „AWS Elasticsearch Service“ Nutzer müssen nicht bangen.
  4. Denn es gibt eine Abwärts-Kompatibilität zu Elasticsearch und Kibana 7.10.2 wie hier besagt und in den FAQs beschrieben.
  5. Diese Abwärts-Kompatibilität bedeutet es ist auch von Elasticsearch-OSS 7.10 oder gar 6.0 auf OpenSearch möglich.
  6. Wer Elasticsearch als SaaS-Dienst oder in SaaS-Dienste oder ähnlichen Produkt-Formaten verwenden will muss auf OpenSearch setzen (oder einfach Solr nutzen)

 

Abschließend bleibt zu sagen…

Nun liebe Lesenden ich weiss, dass war jetzt alles nichts technisches. Aber wir sind bereits den RC1 fleißig für euch am Testen und werden euch so bald es passt davon berichten. Vielleicht sogar passend zur Veröffentlichung von Version 1.0 am 12.07.2021?

Wer bisher auf den „alt“ bewährten Elastic Stack setzen möchte, kann dies in der Zukunft natürlich gerne weiterhin tun. Zu mal auch abzuwarten bleibt, wie es sich bei einer Vielzahl von Anwendungen welche auf Elasticsearch als Speicher setzen, wie z.B Graylog  mit der Integration verhält.

IMHO: Für mich ist klar Amazon in Form von AWS hat, dies bewusst provoziert und ist nicht der faire Spieler in dieser Partie (gewesen). Denn wenn man durchs Leben geht sollte es immer gelten ….

Bei allem, was wir denken, sagen oder tun, sollten wir uns fragen:
1. Ist es wahr?
2. Ist es fair für alle Beteiligten?
3. Wird es Freundschaft und guten Willen fördern?
4. Wird es dem Wohl aller Beteiligten dienen?”

Wer zu den oben erwähnten Themen und Werkzeugen Unterstützung benötigt, darf sich natürlich gerne von uns helfen lassen und bei den Kollegen von Sales nach einem/r Kollegen/Kollegin von Professional Services fragen. Oder in einer unserer Schulungen zu Graylog oder dem Elastic Stack lernen, wie mit den Werkzeugen in der Produktion umgegangen wird.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Elastic Stack Trainings – Last Minute Call

Möchtest Du mehr rund um Elasticsearch, Logstash, Kibana & Beats erfahren? Schau Dir doch mal unsere Elastic Stack Schulungen an. Du hast bereits am 02. Februar 2021 die Chance, in die Elastic Stack Welt einzutauchen. Selbstverständlich hast Du, vor allem in diesen Zeiten, bei uns die Möglichkeit, das Training ganz entspannt von zuhause aus mitzuverfolgen.

 

Wichtige Informationen auf einem Blick:

Was? Elastic Stack Training

Wann? 02.02. – 04.02.2021

Wo? Online

 

Das kommt an Inhalten auf Dich zu:

  • Einführung in modernes Log-Management
  • Einführung in den Elastic Stack
  • Elasticsearch Cluster Basics
  • Logstash Basics
  • Einrichtung von Log-Shippern wie Syslog und Beats
  • Datenaufbereitung durch Filter zur Modifikation von Logs und Events
  • Richtiger Einsatz von Kibana zur Analyse der Daten
  • Elastic Stack Architektur-Konzepte
  • Elastic Stack Maintenance

 

 

Für wen ist diese Schulung geeignet?

Wenn Du bereits fundierte Linux-Kenntnisse hat, Dich grundsätzlich mit einem Text-Editor auskennst und Dich in der Shell bewegen kannst, ist diese Schulung für Dich geeignet. Schau gerne mal auf unserer Website vorbei, um mehr Infos zur Elastic Stack Schulung zu erhalten.

 

Was macht eine NETWAYS Schulung so besonders?

Individuell

Praxisnah

Kommunikativ

Wir legen Wert darauf, die Gruppengrößen auf 10 Kursteilnehmer*innen zu begrenzen, um einen effizienten Lernprozess sicherzustellen. Unsere Schulungsleiter wissen, worauf es ankommt und teilen ihre Kenntnisse gerne mit Dir. Woher sie das wissen? Sie arbeiten regelmäßig in Software- und Kundenprojekten.

Auch in Zeiten des Homeoffices ist uns der Austausch von Teilnehmer*innen untereinander besonders wichtig. Darum stellen wir Euch verschiedene Wege zur Verfügung, um einen Informationsaustausch online zu ermöglichen.

 

Weitere Termine für Elastic Stack Trainings

Du hast am 02.02. – 04.02.2021 keine Zeit, möchtest aber trotzdem mehr über Elastic Stack erfahren? Dann melde Dich doch einfach zu einem anderen Termin an.

Online | 27.04. – 29.04.2021

Online | 20.07. – 22.07.2021

Nürnberg | 07.12. – 09.12.2021

Alle weiteren Informationen und die Anmeldung findest Du auf  unserer Seite zur Elastic Stack Schulung.

 

Termine zu anderen Trainings:

Elastic Stack Schulung| Online | 02.02. – 04.02.2021

GitLab Fundamentals Training | Online | 10.02. – 11.02.2021

Terraform mit OpenStack Training | Online | 23.02. – 24.02.2021

Fundamentals for Puppet | Online | 23.02. – 25.02.2021

 

Wir hoffen, es war etwas dabei für Dich. Schau gern mal bei uns vorbei. Dort findest Du jede Menge weitere Open Source Trainings. Wir freuen uns auf Dich!

Events im Elastic Stack verfolgen

Im folgenden gebe ich einen kurze Übersicht über ein paar Handgriffe, die sich beim Debuggen des Elastic Stack bewährt haben. Vor allem beim Beantworten der Frage “Wo verdammt sind meine Events?”

In Kibana

Zuerst wird man wohl bemerken, dass Events fehlen, wenn man sie in Kibana nicht finden kann. Bevor man sich aber in die Tiefen der Konfiguration begibt, sollte man also erstmal die Möglichkeiten des Webinterface völlig ausschöpfen.

  • Ist ein Filter gesetzt, der die Nachrichten ausblendet?
  • Wurde ein falscher Zeitbereich gewählt?
  • Kann es sein, dass der sendende Host eine falsche Zeiteinstellung hat und die Events deshalb an einer falschen Position des Zeitstrahls angezeigt werden?
  • Wurde das falsche Index-Pattern gewählt?

Einfach zurück setzen kann man die meisten dieser Einstellungen durch einen Klick auf die “New” Schaltfläche im Kibana-Discover.

Führt all das nicht zum Erfolg, folgen tiefer greifende Schritte.

Message Broker

Sehr leicht nachvollziehen kann man, ob Nachrichten im Message broker festhängen, falls man denn einen benutzt. Füllen sich Redis, Kafka oder ähnliches, dann ist auf jeden Fall im Ablauf etwas falsch oder der Stack zu klein gesized. Bei mehreren Pipelines kann hier auch gut nachvollzogen werden, an welcher Stelle es klemmt. Dabei helfen aussagekräftige Namen beim Ablegen im Broker z.B. für Keys in Redis.

Den Füllstand des Brokers sollte man übrigens auch deshalb ständig im Blick haben. Das check_redis.pl Plugin für Icinga bietet sich dafür an.

Logstash

Bevor an der Konfiguration Änderungen vorgenommen werden, sollte unbedingt das Log von Logstash und Elasticsearch geprüft werden. Ein häufiges Problem ist ein “type mismatch” in einem Feld, das verhindert, dass ein Event in Elasticsearch geschrieben wird. Beim Verwenden von dynamic mapping (dem default) wird jedem Feld der Typ verpasst, den das erste Event aufweist, das in diesen Index geschrieben wird. Steht also in client.port eine Nummer, wird Elasticsearch hier den Typ int zuweisen. Kommt später ein Event, wo client.port Text enthält (warum auch immer), dann wird dieses Event mit einer Meldung im Logstash Log verworfen.

Führt auch das nicht zum Erfolg, gibt es einige Tricks, die man anwenden kann, um die Funktionsweise genauer zu durchleuchten.

  • Einzelne Pipelines können in der pipelines.yml vorübergehend deaktiviert werden. Das bietet sich vor allem für “output” oder “forwarder” pipelines an, die an Elasticsearch schreiben
  • Jedem Filter eine id zu vergeben ist immer eine gute Idee. Damit kann man auch sehr gut im Kibana Monitoring sehen, welcher Filter wie viele Events verarbeitet
  • Praktisch ist auch, sich Konfigdateien zurecht zu legen, die nur für’s Debugging gebraucht werden. Bei Bedarf kann man diese in die Verzeichnisse der Pipelines kopieren und danach wieder löschen. Ich verwende dabei gern einen mutate Filter, der einfach nur ein Tag setzt, um zu sehen, ob überhaupt bestimmte Events durch eine Pipeline kommen. Außerdem eine weitere Datei mit einem file Output, der mir alle Events in der Pipeline in eine Testdatei schreibt. Optional kombiniert mit dem dot Codec kann man so sehen, wie viel durch fließt, wenn die genauen Events gar nicht relevant sind. Diese Files kann man dann einfach in die einzelnen Pipelines legen und wieder raus nehmen. Verwendet man sie mehrfach, muss man aber darauf achten, Doubletten zu vermeiden, also verschiedene Namen für Tags, verschiedene Files als Ziel etc.
  • Der obige Tip funktioniert natürlich auch mit mutate Filtern, die man kurzerhand mitten in die eigene Konfig schreibt – z.B. in ein if – um dort Tags und Felder mitzugeben, nach denen man dann sucht
  • Falls Logstash eine Pipeline nicht starten kann, liegt das häufig an Tippfehlern in der Konfiguration. Um diese zu finden kann man den Pfad der Konfig einer Pipeline aus der pipelines.yml kopieren und durch cat anzeigen lassen. Dieser Copy&Paste Ansatz verhindert, dass man z.B. nur eine einzige Datei in der pipelines.yml angegeben hat, aber erwartet, dass das ganze Verzeichnis angezogen wird. Wichtig dabei zu wissen ist, dass Logstash durchaus auch eine einzelne Pipeline offline nehmen kann und der Rest weiter läuft

Wer noch mehr zum Thema Troubleshooting bei Elastic Stack wissen will und das auch mal praktisch ausprobieren möchte, hat dazu in unseren Elastic Stack Schulungen zum Thema Logmanagement Gelegenheit.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...