Monitoring für kleine Teams: Der langweilige Stack, den ihr wirklich lest
Unter ~10 Services reichen fünf Bausteine: ein externer Uptime-Check, Error-Tracking, das nur bei neuen Fehlern alarmiert, strukturierte Logs an einem durchsuchbaren Ort, ein Dashboard mit 4–6 Zahlen (Requests, Fehlerrate, p95, Queue-Tiefe, Disk) und ein Backup-Erfolgs-Check. Die Regel, die das Ganze trägt: Wenn ein Alert um 2 Uhr nachts nicht handelbar ist, ist er ein Report — ab in einen Channel, nicht auf den Pager.
Kleine Teams haben kein Observability-Problem. Sie haben ein Aufmerksamkeitsproblem — und die meisten Monitoring-Setups verschärfen es, weil sie mehr Signal produzieren, als je jemand liest.
Welches Monitoring braucht ein kleines Team wirklich?
| Baustein | Was es ist | Die Frage, die es beantwortet |
|---|---|---|
| Uptime-Check | Externe Probe von außerhalb eurer Infrastruktur | Ist es für echte Nutzer erreichbar? |
| Error-Tracking | Alerts nur bei neuen Fehlern | Hat das letzte Deploy etwas kaputt gemacht? |
| Strukturierte Logs | Ein durchsuchbarer Ort, vernünftige Retention | Was genau ist um 14:32 passiert? |
| Ein Dashboard | 4–6 Zahlen: Requests, Fehlerrate, p95, Queue-Tiefe, Disk | Ist heute normal? |
| Backup-Check | Alarm, wenn ein Backup fehlschlägt oder ausfällt | Funktioniert der Restore im Ernstfall? |
Ein Punkt ist nicht verhandelbar: Der Uptime-Check muss außerhalb eurer Infrastruktur leben. Ein Monitor, der mit dem Server stirbt, den er überwacht, ist Dekoration.
Jeder Alert muss um 2 Uhr nachts handelbar sein
Der Test für jeden Alert: Wollt ihr dafür geweckt werden — und könnt ihr jetzt sofort etwas tun? Ist eine Antwort Nein, ist es ein Report, kein Alert. Der gehört in einen Channel, den ihr beim Frühstück lest.
Das ist keine Komfortfrage. Alert-Müdigkeit ist der Mechanismus, durch den echte Ausfälle übersehen werden: Nach dem vierzigsten Fehlalarm wird der einundvierzigste Page ungelesen weggewischt. In unseren Audits verbessert das Streichen von 80 % der Alerts die Incident-Reaktion durchweg — weil die verbleibenden Pages etwas bedeuten.
Alerts auf neue Fehler verdienen besonderen Nachdruck. Wer auf die Anzahl der Fehler alarmiert, wird bei jedem Traffic-Peak geweckt; wer auf neuartige Fehler alarmiert, wird geweckt, wenn ein Deploy etwas bricht. Ihr wollt das Zweite.
Das 15-Minuten-Ritual pro Woche
Monitoring, das niemand anschaut, ist Write-only-Speicher. Unsere Lösung ist bewusst langweilig: 15 Minuten, einmal pro Woche, das ganze Team schaut gemeinsam auf das eine Dashboard. Kriecht p95 nach oben? Läuft die Disk voll? Leert sich die Queue langsamer als letzten Monat? Schleichende Probleme werden in diesem Termin gefangen; der Pager muss nur die akuten abdecken.
Was ihr unter ~10 Services weglasst
Distributed Tracing, eigene Metrik-Plattformen und alles, was eine Stellenanzeige „Observability-Stack" nennen würde. Diese Werkzeuge lösen Koordinationsprobleme zwischen vielen Teams und vielen Services. Mit einer App und einer Handvoll Services liefern Request-IDs in euren strukturierten Logs 90 % des Tracing-Nutzens — ohne dessen Pflegeaufwand. Die Essentials oben laufen problemlos auf demselben Host wie eure App, dort, wo auch euer Compose-Produktions-Setup lebt.
Genau diesen Stack — Checks, Alerts, Dashboard, Backup-Verifizierung — richten wir in wenigen Tagen ein, als Teil unserer Cloud & DevOps Projekte.
Olio auf LinkedIn
