Thema: observability
-
Continuous Profiling in Produktion: permanent laufende Sampling-Profile und was sie beantworten
Continuous Profiling erstellt systematisch über die Zeit CPU- und Speicherprofile und speichert sie als beschriftete Serien, sodass ein Team fragen kann, welche Funktion gestern über die gesamte Flotte hinweg am meisten CPU verbraucht hat oder was sich zwischen zwei Versionen geändert hat; Sampling-Profiler machen es günstig genug, um dauerhaft eingeschaltet zu bleiben, und Laufzeit-Endpunkte wie Gos /debug/pprof/ oder eBPF-Agenten liefern die Profile.
-
Welche Trace-Sampling-Strategie hält seltene Fehler in einem Dienst mit geringem Verkehr sichtbar?
Offene Frage: Empfehlungen zum Sampling sind für Dienste mit Tausenden von Traces pro Sekunde geschrieben, bei denen ein Prozent noch eine repräsentative Stichprobe ist; welche Kombination aus Head Sampling, Tail Sampling, Raten pro Route und Aufbewahrung hat bei einem Dienst mit wenigen Anfragen pro Sekunde den einen Fehler-Trace pro Woche zu Kosten verfügbar gehalten, die das Team akzeptiert hat?
-
Alarme für Symptome, nicht für Ursachen
Auf das alarmieren, was Nutzende erleben (Fehlerrate, Latenz, Verfügbarkeit, Aktualität) mit Schwellenwerten, die an Ziele gebunden sind, nach Dringlichkeit weiterleiten und aus jedem störenden Alarm entweder eine Behebung oder eine Löschung machen.
-
Welche Observability-Signale sollte ein JVM- oder .NET-Dienst standardmässig ausgeben, und mit welchem Overhead?
Offene Frage: Beide Laufzeitumgebungen bringen eingebaute Telemetrie mit (Flight Recorder und GC-Logging auf der JVM; EventPipe-Counter und dotnet-trace bei .NET), und beide bieten OpenTelemetry-Auto-Instrumentierung – doch es gibt kaum geteilte Belege dazu, welche davon in Produktion dauerhaft aktiv sein sollten, was sie kosten und welche tatsächlich Vorfälle verkürzt haben.
-
Log-Sampling bei Ereignissen mit hohem Volumen: jeden Fehler behalten, die repetitiven Zeilen sampeln
Sampling verwirft absichtlich einen Teil ähnlicher Log-Ereignisse; die nützlichen Formen sind Eins-von-N, Burst-dann-Rate je Zeitraum, Regeln je Level, die Warnungen und Fehler unangetastet lassen, sowie Pipeline-Sampling anhand einer Request-ID, sodass eine ganze Anfrage gemeinsam behalten oder verworfen wird, wobei die angewandte Rate in die überlebenden Ereignisse geschrieben wird.
-
Verteiltes Tracing in Umrissen: Spans, Eltern-Kennungen und W3C Trace Context
Ein Trace ist ein Baum aus Spans, jeder mit Trace-Kennung, eigener Span-Kennung, Eltern-Span-Kennung, Zeitstempeln, Attributen und Status; der W3C-Header traceparent trägt Trace-Kennung, Eltern-Kennung und ein Sampled-Flag über Prozessgrenzen, und ein Dienst, der beide Header nur weiterreicht, hält Traces trotzdem zusammen.
-
journald-Weiterleitung und zentrale Log-Sammlung: ForwardToSyslog, systemd-journal-upload/-remote und Rate Limits
journald kann seine Einträge mit ForwardToSyslog= an einen lokalen Syslog-Daemon übergeben oder per systemd-journal-upload direkt über HTTPS an einen systemd-journal-remote-Listener senden, der eigene Journal-Dateien schreibt. Beide Wege unterliegen dem journald-eigenen Rate Limiting pro Dienst: Nach Überschreiten des Burst-Schwellwerts verwirft es überzählige Meldungen und protokolliert nur deren Anzahl.
-
Ein Betriebs-Dashboard gestalten: eine Frage pro Panel, ein Bildschirm pro Zielgruppe
Von den Fragen ausgehen, die eine reagierende Person beantworten muss, jeder Frage ein Panel geben, Panels von allgemein zu spezifisch ordnen, Einheiten und Achsen vereinheitlichen, Template-Variablen statt Kopien verwenden, jeden Pager-Alarm mit dem benötigten Dashboard verknüpfen und die Dashboard-Definition in der Versionskontrolle halten.
-
Windows Event Forwarding: quellinitiierte Subscription, wecutil und die Gruppe EventLog Readers
Bei einer quellinitiierten WEF-Subscription beziehen die Quellcomputer ihre Konfiguration per Gruppenrichtlinie vom Collector und senden passende Ereignisse dorthin; wecutil verwaltet die Subscription auf dem Collector. Für die Weiterleitung des Security-Logs muss das Konto NETWORK SERVICE auf jeder Quelle zur Gruppe EventLog Readers hinzugefügt werden.
-
Korrelations-IDs über eine gesamte Agent-Aufgabe hinweg verwenden
Aufgabenidentität, einzelne Versuche und den Kontext des verteilten Tracing getrennt halten, damit sich Wiederholungen nachverfolgen lassen, ohne sensible Payloads zu protokollieren.
-
Alarme sinnvoll gestalten: wenige Meldungen, jede mit einem nächsten Schritt
Ein Alarm, der jemanden weckt, muss dringend, handlungsleitend und für Nutzer spürbar sein; alles andere ist ein Ticket. Symptome an der Nutzerkante alarmieren, Schwellen an Ziele und die Verbrauchsrate des Fehlerbudgets binden, eine Wartezeit gegen Flackern setzen, das Runbook verlinken und jeden Alarm ohne Handlung wöchentlich abschaffen oder nachjustieren.
-
Alert-Hygiene für das Host-Monitoring: Änderungsrate statt Schwellwert, fehlgeschlagene Units und Zeitfenster
Eine Alarmierung per Pager soll bedeuten, dass ein Mensch sofort handeln muss. Eine fast volle Host-Disk sollte deshalb anhand ihrer Füllrate alarmieren und nicht anhand eines festen Prozentwerts, bei dem eine langsam wachsende Partition monatelang verharren kann; ein nur kurz überschrittener Schwellwert sollte gar keinen Alarm auslösen. Die SRE-Unterlagen von Google zur Paging-Disziplin und zur Multiwindow-Alarmierung liefern die Begründung, dieser Artikel wendet sie auf die in dieser Serie behandelten Host-Signale an.
-
Wiederabspielbare Ausführungsprotokolle für Agenten: jeden Modell- und Werkzeugaufruf aufzeichnen
Ein Agentenlauf lässt sich nur debuggen, wenn jede Modellanfrage, jede Antwort, jeder Werkzeugaufruf und jedes Werkzeugergebnis in Reihenfolge mit Kennungen und Parametern aufgezeichnet wird; die GenAI Semantic Conventions von OpenTelemetry benennen die Felder, und ein wiederabspielbares Protokoll erlaubt es, einen Fehler zu reproduzieren, ohne für einen neuen Lauf zu bezahlen.
-
Metriknamen und Label-Kardinalität: Einheiten im Namen, begrenzte Werte in den Labels
Die Namenskonventionen von Prometheus setzen ein Anwendungspräfix, eine Basiseinheit und ein _total-Suffix für Zähler in den Metriknamen und reservieren Labels für begrenzte Dimensionen; jede unterschiedliche Label-Kombination ist eine eigene Zeitreihe, sodass Benutzer-IDs, rohe URLs und Fehlermeldungen in Labels den Speicherbedarf vervielfachen, bis der Server in die Knie geht.
-
syslog mit rsyslog über TCP weiterleiten, abgesichert durch eine Disk-Assisted Queue
Eine Drop-in-Datei unter /etc/rsyslog.d/ kann alle Meldungen per TCP an einen zentralen Collector weiterleiten, während eine Disk-Assisted Action Queue Meldungen lokal puffert. So gehen bei einem Collector-Ausfall oder Netzwerkunterbruch keine Logs verloren. Mit rsyslogd -N1 lässt sich die Syntax prüfen, bevor die Änderung übernommen wird.
-
Korrelation versus Kausalität in Vorfalls- und Betriebsdaten
Ein Korrelationskoeffizient misst, wie sich zwei Reihen gemeinsam bewegen; er sagt nichts darüber, welche die andere antreibt, ob ein dritter Faktor wie Traffic beide antreibt, oder ob die Daten nach dem Ergebnis ausgewählt wurden. Zuerst plotten, für die naheliegenden gemeinsamen Ursachen konditionieren, das zeitliche Verhältnis prüfen und mit einer Intervention wie einem Flag oder einem Canary bestätigen, bevor gehandelt wird.
-
Die RED-Methode für anfragegetriebene Dienste, mit Exemplaren, die einen langsamen Bucket mit einem Trace verknüpfen
Jeden anfrageverarbeitenden Dienst identisch mit Rate, Errors und Duration instrumentieren: ein Zähler mit Route-, Methoden- und Status-Labels und ein Duration-Histogramm; existiert Tracing, Exemplare (eine Trace-ID mit einem aufgezeichneten Wert) am Histogramm anhängen, sodass ein langsamer Bucket im Dashboard den dort gelandeten Trace öffnet.
-
Log-Rotation und Aufbewahrungsgrenzen
Logs müssen auf jeder Ebene (Anwendung, Container-Runtime, Proxy, System-Journal) in Grösse und Alter begrenzt sein, wobei die Aufbewahrungsdauer nach Debugging- und rechtlichen Bedürfnissen gewählt wird statt nach dem Prinzip „alles behalten“.
-
Synthetisches Monitoring und Uptime-Checks: von aussen prüfen, was Nutzende sehen
Ein synthetischer Check sendet in festem Intervall eine skriptgesteuerte Anfrage von ausserhalb des Systems und protokolliert, ob die Antwort korrekt war und wie lange sie dauerte; es handelt sich um Black-Box-Monitoring im SRE-Sinn, das Ausfälle erkennt, die interne Instrumentierung nicht sehen kann (DNS, TLS, der Load Balancer, eine abgelaufene Domain), und muss von mehr als einem Ort aus geprüft werden, bevor es jemanden alarmiert.
-
Das Logging-Modul einmal am Einstiegspunkt konfigurieren
Bibliotheken holen sich Logger, konfigurieren aber nie Handler; die Anwendung konfiguriert Handler, Levels und Formate einmalig beim Start, damit die Ausgabe an einer einzigen Stelle kontrolliert wird und Duplikate vermieden werden.
Maschinenlesbar: JSON