Thema: monitoring
-
Ablauf von TLS-Zertifikaten auf jedem Endpunkt überwachen, nicht nur auf der Hauptwebsite
Ein abgelaufenes Zertifikat ist ein Ausfall mit exakt vorhersagbarem Zeitpunkt; das notAfter-Datum jedes tatsächlich ausgelieferten Zertifikats (Web, API, Mail, interne Panels, Load Balancer) von aussen abfragen, mit ausreichendem Vorlauf für eine manuelle Erneuerung alarmieren und sowohl die Zwischenzertifikate als auch das Endzertifikat prüfen.
-
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.
-
Aktualitäts- und Zeilenzahl-Prüfungen an rohen Quelltabellen erkennen die meisten Pipeline-Vorfälle früher als nachgelagerte spaltenbezogene Tests
Hypothese: In einem Warehouse mit geschichteten Modellen zeigt sich die Mehrheit der Vorfälle, die letztlich für Berichtskonsumenten sichtbar werden, zuerst als veralteter oder zu kleiner Rohquellen-Ladevorgang, sodass Aktualitäts- und Volumenprüfungen auf der Quellschicht sie früher erkennen als Not-Null-, Eindeutigkeits- und Wertebereichstests auf nachgelagerten Modellen; ein vorgeschlagener Vergleich anhand aufgezeichneter Vorfälle.
-
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.
-
Datenqualitätsprüfungen: Aktualität, Volumen, Nullwerte und Eindeutigkeit als minimales Testset
Vier günstige Prüfungen decken die meisten defekten Ladevorgänge auf: Die Quelle wurde aktuell genug aktualisiert (Aktualität), das Intervall lieferte eine plausible Zeilenzahl (Volumen), Schlüssel und Pflichtmasse sind nicht null, und die deklarierte Granularität ist eindeutig. Jede Prüfung als Abfrage formulieren, die fehlschlagende Zeilen zurückgibt, nach dem Laden und vor der Veröffentlichung ausführen, und Warnungen von blockierenden Fehlern trennen.
-
Wie viele externe Sondenstandorte und welche Fehlerschwelle machen Uptime-Alarme für eine kleine Website vertrauenswürdig?
Offene Frage: Ein einzelner Sondenstandort erzeugt Alarme für die eigenen Netzwerkprobleme der Sonde, während das Verlangen nach Übereinstimmung vieler Standorte echte Alarme verzögert; welche Kombination aus Standorten, Intervallen und Bestätigungsregeln hat bei einer kleinen Website mit einem Ursprung falsche Alarme niedrig gehalten, ohne Ausfälle zu verpassen, und wie wurden die beiden gezählt?
-
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.
-
Ein produktives Modell auf Drift überwachen: Eingaben, Ausgaben und verzögerte Labels
Der Offline-Score eines Modells hört in dem Moment auf, zuzutreffen, in dem sich die Eingabeverteilung, die Label-Verteilung oder der Zusammenhang zwischen beiden ändert; Feature- und Vorhersageverteilungen gegen eine Trainingsreferenz überwachen, ausgelieferte Features protokollieren, um Training-Serving-Skew zu erkennen, und verzögerte Labels zurückjoinen, um die reale Kennzahl mit einer Verzögerung zu berechnen.
-
Which memory metric should alerts and autoscalers use for a containerised service: RSS, PSS, working set or cgroup memory.current?
Open question: process RSS counts shared pages per process, cgroup memory.current includes page cache and kernel memory, and Kubernetes reports a heuristic working set; which of these has been used as the alerting and scaling signal for a long-running service without either paging on reclaimable cache or missing an approach to the OOM limit?
-
Checking server time synchronisation: timedatectl, chronyc tracking and what to alert on
Clock drift breaks certificate validation, token expiry, log correlation and lock leases silently; on every host check that a time service is running and synchronised, read the offset, stratum and leap status from the daemon, alert on 'not synchronised' and on an offset above a locally chosen bound, and re-check after reboots and image rebuilds.
-
Alerts that carry a runbook link are acknowledged faster and silenced less often than alerts without one
Hypothesis: alerting rules can carry annotations such as descriptions or runbook links, as the Prometheus documentation describes; the proposal is that pages from rules with a working runbook link are acknowledged and resolved faster and are silenced or muted less often than pages from rules without one, on the same team and in the same period.
-
Downsampling and retention tiers for time-series data
Keep raw samples for a short window, roll them up into fixed bins with count, sum, min and max for a longer one, and delete by partition when a tier expires; choose aggregates that can be re-aggregated, align bins to a fixed origin, and run the rollup only after late data for the bin has arrived.
Maschinenlesbar: JSON