Konferenzbericht OSMC 2022

Katharina Sommer, Senior System Engineer bei Telekom MMS

Vom 14.11. bis 16.11.2022 waren Michaela Mattes, Jan Scheufler, Martin Schurz, Daniel Uhlmann, Steve Scholl, Sebastian Gumprich und ich, Katharina Sommer auf der Open Source Monitoring Conference (OSMC) in Nürnberg unterwegs. Ein von Netways organisiertes Event mit vielen Vorträgen rund um Open Source und Monitoring. Die Themen greifen auch in viele andere Bereiche über wie Cloud, IoT, Virtualisierung und Automatisierung. Ich nehme euch in diesem Blogbeitrag mit durch beide Tage.

Frisch ausgeschlafen und gestärkt ging es am 14. November um 9 Uhr mit der Eröffnungsrede los. Bernd Erk, seines Zeichens Geschäftsführer bei Netways, hieß die Besucher willkommen, stellte die Sponsoren vor und verlor einige Worte zum organisatorischen Ablauf. Danach fanden für den Rest der nächsten zwei Tage jeweils parallel zwei Vorträge statt.

Los geht’s: Tag 1 der OSMC 2022

Zunächst hielt Christian Stein seinen Vortrag „Icinga for Windows in the Monitoring of Madness“. Da Windows für unser Tagesgeschäft eine untergeordnete Rolle spielt, waren die Vortragsinhalte nicht unmittelbar für uns anwendbar, doch dann wurde fast beiläufig ein uns bislang unbekanntes Icinga Feature namens „Shared Navigation“ erwähnt, welche das Interesse von Jan Scheufler weckte.

Parallel besuchte unserer Gruppe den Vortrag „AutoHeilung mit Ansible“ von Christian Lorenz. Er stellte zunächst Ansible vor und skizzierte anschließend, wie Datev Ansible nutzt. So gibt es dort eine zentrale AWX Installation die von 55 Teams – insgesamt 450 Leuten – genutzt wird. AWX ist ein Frontend, in dem man Ansible Playbooks und Inventories übersichtlich ausführen kann. Es stellt eine API bereit, um Monitoring, Jenkins, oder auch Webhooks anzubinden. Christian schilderte, wie man mit einem Bug von rsyslogd umging, bei dem keine Aussicht auf eine Behebung des eigentlichen Problems bestand. Das sah dann in etwa so aus:

• Rsyslog steigt aufgrund problematischer Log message(s) aus.
• Das Monitoring schickt eine Mail, welche einen Issue in Gitlab öffnet.
• Der Gitlab Webhook ruft AWX auf und führt ein Playbook zur automatischen Entstörung aus, welches gleichzeitig den Verursacher des Problems benachrichtigt, damit dieser die problematischen Meldungen unterbinden kann.

Bald darauf wurde ein neues Ansible Feature, das genau dies tut, offiziell von Ansible angekündigt. Wir hätten gern noch etwas mehr dazu gehört, aber der Vortrag war dann leider am Ende. Sebastian hat sich dann spontan dazu entschlossen das Thema in einem Ignite Talk zu beleuchten.

Nächstes spannendes Thema: „VictoriaMetrics: scaling to 100 million metrics per second“. Die Datenbank behauptet, effizienter als InfluxDB zu sein und bietet sich als Storage für Prometheus an. Gebündelt mit Grafana kann man dank kompatibler APIs auf Prometheus und Graphite verzichten und erhält so ein schlankes Setup. Im Anschluss wurde ein riesiges Setup für Benchmarking gezeigt. Dieses bestand aus etwa 65 Knoten mit je 16 CPUs und 55GB RAM. Am Ende wurde eine Aufnahmerate von 100.000.000 Messwerten pro Sekunde erreicht und 1.000.000.000 aktive Zeitreihen konnten gespeichert werden.

Parallel dazu haben wir uns den Vortrag „Open Source: Open Choice – A DevOps Guide for OSS Adoption“ von Hila Fish (Wix.com) angesehen. Nach einer Einführung in Open Source Software und deren Vorteilen ging sie darauf ein, was getan werden sollte, wenn OSS im Projekt zum Einsatz kommen soll: zuerst sollte man einschätzen, ob man die Software überhaupt einführen möchte. Man denke da an Jenkins mit seinen Plugins und Sicherheitslücken. Sobald man Software einsetzt, muss man auch überwachen, ob die Software aktualisiert oder noch gepflegt wird und entsprechend handeln. Gründe, die gegen den Einsatz von OSS sprechen, sind unter anderem Kosten, Ressourcen und die Frage, ob man das Rad neu erfinden sollte. Hinzu kommen fehlende Security by Obscurity (was diskutabel ist), die Anfälligkeit für Missbrauch (z.B. left-pad), fehlende Compliance, Open-Core (Kosten), fehlender Support oder einfach bessere Alternativen. Fast alle Nachteile treffen allerdings genauso auf nicht-freie Software zu. Im Endeffekt gibt es kein Richtig oder Falsch bei der Auswahl. Zum Schluss gab es eine Übersicht, anhand welcher Kriterien man Opensource-Software auswählen kann.

Dann folgte ein Vortrag von Julien Pivotto, einem der Maintainer von Prometheus, der einige Neuerungen vorstellte. Bemerkenswert war der Lebenszyklus der Prometheus Releases, der in einem Nebensatz fiel. So werden LTS Releases nur 6 Monate unterstützt, alle anderen Releases lediglich 6 Wochen. Interessant fand ich das Tool PromLens. Es bietet eine Oberfläche, die einem bei der Erzeugung und Visualisierung komplexer PromQL Abfragen helfen kann, indem es autocompletion, highlighting und linting anbietet. Eine Demo ist online verfügbar.

Im Anschluss gab es einen Vortrag von Thomas Gelf: „VMware monitoring with ease“. Es wurde detailliert vorgestellt, welche Versionssprünge seit 2019 in dem eigens geschriebenen Icinga Modul für vSphere stattgefunden haben. Mittlerweile ist sowohl ein Monitoring von einzelnen VMware Servern, als auch großen VMware Clustern möglich. Ebenso wurde die Oberfläche intuitiver, der Import von Ressourcen vereinfacht und neue Funktionen eingefügt, welche sich hauptsächlich an Kundenanforderungen orientieren. Alles in Allem schien das Modul sehr mächtig, nützlich und gut durchdacht.

Als nächstes folgte der Vortrag „Security as Code: A DevSecOps Approach“ von Joseph Katsioloudes, der bei Github tätig ist und Githubs Code Scanning Feature CodeQL vorgestellt hat. Es handelt sich um statische Codeanalyse, das heißt der Code wird zur Analyse nicht aktiv ausgeführt. Es existiert sogar eine Extension für VSCode. Mein Interesse war geweckt, bis mir klar wurde, dass das Feature nur für Forschung und im Opensource Bereich kostenfrei genutzt und somit in vielen Bereichen unserer täglichen Arbeit nicht ohne Weiteres verwendet werden kann. Für bestehende Opensource Projekte aber definitiv einen Blick wert. Eine Alternative in dem Bereich ist semgrep, welches ähnliche Funktionalitäten bietet.

Weiter ging es mit dem Thema OpenTelemetry, vorgetragen von Dotan Horovits, welcher aktiv in der CNCF engagiert ist. Er beschrieb den Wunsch nach einem einheitlichen Tooling für Monitoring und Observability und die dem gegenüberstehende Realität, wonach wohl 25% der User sogar 10-20 verschiedene Tools nutzen. Hier kommt OpenTelemetry ins Spiel. Es vereint OpenCensus und OpenTracing und entwickelt sich gerade in Richtung eines Standards für die Instrumentalisierung cloud-nativer Anwendungen und deckt den Bereich Logs, Metriken und Traces ab. Es stellt jedoch kein Frontend zur Visualisierung der gesammelten Daten bereit, hier muss auf andere Produkte wie z. B. Jaeger zurückgegriffen werden.
Während die Bereiche Tracing und Metrics bereits gut abgedeckt sind, ist beim Logging einiges noch in einem experimentellen Status. Aktuell wird an einigen interessanten Features gearbeitet: continous profiling, real user monitoring und einer automatisierten Instrumentation von Anwendungen auf Basis von eBPF.

Der Vortrag „Scaling SLOs with Kubernetes and Cloud Native Observability“ erklärte und wiederholte zum größten Teil gängige SRE Begriffe und Praktiken. SLAs, SLIs, SLOs, Toil und Error Budgets wurden näher beleuchtet und es wurde darauf hingewiesen, dass man den Fokus auf den Kunden und nicht auf die Technologie legen soll, es entsprechend auch besonders sinnvoll ist Businessprozesse zu überwachen. Mein Interesse wurde geweckt, als es um SLOs as Code ging. Mittels openslo ist es möglich, in Kubernetes Custom Resource Definitions (CRDs) für SLOs, SLIs und einige weitere Dinge zu erstellen, die die Erfassung und Darstellung erleichtern.

Einer der letzten beiden Vorträge des ersten Tages war von Bernd Erk. Er gab einen Überblick über aktuelle Neuerungen und Entwicklungen bei Icinga. So bringt Icinga Director in Version 10 ein sync preview Feature mit. Mit dessen Hilfe sieht man nun einen Diff, bevor man einen Resync aus einer Datasource macht, was einen vor unliebsamen Überraschungen bewahren soll. Ansonsten wurde IcingaDB sehr intensiv in den Mittelpunkt gerückt, welche das bisherige IDO Datenbankmodel ablöst und im Zusammenspiel mit Redis einige Probleme adressieren soll, speziell die Performance bei größeren Installationen. Aktuell in Entwicklung sind Anpassungen bei den Notifications und Möglichkeiten für das Überwachen von Businessprozessen.

Nach dem umfangreichen Input konnten wir den Tag in der Abendlocation ausklingen lassen. Hier gab es neben leckerem Essen, Getränken und guten Gesprächen auch noch einen Roulette-Tisch, an dem man mit Spielgeld spielen konnte. Wir haben viele Gespräche geführt und dabei festgestellt, dass auch sehr viele Telekom-Kollegen vertreten waren, mit denen wir uns am nächsten Tag treffen wollten.

Neuer Tag, neue Vorträge: Tag 2 der OSMC 2022

Nach einer kurzen Nacht erwartete uns ein weiterer Tag, gespickt mit Vorträgen: Der erste Vortrag „Automated Incident Response for Cloud Native Risks“ von Simar Singh hat uns gezeigt, mit welchen Opensource-Tools von Aqua Security man seinen Incident-Workflow verbessern kann. Nach Einleitung und generellen Erklärungen (Was ist SOAR?) gab es eine schöne Übersicht, wie man Trivy, Tracee und Postee mit CI/CD-Automatisierung, Ticketsystemen und Chat-Tools verbinden kann. Wir waren von Postee, einem simplen Message Routing System, sehr angetan und planen, einen PoC damit zu machen.

Weiter ging es mit dem Vortrag „The Power of Metrics, Logs & Traces with Open Source“ von Emil-Andreas Siemes. Zunächst gab es einen Überblick über Grafana. Danach kamen detailliertere Erläuterungen zu einzelnen Features und deren Einsatzzweck, u.a. Loki,  Mimir, Tempo, k6 und On-call. Unser Interesse weckte die Vorstellung eines neuen Features namens Faro, welches nach dem Feedback der Teilnehmer an einer anderen Konferenz die Frage „Was benötigt Ihr?“ hin entwickelt wurde. Mit Faro ist es möglich, Logs und Metriken von Clients zu sammeln und auszuwerten.

Es folgten drei Ignite Talks: Man hat 5 Minuten Zeit, über ein Thema zu sprechen. Dies wird begleitet von 20 Folien, die alle 15 Sekunden automatisch weiter schalten.

Den Anfang machte Julien Pivotto mit einer Kurzvorstellung des O11y Toolkit. Es besteht im Wesentlichen aus den beiden Tools oy-expose und oy-scrape-jitter. Mit oy-expose kann man sehr einfach mit einer Datei als Quelle Prometheus Metriken bereitstellen. Um den Daseinszweck von oy-scrape-jitter zu beschreiben, bedarf es etwas Kontext:
Prometheus nutzt delta-of-delta encoding kombiniert mit XOR-Kompression. Wenn Metriken in exakt gleichen Abständen abgeholt werden, ist es dadurch möglich, diese extrem platzsparend zu speichern. Ab Prometheus 2.30 existiert das config flag „–scrape.timestamp-tolerance“, was den Rahmen angibt in dem Daten komprimiert werden können. Die Anpassung nach oben kann unter Umständen einiges an Speicherplatz freigeben. Oy-scrape-jitter misst nun genau diese Schwankung und schlägt einen sinnvollen Wert für „–scrape.timestamp-tolerance“ vor.

Den zweiten Ignite Talk „Event Driven Ansible„ hielt Sebastian Gumprich, der sich spontan hierzu entschlossen hatte, weil das Thema im Vortrag „AutoHeilung mit Ansible“ angeteasert wurde. Sebastian hatte es getestet und seine Erkenntnisse mit den Anwesenden geteilt. So ist es möglich, Rulebooks zu definieren, welche einem erlauben, Bedingungen zu definieren und bei deren Erfüllung entsprechende Playbooks oder Module auszuführen oder Facts zu definieren. Das vielversprechende Feature ist noch in einem frühen Preview Stadium, nähere Infos in unserem Blogpost.

Ein weiterer Kollege aus unseren Reihen steuerte seinen Beitrag bei: Daniel Uhlmann hielt seinen Vortrag „How we improved our monitoring so that everyone likes to be on-call„. Er skizzierte verschiedene Ursachen, weshalb die Rufbereitschaft zuvor relativ unangenehm war. Beginnend mit Alerting, gab es eine Ausgangssituation, in der sich wahrscheinlich einige wiederfinden können:

Es werden Alertings generiert, die…

• einen zu ungünstigen Zeiten alarmieren. Ich denke hier an meine eigenen Erfahrungen, z.B. ein erfrischender Anruf um 2 Uhr nachts, welcher mich darauf hinwies, dass ein SSL Zertifikat in 14 Tagen abläuft.
• über Dinge informieren, auf die man keinen Einfluss hat. Wenn z.B. eine Schnittstelle nicht verfügbar ist, man aber nachts nichts für deren Entstörung tun kann, etwa weil die zuständigen Personen keine Rufbereitschaft haben.
• permanent flappen und die niemand mehr ernst nimmt
• uninteressant sind und daher ignoriert werden

Abhilfe schaffen können folgende Maßnahmen:

• Es alerten nur Dinge im eigenen Einflussbereich
• informative Checks löschen, um Desensibilisierung zu vermeiden
• sinnvolle Businessprozesse monitoren, also von eventbasiertem Monitoring hin zu SLO-basiertem Alerting

Ein weiterer Punkt für eine bessere Rufbereitschaft ist die Minimierung von Anrufen, speziell nachts. Es empfiehlt sich alles, was im Rahmen der Bereitschaft anrief, am nächsten Tag auszuwerten und konkrete Maßnahmen zu treffen, die Ursache für diesen Alert nachhaltig abzustellen. Checks, die Vorhersagen treffen können, sind hierfür optimal. So kann man frühzeitig erkennen, wenn z.B. eine Disk demnächst einen kritischen Füllstand erreichen würde und kann dies proaktiv unterbinden. Einen Verantwortlichen fürs Monitoring zu definieren kann ebenfalls sinnvoll sein. Um mangelnde Erfahrung zu kompensieren, die auch ein Grund dafür sein kann, das ungern die Rufbereitschaft ausgeübt wird, empfiehlt es sich, mit einem anderen Kollegen als Backup in die Rufbereitschaft zu starten und ggf. einen Ausfall zu simulieren.

Abschließend lauschten wir Colin Douchs Vortrag „Monitoring in a Serverless World“. Bei Nutzung von serverless Diensten (z.B. Google CloudFunctions, Azure Functions oder AWS Lambda) stellen sich Probleme, wenn man regulär Metriken mit Prometheus sammelt. Es ist möglich, dass von einer Function nur ein einziger Request bedient wird und sie somit nur wenige Sekunden lebt. Der Service müsste mindestens 10-15 Sekunden überdauern, um wie gewohnt Metriken einsammeln zu können. Eine Möglichkeit wäre, das Prometheus push-gateway zu nutzen, was aber aufgrund seiner Eigenschaften maximal für batch-jobs empfohlen wird. Außerdem stellt sich die Frage, wie die gesammelten Metriken aggregiert werden können, da man die gesammelten Metriken aller serverless Functions eines Service zusammen betrachten möchte. Ein Beispiel: Man möchte einen request count seiner App sehen und nicht beliebig oft „1“. Dafür gäbe es das aggregation-gateway, was aber nicht besonders flexibel konfigurierbar ist. Cloudflare hat nun beides kombiniert und das gravel-gateway entwickelt. Es bietet flexiblere Möglichkeiten, zu kontrollieren was wie aggregiert werden soll und bietet die benötigte Push-Funktionalität.

Neben den Vorträgen gab es ein paar Stände von Sponsoren mit diversen Gewinnspielen, bei allen gab es Lego Sets zu gewinnen. Einige Kollegen hatten beim Gewinnspiel der Netways Kollegen mitgemacht, bei dem eine Schätzfrage gestellt wurde. Schon halb auf dem Sprung stellte Steve Scholl fest, dass er ein Lego-Set für den DeLorean gewonnen hatte.

Damit endeten 2,5 spannende und inspirierende Tage in Nürnberg. Während der Konferenz wurden alle Vorträge aufgezeichnet und in bekannter Open Source Manier sind die Aufzeichnungen bei Netways im Konferenzarchiv frei zugänglich.

Unser Fazit

Für einige von uns war es die erste OSMC, andere sind bereits seit Langem Dauergäste. Wir alle haben die OSMC 2022 als sehr gut organisiertes Event wahrgenommen und fanden neben den Vorträgen viele Möglichkeiten zum fachlichen Austausch. Die gesammelten Eindrücke und Anregungen haben bei uns so einige Ideen erzeugt, die wir in unseren Projekten umsetzen wollen. Wir konnten uns zudem mit vielen Kollegen aus dem Telekom-Umfeld vernetzen und werden zukünftig einen engeren Austausch organisieren.

---

Katharina Sommer, Senior System Engineer im Bereich Agile Operations & Cloud

Von klein auf fasziniert von Technik und Computern, war mir immer schon klar, dass ich in diesem Bereich tätig sein möchte.
So bin ich seit etwa 15 Jahren mit wechselnden Schwerpunkten im Linux-Umfeld unterwegs und erschließe mir mit Begeisterung aktuelle Cloud-Technologien, optimiere Infrastrukturen samt Anwendungen und entwerfe Lösungen für die Wünsche unserer Kunden.

---