Die wichtigste Frage im Betrieb ist banal: Was tut das System gerade – und woran merken Sie, wenn etwas nicht stimmt?
Dafür braucht es kein SRE-Team und keine APM-Suite, sondern die richtigen Signale am richtigen Ort: Logs, die man lesen kann, Health Checks, die Wahrheit sagen, und Alarme, die nur klingeln, wenn jemand handeln muss. Ausgebaut wird, wenn das System es rechtfertigt.
Das Fundament: Logs mit Kontext (wer, was, welcher Vorgang), sinnvolle Log-Level und eine Korrelations-ID, die einen Request durch alle Schichten verfolgbar macht. Ein gutes Log ersetzt in kleinen Systemen mehr Tooling, als man denkt – ein schlechtes macht jedes Tooling wertlos.
Nicht nur "Prozess läuft", sondern: Erreicht die Anwendung ihre Datenbank, ihre Schnittstellen, ihren Speicher? Aussagekräftige Health-Endpoints sind die Basis für Deployment-Checks, Container-Orchestrierung und externe Überwachung – und in einer Stunde eingebaut, wenn man weiß, was hinein gehört.
Wenige Kennzahlen, die etwas bedeuten: Fehlerrate, Antwortzeiten, Warteschlangen, Plattenplatz, fachliche Durchsätze ("wie viele Dokumente wurden heute verarbeitet?"). Fachliche Metriken verraten oft früher, dass etwas klemmt, als technische – deshalb gehören beide auf dieselbe Übersicht.
Der häufigste Fehler ist nicht zu wenig Alerting, sondern zu viel: Wer täglich zwanzig belanglose Mails bekommt, übersieht die eine wichtige. Ich richte wenige, klare Alarme ein – jeder mit einer Antwort auf die Frage "was ist jetzt zu tun?" – und lösche den Rest.
Ein Backup, das niemand überwacht, ist eine Hoffnung, kein Backup. Dazu gehören: Meldung, wenn ein Backup ausbleibt (nicht nur, wenn es fehlschlägt), Alters- und Größenprüfung der Sicherungen und regelmäßig geprobte Wiederherstellung. Der Ernstfall ist der falsche Zeitpunkt, das zum ersten Mal zu testen.
Wenn etwas passiert ist: vom Symptom systematisch zur Ursache – Logs korrelieren, Zeitpunkte mit Deployments und Datenständen abgleichen, den Fehler reproduzierbar machen. Und danach die Lücke schließen, damit dieselbe Frage beim nächsten Mal in Minuten statt Stunden beantwortet ist.
Prometheus, Grafana, Distributed Tracing, SLOs mit Error Budgets – all das existiert, und all das hat seinen Platz. Aber: für die meisten Mittelstandssysteme ist das nicht der Anfang, sondern eine spätere Ausbaustufe.
Und eine ehrliche Grenze: Ich bin Architekt und Entwickler, kein 24/7-Bereitschaftsdienst. Ich baue Monitoring so auf, dass Ihr Betrieb damit arbeiten kann – und stehe für Analyse und Weiterentwicklung zur Verfügung, nicht als ständige Rufbereitschaft.
Monitoring entsteht bei mir nicht isoliert, sondern zusammen mit Deployment und CI/CD – wer automatisiert ausliefert, muss automatisiert hinschauen.
Wenn Ihr System gerade akut Probleme macht und Sie nicht wissen warum, ist der passende Einstieg die Stabilisierung – Monitoring ist dort Mittel zum Zweck, nicht Selbstzweck.
Wenn die Antwort "nicht immer" lautet, lohnt sich ein Gespräch über die
richtigen Signale –
unverbindlich, 30 Minuten, kostenfrei.