Monitoring

Was diese Kategorie abdeckt

Wissen, dass etwas kaputt ist, bevor es Ihnen ein Kunde erklärt: Verfügbarkeitsprüfungen, Fehlerverfolgung, Metriken, Logs, Traces und die Alarmierung, die jemanden weckt.

Die Produkte reichen von einer einzelnen Prüfung, die eine URL anpingt, bis zu Plattformen, die alles aufnehmen, was eine Infrastruktur ausgibt. Die Lücke dazwischen besteht vor allem aus Datenmenge und Preis.

Das Verhalten von Kunden zu analysieren gehört zu Analytics. Wo die Anwendung läuft, behandelt Hosting und Cloud.

Von außen beginnen

Der nützlichste erste Kauf ist der einfachste: eine Prüfung, die Ihre Website von mehreren Orten lädt und meldet, wenn sie nicht mehr funktioniert.

Externe Prüfungen fangen die Ausfälle ab, die interne Dashboards übersehen, darunter abgelaufene Zertifikate, kaputte Einträge und eine Firewall-Änderung, die niemand angekündigt hat. Sie sind günstig und decken für viele kleine Teams das meiste ab, worauf es ankommt.

Die Fehlerverfolgung kommt an zweiter Stelle. Zu wissen, welche Ausnahmen echte Nutzer erreichen, wie oft und seit welchem Release, macht aus einer vagen Meldung eine Korrektur. Die Qualität der Gruppierung unterscheidet hier die Produkte, denn ein Tool, das viertausend fast identische Alarme erzeugt, erzeugt Rauschen.

Die vier Arten von Daten

• Verfügbarkeitsprüfungen, von außen, auf den Pfaden, die Kunden tatsächlich nutzen.
• Fehler, gruppiert, mit Release und Nutzerkontext.
• Metriken, numerisch und günstig aufzubewahren, für Trends und Schwellenwerte.
• Logs, detailliert und teuer, um zu rekonstruieren, was passiert ist.
• Traces, die eine Anfrage über Dienste hinweg zeigen, um zu finden, wo die Zeit bleibt.

Die meisten Teams brauchen die ersten beiden sofort, Metriken bald danach und den Rest, wenn ein System so komplex ist, dass Raten nicht mehr funktioniert.

Die Aufbewahrung ist die stille Einschränkung. Den heutigen Tag mit demselben Tag des Vormonats zu vergleichen braucht einen Monat an Daten, und Einstiegstarife behalten häufig eine Woche.

Alarmierung ist ein Designproblem

Ein Alarm, auf den niemand reagiert, erzieht alle dazu, den nächsten zu ignorieren, und mit dieser Gewohnheit werden Ausfälle länger.

Alarmieren Sie bei dem, was Nutzer erleben, statt bei jedem internen Schwellenwert. Eine langsam ladende Seite zählt. Ein Prozessor bei achtzig Prozent allein meist nicht.

Jeder Alarm braucht drei Dinge: einen Verantwortlichen, eine dokumentierte Maßnahme und einen Weg, der den Verantwortlichen erreicht, wenn er schläft. Was diesen Test nicht besteht, sollte ein Dashboard-Eintrag sein, keine Benachrichtigung.

Prüfen Sie dann regelmäßig. Alarme sammeln sich an, Bedingungen ändern sich, und eine vierteljährliche Ausmistung ist die günstigste Zuverlässigkeitsarbeit, die es gibt.

Kosten, und warum Rechnungen ohne Vorwarnung wachsen

Die Preise richten sich nach Host, Nutzer, aufgenommenem Volumen oder Ereignissen, und im Volumenmodell liegen die Überraschungen.

Ein einzelner Dienst, der ausführlich loggt, kann die Rechnung vervielfachen, während Ihr Verkehr gleich bleibt. Sampling, Filterung an der Quelle und kürzere Aufbewahrung für Detaildaten sind die üblichen Stellschrauben, fragen Sie also, was das Produkt bietet, bevor Sie sie brauchen.

Benutzerdefinierte Metriken verdienen eine eigene Frage, da sie häufig pro eindeutiger Zeitreihe berechnet werden und ein schlecht gewähltes Label Tausende davon erzeugen kann. Verlangen Sie eine Ausgabengrenze statt eines Alarms und schauen Sie in was Preisseiten verschweigen für den Rest des Musters.

Selbst betreiben

Offene Implementierungen sind leistungsfähig und lizenzfrei. Der Betriebsaufwand ist real: Speicher, Aufbewahrung, Updates und jemand in Bereitschaft für das Monitoring-System selbst.

Dieser letzte Punkt ist der, den man abwägen sollte. Ein selbst gehosteter Stack fällt tendenziell im selben Vorfall aus wie das, was er beobachten sollte, und genau dann braucht man ihn am meisten.

Klein anfangen, ohne sich festzulegen

Ein erstes Monitoring-Setup sollte langweilig sein und an einem Nachmittag fertig.

Zwei externe Prüfungen auf den Pfaden, die zählen, die in die Anwendung eingebundene Fehlerverfolgung und ein Alarmweg, der einen Menschen erreicht. Das deckt die Mehrheit der Vorfälle ab, die ein kleines Produkt in seinem ersten Jahr haben wird.

Ergänzen Sie Metriken, wenn Sie anfangen zu fragen, warum etwas langsam war, statt ob es kaputt war. Ergänzen Sie Traces, wenn das System genug bewegliche Teile hat, dass die Antwort aus einem Log nicht mehr offensichtlich ist.

Die eine Entscheidung, die früh zu treffen sich lohnt, ist, wo Daten erfasst werden und in welchem Format. Instrumentierung nach einem offenen Standard lässt sich später auf ein anderes Backend richten, während Instrumentierung gegen die Bibliothek eines Anbieters zum Argument gegen jeden Wechsel wird.

Führen Sie schriftlich Buch darüber, was jeder Alarm bedeutet und wer reagiert. Diese Seite ist um drei Uhr nachts mehr wert als jedes Dashboard.