Logstash-Konfiguration im Team

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier “sich häufig ändernde und nicht immer klar strukturierte Logformate”)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig “dreinpfuschen”
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
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...

OSMC #Recap with Bodo Schulz | Don’t miss this year!

2017 hat Bodo Schulz über “Automatisiertes und verteiltes Monitoring in einer CI Umgebung” gesprochen, d.h. über

  • Eine Testumgebung, in der alles noch läuft
  • Pinky & Brain in der CI
  • “If you only focus on the problem, you might miss the solution”

Ihr wollt mehr davon? Gibt’s in Bodos Talk von 2017, hier:

 
Don’t miss OSMC 2018! Get your ticket now! Be a part of the Monitoring change.

OSMC | November 5 – 8, 2018 | Nuremberg

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

OSDC 2017: Community connects

After a fully packed and entertaining first day at OSDC, we really enjoyed the evening event at Umspannwerk Ost. Warm weather, tasty food and lots of interesting discussions, just relaxing a bit and preparing for day 2 🙂
 

Warming up

Grabbed a coffee and started with Julien Pivotto on Automating Jenkins. Continuous integration matters these days and there’s not only Jenkins but also GitLab CI and more. Julien told us why automation for Jenkins is needed. Likewise, “XML Everywhere” makes configuration a bit tad hard. Same thing goes for plugins, you literally can’t run Jenkins without. Julien also told us “don’t edit XML”, but go for example for Groovy and the Jenkins /script API endpoint. The Jenkins pipeline plugin even allows to use YAML as config files. In terms of managing the daemon, I learned about “init.groovy.d” to manage and fire additional Groovy scripts. You can use the Job DSL Groovy plugin to define jobs in a declarative manner.
Julien’s talk really was an impressive deep dive leading to Jenkins running Docker and more production hints. After all an amazing presentation, like James said 🙂


I decided to stay in MOA5 for the upcoming talks and will happily await the conference archive once videos are uploaded in the next couple of days.
Casey Calendrello from CoreOS led us into the evolution of the container network interface. I’m still a beginner with containers, Kubernetes and also how networks are managed with it, so I learned quite a lot. CNI originates from rkt and is now built as separate project and library for Go-built software. Casey provided an impressive introduction and deep dive on how to connect your containers to the network – bridged, NAT, overlay networks and their pros and cons. CNI also provides many plugins to create and manage specific interfaces on your machine. It’s magic, and lots of mentioned tool names certainly mean I need to look them up and start to play to fully understand the capabilities 😉


Yesterday Seth Vargo from HashiCorp had 164 slides and promised to just have 18 today, us moving to lunch soon. Haha, no – it is live demo time with modern secrets management with Vault. We’ve also learned that Vault was developed and run at HashiCorp internally for over a year. It received a security review by the NCC group before actually releasing it as open source. Generally speaking it is “just” an encrypted key value store for secrets. Seth told us “our” story – create a database password once, write it down and never change it for years. And the process to ask the DBA to gain access is so complicated, you just save the plain-text password somewhere in your home directory 😉
Live demo time – status checks and work with key creation. Manage PostgreSQL users and credentials with vault – wow, that simple? That’s now on the TODO list to play with too. Seth also released the magic Vault demo as open source on GitHub right after, awesome!


 

Enjoying the afternoon

We had tasty lunch and were glad to see Felix Frank following up with “Is that an Ansible? Stop holding it like a Puppet!” – hilarious talk title already. He provided an overview on the different architecture and naming schemas, community modules (PuppetForge, Ansible Galaxy) and also compared the configuration syntax (Hash-Like DSL, YAML). Both tools have their advantages, but you certainly shouldn’t enforce one’s mode onto the other.


Puh, I learned so many things today already. I’ve unfortunately missed Sebastian giving an introduction about our very own NETWAYS Web Services platform managed with Mesos and Marathon (I rest assured it was just awesome).
After a short coffee break we continued to make decisions – previously Puppet vs. Ansible, now VMware vs. Rudder, location-wise. I decided to listen to Dr. Udo Seidel diving into “VMware’s (Open Source) way of Container“. VMWare is traditionally not very open source friendly, but things are changing. Most likely you’ve heard about Photon OS serving as minimal container host. It was an interesting talk about possibilities with VmWare, but still, I left the talk with the “yet another platform” feeling.
Last talk for a hilarious day about so many learnt things is about containerized DBs by Claus Matzinger from Crate.io. CrateDB provides shared nothing architecture and includes partitioning, auto-sharing, replication. It event supports structured and unstructured data plus SQL language. Sounds promising after all.
Dirk talked about Foreman as lifecycle management tool in MOA4, too bad I missed it.


 

Conclusion

Coffee breaks and lunch unveiled so many interesting discussions. Food was really tasty and I’m sure everyone had a great time, so did I. My personal highlights this year: Follow-up Seth’s talk and try Consul and Vault and do a deep dive into mgmt and tell James about it. Learn more about Ansible and put it into context with Puppet, like Felix has shown in his talk. As always, I’m in love with Elastic beats and will follow closely how to log management evolves, also on the Graylog side of life (2.3 is coming soon, Jan and Bernd promised).
Many thanks to our sponsor Thomas Krenn AG for being with so long. And also for the tasty Linzer Torte – feels like home 🙂


Thanks for a great conference, safe travels home and see you all next year!
Save the date for OSDC 2018: 12. – 14.6.2018!
 

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

GitLab CE: Continuous Integration, Jobs and Runners

NWS GitLab CE Hosting Zur Verwaltung von auf git basierenden Projekten bietet GitLab CE neben Issue Tracker und Wiki auch eine Continuous Integration (CI) Umgebung. Pro Projekt kann eine CI-Konfiguration mit Job Definitionen gesetzt werden, welche nach jedem Commit von sogenannten GitLab Runner ausgeführt werden.  Die klassische CI-Pipeline (vom Build bis zum Deploy) kann mit Hilfe von Stages abgebildet werden. Die CI-Konfiguration wird als Datei (.gitlab-ci.yml) im Projekt mit abgespeichert.
 
Im folgendem ein kleines Beispiel welches einen GitLab Runner mit Docker Executor verwendet:
.gitlab-ci.yml

image: debian:latest
stages:
  - build
  - test
  - deploy
job1:
  stage: build
  script: 'ping -c 4 nws.netways.de'
job2:
  stage: test
  script: 'ping -c 4 netways.de'
job3:
  stage: deploy
  script: 'echo "deploying"'
after_script:
  - 'echo "do some housekeeping"'

 
Mit jedem Commit im Projekt werden die definierten Stages build, test und deploy und deren Jobs durchlaufen und von GitLab CE natürlich auch schön visualisiert wird.

GitLab Runner können verschiedene Executor haben, beginnend mit der klassischen Shell über Parallels hinzu Docker und Kubernetes. Wem das alles zu viel ist kann auch unsere vorkonfiguriertes GitLab CE mit Runner ausprobieren oder bei unserem Manged Services nach einem maßgeschneidertem Angebot nachfragen.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

DEV-Trainings: Git und Jenkins

training_jenkinstraining_gitWir starten 2016 voll durch mit einem erweiterten Schulungsportfolio – neben Foreman und Ceph fokussieren wir uns im Development auf Git und Jenkins.
Die ersten Schulungen mit frisch erstellten Unterlagen fanden letzte Woche In-House bei einem unserer Kunden statt, sozusagen die “Feuertaufe” für die kommenden Schulungen.
git_introduction_basics_03_three_statesNach einer kurzen Einführung in die Geschichte von VCS und der Entstehungsgeschichte von Git haben wir anhand von praktischen Beispielen erste Schritte mit Git gemacht – wie initialisiere ich ein Repository, was bedeutet “modified”, “staged”, “committed”, was passiert bei “git add” und “git commit”? Bevor wir uns in die Tiefe mit Remote Repositories gestürzt haben, kam auch noch das Arbeiten mit Branches und unterschiedlicher Commit-Historie und – natürlich absichtlich provozierten – Fehlern beim Merge und Rebase dran.
Um das Gelernte auch in der Praxis weiterhin verwenden zu können, wurde die Arbeit mit einem lokalen Git-Server und fetch, pull, push und Branches vertieft. Das ganze kombiniert mit den unterschiedlichen Workflows (Feature-Branch, Gitflow, Forking) und praktischen Beispielen und nachgehender Analyse.
Die Brücke zur Jenkins-Schulung haben wir mit einem Git-Hook geschlagen, der für einen Git-Commit einen Jenkins-Job ansteuert.
jenkins_job_chuck_norrisNach der Installation des Jenkins-Installationspakets haben wir uns sogleich in die Konfiguration gestürzt – und natürlich in den ersten gemeinsamen Job. Ein Python-Script will gebaut werden, und später dann auch paketiert. In erster Linie haben wir uns Code Coverage und Qualität für CI und Test-Frameworks angesehen. Mit verschiedenen Build-Schritten und der Hilfe des Trainers gings dann auch gleich weiter mit der Einbindung an einen Jenkins-Agenten, der dediziert die Jenkins-Jobs ausführen sollte. Hierbei gibts einige Fallstricke zu beachten, gerade was SSH-Keys und shared Workspaces betrifft. Die Köpfe haben geraucht – aber spätestens dann als der frisch installierte Git-Hook den Jenkins-Paket-Bau angestossen hat, gabs für jeden das persönliche Erfolgserlebnis.
git_integrations_jenkins_git_hook
Neben den praktischen Beispielen haben wir uns auch Zeit genommen, gezielt Fragen zur eigenen Umgebung zu diskutieren, oder auch aus dem Nähkästchen zu plaudern. Git und Jenkins ist Teil unserer täglichen Arbeit an Icinga & Co und da gibts schon ein bissl Best Practice zu erzählen 😉
Für kurz entschlossene wissbegierige Anwender und jene die ihr Wissen auffrischen wollen – es gibt noch Plätze in unserer Git-Schulung am 28.6.2016 und Jenkins-Schulung am 30.8.2016 🙂
Und für all jene, die das Git-Fachwissen schon in sich aufgesaugt haben – wir hosten auch die eigene GitLab CE Instanz in unserer Cloud. Lust auf mehr? Kommt einfach auf uns zu!
PS: Trainings machen mir Spass – darum werd ich auch den diesjährigen Git-Workshop auf der OSMC halten 🙂
 

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

OSDC 2016 – 8th year of glory

Time flies – 8 years Open Source Datacenter Conference (OSDC) already and now the 3rd time in lovely Berlin.
Kicking off with Dawn Foster’s keynote on Open Source – A job and an adventure gave an interesting insight into Open Source careers and living the spirit. As we do at NETWAYS since 1995 inviting everyone onto our journey and happily organising conferences for talks, chats & some drinks together.
And remember …


Next up was Kris talking about Another 7 tools for your #devops stack which is always fun to watch. I couldn’t decide whether to join him or go for Mike Elsmore on NoSQL is a lie … though Daniela approached me and said “go for Mike, it is funny”. And so it was in combination with the interesting technical questions asked.


Tough decisions already in the morning – we’re using CoreOS at NETWAYS too and so I could join Jonathan Bulle on rkt and Kubernetes: What’s new with Container Runtimes and Orchestration … or learning something new, moving away from Puppet and learn about Salt – A Scalable Systems Management Solution for Datacenters by Sebastian Meyer.
A pretty hard one also for the presenters as these talks ended right before lunch break – and as you might know already, food is always so delicious at OSDC.


Finding a place to chill after lunch (oh, it was delicious) should it now be What’s wrong with my Puppet? by Felix Frank or would I go for learning about some monitoring tasks with Hello Redfish, Goodbye IPMI – The Future of System Management in the Data Center with Werner Fischer. I guess I’m more with Puppet these days, less monitoring admin – and the live demo stuff somehow failed but nice to see David Schmitt helping out.


Ever since Elastic announced their Beats toolstack I wanted to learn more about it. I was pretty sad that I couldn’t join Elasticon earlier this year. So I was eagerly waiting for Monica Sarbu telling me more about Unifying Log Management and Metrics Monitoring with the Elastic Beats.


Having the Icinga stack in mind with open APIs and such, this shed interesting insights on how to further push integration with Elastic forward. Oh and I definitely need to learn Golang to hack my own beats based on the libbeat library.


Continuous Integration in Data Centers – Further 3 Years Later with Michael Prokop sounded interesting as well, especially when it comes to Jenkins and Docker integration. Luckily all talks are recorded and made available later in the conference archive so I decided to go for Elastic Beats this time.


Martin Schütte gave interesting insights into Terraform: Config Management for Cloud Services. This tool fits into the devops stack HashiCorp has been building over the last years, including Vagrant, Atlas and Otto. MySQL clusters are overly complicated in my (developer) opinion so I didn’t go for MySQL-Server in Teamwork – Replication and Galera Cluster presented by Jörg Brühe. Again one for the archive watchers 🙂


ChatOps is becoming more important these days. I’ve already seen Martin’s great talk at Icinga Camp Berlin earlier this year – especially his live demo talking to the Icinga 2 API which makes me a proud developer. ChatOps – Collaborative Communication (or: You cannot not communicate) is definitely something everyone needs to consider and play around with. Especially when it is Open Source.


Heading over from Austria left behind my DNS related past though I’m trying to keep with it. Especially since Jan-Piet is talking about DNS for Developers aka “Everything is a freaky DNS problem” 😉

Evening event

Now that we’ve learnt and discussed so much on the first day we are ready for the evening event. This time it located at Umspannwerk Ost which looks nice indeed. Looking forward to delicious food again and later on, some G&T with the OSDC gang 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...