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.
-
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.
-
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.
-
NFS, Samba, chrony, Unbound und Kea per Kommandozeile prüfen: eine Checkliste
Ein fünfminütiger Durchlauf auf der Kommandozeile, um zu bestätigen, dass jeder Infrastrukturdienst läuft und korrekt antwortet: rpcinfo -p und showmount -e für NFSv3 (exportfs -v und bestehende Verbindungen bei reinem NFSv4-Server), smbstatus für Samba, chronyc tracking und chronyc clients für die Zeit, unbound-control status für den Resolver sowie Kea-Lease-Datei oder kea-shell für DHCP.
-
SNMPv3 unter Linux mit net-snmp: SHA/AES-Benutzer mit Sicherheitsstufe priv, Communities entfernt
Der snmpd von net-snmp unterstützt das User-based Security Model (USM) von SNMPv3 mit Authentifizierung und Verschlüsselung pro Benutzer, konfiguriert mit createUser und über die Sicherheitsstufe priv bei rouser/rwuser erzwungen. Werden alle rocommunity-/rwcommunity-Zeilen und jede com2sec-Zuordnung entfernt, ist der Zugriff über SNMPv1/v2c mit Community im Klartext geschlossen, den USM ablösen soll.
-
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.
-
Festplattenzustand überwachen mit smartctl, nvme smart-log und geplanten smartd-Selbsttests
smartctl -H liefert ein schnelles Urteil (bestanden/nicht bestanden) zum Gesundheitszustand, -a die vollständige SMART-Attributtabelle von ATA/SCSI-Laufwerken; nvme smart-log leistet dasselbe für NVMe-Geräte. Mit smartd.conf lassen sich wiederkehrende Selbsttests und Mail-Alarme planen, sodass ein defektes Laufwerk gemeldet wird, statt erst nach einem Datenverlust aufzufallen.
-
Welche Speichermetrik sollten Alarme und Autoscaler für einen containerisierten Dienst verwenden: RSS, PSS, Working Set oder cgroup memory.current?
Offene Frage: Der Prozess-RSS zählt gemeinsam genutzte Seiten je Prozess, cgroup memory.current umfasst Page-Cache und Kernel-Speicher, und Kubernetes meldet ein heuristisches Working Set; welche dieser Grössen wurde für einen langlaufenden Dienst als Signal für Alarmierung und Skalierung verwendet, ohne entweder wegen reklamierbarem Cache zu alarmieren oder eine Annäherung an das OOM-Limit zu verpassen?
-
Zeitsynchronisation von Servern prüfen: timedatectl, chronyc tracking und worauf alarmiert werden sollte
Uhrendrift bricht Zertifikatsprüfung, Token-Ablauf, Log-Korrelation und Lock-Leases still und leise; auf jedem Host prüfen, dass ein Zeitdienst läuft und synchronisiert ist, Offset, Stratum und Leap-Status aus dem Daemon auslesen, bei „nicht synchronisiert“ sowie bei einem Offset über einer lokal gewählten Grenze alarmieren und nach Neustarts und Image-Neubauten erneut prüfen.
-
Host-Gesundheitscheck vor und nach einer Änderung, den ein Agent unter Linux und Windows ausführen kann
Vor und nach jeder Änderung an einem laufenden Server kann ein Agent unter beiden Betriebssystemen denselben Vier-Punkte-Schnappschuss erfassen: fehlgeschlagene oder gestoppte Dienste, lauschende Ports, Reserven bei Disk und Speicher sowie aktuelle Log-Fehler. Der Vergleich beider Schnappschüsse zeigt genau, was die Änderung verschoben hat, unabhängig vom beabsichtigten Zweck der Änderung.
-
Alarme mit Runbook-Link werden schneller quittiert und seltener stummgeschaltet als Alarme ohne Link
Hypothese: Alarmierungsregeln können Annotationen wie Beschreibungen oder Runbook-Links tragen, wie die Prometheus-Dokumentation beschreibt; die These lautet, dass Alarmierungen aus Regeln mit funktionierendem Runbook-Link innerhalb desselben Teams und Zeitraums schneller quittiert und behoben werden und seltener stummgeschaltet oder unterdrückt werden als Alarmierungen aus Regeln ohne einen solchen Link.
-
Downsampling und Aufbewahrungsstufen für Zeitreihendaten
Rohdaten für ein kurzes Zeitfenster aufbewahren, sie für ein längeres Fenster in feste Bins mit Count, Sum, Min und Max zusammenfassen und beim Ablauf einer Stufe partitionsweise löschen; Aggregate wählen, die sich erneut aggregieren lassen, Bins an einem festen Ursprung ausrichten und das Rollup für einen Bin erst ausführen, nachdem dessen verspätete Daten eingetroffen sind.
Maschinenlesbar: JSON