Seit ich 1992 im Technologiebereich arbeite – das sind über drei Jahrzehnte – bin ich auf zahlreiche Situationen gestoßen, in denen von mir erwartet wurde, „mehr mit weniger“ zu tun. Ob es darum ging, mit weniger Teammitgliedern mehr zu liefern oder in Rahmen beschränkter Hardwareressourcen zu arbeiten, dieser Gedanke war ein ständiger Begleiter. Ein spezielles Erlebnis während meiner Zeit als Backend-Architekt bei einem Cloud-Modernisierungsprojekt fällt mir hier besonders ins Auge. Um Kosten zu reduzieren, wurden wir gebeten, die Service-Level-Logging-Funktionen stark zu minimieren oder sogar vollständig zu eliminieren. Diese Entscheidung wurde durch die hohen Kosten der Log-Ingestion in unserer Observabilitätsp Plattform getroffen. Alles ging gut, bis es schiefging. Wir Brauchten Die Logs Wirklich! Natürlich trat irgendwann ein unvorhergesehenes Problem auf, und wir benötigten die fehlenden Logs, die sich als einzige Möglichkeit erwiesen, die Ursache zu identifizieren. Ohne diese Logs vergingen Stunden ohne Lösung, Unsicherheit wuchs, und die gesamte Mannschaft geriet in eine zunehmende Anspannung. Ein einfaches strukturiertes Fehlerprotokoll wie folgendes hätte uns enorm geholfen: { "timestamp": "2025-03-21T14:05:03Z", "service": "preference-engine", "level": "ERROR", "message": "Worker queue overflow: unable to dispatch to worker pool", "requestId": "abc123", "userId": "admin_42" } Mit einem einfachen Log-Abfrage hätten wir das Problem verstehen, diagnostizieren und beheben können: _sourceCategory=prod/preference-engine "Worker queue overflow" | count by userId, requestId Durch die Reduzierung des Loggings befand sich das Projekt in einer sehr verletzlichen Position. Unser Haupt-Sicherheitsnetz war weg. Minimalismus Muss Nicht Notwendigerweise Ressourcenmangel Bedeuten Der Ansatz „mehr mit weniger“ ist an sich nicht schlecht. Viele Startups profitieren davon, indem sie sich auf Kernprioritäten konzentrieren und leichte, effiziente Software nutzen. Minimalistisches Design kann die Qualität verbessern, solange die entscheidenden Werkzeuge erhalten bleiben. Aber das war nicht der „gute“ Minimalismus. Unser Deadlines zur Cloud-Migration waren festgelegt, da wir uns gegen eine Browser-Veraltungsfrist durchsetzen mussten. Das bedeutete, Dienste in ein cloud-eigenes Design umzuschreiben, mit Klienten-Teams zu koordinieren und unter Druck zu liefern. Da wir keine Zeit für umfassende Testabdeckungen oder tiefgreifende Observabilitätseingriffe hatten, lehnten wir uns auf die Logs, um Probleme zu lösen und Wurzelursachen zu bestimmen. Zunächst funktionierte das gut, wir fügten nur die notwendigen Logs hinzu, während wir an jeder Methode arbeiteten. Doch als das Logging reduziert wurde, stand die Mannschaft plötzlich leer. Unser primäres Sicherheitsnetz war verschwunden. Wurzelursachen Ohne Sicherheitsnetz Die internen Tests liefen gut. Als wir uns dem Produktionsstart näherten, waren wir zuversichtlich, dass unsere neue cloudbasierte Architektur stabil war. Wir hatten bekannte Probleme im Test gelöst und unseren Termin eingehalten. Bald stellten wir jedoch fest, dass unsere Zuversicht unbegründet war und unsere Testabdeckung lückenhaft. Sobald echte Kunden das System nutzten, tauchten unerwartete Randfälle auf. Ohne detaillierte Logs oder genügend Observabilität konnten wir die Probleme nicht untersuchen. Die begrenzte Telemetrie reichte einfach nicht aus, um herauszufinden, was schiefgelaufen war. Wenn wir Logs sowohl für die Backend-Tests als auch für die Frontend-Kunden gehabt hätten, wüssten wir, was passiert ist, und könnten das Team und den Nutzer informieren. Eine einfache Abfrage hätte ausgereicht: _sourceCategory=prod/preference-engine OR prod/frontend error | join ( _sourceCategory=prod/tester-feedback “queue error” ) on requestId | fields requestId, _sourceCategory, message Ohne die Logs war es nahezu unmöglich, die Vorfälle lokal nachzubilden. Es gab einfach zu viel Variabilität in den echten Nutzungsszenarien. Versuche, das Logging teilweise wieder einzuschalten, führten nur zurück zu den erhöhten Ingestion-Kosten, ohne uns nützliche Erkenntnisse zu liefern. In manchen Fällen konnten wir die Wurzelursachen überhaupt nicht identifizieren. Dies schuf ein allgegenwärtiges Gefühl der Hilflosigkeit im Team. MTTR Gegen Signalqualität In unseren Vorfall-Rückblicksbesprechungen wurde die mittlere Wiederherstellungszeit (MTTR) als Hauptmetrik behandelt. Doch wir stellten fest, dass MTTR meist ein Symptom und nicht die Wurzelursache ist. Industriebenchmarks zeigen oft, dass Elite-Teams innerhalb von einer Stunde einen MTTR erreichen. Was wir aber erkannten, war, dass Geschwindigkeit nicht nur durch Automatisierung, sondern auch durch hochwertige Signale erreicht wird. Niedrige Signalqualität, wie generische 500-Fehler oder verzögerte Warnmeldungen von aggregierten Metriken, hilft nicht wirklich. Sie führen nur zu Unsicherheit und verschwenden wertvolle Ressourcen, wie kostbare Triagizeit und Log-Budget. Im Gegensatz dazu helfen detaillierte, kontextuelle Signale – wie strukturierte Logs mit Benutzer-ID, Anforderungs-ID und einem Servicetrace – direkt auf die Wurzelursache. Observabilitätsp Plattformen können die MTTR reduzieren, aber nur, wenn die eingespeisten Daten handlungsfähig sind. Wenn Ihre Logs diese Fragen nicht beantworten, liegt Ihr MTTR nicht an der Teamspeed, sondern an der Signalklarheit. Wie Sumo Logic Den Tag Retten Könnte Was anders und besser hätte laufen können, während meines Cloud-Modernisierungsprojekts? Erstens wünschte ich, wir hätten bessere Log-Analysen und Anwendungsdienstleistungsmessung (APM). Dazu hätten wir Log-Management, Service-Monitore, Warnmeldungen und definierte Metriken benötigt, die eng mit dem Funktionserfolg verbunden sind. Für jede neue Funktion hätte ich eine Metrik haben sollen, die ihren Erfolg misst. Und ich will meine Logs zurück! In meinem früheren Beitrag „DevSecOps: Es Ist Zeit, Für Ihre Nachfrage Und Nicht Die Ingestion Zu Bezahlen“ habe ich beschrieben, wie Sumo Logic den Observabilitätsmarkt durcheinander gebracht hat, indem es ein pay-per-analysis-Modell anbot. Logs können kontinuierlich eingespeist werden, aber Sie zahlen nur, wenn Sie eine Abfrage oder Analyse durchführen. Führen Sie ein Projekt ohne vollständige Unit-Testabdeckung? Leiden Sie unter mangelhafter Echtzeit-Warnung oder fehlender Granularität von Metriken? Haben Sie ein enges Budget? Mangeln Ihnen die Logs? Mit kostenloser vollständiger Ingestion können Teams so viele Logs erstellen, wie sie benötigen, ohne Sorgen. Und wenn ein Vorfall schließlich eintritt, kann die Analyse bei Bedarf durchgeführt werden, mit einem gerechtfertigten Kostenansatz, der direkt mit dem Kundenaufwand oder der Geschäftsfortführung verbunden ist. Die Finanzverantwortlichen sind glücklich, Sie auch. Dieser Ansatz gibt den Teams die Kontrolle zurück und verringert die Anspannung, da sie gründlich ermitteln können, wenn es am wichtigsten ist. Aber Warten Sie: Sie Brauchen Auch Maschinengestütztes Triage, um Ihre Abfragen zu Klären Moderne Observabilität geht nicht nur darum, all diese schönen Log-Daten zu haben – es geht auch darum, zu wissen, wo Sie in diesen Daten suchen müssen. Besonders in Umgebungen mit unbegrenzter Ingestion ist dies besonders nützlich. Anstatt durch Tausende von Log-Zeilen zu wühlen, erhalten Sie „Log-Signaturen“ – verdichtete Muster, die Gruppen verwandter Ereignisse repräsentieren. Sumo Logic bietet beispielsweise maschinengestützte Triage-Werkzeuge, die anomales Verhalten automatisch gruppieren, Ausreißer erkennen und korrelierte Signale über Dienste hinweg vor der ersten Abfrage darstellen. Dies ist besonders hilfreich in Hochvolumenumgebungen. Anstatt durch zehntausende Log-Zeilen zu waten, erhalten Sie kondensierte Muster, die Gruppen verwandter Ereignisse repräsentieren. Beispielabfrage: _sourceCategory=prod/* error | logreduce Dieser einzelne Befehl klumpft rauschige Log-Daten in handlungsfähige Gruppen wie: - Fehler: Worker-Queue-Überlauf - Fehler: Authentifizierungstoken abgelaufen für Benutzer * - Fehler: Timeout in Dienst * Nach der Klumpung können Teams in tieferen Kontexten weiterarbeiten: | where message matches "Auth token expired*" | count by userId, region Das Ergebnis? Weniger blinde Suchen, schnellere Entscheidungspfade und weniger Anspannung während eines Vorfalles. Fazit Die Philosophie „mehr mit weniger“ muss Ingenieurteams nicht in eine schwächere Position bringen. Sie muss jedoch mit den richtigen Werkzeugen einhergehen. Ohne diese fühlen sich selbst die fähigsten Teams, als würden sie während eines Vorfalles zielloser navigieren – was zu Frustration und Stress führt. Meine Leser erinnern sich möglicherweise an meine persönliche Missionserklärung, die ich jedem IT-Professionellen empfehlen kann: „Konzentrieren Sie Ihre Zeit darauf, Funktionen zu liefern, die den Wert Ihres geistigen Eigentums erweitern. Nutzen Sie Frameworks, Produkte und Dienstleistungen für alles andere.“ – J. Vester In diesem Artikel haben wir gesehen, wie ein kostenfreies Ingestion-Modell dieser Mission entspricht. Es hilft Teams, Wurzelursachen schnell zu identifizieren, Downtime zu reduzieren und Stressebenen zu senken – und das alles ohne das Budget zu sprengen. Lassen Sie uns die Logs behalten!