Worauf alarmierst du in einer Cloud-Umgebung, und was loggst du nur?

Alarmier auf Symptome, die ein Kunde merken würde und bei denen ein Mensch jetzt sofort handeln kann, meist gekoppelt an deine Service-Ziele: erhöhte Fehlerraten, Latenz über dem Zielwert, eine unbegrenzt wachsende Queue, ein fehlgeschlagenes Backup. Alles andere loggst und dashboardest du, inklusive einzelner Ressourcenmetriken wie CPU, die zur Diagnose nützlich, als Auslöser aber schlecht sind. Wenn die Reaktion auf einen Alert ist, ihn wegzuklicken und weiterzuschlafen, gehört er ins Ticketsystem.

Meine Messlatte hat drei Punkte: ein Kunde ist betroffen oder gleich betroffen, es ist dringend, und es gibt etwas, das ein Mensch jetzt tun kann. Ist eines davon falsch, ist es ein Ticket oder ein Dashboard. Also Fehlerrate über dem Ziel, Latenz über dem Zielwert, eine unbegrenzt wachsende Queue, ein scheiternder Checkout, das pagt. CPU bei achtzig Prozent nicht, denn das kann völlig gesund sein und sagt mir nichts darüber, ob jemand leidet. Das gehört auf ein Dashboard für den Moment, in dem ich diagnostiziere. Auf Ursachen statt Symptome zu alarmieren ist der Weg zu vierzig Alerts für einen Incident und einem Team, das den Channel stummgeschaltet hat. Es gibt Ausnahmen, die ich immer behalte: Zertifikatsablauf, weil er verborgen bleibt, bis er katastrophal ist, fehlgeschlagene Backups, und harte Quota-Limits, auf die man zuläuft, denn alle drei sind still, bis sie dir die Woche ruinieren. Und ich prüfe Alerts regelmäßig, schaue mir an, was gefeuert hat und was jemand tatsächlich getan hat. Alles, was oft feuert und nie zu einer Handlung führt, wird gelöscht oder herabgestuft, denn ein lärmender Pager ist schlimmer als gar keiner.