Wie kommt man vom Game Design zum Monitoring?
Game Design habe ich nicht wegen des Spielens, sondern wegen der Technologie studiert. Aber da gibt es schon Gemeinsamkeiten. Ich entwickle ungern, wenn sich dabei nichts „bewegt“. Ich möchte die Auswirkungen meiner Entwicklung sehen und nachvollziehen können. Monitoring kompensiert, was mir in der Beziehung bei der Entwicklung einer Backendsoftware fehlt.
Was genau ist deine Aufgabe?
Ich bin seit mehreren Monaten Mitglied im Team rund um POI (Points-of-Interest)-Dienste. Meine Aufgabe dreht sich insbesondere um die Entwicklung und Umsetzung des Monitorings für den Content Aggregator. Das ist eine Software, die Informationen, die POI-Informationen von mehreren Anbietern aggregiert, vergleicht und nur die relevanten Informationen an den Anfragenden sendet.
Um was zu erreichen?
Als Verantwortliche für die Infotainment-Dienste im Fahrzeug müssen wir die Stabilität und Schnelligkeit der Dienste im Fahrzeug sicherstellen. Dabei unterliegen wir jedoch der Schwierigkeit, dass wir keinen direkten Zugriff auf die geschützten Test- und Integrationsumgebung des Kunden haben. Wir müssen uns daher bei Fehlermeldungen auf die vom Kunden bereitgestellten Daten verlassen. Da Fehlermeldungen nicht immer unmittelbar bei uns eintreffen, wurde es für uns in der Vergangenheit zunehmend schwieriger die Fehler nachzuvollziehen. Daher haben wir im Team beschlossen, uns auf den vom Kunden bereitgestellten Daten ein Monitoring-Tool aufzusetzen, das es uns ermöglicht zeitgenau die Fehler den Quellen zuzuordnen.
Warum habt ihr keine gängigen Monitoring-Tools benutzt?
Unser Approach unterscheidet sich insofern, dass wir das Monitoring tiefer mit der Software verheiraten, Datenpakete hochfrequenter und präziser abfragen. Wo ist das Paket? Welche „Stationen“ hat es durchlaufen? Ist es erfolgreich am Ziel angekommen? Wenn nein, wo ist es hängengeblieben? Wie schnell ist es von A nach B nach C nach D gereist? Welche Zustände hat es angenommen? Alleine dadurch, dass wir alle 30 Sekunden auswerten, erhalten wir mehr Information bezüglich Stabilität, Performance und Auslastung. Gerade bei einer Microservice-Architektur ist das Gold wert – nicht nur für den Betrieb, sondern vor allem für uns Entwickler.
Inwiefern?
Der Entwickler bekommt ein besseres Verständnis dafür, wie gut die Dienste – insbesondere nach Updates – laufen, wo der Flaschenhals ist und wie kontinuierlich an einer Verbesserung der Leistung gearbeitet werden kann. Wir können Vorzeichen frühzeitig erkennen und interpretieren. Uns gelingt es inzwischen Fehler zu beheben, bevor sie beim Nutzer ankommen.
Wie habt ihr diesen Approach technisch umgesetzt?
Der Kunde stellt uns seit jeher eine Check JSP – die „Diagnose-Seite“ der jeweiligen Anwendung, um es vereinfacht auszudrücken – zur Verfügung, über die wir den Status des Dienstes von der Test- und Integrationsumgebung einsehen können. Leider liefert diese jedoch nur die aktuellen Daten, so dass wir bei verspätetet ankommenden Fehlermeldungen keine Informationen mehr über den Status des Fehlereintritts erhalten. Um dieser Problematik entgegenzuwirken, haben wir uns dazu entschieden, die vom Kunden bereitgestellten Daten in einer zeitbasierten Datenbank abzuspeichern.
Konkret?
Wir haben uns bei der Persistierung der Monitoring-Daten für die Influx-Datenbank entschieden, da sie wie geschaffen ist für zeitbasierte Datensätze. Sie ermöglich sekundenschnelle Abfragen, die Definition von Zeitintervallen und räumt alte, nicht mehr relevante Datensätze automatisch auf. Der von uns entwickelte Service fragt regelmäßig die zur Verfügung gestellten Daten ab und speichert diese in der Datenbank. Mit Hilfe von Grafana, einem Open Source-Dashboard, visualisieren wir die Zustände unserer Services und virtuellen Maschinen. Zudem haben wir in Grafana Alerts definiert, die uns über prekäre Zustände automatisch per Mail und Chat informieren. Vom Fehlerfall bis hin zu knappen Ressourcen ist da alles dabei. Dies ermöglicht uns sehr schnell zu reagieren, aber auch uns auf andere Dinge zu konzentrieren, solange alles in Ordnung ist.
Back to the Roots: deine Top3-Games?
Prey, Codename Eagle, Witcher 3. Aber eigentlich bin kein Zocker. Diese Phase hatte ich zwischen 16 und 17; war dann aber recht schnell wieder vorbei.
Ungewöhnlich.
Meinen Spieltrieb lebe ich mit meinen Drohnen aus. Ich habe mit einer DJI Phantom 2 angefangen, aber schnell gemerkt, dass ich die nicht reparieren kann. Was bei dem Hobby, vor allem wenn man Anfänger ist, dann ein teures Vergnügen ist. Also habe ich angefangen selbst Drohnen zu bauen. Besonders interessiert war ich vor allem an cinematischen Aufnahmen. Deshalb haben meine beiden großen Drohnen auch jeweils ein Gimbal um möglichst stabile Aufnahmen zu ermöglichen. Kombiniert habe ich das mit FPV und Head Tracking. Das Kamerabild der Drohne wird auf eine FPV Brille zu mir am Boden übertragen, die Kamera bewegt sich so wie ich meinen Kopf bewege. Wie ich vorhin schon gesagt habe: Ich möchte die Auswirkungen meiner Entwicklung sehen – scheinbar im wahrsten Sinn des Wortes.
