SMS-Alarmierung für IT-Monitoring und Rechenzentrum
Das Monitoring erkennt den Ausfall in Sekunden, aber die Benachrichtigung nimmt denselben Weg wie die Störung: E-Mail über den betroffenen Mailserver, Push über die tote Internetleitung, Chat über das isolierte Netz. Der Alarm über den Ausfall bleibt in der ausgefallenen Infrastruktur stecken.
Im Rechenzentrum kommt die Zeitfrage dazu: Nach einem Klimaausfall bleiben je nach Raum nur Minuten bis zur thermischen Abschaltung, eine USV auf Batterie ist ein Countdown. Ein bekannter Praxisfall: Klimaausfall am Freitagabend, entdeckt am Montag, Serverraum bei 41 Grad.
Was auf dem Spiel steht
- Hardware-Schäden durch Übertemperatur nach Klimaausfall
- Datenverlust, wenn die USV leerläuft, bevor jemand reagiert
- SLA-Verletzungen und Ausfallzeiten, weil die Nacht verloren geht
- Wasserschaden unter dem Doppelboden, der stundenlang unbemerkt bleibt
So läuft die Alarmkette
- Schritt 1Meldung geht einDas Monitoring meldet an genau ein Ziel: das SMSEagle im eigenen Netz, per HTTP-API oder SNMP-Trap, ganz ohne Internetstrecke. Connect liest am Gateway mit und legt den Alarm an.
- Schritt 2Kette greiftPriorität critical löst die Kette Serverraum und RZ-Technik aus, der Dienstplan kennt die IT-Bereitschaft dieser Woche.
- Schritt 3SMS über MobilfunkDas SMSEagle sendet über die eigene SIM, unabhängig von Netzwerk, DNS und Internet. Delivery-Report inklusive.
- Schritt 4Auch wenn alles stehtIst Connect oder die Internetleitung nicht erreichbar, alarmiert das Gateway eigenständig nach lokalem Regelsatz an die Fallback-Bereitschaft. Ohne Quittierung eskaliert Stufe 2 per SMS und Sprachanruf.
So löst es smsreach
- Ein Ziel je Quelle: das Monitoring meldet nur ans Gateway im LAN, Connect liest dort mit und ergänzt Dienstplan, Eskalation und Protokoll
- Lokaler Regelsatz im SMSEagle: alarmiert auch bei Internet-, DNS- oder Plattformausfall weiter
- Deduplizierung: ein ausgefallener Core-Switch wird ein Alarm, nicht dreißig
- Temperatur- und Leckagesensorik im RZ als zweite, unabhängige Meldequelle
- Watchdog und Protokoll: verstummte Wege fallen auf, MTTA und Verläufe für Post-Mortems
Host down SRV-DB-02 um 23:40 Uhr: Das Kassensystem einer Filialkette hing, gemeldet hätte es sonst erst der Anruf einer Filiale am Morgen. So bekam die IT-Bereitschaft die SMS nach 20 Sekunden, quittierte per Antwort und hatte den Dienst nach 15 Minuten wieder oben.
Passende Integrationen
Häufige Fragen
Wir haben schon E-Mail- und Chat-Alarme. Warum noch SMS?
Weil beide an der Infrastruktur hängen, die das Monitoring überwacht. Die SMS über das eigene Gateway ist der Weg, der auch bei Internet-, DNS- und Mailserver-Ausfall funktioniert, und sie weckt nachts zuverlässiger als jede App mit Stummschaltung.
Wie schnell ist die Kette eingerichtet?
Die Anbindung des Monitorings ist ein Webhook oder eine Custom-URL, typisch 15 Minuten. Dienstplan, Ketten und Testalarm dazu, dann ist der erste produktive Tag realistisch.
Was passiert bei einem Alert-Sturm?
Ereignisregeln fassen gleiche Meldungen zu einem Alarm mit Zähler zusammen, ab einer Schwelle wird ein Sammelalarm daraus. Die Bereitschaft bekommt ein klares Signal statt Dauerfeuer.
Muss das Monitoring zwei Ziele pflegen?
Nein, genau eines: das SMSEagle im eigenen Netz. Connect beobachtet das Gateway über die Geräte-API, legt zu jedem Ereignis den Alarm an und übernimmt Dienstplan, Eskalation und Protokoll. Empfänger und Regeln werden nur in Connect gepflegt und automatisch aufs Gerät synchronisiert.
Weitere Lösungen
Erleben Sie die Alarmkette live.
In der Demo bekommen Sie einen echten Alarm auf Ihr Handy und quittieren ihn per SMS-Antwort, die Plattform zeigt die Quittierung in Echtzeit.