Viel Infrastruktur, wenig Erkenntnis: Die Observability-Lücke

Logfiles voller Notices, die im Ernstfall doch nichts erklären. SaaS-Lösungen, die nur bei Exceptions aufwachen und Sampling, das genau den einen Request verwirft, der interessant gewesen wäre. Wir haben heute mehr Observability-Infrastruktur als je zuvor – und trotzdem stehen wir beim nächsten Incident oft mit denselben offenen Fragen da.

Doch das liegt nicht an fehlenden Werkzeugen, sondern an der Art, wie wir protokollieren!

Dieser Talk geht daher der Frage nach, was Observability eigentlich bedeutet, wenn man sie einmal nicht mit Fehlerprotokollierung verwechselt – und zeigt ein Architekturkonzept, das wichtige Entscheidungen dorthin verlagert, wo sie sich tatsächlich treffen lassen. Denn Daten zu sammeln ist nur die halbe Miete: Was nützt schließlich die perfekte Blackbox, wenn man die Daten hinterher nicht sinnvoll herausbekommt?

Vorkenntnisse

Keine Voraussetzungen im engeren Sinne. Hilfreich, aber nicht zwingend nötig:

• Praktische Erfahrung mit Logging/Monitoring in produktiven Webanwendungen
  
• Grundlegendes Verständnis von HTTP-Requests und Backend-Architektur.
  
• Keine Vorkenntnisse zu OpenTelemetry, Distributed Tracing oder spezifischen Observability-Tools nötig; diese werden im Talk kurz eingeordnet, aber nicht vorausgesetzt.

Lernziele

• Verstehen, warum die klassische Trennung "Log-Level entscheidet über Relevanz" strukturell an ihre Grenzen stößt
  
• Den Unterschied zwischen Fehler protokollieren und Observability klar benennen und im eigenen Systemkontext einordnen können
  
• Rolle von Korrelation und SLI/SLO als nachgelagerte Bewertungsebene verstehen
  
• Den Unterschied zwischen vorab (Head-based) und nachträglich entscheidendem (Tail-based) Sampling einordnen können – und warum dieser Unterschied mehr ist als eine Kostenoptimierung