Das Problem mit reaktivem Monitoring
Klassisches Monitoring arbeitet mit Schwellenwerten: CPU über 90 %, Festplatte über 85 %, Warteschlange über 1.000 Einträge. Diese Alarme sind nützlich — aber sie lösen aus, wenn der Schaden bereits eingetreten ist. Wenn das Dashboard rot wird, laufen Transaktionen bereits in Timeouts und das Support-Telefon klingelt.
Schlimmer noch: Generische Tools decken nur generische Kennzahlen ab. Sie sehen, dass ein Java-Prozess Speicher verbraucht — nicht, dass ein bestimmter Batch-Job in Ihrem ERP viermal so viele Datensätze in die Warteschlange stellt wie im selben Zeitfenster am vergangenen Dienstag. Genau in dieser Sichtbarkeitslücke entstehen Produktionsvorfälle.
Was proaktives Monitoring wirklich bedeutet
Proaktives Monitoring verschiebt die Frage von "liegt diese Kennzahl über der Grenze?" zu "verhält sich dieses System wie es selbst?". Die Plattform, die wir für unsere Managed-Services-Kunden betreiben, basiert auf vier Grundideen:
Musterbasierte Verhaltenserkennung
Jedes überwachte Asset hat eine gelernte Baseline. Alarme werden ausgelöst, wenn das Verhalten vom Muster abweicht — nicht erst, wenn ein willkürlicher Schwellenwert überschritten wird. So werden Speicherlecks, langsame Festplatten und schleichend schlechtere Abfragepläne erkannt, bevor jemand einen Anruf bekommt.
5 Jahre Historie
Eine lange Aufbewahrungsdauer erlaubt den Vergleich der heutigen Last mit derselben Woche im letzten Quartal oder Jahr. Kapazitätsplanung und Anomalie-Bewertung sind damit keine Vermutung mehr.
Hunderte individuelle Plugins
Standard-Monitoring endet bei den offensichtlichen Kennzahlen. Über die Jahre haben wir Hunderte Plugins und Connectoren für proprietäre Datenbanken, Legacy-Middleware, Nischen-Storage-Arrays und kundenspezifische Geschäftsprozesse gebaut.
Alarm-Routing, das den Vertrag respektiert
Jeder Alarm ist an eine Benachrichtigungsregel und ein Vertragsmodell gebunden — die richtige Person, der richtige Kanal, der richtige Schweregrad, mit Unterdrückung für bekannte Wartungsfenster.
Was wir überwachen
Kunden starten meist mit ein paar offensichtlichen Assets — einer Produktionsdatenbank, einer kritischen API — und bauen die Abdeckung von dort aus. Heute überwacht dieselbe Plattform alles von Bare-Metal-Storage bis zu SaaS-ERPs mit einem einheitlichen Alarmierungsmodell.
| Ebene | Was wir abdecken |
|---|---|
| Server & Betriebssystem | Linux, Windows, AIX, Solaris — CPU, Arbeitsspeicher, Prozesse, Kernel-Ereignisse |
| Datenbanken | Oracle, PostgreSQL, SQL Server, MySQL, MongoDB — Sessions, Locks, Tablespaces, langsame Abfragen |
| Middleware | WebLogic, Tomcat, JBoss, IIS, Kafka, RabbitMQ — JVM, Queues, Threads |
| Storage & Backup | SAN/NAS-Arrays, Snapshot-Status, Einhaltung von Backup-Fenstern, Restore-Tests |
| Netzwerk | Firewalls, Switches, Load Balancer, VPN-Tunnel, Latenz und Paketverlust |
| Cloud & SaaS | AWS, Azure, OCI, Microsoft 365, NetSuite — Kontingente, Abrechnungsanomalien, API-Verfügbarkeit |
| Business-APIs | Individuelle REST/SOAP-Endpunkte, Antwortzeiten, Fehlerbudgets, Vertragsabweichungen |
| ERP & Business-Anwendungen | NetSuite, Oracle Fusion, SAP — Batch-Jobs, Integrationen, transaktionale KPIs |
Die Plugin-Schicht ist der eigentliche Vorteil
Die Basisplattform ist Enterprise-tauglich und gut dokumentiert. Der Grund, warum Kunden bleiben, ist die darauf aufgebaute Plugin- und Connector-Bibliothek: Hunderte Sonden für Systeme, die kein kommerzieller Agent von Haus aus unterstützt.
- Legacy-Datenbanken und -Middleware — Agenten für alte Oracle-E-Business-Module, Mainframe-Gateways und individuelle Java-Stacks, die weiterhin das Geschäft am Laufen halten.
- Business-Process-Monitore — synthetische Checks, die eine reale Nutzerreise simulieren (Login, Bestellung aufgeben, Rechnung buchen) und bei funktionalen Regressionen alarmieren, nicht nur bei Infrastrukturproblemen.
- ERP- und Finance-Sonden — NetSuite-Saved-Search-Watcher, Integrationsstatus von Oracle Fusion, SAP-IDoc-Rückstands-Checks.
- Branchenspezifische Connectoren — Status von Payment-Switches für Fintech-Kunden, RPA-Bot-Status für Shared-Service-Center, IoT-Telemetrie für Facility-Management.
Vom Alarm zum Ergebnis
Erkennung ist nur die halbe Miete. Jeder Alarm landet in einem definierten Reaktions-Workflow:
- Angereichertes Ereignis — Alarme kommen mit Asset, Verantwortlichem, letztem ähnlichem Vorfall und angehängtem Runbook an.
- Routing nach Vertrag — unterschiedliche Kunden haben unterschiedliche Eskalationspfade, Bereitschaftspläne und Schweregrad-Definitionen. Die Plattform respektiert das.
- Automatische Behebung, wo sicher möglich — einen hängenden Dienst neu starten, Tablespace freigeben, ein Log rotieren, eine ausufernde Session beenden — alles protokolliert, alles rückgängig machbar.
- Trendbelege bei jedem Ticket — wenn ein Ingenieur einen Vorfall öffnet, erhält er die letzten 12 Monate derselben Kennzahl, nicht nur den Ausschlag.
Was sich für das Unternehmen ändert
- Ausfälle werden im Vorstadium erkannt, nicht erst in der Nachbetrachtung.
- Weniger Gespräche der Art "warum haben wir das nicht kommen sehen?" nach Vorfällen.
- Kapazitätsentscheidungen basierend auf fünf Jahren Verhaltensdaten, nicht auf Hersteller-Heuristiken.
- Ein Alarmierungsmodell über Cloud, On-Premise, SaaS und individuelle Anwendungen hinweg.
- Auditfähige Nachweise für ISO 27001 und SOC-ähnliche Kontrollen.
Wie Sie starten
Typischerweise führen wir eine zweiwöchige Discovery-Phase durch: Bestandsaufnahme der Systemlandschaft, Identifikation der zehn wichtigsten Ausfallmuster, die das aktuelle Tooling übersieht, und Aufbau des Monitorings dafür. Wenn ein System nicht durch ein vorhandenes Plugin abgedeckt ist, bauen wir eines — so ist die Bibliothek auf ihre heutige Größe gewachsen.
Wenn Sie es leid sind, von Vorfällen erst durch Ihre Nutzer zu erfahren, ist das genau das Gespräch, das wir führen sollten.