Polyglottes IoT‑Logging in der Praxis: Wie Tractive GmbH mit JSON und dem Elastic Stack Container‑Logs vereinheitlicht

Einordnung: Warum diese Session wichtig ist

Bei DevJobs.at haben wir „Logging in a Polyglot IoT Environment“ mit Speaker Dominik Hurnaus (CTO) von Tractive GmbH verfolgt. Der Talk zeigt sehr konkret, wie ein IoT‑Unternehmen mit Mobile‑Apps, Firmware auf Geräten und einem vielschichtigen Backend ein zentrales Logging aufbaut, das täglich große Datenmengen bewältigt – und wie dieses Logging zum operativen Rückgrat für Qualität, Stabilität und Geschwindigkeit im Betrieb wird.

Tractive GmbH entwickelt GPS‑Tracker für Haustiere. Das Produktumfeld ist typisch IoT: Geräte draußen im Feld funken kontinuierlich Daten, Mobile‑Apps begleiten Nutzer:innen in Echtzeit, und im Backend koordiniert eine Vielzahl an Services die gesamte Datenverarbeitung. Dominik stellt klar: Neben Themen wie sichere Kommunikation, Updatefähigkeit, Zero‑Downtime‑Deployments und Datenbankskalierung ist Logging ein Kernbaustein. Denn ohne gute Logs fehlt dem Team die Transparenz, um Probleme früh, reproduzierbar und effizient zu lösen.

Der Problemraum: Viele Quellen, viele Formate, 24/7‑Betrieb

Ein zentrales Motiv des Talks ist die Polyglottie:

• Mobile‑Apps in Swift und Kotlin, ergänzt um React Native und JavaScript‑Anteile.
• Backend‑Services in Kotlin, Ruby, JRuby und Java.
• Firmware‑Entwicklung in C und C++.
• Webanwendungen und Webshop in verschiedenen Webframeworks.

Jede dieser Welten loggt – häufig mit eigenen Bibliotheken und Konventionen. Dazu kommen die Geräte (GPS‑Tracker) im Feld und die Apps, die Ereignisse erzeugen, die für Betrieb und Support wichtig sind. Dominik betont weitere Randbedingungen:

• Sicherheit in der Kommunikation zwischen Apps, Servern und Geräten.
• Updatefähigkeit (Firmware‑Updates über Bluetooth, Wi‑Fi, GSM/LTE; App‑Updates; Server‑Rollouts).
• Hohe Verfügbarkeit mit Zero‑Downtime‑Deployments.
• Skalierung – u. a. der Datenbank (als Kerndatenbank nennt er MongoDB).

In Summe entstehen „viele Logs aus verschiedenen Softwaresystemen“. Genau dafür braucht es eine zentrale, robuste Lösung.

Architekturüberblick: Docker‑Swarm‑Cluster und vielfältige Services

Im Backend setzt Tractive GmbH auf eine Docker‑Swarm‑Umgebung mit einem größeren Cluster aus mehreren Servern. Darauf laufen:

• REST‑APIs.
• Endpunkte für die GPS‑Tracker („device endpoints“), die IoT‑Daten entgegennehmen.
• Ergänzende Services wie ein Notification‑Service (Push‑Benachrichtigungen) und geolokationsnahe Anwendungen.
• Infrastrukturkomponenten wie Load Balancer, Caches und die Kerndatenbank MongoDB.

Alle diese Komponenten generieren Logs. Zusätzlich kommen Logs von außen: GPS‑Tracker im Feld senden kontinuierlich Daten; die Mobile‑Apps erzeugen ebenfalls Einträge. Das heißt: Das Logging muss sowohl Container‑Logs innerhalb des Clusters bündeln als auch externe Ereignisse verarbeitbar machen – konsistent, suchbar und mit ausreichendem Kontext.

Die gewählte Lösung: Elastic Stack (ehemals ELK)

Dominik und sein Team entschieden sich für den Elastic Stack – die Kombination aus Beats, Logstash, Elasticsearch und Kibana.

Beats (Filebeat) als Log‑Collector

• Beats ist die Sammlung schlanker Datensammler.
• Tractive GmbH nutzt Filebeat, um Logfiles einzusammeln, die die Docker‑Umgebung erzeugt.
• Filebeat liest „alle Logs aus den Dateien, die vom Docker‑Environment generiert werden“.

Logstash als Aggregator und Enricher

• Logstash aggregiert die eingehenden Log‑Events, filtert bei Bedarf und „fügt Felder hinzu“ – abhängig vom Service.
• Diese Anreicherung ist wichtig, um in späteren Analysen und Alerts die richtigen Dimensionen (z. B. IDs) parat zu haben.

Elasticsearch als skalierbare Log‑Datenbank

• Elasticsearch dient als Speicher und Suchmaschine für Logdaten.
• Volltextsuchen sind schnell und flexibel; strukturiert abgelegte Felder erlauben präzise Filter und Aggregationen.

Kibana als Abfrage‑ und Visualisierungsebene

• Kibana ist das Tool, um Logs „wie mit Google“ zu durchsuchen: ein Suchbegriff, und man erhält relevante Treffer.
• Darüber hinaus lassen sich Dashboards und Saved Searches bauen, die den täglichen Betrieb unterstützen.

Der Schlüsselschritt: Ein einheitliches Format (JSON)

„Der Schlüssel zum Puzzle“ ist laut Dominik ein zentrales Logformat: JSON. In einem polyglotten Umfeld wird das Parsing sonst schnell zum Flaschenhals. Die gewählte Umsetzungsstrategie nutzt vorhandene Mechanismen von Docker und Beats:

• Docker bietet einen JSON‑Logger, der Container‑Logs als JSON in Dateien schreibt.
• Filebeat liest diese JSON‑Dateien aus dem Docker‑Environment.
• Sobald ein Service startet, „pickt Filebeat die Logs automatisch auf“ und leitet sie weiter – ohne manuelles Tailen oder SSH auf einzelne Hosts.

Damit gilt: Keine verstreuten Logfiles mehr, sondern eine zentrale Datenbasis. Die JSON‑Struktur schafft eine verlässliche Grundlage für Parsing, Anreicherung und Suche.

Lessons Learned: Was in der Praxis wirklich zählt

Dominik fasst die wichtigsten Erkenntnisse aus dem Aufbau und Betrieb zusammen. Aus Redaktion‑ und Engineering‑Sicht sind diese Punkte universell relevant.

1) Kontext ist König: Metadaten konsequent mitschreiben

Ein Logeintrag „User logged out“ ist wertlos, wenn die zentrale Information – welcher User? – fehlt. Deshalb:

• IDs aller betroffenen Entitäten mitschreiben (z. B. User‑ID, Tracker‑ID, Payment‑ID, Subscription‑ID).
• Bei Domänenereignissen (z. B. „Haustier erstellt“) sinnvolle Zusatzinformationen aufnehmen.
• Bei Löschungen zumindest die ID protokollieren.

So wird ein Logeintrag von einer vagen Aussage zu einem nachvollziehbaren, korrelierbaren Ereignis. Späteres Debugging lebt genau von dieser Kontexttiefe.

2) Log‑Level bewusst einsetzen – je Umgebung unterschiedlich

• In Staging/Test kann und sollte man mehr Details loggen als in Produktion.
• In Produktion gezielt lautstarke Logs vermeiden, um Signal‑zu‑Rauschen im Griff zu behalten – ohne die nötigen Diagnosen zu verlieren.

Die klare Definition, welche Ebene (DEBUG/INFO/WARN/ERROR) für welche Ereignisse angemessen ist, ist ein Teamthema – und kein einmaliges Set‑and‑Forget.

3) Keine sensiblen Daten loggen

Explizit benannt werden: personenbezogene Daten, Secrets, Schlüssel, API Keys und alle Daten, die „niemand sonst lesen“ sollte. Der Elastic Stack macht das Suchen einfach – also müssen Teams die Compliance schon beim Emittieren beachten. Redaction‑Strategien sind ein möglicher Baustein; noch wichtiger ist aber, solche Daten gar nicht erst zu loggen.

4) Drittanbieter‑Calls vollständig aufzeichnen

Wenn ein externer Dienst ausfällt oder sich Semantiken ändern, sind Logs oft die einzige schnelle Brücke zur Ursache. Daher empfiehlt Dominik:

• „Alle Details“ zu Calls loggen: gesendete Daten, empfangene Daten.
• „Headers notieren“, da sie bei Fehlersuche wertvolle Hinweise enthalten können.

Gerade Integrationen sind häufige Fehlerquellen – vollständige, kontextreiche Logs sparen hier Tage an Analysezeit.

5) Volumen im Blick behalten – und bewusst managen

Dominik nennt eine konkrete Größenordnung: „rund 20 Gigabyte Logs pro Tag“ aus den verschiedenen Systemen. Das ist nicht nur eine Speicherfrage – auch Kosten, Durchsatz und Abfragen sind betroffen. Deshalb braucht es klare Strategien für Retention, Sharding/Indexierung und SLOs für Suchzeiten. Im Elastic Stack hilft die integrierte Lifecycle‑Verwaltung (siehe unten).

Was tun mit all den Logs? Operative Nutzung statt Datengrab

Zentralisierte Logs sind nur dann wertvoll, wenn Teams sie täglich nutzen. Dominik beschreibt einen Arbeitsmodus, der Logs vom passiven Artefakt zur aktiven Steuerungsgröße macht.

Tägliche Routinen: Morning Check und Ticket‑Ableitung

• Die Entwickler:innen werden „trainiert, die Logs zu nutzen“.
• Jeden Morgen prüft eine rotierende Person die Fehlereinträge: Gibt es neue, unbekannte Fehler? Häufen sich bestimmte Exceptions?
• Erkenntnisse führen direkt zu Tickets im Ticketing‑System.

Diese Routine verankert Prävention im Alltag – kleine Fehler werden sichtbar, bevor sie groß werden.

Nach Deployments: Error‑Log‑Review

• Nach jedem Rollout wird gezielt auf die Fehlerlage geschaut: Hat sich etwas verändert? Sind Warnungen aufgetreten, die vorher nicht da waren?
• So lassen sich Regressionen schnell identifizieren und zurückrollen oder nachbessern.

Log‑basierte Beobachtbarkeit: Monitoring und Alerting

Neben klassischem Application Performance Monitoring setzt Tractive GmbH auf logbasierte Alerts:

• Logs „erzählen“ vom Geschäft: Käufe, User‑Anlage usw.
• Schwellwerte pro Zeitfenster liefern einfache, aber effektive Wächter. Beispiel aus dem Talk: „keine Zahlungen innerhalb einer Stunde“ → Alarm aus den Logs.

Der Vorteil: Man muss keine zweite Telemetrielogik bauen. Was das System bereits sinnvoll loggt, kann direkt zur Überwachung werden.

Lebenszyklusmanagement: Aufbewahren, dann automatisiert löschen

Elastic bietet „Index Lifecycle Management“ (ILM):

• Teams definieren, wie lange Logdaten verfügbar sein sollen (z. B. 30 Tage).
• Nach Ablauf werden Daten automatisch gelöscht.
• Das verhindert unkontrolliertes Wachstum und schützt das Budget.

Die Kunst ist, Retention so zu wählen, dass operative und rechtliche Anforderungen erfüllt sind – ohne die Plattform zu überfrachten.

So sieht ein Log aus: Allgemeine Struktur, domänenspezifische Felder

Dominik skizziert einen typischen Logeintrag:

• Ein Timestamp.
• Ein Log‑Level.
• Eine Nachricht.

Darüber hinaus enthalten Logs bei Tractive GmbH domänenspezifische Felder – z. B. Payment‑ID, Tracker‑ID, Subscription‑ID –, „weil es für diesen Logtyp sinnvoll ist“. Andere Logarten haben andere, passende Felder. Genau diese flexible, JSON‑basierte Struktur macht die Suche effektiv: Teams können nach IDs filtern, Ereignisse korrelieren und Fehlerpfade rekonstruieren.

Praktische Leitlinien für Teams, die das nachbauen wollen

Wir bleiben eng an dem, was Dominik gezeigt hat, und leiten daraus einen möglichen Pfad ab – ohne eigene Werkzeuge zu ergänzen.

1) Standardisieren: JSON als verbindliches Logformat

• Beschließen Sie teamweit: Alle Services loggen strukturiert in JSON.
• Legen Sie gemeinsame Feldnamen fest (z. B. timestamp, level, message, service, request_id, user_id, tracker_id etc.).
• Dokumentieren Sie Domainfelder je Service – damit Entwickler:innen wissen, welche IDs/Attribute zu loggen sind.

2) Container‑Ebene nutzen: Docker JSON‑Logger einschalten

• Docker kann Logs als JSON in Dateien schreiben.
• Diese einheitliche Quelle ist ideal für Filebeat.

3) Sammeln: Filebeat deployen und konfigurieren

• Filebeat liest die von Docker erzeugten Dateien.
• Bei neuen Services greift es automatisch und schickt die Einträge weiter.

4) Anreichern und verteilen: Logstash als Drehkreuz

• Parsen der JSON‑Struktur.
• Anreicherung mit Zusatzfeldern (z. B. Environment, Service‑Name, Host, Container‑ID).
• Optionale Filterung, um Rauschen zu reduzieren.

5) Speichern und suchen: Elasticsearch

• Index‑Strategie passend zur Retention und zum Suchprofil wählen.
• Für häufige Queries geeignete Felder mappen.

6) Nutzen: Kibana für Suche, Saved Searches, Dashboards

• Tägliche Arbeit beginnt in der Suche – gerade für Fehleranalysen.
• Dashboards für wiederkehrende Fragestellungen (z. B. Fehler pro Service, pro Version).

7) Operativer Rahmen: Prozesse definieren

• Daily Log Review mit rotierender Verantwortlichkeit.
• Post‑Deployment‑Checks.
• Alerting auf Basis logspezifischer Schwellwerte (z. B. „keine Payments in 60 Minuten“).

8) Hygiene: Log‑Level, Datenschutz, Reduktion

• Log‑Level pro Umgebung klar regeln.
• Keine sensiblen Daten loggen.
• Bei Bedarf payloads kritischer Integrationen maskieren oder zusammenfassen – ohne Diagnostik zu verlieren.

9) Lebenszyklus: Retention per ILM steuern

• Definieren Sie, wie lange Logs aufbewahrt werden (z. B. 30 Tage, wie im Talk als Beispiel genannt).
• Automatisierte Löschung einstellen, um Wachstum zu begrenzen.

Warum diese Umsetzung trägt: Unsere wichtigsten Beobachtungen

• Einheitliches Format senkt Reibung: JSON macht Parsen und Anreicherung zuverlässig – besonders in einem polyglotten Umfeld.
• Logenrichment ist nicht Kür, sondern Pflicht: Ohne IDs ist Troubleshooting Glücksspiel.
• Prozesse zählen ebenso wie Tools: Der morgendliche Log‑Check und das Post‑Deployment‑Review sind der Unterschied zwischen „Wir haben Logs“ und „Logs treiben unsere Qualität“.
• Log‑basierte Alerts treffen die reale Nutzung: Ereignisse wie „Purchase“ oder „User created“ sind geschäftsrelevant und deshalb gute Kandidaten für einfache, robuste Überwachung.
• Retention schützt Team und Budget: Mit ILM bleibt der Datensatz handhabbar und compliance‑konform.

Häufige Fallstricke – und wie die Session ihnen vorbeugt

• Unstrukturierte Logs: Freitext lässt sich schlecht korrelieren. JSON löst das.
• Zu wenig Kontext: „Fehler ist passiert“ hilft nicht. IDs, Headers, Payload‑Ausschnitte sind die Antwort.
• PII/Secrets in Logs: Früh Regeln definieren und Reviews etablieren.
• Alert‑Flut: Schwellwerte an realen Metriken ausrichten (z. B. „keine Payments in 1h“) statt rein technischer Zähler.
• „Set and forget“: Log‑Level, Felder und Prozesse verändern sich mit dem System – regelmäßige Pflege ist nötig.

Fazit: Ein robustes, alltagstaugliches Logging‑System für ein polyglottes IoT

„Logging in a Polyglot IoT Environment“ von Dominik Hurnaus zeigt einen klaren, praxistauglichen Weg:

• Polyglottes Stack? Vereinheitlichung über JSON.
• Containerisiert? Docker JSON‑Logger plus Filebeat als Einstieg.
• Zentral speichern und durchsuchen? Logstash → Elasticsearch → Kibana.
• Nutzbar machen? Enrichment mit IDs, klare Log‑Level, Datenschutz beachten.
• Operativ verankern? Daily Reviews, Post‑Deployment‑Checks, logbasierte Alerts.
• Wachstum managen? Lifecycle‑Management mit definierter Retention (z. B. 30 Tage).

Das Ergebnis ist mehr als ein technisches Setup: Es ist ein Arbeitsmodus, in dem Logs als Frühwarnsystem, Diagnosequelle und Qualitätshebel dienen – in einem Umfeld, das durch Geräte im Feld, mobile Clients und skalierende Backends naturgemäß komplex ist. Genau deshalb ist Dominiks Fokus auf Struktur, Kontext und Routine so wertvoll.

Zum Schluss erwähnt Dominik, dass Tractive GmbH wächst und neue Kolleg:innen sucht – von Senior Backend (Kotlin oder Ruby) über Cloud Engineering und Software Testing bis zu Hardware‑ und Firmware‑Engineering. Wer sich für die Kombination aus IoT‑Produkt, polyglottem Stack und sauberer Engineering‑Praxis interessiert, findet dort ein Umfeld, in dem Logging nicht Beiwerk ist, sondern Wirkung entfaltet.

• 

  

  The purpose of your data

  Clemens Kaar von Tractive zeigt in seinem devjobs.at TechTalk den Unterschied zwischen functional Data und analytical Data – und die wichtige Rolle, die diese Unterteilung in einem Devteam spielen kann.

  Jetzt ansehen