Den Dienst und seine Nutzer beobachten

Beginnen Sie mit der Frage

Monitoring prüft bekannte Bedingungen. Observability hilft, Systemverhalten zu untersuchen, einschließlich nicht vorhergesehener Fehler. Mehr Dashboards liefern nicht automatisch bessere Antworten.

Beginnen Sie bei einem fiktiven Exportdienst mit einer Nutzerfrage: Kann ein berechtigter Nutzer den richtigen Export innerhalb der vereinbarten Zeit erhalten? Wählen Sie dann Signale, die diese Frage unterstützen und Fehler erklären helfen.

OpenTelemetry bietet Instrumentierung und Standards für Telemetrie. Es kann Signale an kompatible Backends senden. Sie brauchen weiterhin Speicher, Abfragen, Zugriffskontrollen, Aufbewahrungsregeln und Menschen, die anhand der Nachweise handeln. Einführung in Observability.

Verbinden Sie unterschiedliche Nachweise

Eine Metrik misst eine Größe über die Zeit. Ein Log erfasst ein Ereignis. Ein Trace verbindet zusammengehörige Vorgänge, während eine Anfrage durch ein System läuft. Ein Span bildet einen Vorgang innerhalb eines Traces ab.

Erhalten Sie bei asynchroner Arbeit eine sichere Zuordnung zwischen eingereichtem Job und Worker-Ausführung. Eine HTTP-202-Antwort kann bedeuten, dass Arbeit angenommen wurde. Sie beweist nicht, dass der Export abgeschlossen ist.

Alarmieren Sie, wenn Handeln nötig ist

Definieren Sie SLI und Nenner, bevor Sie das SLO festlegen. Zählen Sie im Beispiel berechtigte Exporte, die innerhalb der vereinbarten Dauer korrekt abgeschlossen wurden. Definieren Sie, wie Jobs mit langer Laufzeit und abgebrochene Jobs in die Messung eingehen.

Ein Fehlerbudget beschreibt die erlaubten Fehler im SLO-Zeitfenster. Eine Burn Rate beschreibt, wie schnell Fehler dieses Budget verbrauchen. Googles Leitfaden nutzt mehrere Zeitfenster, um rechtzeitige Erkennung und Alarmrauschen auszugleichen. Alarmierung anhand von SLOs.

Alarmieren Sie eine Person unmittelbar, wenn der Zustand zeitnahes Handeln verlangt. Leiten Sie weniger dringende Arbeit in eine Warteschlange. Jeder Alarm braucht einen Verantwortlichen, eine Beschreibung der Folgen, einen Untersuchungslink und eine Handlungsanweisung. Prüfen Sie Alarme, die wiederholt zu keiner Aktion führen.

Nutzen Sie nicht einen allgemeinen Schwellenwert für jeden Dienst. Nutzerfolgen, Verkehr, Geschäftszeiten und Reaktionskapazität beeinflussen die Entscheidung.

Schützen Sie die Telemetriepipeline

Telemetrie kann personenbezogene Daten, Tokens, Anfrageparameter und vertrauliche Dokumente enthalten. Definieren Sie erlaubte Felder vor der Erfassung. Begrenzen Sie Zugriff und Aufbewahrung. Entfernen Sie Secrets vor dem Export an ein externes Backend. Sensible Telemetrie.

Verwenden Sie keine Kunden-E-Mail-Adresse oder eindeutige Job-ID als Metriklabel. Unbegrenzte Labels erhöhen die Zahl der Zeitreihen und können Kennungen offenlegen. Nutzen Sie kontrollierte Dimensionen für Metriken. Legen Sie freigegebene Korrelationskennungen in zugriffsgeschützten Logs oder Traces ab.

Messen Sie die Pipeline selbst. Prüfen Sie Erfassungsfehler, verworfene Daten und das Alter der letzten Beobachtung. Ein flaches Fehlerdiagramm kann keine Fehler oder keine eingehende Telemetrie bedeuten. Machen Sie diesen Unterschied sichtbar.

Untersuchen Sie einen konkreten Fehler

Der fiktive Dienst meldet HTTP 202 für jede Anfrage. Das Alter der wartenden Aufgaben steigt von Sekunden auf 15 Minuten. Worker-Logs zeigen wiederholte Datenbank-Timeouts. Stichproben von Traces ordnen den Großteil der Worker-Zeit Datenbankaufrufen zu.

Diese Nachweise stützen eine gezielte Untersuchung. Sie klären nicht, ob eine Abfrageänderung, ausgeschöpfte Verbindungen oder Datenbankkapazität die Ursache ist. Vergleichen Sie diese Hypothesen mit der Debugging-Methode.

Taiga Monitoring bietet eine Ansicht zum Produktzustand mit Signalen zur Verfügbarkeit und zum Nutzererlebnis im Browser. Es ergänzt Observability für Infrastruktur und Anwendung, ersetzt diese Systeme aber nicht. Monitoring.