Überwachung und Beobachtbarkeit: Best Practices für APM, Protokollierung und Alarmierung

Unternehmen mit ausgereiften Observability-Praktiken lösen Vorfälle laut dem State of Observability-Bericht von Splunk um 69 % schneller. Die Überwachung sagt Ihnen, dass etwas nicht stimmt. Durch die Beobachtbarkeit erfahren Sie, warum es kaputt ist und wo Sie suchen müssen. Der Unterschied zwischen der stundenlangen Brandbekämpfung jedes Produktionsproblems und der Lösung innerhalb von Minuten hängt davon ab, wie gut Sie Ihre Systeme instrumentieren, Ihre Protokolle strukturieren und Ihre Warnungen entwerfen.

Wichtige Erkenntnisse

• Die drei Säulen der Beobachtbarkeit – Metriken, Protokolle und Traces – beantworten jeweils unterschiedliche Fragen und arbeiten zusammen, um ein vollständiges Systemverständnis zu ermöglichen
• Warnung zu Symptomen (Auswirkungen auf den Benutzer) und nicht zu Ursachen (interne Metriken), um Alarmmüdigkeit zu reduzieren und neuartige Fehlermodi zu erkennen – Strukturierte JSON-Protokollierung mit Korrelations-IDs ermöglicht die Suche über Dienste hinweg und die Rekonstruktion von Anforderungsflüssen
• SLOs (Service Level Objectives) verwandeln die Überwachung von „Ist etwas kaputt“ in „Erfüllen wir unsere Verpflichtungen gegenüber Benutzern?“

---

Die drei Säulen der Beobachtbarkeit

Beobachtbarkeit basiert auf drei komplementären Datentypen. Jede Säule beantwortet unterschiedliche Fragen zum Verhalten Ihres Systems.

Metriken

Metriken sind numerische Messungen, die in regelmäßigen Abständen erfasst werden. Sie beantworten „Was passiert?“-Fragen: Wie viele Anfragen pro Sekunde? Wie hoch ist die durchschnittliche Reaktionszeit? Wie viel Speicher wird verwendet?

Eigenschaften:

• Aggregiert und kompakt – Millionen von Ereignissen komprimiert in Zeitreihenzählern
• Günstig zu speichern – Daten mit fester Größe, unabhängig vom Verkehrsaufkommen
• Ideal für Dashboards und Alarmierung
• Eingeschränkter Kontext – Sie wissen, dass die Antwortzeit zugenommen hat, aber nicht, welche spezifischen Anfragen langsam sind

Wichtige Metriktypen:

• Zähler – monoton steigender Wert (Gesamtanzahl der Anfragen, Gesamtfehler)
• Messwert – Wert, der nach oben und unten geht (aktuelle CPU-Auslastung, aktive Verbindungen)
• Histogramm – Verteilung der Werte (Antwortzeitperzentile, Nutzlastgrößen)
• Zusammenfassung – vorberechnete Perzentile auf der Clientseite

Protokolle

Protokolle sind zeitgestempelte Textaufzeichnungen diskreter Ereignisse. Sie beantworten „Was ist passiert“-Fragen: Welche Fehlermeldung hat der Benutzer gesehen? Welche Parameter wurden an die fehlgeschlagene Funktion übergeben? In welchem ​​Zustand befand sich das System, als das Problem auftrat?

Eigenschaften:

• Umfangreicher Kontext – beliebige Details zu einzelnen Ereignissen – Im großen Maßstab teuer – Systeme mit hohem Datenverkehr generieren Gigabyte an Protokollen pro Stunde
• Durchsuchbar – finden Sie bestimmte Ereignisse mit der Volltextsuche – Erfordert Struktur – unstrukturierte Protokollzeilen sind schwer zu analysieren und zu korrelieren

Spuren

Traces folgen einer einzelnen Anfrage über mehrere Dienste hinweg. Sie beantworten „Wo bleibt die Zeit?“-Fragen: Welcher Serviceabruf ist langsam? Wo divergiert der Anforderungspfad? Welche Datenbankabfrage ist der Engpass?

Eigenschaften:

• Zeigen Sie Kausalität auf – Eltern-Kind-Beziehungen zwischen Vorgängen
• Ermitteln Sie das Verhalten verteilter Systeme – Latenz über Servicegrenzen hinweg
• Stichproben in großem Maßstab erforderlich – die Rückverfolgung jeder Anfrage ist teuer – Unverzichtbar für Microservices – ohne Spuren ist das Debuggen von Multi-Service-Abläufen ein Rätselraten

---

Observability Tool-Ökosystem

Einen Stapel auswählen

Für die meisten wachsenden Unternehmen empfehlen wir, mit Folgendem zu beginnen:

1. Sentry zur Fehlerverfolgung – fängt Ausnahmen mit vollständigen Stack-Traces, Quellzuordnungen und Release-Tracking ab
2. Prometheus + Grafana für Metriken – Open Source, kampferprobt, umfangreiches Integrationsökosystem
3. Strukturierte Protokollierung bei einem verwalteten Dienst – Datadog Logs, AWS CloudWatch oder Grafana Loki, abhängig von Ihrem Cloud-Anbieter
4. OpenTelemetry für die Instrumentierung – herstellerneutraler Standard, der mit jedem Backend funktioniert

Für Teams, die einen einzigen Anbieter wünschen, bietet Datadog das beste All-in-One-Erlebnis, jedoch zu erheblichen Kosten im großen Maßstab. Der Open-Source-Stack von Grafana (Prometheus, Loki, Tempo) bietet gleichwertige Funktionen bei geringeren Lizenzkosten, aber höherer Betriebsbelastung.

---

Best Practices für die strukturierte Protokollierung

Unstrukturierte Protokollzeilen wie Error processing order 12345 for user john@example.com sind für Menschen lesbar, aber maschinenfeindlich. Strukturierte JSON-Protokolle ermöglichen das Suchen, Filtern, Aggregieren und Warnen für bestimmte Felder.

Protokollstruktur

Jeder Protokolleintrag sollte Folgendes enthalten:

Korrelations-IDs

Eine Korrelations-ID ist eine eindeutige Kennung, die zu Beginn jeder Anfrage generiert und an jeden nachgelagerten Dienstaufruf, jede Datenbankabfrage und jeden Hintergrundjob übergeben wird. Bei der Untersuchung eines Problems zeigt die Suche nach Korrelations-ID jeden Protokolleintrag an, der sich auf diese spezifische Anfrage in allen Diensten bezieht.

Implementierung: Generieren Sie eine UUID am API-Gateway oder Load Balancer, übergeben Sie sie im X-Request-ID-Header und fügen Sie sie in jeden Protokolleintrag ein. Verwenden Sie in NestJS eine Middleware, die die Korrelations-ID extrahiert oder generiert und sie im asynchronen lokalen Speicherkontext speichert.

Protokollebenen

Verwenden Sie die Protokollebenen konsequent:

• DEBUG – detaillierte Diagnoseinformationen, in der Produktion deaktiviert, sofern nicht aktiv debuggt wird
• INFO – wichtige Geschäftsereignisse (Bestellung aufgegeben, Benutzer registriert, Zahlung verarbeitet)
• WARNUNG – unerwartete Situationen, die das System behandelt hat, die aber untersucht werden sollten (Wiederholung erfolgreich, Cache-Fehler, veralteter API-Aufruf)
• FEHLER – Fehler, die sich auf die Benutzererfahrung ausgewirkt haben (Anfrage fehlgeschlagen, Zahlung abgelehnt, externer Dienst nicht verfügbar)
• FATAL – die Anwendung kann nicht fortgesetzt werden (Datenbank nicht erreichbar, erforderliche Konfiguration fehlt)

Protokollaufbewahrung und Kostenmanagement

Protokolle sind die teuersten zu speichernden Beobachtbarkeitsdaten. Implementieren Sie eine abgestufte Aufbewahrung:

• Hot Storage (30 Tage) – Volltext durchsuchbar, schnelle Abfragen, hohe Kosten
• Warmer Speicher (90 Tage) – komprimiert, langsamere Abfragen, moderate Kosten
• Kühllagerung (1 Jahr+) – archiviert, Abfrage bei Bedarf, niedrige Kosten
• Debug-Protokolle – werden nicht in der Produktion gespeichert, es sei denn, sie führen eine aktive Fehlerbehebung durch

---

Alarmierungsdesign

Schlechte Alarmierung führt zu Alarmmüdigkeit – Teams reagieren nicht mehr auf Alarme, da es sich bei den meisten Alarmen um Fehlalarme oder Störungen mit niedriger Priorität handelt. Eine gute Alarmierung deckt echte Probleme auf, die menschliches Eingreifen erfordern.

Warnung bei Symptomen, nicht bei Ursachen

Symptombasierte Warnung (gut): „Fehlerrate bei /api/orders hat 5 Minuten lang 1 % überschritten“ – dies zeigt direkt die Auswirkungen auf den Benutzer an, unabhängig von der zugrunde liegenden Ursache.

Ursachebasierte Warnung (schlecht): „Datenbank-CPU hat 90 % überschritten“ – dies kann sich auf Benutzer auswirken oder auch nicht. Die Datenbank kann 95 % der CPU problemlos bewältigen, oder sie hat 50 % der CPU, ist aber völlig blockiert.

Ursachenbasierte Metriken gehören zu Untersuchungszwecken in Dashboards, nicht in Benachrichtigungsregeln.

Alarmschweregrade

Reduzierung des Alarmgeräuschs

1. Gruppenbezogene Warnungen – Wenn die Datenbank ausfällt, erhalten Sie eine Warnung „Datenbank nicht verfügbar“ und nicht 50 Warnungen von jedem Dienst, der davon abhängt
2. Anhaltender Verstoß erforderlich – „CPU über 90 % für 5 Minuten“ und nicht „CPU über 90 % für 1 Sekunde“, um vorübergehende Spitzen zu vermeiden
3. Automatische Lösung – Warnungen sollten automatisch gelöscht werden, wenn der Zustand behoben ist
4. Wöchentliche Warnungsüberprüfung – Überprüfen Sie alle ausgelösten Warnungen, identifizieren und beheben Sie diejenigen oder schalten Sie sie stumm, die kein menschliches Eingreifen erforderten
5. Rückmeldungsschleife beim Bereitschaftsdienst – nach jeder Bereitschaftsrotation dokumentiert der Techniker, welche Warnungen umsetzbar waren und welche optimiert werden müssen

---

SLOs: Service-Level-Ziele

SLOs verwandeln die Überwachung von reaktiv („etwas ist kaputt, repariere es“) in proaktiv („Wir verbrauchen unser Fehlerbudget, untersuchen wir es, bevor es die Benutzer bemerken“).

SLOs definieren

Ein SLO definiert die Zielzuverlässigkeit für einen Dienst. Es besteht aus:

• SLI (Service Level Indicator) – die gemessene Metrik (Erfolgsrate der Anfrage, Latenzperzentil)
• Ziel – der Schwellenwert, der eine akzeptable Leistung definiert (99,9 % Erfolgsquote, P95 unter 200 ms)
• Fenster – der Zeitraum, über den das Ziel bewertet wird (gleitend 30 Tage)

Beispiel-SLOs für eine E-Commerce-Plattform

Fehlerbudgets

Das Fehlerbudget ist das Gegenteil Ihres SLO-Ziels. Ein SLO von 99,9 % ermöglicht 0,1 % Fehler – etwa 43 Minuten Ausfallzeit pro Monat. Wenn das Fehlerbudget erschöpft ist, verlagert das Team den Schwerpunkt von den Funktionen auf die Zuverlässigkeitsarbeit.

Fehlerbudgets bieten eine gemeinsame Sprache zwischen Entwicklungs- und Produktteams. Anstatt darüber zu diskutieren, ob ein Dienst „zuverlässig genug“ ist, können beide Teams genau sehen, wie viel Fehlerbudget verbleibt, und datengesteuerte Entscheidungen über die Bereitstellung neuer Funktionen im Vergleich zu Investitionen in Stabilität treffen.

---

Häufig gestellte Fragen

Wie viel kostet Beobachtbarkeit im großen Maßstab?

Die Observability-Kosten liegen zwischen 10 und 50 US-Dollar pro Host und Monat für Open-Source-Stacks (Prometheus, Grafana, Loki) und 30 bis 100 US-Dollar und mehr pro Host für kommerzielle Lösungen (Datadog, New Relic). Der größte Kostentreiber ist das Protokollvolumen. Optimieren Sie es, indem Sie Debug-Protokolle auswerten, gespeicherte Protokolle komprimieren und geeignete Aufbewahrungsfristen festlegen. Für die meisten Unternehmen mit weniger als 50 Servern betragen die Kosten 500–2.000 US-Dollar pro Monat.

Sollte ich OpenTelemetry oder herstellerspezifische Agenten verwenden?

Verwenden Sie OpenTelemetry. Es handelt sich um den Industriestandard für Instrumentierung, der von allen großen Observability-Anbietern unterstützt wird und eine Anbieterbindung verhindert. Sie können Backends wechseln (z. B. von Datadog zu Grafana), ohne Ihren Code neu zu instrumentieren. Anbieterspezifische Agenten bieten manchmal eine tiefere Integration, aber der Kompromiss bei der Portabilität lohnt sich nicht.

Wie richte ich die Überwachung für eine NestJS-Anwendung ein?

Verwenden Sie in NestJS Interceptoren für das Anforderungstiming, Ausnahmefilter für die Fehlerverfolgung und Middleware für die Korrelations-ID-Weitergabe. Integrieren Sie Sentry mit @sentry/nestjs zur Fehlerverfolgung. Exportieren Sie Prometheus-Metriken mit der prom-client-Bibliothek, die auf einem /metrics-Endpunkt verfügbar ist. Verwenden Sie die strukturierte Protokollierung mit nestjs-pino oder winston, die für die JSON-Ausgabe konfiguriert sind.

Was ist der Unterschied zwischen Überwachung und Beobachtbarkeit?

Die Überwachung informiert Sie, wenn vordefinierte Dinge schiefgehen (CPU hoch, Fehlerrate erhöht, Festplatte voll). Mit Observability können Sie neue Fragen zum Systemverhalten stellen, ohne neue Instrumente einzusetzen. Ein System ist beobachtbar, wenn Sie seinen internen Zustand anhand seiner externen Ausgaben (Metriken, Protokolle, Spuren) verstehen können. In der Praxis ist eine gute Überwachung eine Teilmenge der Beobachtbarkeit.

Wie überzeuge ich mein Team, in Observability zu investieren?

Verfolgen Sie die mittlere Zeit bis zur Lösung (MTTR) für Produktionsvorfälle vor und nach Verbesserungen der Beobachtbarkeit. Teams mit guter Beobachtbarkeit reduzieren die MTTR typischerweise um 60–70 %. Multiplizieren Sie die eingesparte Zeit mit den Entwicklungskosten, um den ROI anzuzeigen. Verfolgen Sie auch die Anzahl der erkannten Vorfälle durch Überwachung im Vergleich zu Benutzerberichten – eine proaktive Erkennung stärkt das Vertrauen der Kunden.

---

Was kommt als nächstes?

Beginnen Sie mit der Fehlerverfolgung (Sentry), wenn Sie nichts haben – es bietet den unmittelbarsten Nutzen, indem es Produktionsfehler erkennt und darauf aufmerksam macht. Fügen Sie als Nächstes eine strukturierte Protokollierung mit Korrelations-IDs hinzu. Implementieren Sie dann die Metrikerfassung mit Prometheus- und Grafana-Dashboards. Fügen Sie schließlich die verteilte Ablaufverfolgung hinzu, wenn Sie über mehrere Dienste verfügen.

Den vollständigen Performance-Engineering-Kontext finden Sie in unserem Säulenleitfaden zur Skalierung Ihrer Geschäftsplattform. Um die von Ihrer Überwachung überwachte Infrastruktur zu optimieren, lesen Sie unseren Leitfaden zur Infrastrukturskalierung.

ECOSIRE implementiert Observability-Stacks für Geschäftsplattformen, die auf Odoo ERP und benutzerdefinierten Architekturen laufen. Kontaktieren Sie unser DevOps-Team für eine Überwachungs- und Beobachtbarkeitsbewertung.

---

Veröffentlicht von ECOSIRE – Unterstützung von Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.