Seite wählen

NETWAYS Blog

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

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

YouTube player

 

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.

YouTube player

 

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
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

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

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

YouTube player

 

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”.

[bash]
LOGGER.debug(
"Cart price is now {}", cart.getPrice())
[/bash]

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
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

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
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...

Logstash automatisiert ausrollen? Freilich!

Der Lennart sagt mir ja immer, ich soll nicht über ungelegte Eier sprechen, aber momentan fasziniert mit das Thema einfach zu viel, als dass ich nicht drüber was schreiben könnte. Dass ich gern mit dem Elastic Stack arbeite, sollten auch weniger aufmerksamere Leser schon mitbekommen haben, aber mit Ansible hab‘ ich mich bisher recht zurückgehalten. Da ich aber eigentlich beides ganz gern mag, dachte ich mir, ich verbinde es mal.

 

Mit Ansible ist es wie bei den meisten Configmanagementsystemen: Man fängt mal an, was zu bauen, findet’s gut, lernt was dazu, findet’s nicht mehr gut, baut’s neu, findet’s richtig gut, lernt dazu, findet’s eher mies, baut’s neu, ein Loch ist Eimer, lieber Reinhard, lieber Reinhard.

Deshalb dachte ich, ich bemüh‘ mich jetzt mal, eine Rolle für Logstash zu bauen, die man auch wirklich guten Gewissens so rausgeben kann. Falls was nicht so schön ist, gibt’s dann wenigstens die ganzen lieben Leute da draußen, die Pull Requests machen *wink*. Hier also der aktuelle Stand unserer Ansible Rolle für Logstash.

Ich geb‘ ja zu, es ist noch eine recht frühe Version, aber sie ist immerhin so gebaut, dass sie umfassend konfigurierbar ist und auch der Linter von ansible-galaxy beschwert sich dabei nicht mehr. Anders ausgedrückt: Sie kann noch nicht extrem viel, aber das, was sie kann, kann sie ziemlich gut, meiner Meinung nach.

Ein schönes Feature, das mir besonders zusagt ist, dass sie einen dazu bringt, die Konfiguration der einzelnen Pipelines in einem Git Repository zu pflegen und zwar ein Repository pro Pipeline. Damit kann man die Rolle schön in Kombination mit unserer Logstash Pipeline für Icinga Logs nutzen. Ein paar Beispielpipelines, die aktuell nur Logs von A nach B schaufeln, habe ich in meinen persönlichen GitHub Account gelegt, von wo sie auch als Beispiele bei der Installation verwendet werden können. Ob das so bleibt, entscheidet sich noch, auf jeden Fall soll die Pipeline mit minimaler oder keiner Konfiguration zumindest mal Basisfunktionalität in Logstash herstellen. Ganz so, wie Elastic das geplant hat – ein einfacher Einstieg für Neulinge. Aber auch ausgefeiltere Setups sind damit möglich.

Besonders gut funktioniert die Rolle übrigens gemeinsam mit einer Rolle für Redis, aber das ist alles in der Readme beschrieben.

Weitere Rollen zum Rest vom Stack werden wohl noch kommen und die Logstash Rolle kann auch noch einiges an zusätzlichen Konfigoptionen brauchen. Lasst Euch also nicht aufhalten, Issues aufzumachen oder Pullrequests zu schicken.

 

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...

Elastic Stack viel neues, aber sicher!

Mit der Veröffentlichung von Elastic Stack 7 kamen bereits eine Menge Neuerungen in den Stack aber auch in den beiden darauf folgenden Releases Elastic Stack 7.1 und 7.2 wurde es nicht langweilig. Vieles davon wurde aber nicht sonderlich ins Rampenlicht gerückt oder gar groß diskutiert. Ich möchte heute mal zwei Neuerungen erwähnen und damit verbundene Auffälligkeiten.

Elastic Stack 7.1 und Elastic Stack 6.8 Elasticserach Security X-PACK Basic License

Als ich zum ersten mal am 21.05.2019 durch Zufall auf dem Elastic Blog gelesen habe, dass seit dem 20.05.2019 mit dem Release von Elastic Stack 7.1 und Elastic Stack 6.8.0 eine Basis Elasticsearch X-Pack Security verfügbar ist, dachte ich nur so: „OK“ und wo ist die Diskussion wo sind die Aufhänger? Fehlanzeige nichts von alle dem.

X-Pack Security Basic License

Folgend will ich euch kurz schildern was in der Basic License möglich ist:

  • Elasticsearch HTTP und Transport TLS Encryption der Kommunikation
  • Index Security und Kibana Security mit Benutzerauthentifizierung und Rechte-Management mittels Rollen. Jedoch kommt die Basic Variante ohne LDAP/AD und Rechte-Management auf Dokumenten-Ebene und Feld-Ebene
  • Alle Komponenten können nun mit TLS und Benutzerauthentifizierung mit Elasticsearch kommunizieren

Besonders interessant dabei ist der Punkt „Index Security und Kibana Security“. Einfach ausgedrückt kann man damit Namensschemata für Indices angeben, auf die User Zugriff haben oder nicht. Auch wenn feldbasierte Rechte schön wären, reicht das meist aus, um effektiv User einzuschränken. z.B. können dann Webmaster auf alle logstash-webserver-* , DBAs auf alle logstash-db-* und Security-Leute auf alle logstash-* Indices und die darin gespeicherten Events zugreifen.

Nun noch ein kleiner Hinweis:

Ihr könnt einem User nur Rechte auf bereits vorhandene Index Pattern/Schema im Kibana geben, welche bekanntlich nur erstellt werden können wenn ein Index bereits besteht. Somit müsst ihr zum Beispiel einem User den Ihr in Logstash für das Schreiben via „logstash-output-elasticsearch“ verwenden wollt, für die initiale Erstellung Superuser-Rechte vergeben. Dies ist zugegebener maßen etwas umständlich.

Bei Gelegenheit aber mehr zu diesem Thema in einem neuen Blog-Post.

Beats Logging

Die oben genannte Änderung fand in Beiträgen von Elastic auf Ihrem Blog einen Platz oder in den Breaking Changes. Jedoch gab es auch Änderungen welche weder in den Breaking Changes zu Elastic Stack 7.0 noch in einem Blogeintrag erwähnt wurden. Jedoch ist für mich die Neuerung das Logging für alle Beats über stderr in den journald zu schreiben, eine Erwähnung in den Breaking Changes wert und nicht nur in den Release Notes. So kommt es, dass jede Beats Variante unweigerlich in das System-Log schreibt und eine Option wie `logging_to_syslog: true` keine Wirkung zeigt. Denn die Einstellung wird über eine Umgebungsvariable im Systemd-Unit File als Default gesetzt, welche Einstellungen in einer Beats-Konfiguration hinfällig macht.

Nicht jeder aber möchte die Logs eines Beats in seinem System-Logs haben. Um dies zu verhindern ist eine Änderung des Unit-Files notwendig. Diese nimmt man wie folgt:

systemctl edit elasticsearch
[Service]
Environment="BEAT_LOG_OPTS="
systemctl daemon-reload
systemctl start

Die neuen Releases des Elastic Stack seit 7.x haben noch wesentlich mehr neues zu Entdecken wie z.B eine SIEM Lösung in Kibana oder das ILM im Stack welches nun auch in den Beats und Logstash vollständig integriert ist. Jedoch alles in einem Blog-Post zu verarbeiten wäre zu viel. Darum werden wir uns bemühen für euch in weiteren Blog-Posts das ein oder andere vorzustellen.

Kurz erklärt soll aber „ILM“ werden, das Regeln in Elasticsearch hinterlegt, wann ein Index rotiert oder gelöscht werden soll. Das ersetzt Cronjobs mit REST-Calls oder den Curator und bietet eine einfache Möglichkeit Hot/Warm-Architekturen umzusetzen.

Auch spannend wird es für uns unsere Trainings für euch anzupassen so das diese dem neuen Elastic Stack 7.x gerecht werden. Da ich mich schon seit mehren Jahren mit dem Elastic Stack auseinander setze, finde ich gerade die Entwicklung im Kibana und dem Management des Stacks als sehr interessant. Diese bringt doch für viele eine große Erleichterung in der Wartung eines Stacks. Ich bin gespannt wie sich das entwickelt.

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.