Seite wählen

NETWAYS Blog

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!

Natalie Regn
Natalie Regn
Junior Marketing Manager

Natalie macht seit September 2019 ihre Ausbildung zur Kauffrau für Büromanagement hier bei NETWAYS. Vor ihrer Zeit bei NETWAYS war sie ein Jahr als Au-pair in Schottland unterwegs. Passend dazu widmet sie sich seit vielen Jahren dem Spielen der Great Highland Bagpipe. Natalie ist in ihrer Freizeit nicht nur musikalisch unterwegs, sondern auch sportlich. Sie trainiert im Fitnessstudio, geht gerne in den Kletterpark und in die Trampolinhalle.

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
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Evolution of a Microservice-Infrastructure by Jan Martens | OSDC 2019

This entry is part 2 of 6 in the series OSDC 2019 | Recap

 

At the Open Source Data Center Conference (OSDC) 2019 in Berlin, Jan Martens invited to audience to travel with him in his talk „Evolution of a Microservice-Infrastructure”. You have missed him speaking? We got something for you: See the video of Jan‘s presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place from June 16 to 18, 2020. Join us, live online! Save your ticket now at: stackconf.eu/ticket/


 

Evolution of a Microservice-Infrastructure

Jan Martens signed up with a talk titled “Evolution of a Microservice Infrastructure” and why should I summarize his talk if he had done that himself perfectly: “This talk is about our journey from Ngnix & Docker Swarm to Traefik & Nomad.”

But before we start getting more in depth with this talk, there is one more thing to know about it. This is more or less a sequel to “From Monolith to Microservices” by Paul Puschmann a colleague of Jan Martens, but it’s not absolutely necessary to watch them in order or both.

 

So there will be a bunch of questions answered by Jan during the talk, regarding their environment, like: “How do we do deployments? How do we do request routing? What problems did we encounter, during our infrastructural growth and how did we address them?”

After giving some quick insight in the scale he has to deal with, that being 345.000 employees and 15.000 shops, he goes on with the history of their infrastructure.

Jan works at REWE Digital, which is responsible for the infrastructure around services, like delivery of groceries. They started off with the takeover of an existing monolithic infrastructure, not very attractive huh? They confronted themselves with the question: “How can we scale this delivery service?” and the solution they came up with was a micro service environment. Important to point out here, would be the use of Docker/Swarm for the deployment of micro services.

Let’s skip ahead a bit and take a look at the state of 2018 REWE Digital. Well there operating custom Docker-Environment consists of: Docker, Consul, Elastic Stack, ngnix, dnsmasq and debian

Jan goes into explaining his infrastructure more and more and how the different applications work with each other, but let’s just say: Everything was fine and peaceful until the size of the environment grew to a certain point. And at that point problems with nginx were starting to surface, like requests which never reached their destination or keepalive connections, which dropped after a short time. The reason? Consul-template would reload all ngnix instances at the same time. The solution? Well they looked for a different reverse proxy, which is able to reload configuration dynamically and best case that new reverse proxy is even able to be configured dynamically.

The three being deemed fitting for that job were envoy, Fabio and traefik, but I have already spoiled their decision, its treafik. The points Jan mentioned, which had them decide on traefik were that it is dynamically configurable and is able to reload configuration live. That’s obviously not all, lots of metrics, a web ui, which was deemed nice by Jan and a single go binary, might have made the difference.

Jan drops a few words on how migration is done and then invests some time in talking about the benefits of traefik, well the most important benefit for us to know is, that the issues that existed with ngnix are gone now.

Well now that the environment was changed, there were also changes coming for swarm, acting on its own. The problems Jan addresses are a poor container spread, no self-healing, and more. You should be able to see where this is going. Well the candidates besides Docker Swarm are Rancher, Kubernetes and Nomad. Well, this one was spoiled by me as well.

The reasons to use nomad in this infrastructure might be pretty obvious, but I will list them anyway. Firstly, seamless consul integration, well both are by HashiCorp, who would have guessed. Nomad is able to selfheal and comes in a single go binary, just like traefik. Jan also claims it has a nice web UI, we have to take his word on that one.

Jan goes into the benefits of using Nomad, just like he went into the benefits of ngnix and shows how their work processes have changed with the change of their environment.

This post doesn’t give enough credit to how much information Jan has shared during his talk. Maybe roughly twenty percent of his talk are covered here. You should definitely check it out the full video to catch all the deeper more insightful topics about the infrastructure and how the applications work with each other.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Fast log management for your infrastructure by Nicolas Frankel | OSDC 2019

This entry is part 4 of 6 in the series OSDC 2019 | Recap

 

Nicolas Frankel is a Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts. “Fast log management for your infrastructure” was his topic at the Open Source Data Center Conference (OSDC) 2019 in Berlin. Those who missed the talk back then now have the opportunity to see the video of Nicolas’ presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

We are proud to announce that Nicolas Frankel is in our speaker lineup this year, too. We are looking forward to his talk: “Real Continuous Deployment of JVM applications”.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place June 16 – 18, 2020. Be there, live online! Save your ticket now at: stackconf.eu/ticket/


Fast log management for your infrastructure

Fast log management for your infrastructure”, well that is one way to get OSDC visitors excited. Nicolas Frankel signed up with that one and he did not disappoint. The issues, he was tackling, were issues produced by optimization, that being said do you think about the logs when it comes to migrating your application to reactive micro services?

Before we get to all that, Nicolas had to take a little detour through programming logic and how logging works, and he also points out some misconceptions of how things are done and how they work. Like for example, his so called “[…] root of all evil”.

LOGGER.debug(
"Cart price is now {}", cart.getPrice())

He states the question, who believes that in case of the log level being above debug the statements will be ignored? That’s what is to be expected, however it is not the case. In a small demo section he gives further insight on the topic from the perspective of a software developer.

From the developer point of view one should only do physical logging is the statement he ends his demo explanation run on. Directly afterwards he states that developers do not like to think that they are dealing with the physical world, then he goes further on about the respective storage possibilities like the write time regarding SSDs, HDDs or on an NFS, which should be taken into account.

Tackled some issues already, Nicolas keeps switching back and forth between the perspective of a software developer and an operator. He puts a lot of empathizes on these perspective changes to make sure that everyone involved starts to understand where the issue lies and if there is an issue at all.

For example the writing process and the opening and closing of streams for single log statements. It would be great if the stream could be continuously open and log statements can be written until the stream can be closed. But arguably and in most cases by default, logging is blocking. While most frameworks allow asynchronous logging, there is no right or wrong. And it also doesn’t have to be a software development mistake nor a bad infrastructure.

He dives deeper into asynchronous logging, because if you want to use it, you have to understand it: from queue size to discarding thresholds, the difference between blocking and dropping messages, everything. Nicolas also covers some logging basics, like metadata and what is especially important. Most essential metadata named timestamp, log level, line number and more. You may ask, why? Because some metadata is more expensive to get than others.

After some more detours through log aggregations and common pitfalls, with searching in logs or mandatory metadata, we get to a well-known application stack in the world of logging, the Elastic Stack.

He explains the basic architecture of the Elastic Stack and how the applications work with each other. Especially Filebeat and Logstash take the spotlight during this part. Step by step he works his way through an abstraction of the path a log takes from Filebeat to Logstash until you get a JSON you are familiar with. Then common misunderstandings like “Why do I need Logstash at all?” are being tackled by him, before he goes onto how he is doing logging at Exoscale.

They are using syslog-ng instead of Filebeat, basically just because when they started Filebeat was not ready for production. Then a regular Logstash and before we come to Elasticsearch there is a Kafka running. The reason why they are using Kafka is that Kafka being a decentralized data store, and using Logstash to get data out of it there is lower risk of dropping data instead of buffering towards elasticsearch, because there are not multiple nodes writing at once.

Nicolas summarizes his talk at the end with six short statements or maybe even lessons for log management. If you want, head over to the video above to learn about them from Nicolas himself or experience him live to learn from him.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Namen sind Schall und Rauch? Lieber nicht.

Das Problem

Bei vielen Projekten zu Logmanagement stellt sich recht schnell die Frage nach der Benamsung der Felder, in die Events zerlegt werden sollen. Da man sie weitestgehend frei wählen kann, startet so schnell ein gewisser Wildwuchs und das unabhängig davon, ob der Elastic Stack oder Graylog verwendet wird, um die Nachrichten zu “zergrokken”, wie es mal ein Kunde so schön formuliert hat.

Das Kuddelmuddel rund um die Feldnamen hat einige Nachteile, die früher oder später zuschlagen:

  • Ein Feld innerhalb eines Index darf nur einen Typ haben. Wenn also zufällig zwei Regeln ein Feld namens errorlevel anlegen und eine schreibt debug rein, die andere 4 wird das früher oder später dazu führen, dass Events von Elasticsearch abgelehnt werden
  • Gemeinsame Dashboards gestalten sich schwierig, wenn die IP des sich verbindenden Hosts mal in client , mal in client_ip und mal in anfragenderhost drin steht
  • Andere Tools und mitgelieferte Regeln / Dashboards haben keine Möglichkeit, vorherzusagen wie Felder heissen werden, deren Informationen sie brauchen

Schon immer galt die Empfehlung, sich ein Namensschema zu überlegen und sich strikt dran zu halten. Das klappt leider meist schon nicht, wenn nur eine Person dran arbeitet und wird nahezu unmöglich, wenn mehrere Teams eine gemeinsame Konfiguration pflegen. Das muss gar nicht einer gewissen Nachlässigkeit geschuldet sein, sondern kann alleine schon daraus resultieren, dass die gleichen Dinge manchmal in verschiedenen Teams einfach unterschiedlich genannt werden. Man muss nur an die Diskussion rund um “Satellite” oder “Slave” bei Icinga 2 oder die verschiedenen Logstash Instanzen (“Shipper”, “Indexer”, “Forwarder”, “häh?”) denken, um ein naheliegendes Beispiel zu haben.

ECS to the rescue

Elastic hat nun eine schöne, wenn auch noch nicht umfassende Lösung dafür geschaffen: Das “Elastic Common Schema”, kurz ECS.

Beschrieben in einem eigenen Abschnitt der Dokumentation. Darin sind Regeln festgelegt, wie Felder heissen müssen, die bestimmte Daten beinhalten. So gibt es z.B. nicht mehr logsource oder beat.hostname sondern host.hostname (der Host, auf dem das Event passiert ist, das den Logeintrag ausgelöst hat) und agent.name (Name des Agenten, der die Nachricht verschickt hat – kann der Hostname sein, aber auch ein Custom Name, falls z.b. mehrere Filebeat auf einem Host laufen)

Definiert im ECS sind eine ganze Menge von Überkategorien unter denen dann verschiedene Unterfelder definiert sind, die dann wiederum einen “Level” haben. Der Level gibt an, ob die Felder nach Möglichkeit befüllt werden sollen (“core”) oder eher optional sind (“extended”). Die core-Felder werden auch von diversen Tools des Elastic Stack genutzt, um automatische Auswertungen zu erlauben, was gleich einen riesigen Vorteil des ECS offenbart: Man kann damit viel einfacher fertige Lösungen verschicken, weil man nicht mehr rätseln muss, wie denn die Felder heissen könnten, in denen die wertvollen Informationen stecken.

So wird den meisten langjährigen Usern von Kibana aufgefallen sein, dass es inzwischen eine grosse Menge weiterer Tools in Kibana gibt als die klassischen “Discover”, “Visualize” und “Dashboard”. Die neuen Tools wie SIEM oder Infrastructure verlassen sich darauf, dass die benötigten Informationen in den richtigen Feldern abgelegt sind. Wenn man also ECS umsetzt, dann funktioniert z.B. der SIEM Teil von Kibana mehr oder weniger ohne weiteres zutun.

Im ECS ist auch definiert, welchen Typ welches Feld haben sollte. Sprechen Beats direkt mit Elasticsearch, kümmern sie sich darum, dass das richtig gesetzt wird. Baut man seine eigene Zerlegung in Logstash oder Graylog, dann sollte man darauf achten, dass die Felder auch entsprechend typisiert sind. In den meisten Fällen ergibt sich das aus der Art von Information, die im Feld gespeichert wird automatisch – man sollte dennoch immer wieder mal kontrollieren, ob nicht das eine oder andere durchgeschlüpft ist. Es sollte aber auch nichts dagegen sprechen, die Multifields von Elastic Search zu nutzen. Wird also ein Feld vom Typ keyword gefordert, kann man es auch als string in Elasticsearch schreiben, da der immer sowohl als text und als keyword abgelegt wird.

Der Umstieg

Wer schon ein funktionierendes Logmanagement hat, kann übrigens ziemlich sanft auf ECS umsteigen. ECS erlaubt nämlich ausdrücklich auch, eigene Felder zu definieren. Anders ausgedrückt sollten die relevanten Informationen in den angegebenen Feldern vorhanden sein. Ausser der dabei entstehenden Ressourcenverschwendung spricht aber nichts dagegen, die Daten auch in den zuvor genutzten Feldern vorzuhalten, solange man migriert. Man kann also die Information durchaus duplizieren, falls das nötig ist.

Wer noch ältere Clients im Einsatz hat, muss ohnedies vorsichtig sein, da Elastic die Standardfelder, die automatisch hinzugefügt werden, im Laufe der Zeit in einer nicht abwärtskompatiblen Art verändert hat. So kommen insbesondere Logs, die über Syslog verschickt wurden mit einem host Feld, in dem schlicht der Hostname drin steht. Laut ECS (und damit auch in Events von Beats) ist host aber ein “Nested Field”, das selbst wieder Unterfelder beinhaltet. Schickt man also in den selben Index Events, die man über Syslog-Protokoll erhalten hat und solche, die via Beats eingeliefert wurden, dann hat man leicht einen type mismatch. Dabei ist das nur eines von mehreren möglichen Beispielen. Die Logs von Elasticsearch und Logstash bzw. Graylog zeigen, wenn Events abgelehnt werden und üblicherweise auch wieso.

Eine gewisse Herausforderung ist dabei wieder, sich in die verschiedenen Positionen hineinzuversetzen. Aus Sicht des Logadmins ist der Client vielleicht der Agent, der die Nachricht verschickt, aber aus der Sicht dessen, der die Nachricht zur Überwachung seiner Applikation benötigt, ist der Client der, der mit seiner Applikation gesprochen hat. Dafür gibt es eben eigene Felder wie agent oder event, die Metadaten beinhalten können, die sich nur auf das Logmanagement beziehen, nicht auf den Inhalt der Nachricht. Das Problem ist aber nicht ECS spezifisch, sondern allgemein etwas, das Logadmins plagt.

Abschliessendes

Wer neue Regeln zum Zerlegen von Events anlegt, sollte aber von vornherein darauf achten, dass das ECS eingehalten wird. Dazu sollte man noch ein Feld mitgeben, das die ECS Version anzeigt, um in Kibana für Klarheit zu sorgen und ggf. noch ein paar Regeln kurz vor den Outputs einzuführen, die alte Nachrichten nachbessern. Das haben wir z.B. auch in der Logstash Pipeline für Icinga Logs getan.

Wer sich dazu noch etwas ausführlicher erzählen lassen möchte, kann ja mal in einer unserer Elastic Stack Schulungen vorbei schauen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Veranstaltungen

Di 20

Icinga 2 Advanced Training | Online

April 20 @ 09:00 - April 22 @ 17:00
Di 20

InfluxDB & Grafana | Online

April 20 @ 09:00 - April 21 @ 17:00
Di 27

Elastic Stack Training | Online

April 27 @ 09:00 - April 29 @ 17:00
Di 27

Graylog Training | Online

April 27 @ 09:00 - April 28 @ 17:00
Mai 04

GitLab Fundamentals Training | Online

Mai 4 @ 09:00 - Mai 5 @ 17:00