Bei der Inxmail GmbH gibt es seit etwa 2 Jahren einen produktiv genutzten Kubernetes Cluster. Im Laufe dieser kurzen Zeit sind bereits mehr als 70 Services und 20 Cronjobs deployed worden und befinden sich im produktiven Einsatz. Diese Services umfassen sowohl Kundenprojekte als auch Teile der Kernprodukte Inxmail Professional und Inxmail Commerce. Die Bandbreite dieser Services und Cronjobs gehen vom einfachen Exporttool hin zu komplexen, hoch performanten Diensten, die verschiedene Aufgaben übernehmen und zuverlässig erfüllen, zum Beispiel Barcode/Gutschein-Service. Im Laufe der letzten 2 Jahre wurden einige Erfahrungen im Bereich Monitoring, Logging und Stabilität gemacht. Diese Erfahrungen wollen wir mit den Konferenzteilnehmern tei-len. In diesem Vortrag wollen wir die Tools und Methoden zeigen, die wir aktuell einset-zen um die mittlerweile doch große Anzahl von Services und Cronjobs zu überwachen. Auch den Weg dahin und unsere Erfahrungen werden wir den Konferenzteilnehmern mitteilen. In dem Vortrag gehen wir auf die von uns aktuell eingesetzten Tools ein. Hierzu gehören die Werkzeuge, die uns Kubernetes zur Verfügung stellt - wie zum Beispiel die Readi-ness- und Livenessprobe - um Services von Kubernetes selbst überwachen zu lassen, aber auch andere Tools. Zudem haben wir auch eigene Erweiterungen für unser Monito-ring entwickelt, um zum Beispiel die erfolgreiche Bearbeitung von wiederkehrenden Jobs zu überwachen. Nebenher erfassen wir auch Metriken über unser Logging und können dies entsprechend auswerten. Für alle Punkte gibt es Beispiele aus “dem echten Leben”, welche den Vortrag abrunden.

1. Erfahrungen im Bereich
Monitoring & Logging von Services
und Cronjobs in Kubernetes
Stefan Biermann
Dev/Consultant @ Inxmail

2. Speaker
VORSTELLUNG
› Stefan Biermann
› Bei Inxmail seit Juni 2006
› Entwickler
› Consultant
› Team Connected Solutions
› Twitter: @biermi

3. Zahlen und Fakten
RUND UM INXMAIL
19
Jahre
Erfahrung
150
Motivierte
Mitarbeiter
2.000
Zufriedene
Kunden
200
Internationale
Partner
Ausgezeichneter
Service
120% 100%
Persönlicher
Ansprechpartner
100%
Made in
Germany

4. 2000+ Kunden. 200+ Partner.
AUSZUG UNSERER REFERENZEN
Und viele
mehr…
Kunden Partner

5. Daily Business
IM CONNECTED SOLUTIONS TEAM
› Kundenprojekte
› Exporter
› Importer
› Integrationen
› Beratung
› Schulungen
› Workshops
› Mehr als 80 Anwendungen
die derzeit betrieben werden

6. Daily Business
TOOLING
Sprachen
Java EE (SE)
.NET
Shell Scripte
Tooling
Intellij
Jenkins
Jira /
Confluence /
Bitbucket
Maven /
Gradle
Environment
(staging &
production)
Kubernetes
Legacy
Anwendungen
auf bare metall

7. Logging von Anwendungen
ES WAR EINMAL…
› Legacy Anwendungen haben lokales Logfile
geschrieben (über Logback)
› Nachteile
› Kein direkter Zugriff
› Umständliches Dateien durchsuchen

8. Logging von Anwendungen
ES WIRD MODERNER…
› ELK Stack wird eingeführt
› Elasticsearch
› Logstash
› Kibana
› Vorteile
› Direkter Zugriff
› Einfache Suche
› Mail versenden aus
zentraler Logstash Instanz
› Standardisierte logback.xml

9. Logging von Anwendungen
WIR SCHREIBEN DAS JAHR 2016…
› Kubernetes wird eingeführt
› Wie kann das Logging nun erfolgen?
› 1. Ansatz:
Pro Pod gibt es ein zusätzlichen Container mit
Logstash Shipper

10. Logging von Anwendungen
WIR SCHREIBEN IMMER NOCH DAS JAHR 2016… IM HERBST
› Kubernetes wird produktiv genutzt
› Status Quo: Pro Pod gibt es ein zusätzlichen
Container mit Logstash Shipper
› Nachteile
› Erhöhter Verbrauch an Resourcen wegen
zusätzlichen Container
› Java 8 kennt keine Container und allokiert mehr
Speicher als es darf => OOMKiller
› Jedes Deployment muss angepasst werden wenn
sich am Shipper etwas ändert

11. Logging von Anwendungen
WIR SCHREIBEN IMMER NOCH DAS JAHR 2016… IM HERBST
› 2. Ansatz:
Es gibt pro Kubernetes Worker
einen Shipper

12. Logging von Anwendungen
HIER UND JETZT…
› Es gibt pro Kubernetes Worker
einen Shipper
› Erste Metriken werden erfasst
› Standard logback.xml

13. Logging von Anwendungen
AUSBLICK IN DIE ZUKUNFT
› Metriken sind ausbaufähig
› Weniger Error, mehr Info
oder Warn loggen

14. Monitoring von Cronjobs und Services
WAS BIETET KUBERNETES FÜR MÖGLICHKEITEN?
› readinessProbe
› Prüft ob Anwendung bereit ist Requests entgegen zu
nehmen
› Startet den Pod nicht neu
› livenessProbe
› Prüft ob die Anwendung noch „lebt“
› Startet den Pod neu wenn er nicht mehr „lebt“
› matchLabels / selector
› Bietet die Möglichkeit gezielt Pods aus dem Service zu
nehmen
› Ideal für Analyse und Debugging von Anwendungen
die in einen
undefinierten Zustand gekommen sind

15. Monitoring von Cronjobs und Services
WIE NUTZEN WIR DIE KUBERNETES MÖGLICHKEITEN
› readinessProbe
› Initial Delay lang genug damit die Anwendung sauber
starten kann
› Falls es Probleme gibt, soll der Service keine Requests
mehr bekommen
› livenessProbe
› Initial Delay extrem lang, falls der Kubernetes Cluster
Probleme hat
und viele Pods neu starten
› Überlegungen bei jedem Projekt:
› Wann kann ein Neustart hilfreich sein um sich selbst
zu heilen?
› Welche Teile der Software sollen entsprechend
überwacht werden?

16. Monitoring von Cronjobs und Services
WAS NUTZEN WIR ALS ENDPUNKTE FÜR DIE PROBES
› Spring Boot Actuator basierende selbst entwickelte Java EE Implementierung

17. Monitoring von Cronjobs und Services
XYMON… OLDSCHOOL ABER GUT
› Erste Version erschien 2002
› Open Source unter GPL
› Skalierbarkeit (>10k Hosts bei 1 Xymon Server)
› Leichtgewichtig, kaum Impact auf Performance
› Fast alles kann überwacht werden
› http, content-checks, sslcert
› Scriptbar per CLI

18. Monitoring von Cronjobs und Services
CRONJOBS
› Beispiel Daily Exporter:
› Anforderungen:
› Um 5 Uhr UTC sollen alle Empfängerdaten aus Inxmail Professional exportiert werden
› Die Empfängerdaten sollen als CSV-Datei (gezippt als tar.gz) auf dem Kunden SFTP bereit gestellt werden
› Warum nicht als Service in Kubernetes?
› Unnötiger Resourcen Verbrauch
› Cronjob in Kubernetes
› Kubernetes startet zum definierten Zeitpunkt den Job
› Ein Pod wird einen Worker zugewiesen und gestartet
› Verbraucht nur zur Ausführung des Jobs Resourcen
› Hat eine begrenzte Lebensdauer

19. Monitoring von Cronjobs und Services
MONITORING VON CRONJOBS IN KUBERNETES
› Was soll gemonitored werden?
› Job wurde gestartet
› Wurde der Job fachlich erfolgreich ausgeführt
› Welche Zustände sind im Beispiel Daily Exporter zu erwarten:
› Der Job ist erfolgreich gelaufen, sprich Empfängerdaten exportiert und Datei wurde auf den SFTP geladen
› Die Empfänger konnten nicht geladen werden weil Inxmail Professional nicht erreichbar war
› Die Datei konnte nicht auf den SFTP geladen werden
› Wann soll das Monitoring „rot“ bzw. „grün“ werden
› Job erfolgreich => grün
› SFTP Server nicht erreichbar => rot wenn dies mehrfach hinter einander passiert
› Inxmail Professional nicht erreichbar => rot wenn dies mehrfach hinter einander passiert

20. Monitoring von Cronjobs und Services
FUNKTIONSWEISE
› Es wird eine Datei pro Programm Lauf auf einen PVC geschrieben
› Dateiname entspricht Programmnamen
› Inhalt ist ein JSON
› Xymon liest Datei ein und verarbeitet Datum + „lifetimeInterval“
› Aktuelles Datum < berechnetes Datum = Monitoring „grün“
› Aktuelles Datum > berechnetes Datum = Monitoring „rot“

21. Monitoring von Cronjobs und Services
XYMON

22. Monitoring von Cronjobs und Services
PROGRAMMCODE

23. Erfahrungen im Bereich Monitoring & Logging
VON SERVICES UND CRONJOBS IN KUBERNETES
› Vielen Dank!
› Fragen?