Monitoring
MailStore verfügt selber nur über eingeschränkte Benachrichtigungs- oder Monitoringfunktionalitäten. Mittels externer Komponenten kann jedoch zum Beispiel der Status der Archivierungsdurchläufe überwacht werden.
Einsatz einer externen Monitoring-Software
MailStore Nagios/Icinga Plugin
Im Scripting-Paket befindet sich das Plugin check_mailstore.py. Das Plugin prüft die Anzahl der Jobs oder die Anzahl der archivierten E-Mails in einem gewissen Zeitraum.
Das Verzeichnis mailstoreapi aus dem Paket gehört in das site-packages Verzeichnis Ihrer Python Installation. Dieses kann mittels
python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
ausgegeben werden.
Das Plugin kommuniziert mit der MailStore Administration API. Diese muss folglich aktiviert sein.
Ein Check der die erfolgreiche Ausführung von Profilen überwacht, könnte folgendermaßen definiert sein:
define command { command_name check_mailstore command_line /usr/local/lib/nagios/plugins/check_mailstore.py --host $ARG1$ --password $ARG2$ -s since:$ARG3$ --status $ARG4$ -c $ARG5$ -w $ARG6$ --search $ARG7$ }
Die passende Service-Definition könnte so aussehen:
define service { host_name mailstoreserver service_description MailStore Succeeded Jobs check_command check_mailstore!mailstoreserver!sUp3rs3CcR6ET3!1H!succeeded!8!10!jobs use generic-service }
In diesem Beispiel wird überprüft, ob in der letzten Stunde (-s since:1H) mehr als 10 Jobs erfolgreich (--status succeeded) ausgeführt wurden.
Das Plugin unterstützt folgende Parameter
--help|--h
Zeigt die Hilfeseite
--host HOST
Hostname oder IP-Adresse des MailStore Servers. Standardmäßig wird localhost verwendet
--port PORT
TCP Port auf welchem die MailStore Administration API Verbindungen annimmt. Standardmäßig wird 8463 verwendet.
--userName USERNAME
Benutzernamen zur Anmeldung am MailStore Server. Dieser muss ein MailStore Administrator sein. Standardmäßig wird admin verwendet.
--password PASSWORD
Passwort des Benutzers, welcher bei userName angegeben wurde.
--start STARTTIME|--s STARTTIME
Gibt die Startzeit des Betrachtungszeitraums an. Die Startzeit im Format YYYY-mm-ddTHH:MM:SS (z.B. 2013-01-01T00:00:00) gibt die Anfangszeit des zu betrachtenden Zeitraums an. Es muss zusätzlich der --end Parameter verwendet werden. Alternativ kann ein Zeitraum in der Form since:XY angegeben werden, wobei X eine Zahl und Y einer der folgenden Buchstaben ist: Y (Jahr), m (Monat), d (Tag), H (Stunde), M (Minute) und S (Sekunde). Beispiel --s since:90M (die letzten 90 Minuten).
--end ENDTIME|--e ENDTIME
Gibt die Endzeit des Betrachtungszeitraums an. Das Format ist ebenfalls YYYY-mm-ddTHH:MM:SS (z.B. 2013-02-28T23:59:59). Bei der Verwendung von since: wird dieser Parameter nicht benötigt.
--timezone TIMEZONE
MailStore Server speichert die Daten in UTC Zeit. Hiermit kann die die Ausgabe angepasst werden. Standardmäßig wird $Local verwendet. Dies entspricht der Zeitzonen-Einstellung des MailStore Server Betriebssystemes. Mittels des API Befehls GetTimeZones können sich die möglichen Werte ausgegeben werden lassen. In den meisten Fällen, wird dieser Parameter nicht benötigt.
--machinename MACHINENAME|--m MACHINENAME
Filtert die Ergebnisse nach MACHINENAME. Dies kann sinnvoll sein, wenn die Ergebnisse lokaler Jobs verschiedener Rechner überwacht werden sollen.
--profile PROFILE|--p PROFILE
Filtert die Ergebnisse nach Profilname. Es kann die ID des Profils verwendet werden.
--status STATUS
Filtert die Ergebnisse nach STATUS. Mögliche Werte sind succeeded, failed und completedWithErrors. Der Status kann durch ein vorangestelltes # negiert werden. Standard ist succeeded.
--search [jobs|emails]
Gibt an, ob auf die Anzahl der zurückgelieferten Jobs oder auf die Anzahl der archivierten Mails geprüft werden soll. Standard ist jobs.
--warning WARNING|--w WARNING
Schwellenwert ab dem gewarnt wird.
--critical CRITICAL|--c CRITICAL
Schwellenwert ab dem alarmiert wird.
--compare COMPARE
Gibt an, wie die Werte WARNING und CRITICAL mit dem zurückgeliefertem Ergebnis verglichen werden. Mögliche Werte sind lt, le, eq, ge, gt (lesser than = kleiner als, lesser or equal = kleiner oder gleich, equal = gleich, greater or equal = größer oder gleich, greater than = größer als)
--DEBUG
Gibt die Liste der zutreffenden Jobs auf der Standardausgabe aus. Ist nur beim Testen sinnvoll, um zu prüfen, welche Ergebnisse tatsächlich beachtet werden.
Weitere Beispiele
check_mailstore.py --host 192.168.0.1 --password sUp3rs3CcR6ET3 -s "since:1d" -c 5 -w 2 --search jobs --status="#succeeded" --compare gt
Status ist Critical, wenn mehr (--compare gt) als 5 (-c 5) Jobs (--search jobs) NICHT mit dem Status erfolgreich (--status="#succeeded") innerhalb eines Tages beendet wurden. Eine Warnung wird bei mehr als 2 nicht erfolgreichen Jobs ausgegeben.
check_mailstore.py --host 192.168.0.1 --password sUp3rs3CcR6ET3 -s "since:1d" -c 5 -w 20 --search emails --profile "MailStore Proxy"
Status ist Critical, wenn weniger als 5 (-c 5) E-Mails (--search emails) vom Profil "MailStore Proxy" (--profile "MailStore Proxy) innerhalb eines Tages archiviert wurden. Eine Warnung wird bei weniger als 20 archivierten E-mails ausgegeben.
Nagios/Icinga mit NSClient++ überwacht die geplanten Tasks
Dieses Beispiel setzt voraus, dass im Abschnitt [NRPE] der Datei NSC.ini der Parameter allow_arguments=1 gesetzt ist. Alternativ und in öffentlichen Umgebungen sicherer, können Sie auch im Abschnitt [External Alias]] einen Alias definieren.
Die entsprechende Service Check sieht unter Nagios/Icinga wie folgt aus:
define service { use generic-service host_name mailstore.mydomain.tld service_description Scheduled Tasks check_command check_nrpe!CheckTaskSched!filter="exit_code ne 0" "syntax=%title%: %exit_code%" "crit=>0" }
Der Service-Check gibt eine Liste alle zeitgesteuerten Aufgaben im Windows Task-Planer aus, deren Exit-Code ungleich Null ist. Bei mehr als einem Ergebnis wird der Check-Status Critical gesetzt. Die Rückgabe beinhaltet eine Liste aller Aufgaben mit Exit-Code ungleich Null und der Exit-Codes.
Monitoring der Audit Ereignisse im Windows Eventlog
Die in MailStore Server enthaltene E-Mail-Benachrichtigungsfunktion versendet derzeit nur dann eine E-Mail, wenn das automatische Erstellen eines neuen Standard-Archivspeichers fehlschlägt.
Administratoren die darüber hinaus Benachrichtigung über Vorfälle auf Ihrem MailStore Server erhalten wollen, finden in diesem Artikel nützliche Hinweise zum Monitoring des MailStore Servers.
Benachrichtigungen aufgrund von Audit-Ereignissen
Eine Möglichkeit des Monitorings besteht darin, die in MailStore enthaltene Auditing-Funktion in Kombination mit der Windows Aufgabenplanung zu verwenden.
Bitte beachten Sie, dass dieses Vorgehen den eigentlich Zweck des Auditing-Features von MailStore zweckentfremdet. Pruefen Sie daher nach einer Aktualisierung des MailStore Servers ob die Trigger-Parameter weiterhin korrekt konfiguriert sind.
Um die Aktivierungstrigger in Windows konfigurieren zu können, wird mindestens Windows Vista/7/8/2008/2008 R2/2012 benötigt. Unter Windows 2000/XP/2003 stehen diese nicht zur Verfügung.
Aktivierung des Auditing Features
- Öffnen Sie den MailStore Client als Administrator.
- Klicken Sie auf Verwaltung > Compliance > Auditing.
- Aktivieren Sie die Benutzeraktivität ProfileRunArc.
Es werden nun nach der Ausführung von Archivierungsprofilen, entsprechende Einträge in das Windows-Eventlog geschrieben.
Manuelles Überprüfen der Windows-Eventlogs
- Öffnen Sie die Ereignisanzeige Ihres Windows-Systems.
- Klicken sie auf Ereignisanzeige (lokal) > Windows-Protokolle > Anwendungen.
- Suchen Sie dort nach Ereignissen der Quelle MailStore Server Auditing.
Sind Fehler bei der Ausführung des Profils aufgetreten, so ist die Ebene Fehler, war Ausführung erfolgreich, ist die Ebene Information.
Erstellung der Benachrichtigungen
Der Windows Aufgabenplaner kann Aufgaben an ein Ereignis binden. Wir nutzen dies, um eine E-Mail beim Event Archivierung fehlgeschlagen zu verschicken.
- Öffnen Sie die Aufgabenplanung Ihres Windows-Systems.
- Erstellen Sie einen neuen Ordner, z.B. MailStore Auditing in der Aufgabenplanungsbibliothek.
- Erstellen Sie eine Aufgabe über Aktion > Aufgabe erstellen. Beachten Sie bitte, dass Sie keine Einfache Aufgabe erstellen.
- Geben Sie einen aussagekräftigen Namen.
- Wählen Sie diese Option Unabhängig von der Benutzeranmeldung ausführen aus.
- Wählen Sie unter Konfigurieren für mindestens Windows Vista oder Windows Server 2008, da sonst der Trigger Bei einem Ereignis nicht zur Verfügung steht.
- Klicken Sie auf die Registerkarte Trigger
- Klicken Sie auf Neu..
- Wählen Sie unter Aufgabe starten den Wert Bei einem Ereignis aus.
- Aktivieren Sie unter Einstellungen die Option Benutzerdefiniert und klicken Sie anschließend auf Neuer Ereignisfilter.
- Setzen Sie unter Ereignisebene das Häkchen bei Fehler.
- Wählen Per Quelle aus und setzten Sie unter Quellen ein Häkchen bei MailStore Server Auditing.
- Klicken Sie auf OK um die Einstellungen zu speichern.
- Hinweis: Die Kriterien von Benutzerdefinierten Einstellungen werden als XML-Daten gespeichert. Leider vermag es der Trigger bearbeiten-Dialog nicht, dieses XML-Daten zurück in GUI-Elemente umzuwandeln. Ein nachträgliches Manipulieren des Triggers ist leider nur in XML möglich. Sollte das unerwünscht sein, muss der Trigger gelöscht und neu erstellt werden
- Wechseln Sie zur Registerkarte Aktionen.
- Klicken Sie auf Neu....
- Wählen Sie E-Mail senden im Feld Aktion aus.
- Füllen Sie die Felder im Abschnitt Einstellungen vollständig aus.
- Hinweis: Bitte beachten Sie, dass der angegebene SMTP-Server dem MailStore Server-Computer gestatten muss, ohne vorherige Anmeldung E-Mails zu verschicken.
Ist dies nicht gewünscht oder möglich, verwenden Sie einen lokal installierten SMTP-Server und tragen die zum E-Mail-Versand in Ihrer Umgebung benötigten Daten ein.
- Eventuelle werden Sie nach Ihrem Benutzerpasswort gefragt. Dies wird zur Ausführung der Aufgabe benötigt, sollten Sie nicht angemeldet sein.