Bereits seit der CONZEPT 16-Server-Version 1.8 ist es möglich, zeitnah über auftretende Fehler per E-Mail informiert zu werden. Damit nach Erhalt einer “Alert-Mail” die richtigen Maßnahmen getroffen werden können, sind einige Punkte zu beachten. In diesem Artikel möchte ich einige Fragestellungen aufgreifen, die in diesem Zusammenhang eine Rolle spielen.
In welchen Fällen wird eine Alert-Mail versendet
Allgemein sprechen wir davon, dass im Fehlerfall ein Mail versendet wird. Aber was bedeutet das konkret?
Ausschlaggebend für den Versand sind bestimmte Einträge, die in Protokolldateien je nach Ereignis vorgenommen werden. Jeder Protokolleintrag ist einer Klasse von Meldungen zugeordnet. Aktuell existieren davon vier, wobei zwei Klassen zum Auslösen einer Alert-Mail führen. Dabei handelt es sich zum einen um die Klasse der “Warnungen” und zum anderen um die der “Fehler“. Bei den Einträgen der Klasse “Information” und “Debug” wird keine E-Mail erzeugt.
Beim Betrachten einer Protokolldatei mit Hilfe des Log-Viewers wird über das Symbol in der Spalte “Typ” die jeweilige Klasse visualisiert.
Anzeige von Warnungen und FehlerWelche Informationen liefert die Alert-Mail
Die nächste Fragestellung beschäftigt sich mit den Informationen, die einer Alert-Mail entnommen werden können. Hierzu werfen wir einen Blick auf den Aufbau einer solchen E-Mail. Die Betreff-Zeile der E-Mail setzt sich aus folgenden Angaben zusammen:
- CONZEPT 16-Komponente, welche die E-Mail versendet hat
- Versionsnummer der Komponente
- Name des Server-Prozesses, Alias-Name der Datenbank oder Name des SOA-Tasks
Beispiel:
CONZEPT 16 Server alert [5.7.03: manager process]
CONZEPT 16 Server alert [5.7.03: MyDatabase]
CONZEPT 16 SOA Service alert [5.7.03: MySoaTask]]
Aktuell können wir vom CONZEPT 16-Server und vom SOA-Service eine E-Mail erhalten.
Ist ein Protokoll-Eintrag der Auslöser, besteht der Inhalt der Mail aus einer chronologischen Auflistung der Einträge der jeweiligen Protokolldatei, wobei ausschließlich Einträge der Klasse “Wanung” und “Fehler” berücksichtigt werden.
Beispiel:
2013-07-01 09:03:00 – E data Database open failed (Access denied)
2013-07-01 09:13:41 – w data Transaction Rollback started (area not closed)
2013-07-01 09:13:41 – w data 64 KB restored from transaction log file TL2 (first: 2013-07-01 09:12 last: 2013-07-01 09:12)
2013-07-01 09:13:41 – w data Transaction Rollback finished
Falls die automatischen Diagnose einen Fehler feststellt, besteht die E-Mail lediglich aus dem Diagnoseresultat, welches als Anhang der Mail beigefügt ist. Im Betreff wird darauf hingewiesen, dass Datenbankdefekte erkannt wurden.
Beispiel:
CONZEPT 16 Server alert [5.7.03: MyDatabase: The database check-up detected errors. The result file is attached].
Was ist zu beachten
Die Aufgabe der E-Mail-Benachrichtigung besteht darin, zeitnah über auftretende Probleme zu informieren. Von daher ist es wichtig, dass möglichst mehrere Personen in den Verteiler aufgenommen werden. Zusätzlich ist organisatorisch festzulegen, wer nach Erhalt einer E-Mail aktiv wird.
Neben der Auswertung der Alert-Mail ist eine Analyse der Protokolldateien absolut notwendig. Nur so lassen sich die richtigen Maßnahmen einleiten.
Ein weiterer wesentlicher Punkt ist die Definition der Absenderadresse der E-Mail. Anhand der Absenderadresse sollte der Anwender und der Rechner, auf dem der CONZEPT 16-Server oder SOA-Service eingesetzt wird, eindeutig identifiziert werden können. Bei der Wahl der Absenderadresse ist zu berücksichtigen, dass diese vom Mail-Server akzeptiert wird.
Ob eine Alert-Mail auch erfolgreich versendet werden kann, lässt sich am einfachsten über eine Testfunktion des CONZEPT 16-Servers überprüfen. Der Test der Alert-Mail wird über die Web-Administration auf der Seite “Konfiguration“, oder alternativ über das Control-Center auf der Seite “Server“, jeweils über den Button “Mail-Test” gestartet. Als Folge wird der Eintrag “Alert mail test” mit der Klasse “Warnung” in das Protokoll des Manager-Prozesses eingetragen.
Eine Antwort
Lassen sich in solchen Fällen weitergehende Informationen ermitteln/speichern ?
Inbesondere bei "Invalid tree root (tree 65400)", kann Ich zwar über die Logdatei ermitteln, welcher User aus der Datenbank geflogen ist, aber nicht z.B. an welcher Stelle.
Und eine Befragung der User (selbst intern) ist meist erfolglos.