Quelle: iStockphotos
Heute bin ich mit der Blogreihe „Systemautomation“ wieder zurück und stelle das erweiterte Monitoring vor.
Wie ich schon im 2. Teil „Systemautomation – Filteranalyse & Kriterien“ geschrieben habe, agiert die Systemautomation Message-getrieben. Meldungen werden analysiert und anhand definierter Kriterien wird dann darauf reagiert.
Was tun wir aber in dem Fall, wenn eine Ressource eigentlich verfügbar ist, aber trotzdem nicht ordentlich funktioniert? Primär wird durch die Systemautomation nur der Status der verwalteten Ressourcen evaluiert (z.B. startend, verfügbar, stoppend, unverfügbar, abgebrochen). Dies kann für einfache Anwendungen ausreichend sein. Sieht man sich jedoch komplexe Anwendungen wie Datenbank- oder Kommunikationssysteme an, die aus mehreren Teilkomponenten bestehen, wird schnell klar, dass die Sicherstellung der Verfügbarkeit nicht gleichbedeutend mit der Sicherstellung der Funktionalität ist.
Quelle: iStockphotos
Beispiele Verfügbarkeit ≠ Funktionalität
Der Status eines IMS -Datenbanksystems kann beispielsweise verfügbar sein, sind jedoch keine Datenbanken in dem IMS gestartet, können externe Anwendungen keine Datenbankzugriffe vornehmen.
Ein anderes Beipiel: Ist bei einem MQSeries (Message-Queue-Applikation) kein TCP/IP-Listener gestartet, können keine externen Anwendungen mit Hilfe von TCP/IP-Services Messages vom MQSeries holen oder dort einstellen.
Diesen „internen“ Status einer Anwendung bezeichnet die Systemautomation als deren Health State („Gesundheitszustand“).
Health State
Zur Feststellung eines Health State bedient sich die Systemautomation sogenannter „Monitoring Resources (MTRs)“, die logisch mit der Anwendung verknüpft werden. Je nach Anforderung und Notwendigkeit kann die MTR aktiv, passiv oder als eine Kombination aus beidem eingerichtet werden. Aktiv bedeutet, dass in regelmäßigen Intervallen eine Anwendungs-interne Abfrage durchgeführt und daraus der Health State ermittelt wird. Passiv wird auf bestimmte Messages reagiert und daraus der Health State ermittelt.
Wir benutzen diese MTRs für unser System-Heartbeating, aber auch sehr viel im Bereich der Überwachung von IMS-Konnektivität, MQSeries Queue-Schwellwerten und DB2-Transaktions-Schwellwerten sowie –Tablespace-Verfügbarkeit. Dadurch sind wir in der Lage, frühzeitig auf interne Fehler zu reagieren oder auch schleichende Verschlechterungen zu erkennen.
Quelle: iStockphotos
Externe Monitore
Ergänzt wird das Ganze durch die Anbindung externer Monitore. Externe Monitore sind spezialisierte Programme, die sehr tief in die zu überwachenden Anwendungen schauen und durch Kombination diverser Schwellwerte und Zustände ein sehr detailliertes Bild einer Anwendung oder eines Systems abgeben können. Bei Bedarf können die externen Monitore über definierte Schnittstellen mit der Systemautomation interagieren und so ebenfalls automatisierte Aktionen auslösen. Die Systemautomation kann ihrerseits wo notwendig Zustände an die externen Monitore weitergeben. Vor allem zur Ermittlung eventueller Fehlerzustände ist ein Zusammenspiel von externen Monitoren und der Systemautomation absolut notwendig.
Bei FI-TS haben wir einen umfangreichen Katalog an vorkonfigurierten Monitordefinitionen, die wir für unser eigenes Monitoring, aber auch auf Anforderung von Kunden, einsetzen können. Insgesamt können wir so ein recht engmaschiges Monitoring sicherstellen.
Im letzten, also 4. Teil zur Systemautomation im Februar werde ich noch kurz auf das Thema K-Fall-Handling und Datenkonsistenz eingehen. Ich freue mich auch auf Ihre Kommentare zum Thema.