IP-Symcon: Monitoring Kernkomponenten (Settings & logging.db)

Eines gleich vorweg: ich hatte das Problem vielleicht 3-5 Mal in den verg. 2 Jahren (Dauerbetrieb). Und soweit ich mich erinnere, immer nur während der Beta-Testphasen. Allerdings berichten im Forum einige User davon, dass ihnen sowas ständig passiert. Und wenn – dann kann die Arbeit von mehreren Stunden im Eimer sein.

Wo liegt eigentlich das Problem?

IP-Symcon hat 2 dynamische Kernkomponenten auf Dateisystem-Ebene, die ständig aktualisiert werden (müssen):

• Settings: in ihr wird der gesamte Objektbaum (incl. aller Meta-Informationen, die zu einem Objekt gehören) abgespeichert
• logging.db: in ihr werden alle  Istwerte abgelegt, die langfristig gespeichert werden sollen (Variablenwerte)

Normalerweise wird die logging.db alle 60 sec aktualisiert (d.h. es erfolgt ein schreibender Zugriff auf das file „logging.db“). Alle Daten, die innerhalb dieses Zyklusses von 60 sec anfallen, werden im File „logging.db-journal“ zwischengespeichert und anschließend in die „logging.db“ transferiert. Darum braucht man sich nicht kümmern. Normalerweise. Fast genau so verhält es sich mit der  settings-Datei (je nach IPS-Version ist das die „settings.xml“ oder die „settings.json“). Nur dass es hier kein „-journal“-File als temporäres File daziwschen gibt. Weiterhin wird die settings nur alle 10 Minuten geschrieben (Default-Einstellung, kann vom User angepasst werden).

Nun  kann man sich leicht vorstellen, dass es sehr ärgerlich ist, wenn man stunden- oder tagelang am System rumgeschraubt hat, neue Objekte angelegt und konfiguriert hat, sich freut – dass alles perfekt läuft, das IP-Symcon neu startet und feststellen muss, dass alle Änderungen nicht mehr vorhanden sind.

Was ist in einem solchen Fall passiert?

Es kommt manchmal vor (wie gesagt: selten), dass IPS die settings oder die DB nicht mehr aktualisiert. Als Anwender merkt man davon nichts (das ist ja das Schlimme). Startet man IP-Symcon neu, wird logischerweise die (veraltete) settings geladen ( in der ja alle Infos stehen, wie der Objektbaum auszusehen hat. Und das Staunen (und nach Milisekunden der Ärger) wird groß, wenn IPS mit dem Stand von …vor 3 Tagen (?) startet.

Die Folge ist,

dass man wohl oder übel (und aus dem Gedächtnis -sofern vorhanden) die Objekte im Objektbaum erneut anlegen, konfigurieren und miteinander verknüpfen muss. Alle Scripte, die in der Zeit angelegt wurden, sind davon unberührt und existieren noch auf der Ebene des Dateisystems. Nur dass IPS sie nicht kennt (die Scripte müssen im Objektbaum ebenfalls neu angelegt werden). Eben ne Menge Arbeit.

Passiert Ähnliches mit der logging.db sind die Auswirkungen nicht ganz so fatal: „nur“ die in der Zwischenzeit erhobenen Daten sind unter Umständen verloren.  Wenn man Glück hat, befinden sich die Daten noch im „-journal“-File und werden vom System beim bächsten Start eingesaugt und in die „logging.db“ transferiert. Man merkt das daran, dass a) sich dieses „-journal“-File aufbläht wie ein Kugelfisch (es wird einige 100kb- einige -zig MB groß, je nach Laufzeit) und b) IPS deutlich länger zum Starten braucht.

Was kann man dagegen tun?

Wenn es erst einmal passiert ist: nicht mehr viel. Man sollte versuchen, IPS so schnell wie möglich zu beenden (im Notfall den Task via Taskmanager abschießen) und neu startet. Je eher man das tut, desto geringer die Schäden.

Und hier kommt das IPS-Monitoring ins Spiel:

Man kann natürlich beide Dateien auf Aktualität überwachen lassen und sich im Ernstfall informieren lassen. Automatisierte Gegenmaßnahmen (z.B. automatisierter Neustart von IPS)  sind m.E. nicht zu empfehlen. Bleibt das System beim Neustart hängen (weil meistens klemmt es ja im Fehlerfall an mehreren Stellen), ist der entstehende Schaden evtl. noch größer.

Ich habe mir daher Mitte 2011  2 Scripte gebaut, die die beiden Files auf Aktualität überwachen, den Status im WFE anzeigen und im Fehlerfall Alarm schlagen. Alarm heisst in diesem Fall: Warnmails versenden.

Seit Mitte diesen Jahres lasse ich die beiden Files von PRTG Network Manager überwachen. PRTG schickt mir im Fehlerfall Mails, für Logging- und Visualisierungszwecke importiere ich mir die Daten (und nicht nur die) aus PRTG ins IPS nach Werners (IPS-Forum: wgreipl) Script: klick.

Aus technischen Gründen ist das Monitoring von außen dem internen aus IPS vorzuziehen, aber nicht jeder will/kann PRTG auf seinem System haben und konfigurieren. Für den Fall kann einem hier geholfen werden:

IPS Logging&Settings-Monitoring

Das Script ist eine eiligst zusammengedengelte plug-and-play-Lösung für Leute, die es ganz schnell machen wollen: Script im Anhang downloaden, in IPS importieren (einfach in ein neu angelegtes, leeres Script einkopieren) und einmalig per Hand starten. Anschließend noch 1-7 Konfigurationsangaben machen (mindestens 1, der Rest ist fakultativ) ==> feddich! Optional kann man noch das übergeordnete Dummy-Modul ins WFE verlinken (muss manuell erfolgen). 

Vielleicht will noch jemand die Funktionen des Scripts vorher kennenlernen (wird aber meistens überbewertet):

Funktionalität: 

wird bei einer der beiden Dateien festgestellt, dass das Alter den eingestellten Schwellwert überschreitet, werden folgende Warmeldungen generiert:

1. Erst-Warnung: Meldungsfenster IPS/ IPS-Logfile
2. Erst-Warnung: IPS-Logger (wenn vorhanden)
3. Erst-Warnung: Mailversand

weitere Warnmeldungen werden generiert:

1. Folge-Warnung: Meldungsfenster IPS/ IPS-Logfile (bei jedem Scriptdurchlauf)
2. Folge-Warnung: IPS-Logger (wenn vorhanden bei jedem Scriptdurchlauf)
3. Folge-Warnung: Mailversand (wenn Mailintervall überschritten)

werden die Warnschwellwerte wieder unterschritten, werden folgende Meldungen generiert:

1. Warnung aufgehoben: Meldungsfenster IPS/ IPS-Logfile
2. Warnung aufgehoben: IPS-Logger (wenn vorhanden)
3. Warnung aufgehoben: Mailversand