Event2Mail - Systemmonitoring per Mail

EventMelder kann und soll kein Wettbewerber zu richtigen Eventlog Management Systemen oder Netzwerk Management Systemen sein. Aber es soll mittleren und kleinen Firmen helfen, ihre Eventlogs an einer zentralen stelle (z.B. ein Exchange Postfach oder öffentlichen Ordner) zu sammeln und über Filter die "unerwünschten" Events auf einfache Art zu filtern, so dass hoffentlich nur die "wichtigen" Events letztlich in ihrer Mailbox landen.

Überwachung ist aus meiner Sicht für den professionellen Betrieb einer IT-Landschaft erforderlich. Neben aktiven Funktionstests und der Aufzeichnung von Kennzahlen ist die Verwaltung von Events (Fehlern, Warnungen etc.) besonders wichtig. Es gibt natürlich eine ganze Menge von Protokollen und Programmen, die Events einsammelt und anzeigen. So kann man mit Syslog z.B. die Windows Eventlogs an einen Syslog-Daemon (z.B. Kiwi Syslog Daemon oder Unix Syslog-NG) weitergeben. Aber das ist erst die Hälfte der Arbeit. Irgendwo müssen Regeln hinterlegt werden, welche Events dann auch wie gemeldet werden müssen. Auch sollte eine Software Events als "erledigt" anzeigen können. "Große Lösungen" wie System Center Essentials oder MOM2005 können das und andere Dinge natürlich sehr gut. Was macht aber eine Firma, die für ihre Überwachung eigentlich keinen aufgeblasenen kostenintensiven Server betreiben möchte, sondern einfach nur Events in einer bekannten Oberfläche erhalten möchte ?

Eventlog2Mail schnappt sich die Eventlogs auf den Servern und sendet diese einfach per SMTP an ihren Exchange Server, der natürlich entsprechend empfangsbereit sein muss. Das System funktioniert um so besser, je weniger Events ankommen. Gerade am Anfang wird es sicher ein paar Tage dauern, bis sie alle Fehler und Warnungen durch KonfigurationsÄnderungen eliminiert oder in Event2Mail ausgeschlossen haben. Aber nur so bekommen Sie neue Events auch zu Gesicht, die Sie bei eine Positivliste nicht erhalten würden.

Die Meldung

Ein "Event" ist klassische eine Information mit einem Datum, einer Quelle, einer Meldung, einer Wichtigkeit, eventuell zusätzlichen Informationen etc., die gesendet, empfangen, verarbeitet und gespeichert werden muss. Irgendwie drängt sich mit hier der Vergleich zu eine Mail auf: Ich bin natürlich erst einmal auf Windows und Exchange zentriert. Daher ist natürlich ein Posteingang oder ein öffentlicher Ordner durchaus eine interessante Stelle, um Systemmeldungen zu sammeln und zu verarbeiten. Ein Eventlog (Beispiel Vista) enthält z.B. folgende Daten:

Eine Mail selbst hat aber Felder, die fast übereinstimmend sind.

Event-Feld E-Mail-Feld Bedeutung

Datum

Sendedatum

Die Zeit, wann ein Event aufgetreten ist, lässt sich wunderbar auch das Datum umsetzen, wann eine Mail erstellt wurde

Quelle

Displayname des Absender

Die Quelle eines Events ist idealerweise der Server oder die Anwendung. Nun möchte man vieleicht nicht für jede Quelle auch eine gültige Mailadresse angeben. Aber der Displayname ist für eine Sortierung ausreichend.
Die SMTP-Absenderadresse wird natürlich immer die "gleiche" sein, die hoffentlich auch NDRs empfangen kann.

Severity

Priorität

Ob ein Event eine Information, eine Warnung oder ein Fehler ist, kann über die Priorität abgebildet werden ,z.B.:

  • Information = Niedrige Priorität
  • Warnung = "normale Mail"
  • Error = "dringende Mail"

EventID und Kurzfassung

Subject

Die EventID als numerisches Feld kann ebenso wie z.B. die ersten Worte des Langtexts in den Betreff mit übernommen werden.

Textinformation

Body

Die komplette Eventlogmeldung samt zusätzlicher Daten kann natürlich einfach in den Body der Mail abgelegt werden. Damit ist sie sogar einfach "durchsuchbar. Da Windows Eventlogs ihre "Beschreibung" aus lokalen DLLs ziehen, muss der Text auf dem jeweiligen Server natürlich erstellt werden.

Outlook und Exchange beherrschen natürlich noch weitere Felder, die aber per SMTP so erst einmal nicht zu erreichen sind. Es wäre aber denkbar, dass ein SMTP-Sink oder Exchange 2007 Transport Agent den Body der Mail extrahiert und Daten weiter aufbereitet, so dass weitere Felder nutzbar würden.

Und selbst wenn Sie gar nicht Exchange und Outlook einsetzen wollen, so können Sie SMTP-Mails natürlich auch Richtung Sharepoint zustellen. Selbst entfernte Standorte können einfach per SMTP ihre Meldungen über Relays, VPNs oder das Internet an "ihr" System übermitteln.

Also fehlt nur noch ein Modul, welches auf die verschiedenen Server installiert wird und dort die verschiedenen Quellen (z.B. das Eventlog in erster Stufe) überwacht und bei Fehlern diese an eine Mailadresse sendet. Ja ich weiß, dass ohne Mailsystem dieses Monitoring nicht funktioniert. Niemand ist perfekt.

Die Verarbeitung

Es ist klar, dass als Mailsystem natürlich idealerweise Exchange zum Einsatz kommt und Outlook als Client. Die Mails an den Alias "z.B. systemmeldungen@firma.tld sollten in einem Postfach auflaufen, auf welches die verschiedenen Administratoren einfach berechtigt werden. Damit kann ein Admin dieses Postfach zusätzlich mit einbinden und darin die neuen Meldungen sehen. Wenn die Mails nun in einem Postfach oder Ordner gelandet sind, dann sind natürlich alle alle Möglichkeiten eine Bearbeitung in Outlook gegeben:

  • Neu und gelesen
    Neue Events sind von Natur aus "ungelesen" und jeder kann sehen, ob die Mail gelesen wurde.
  • Kennzeichnungen
    Über die "Flaggen" in Outlook können Sie sich selbst die Arbeit organisieren.
  • Ansichten mit Sortierung, Gruppierung und Filter
    Da Felder wie Datum, Absender, Betreff, Priorität auch für Gruppierungen und Filter zu gebrauchen sind, können Sie sich über passende Ansichten natürlich auch die Arbeit erleichtern.
  • Regeln
    In bestimmten grenzen können Sie sogar ein Regelwerk aufbauen, um Mails von bestimmten Systemen weiter zu leiten. Wobei hier natürlich die Einschränkungen von Outlook und Exchange zu beachten sind.
  • Kategorien
    Outlook Kategorien kann ich ohne "Hilfe" von extern per SMTP leider nicht setzen, aber manuell können Sie sofort Kategorien einsetzen, um die Arbeit im Team zu vereinfachen (Zuständigkeit etc.). Sie könne ja in dem Ordner ein "CustomForm" veröffentlichen, welches die Mails verarbeitet oder umschreibt oder mit einem StoreSink oder SMTP-Transportagent nachhelfen.
  • Unterordner zur Ablage
    Sie können natürlich auch einfach die Events in unterordnern strukturiert ablegen, nachdem Sie gesichtet und verarbeitet wurden.
  • OWA-Webzugriff
    Dank Outlook Web Access ist eine beschränkte Bearbeitung sogar über Webbrowser von überall möglich
  • RSS-Feed
    Es gibt Drittprodukte, die z:B. einen Exchange 2007 öffentlichen Ordner oder ein Postfach als RSS-Feed anbieten. Platz für weitere Entwicklungen ist hier natürlich in jeder Hinsicht.

Und wenn Ihnen das alles nicht reich, dann können Sie die Mails auch einfach in ein anderes System (z.B.: Sharepoint Libraries) ablegen lassen. Aber auch Outlook kann in einem Postfach mit Ordnern umgehen. Interessant wäre als z.B. eine unterstruktur im Posteingang mit den Ordnern:

Ordnername Funktion

Erledigt

Hier könnte ein Administrator die Meldungen verschieben, die erledigt sind. Ein Aufräumprozess (z.B: Message Records Management könnte diese Mails nach einiger Zeit löschen

Ignorieren

Events, die hier hinein gelegt werden, könnten später automatisch ignoriert werden. (Siehe weiter unten)

Archiv

Meldungen, die länger vorgehalten werden müssen, können in diesem Ordner vor dem Löschen (aus Erledigt) gesichert werden. Viele Archivlösungen können

Denkbar sind natürlich auch Ordner nach Servern oder Produkten. Denkbar ist auch, dass sich ein Administrator das Postfach als primäres Postfach einbindet und über Regeln schon einige Aktionen automatisieren kann. Über Postfachquotas kann man verhindern, dass die Datenbank über Gebühr anwächst.

Event2Mail Agent

Kommen wir also zum eigentlich Kern: Dem Programm oder Skript, um auf neue Events zu überwachen und diese per Mail zu versenden. Sicherlich sollte diese Routine als echtes Windows Service realisiert werden können, aber in der ersten Version könnte auch ein VBscript oder PowerShell-Skript die Aufgabe übernehmen. Allerdings sind einige Funktionen in der PowerShell einfach bestechend einfacher gelöst, z.B. XML-Konfigurationsdateien einlesen.

Ein Dienst ist aber einfacher zu überwachen und auch nicht allzu schwer zu entwickeln. Notfalls helfen SRVANY und INSTSRV weiter. Diese Agenten müssen aber die Konfiguration möglichst automatisch und zentral erhalten. Das betrifft nicht nur die Regeln, sondern auch z.B. die IP-Adresse des Mailserver und erforderliche Anmeldedaten. Denn "sicher" sollte es schon sein und das erreichen Sie einfach per SMTP-Anmeldung auf der Clientseite und Transportregel auf Exchange, um Mails an das Systemmeldungspostfach nur von diesem Clients zu erlauben.

Das Skript liest beim Start eine XML-Datei ein, in der die Konfiguration hinterlegt ist. Um möglichst unabhängig von Active Directory, Gruppenrichtlinien etc. zu sein, könnte der Agent diese XML-Datei einfach per HTTP von einem Server zu laden, der über DNS auflösbar ist. Dazu hole ich mir einfach die lokale DNS-Domain des Computers und hole dann die folgende URL:

http://event2mail.%domain%/event2mail.xml

Über diesen Kniff können Sie die Konfiguration auf einem zentralen Webserver je Domäne ablegen und wenn Sie etwas "Dynamik" addieren wollen, können Sie auf dem Webserver ja für jeden Client, den sie anhand der IP-Adresse bzw. dem Namen ja unterscheiden können, eine eigene Konfigurationsdatei generieren lassen oder ablegen. Es sollte auch kein Problem sein, die URL im PowerShell Code anzupassen um z.B. http://event2mail.%domain%/%servername.xml abzurufen oder http://event2mail.%domain%/event2mail.asp?server=%servername%. In der Basisausstattung reicht mit eine XML-Datei für alle Server aus.

Das Skript verbindet sich dann per WMI um neue Events einzusammeln und entsprechend der Konfiguration zu verarbeiten. Die Konfiguration enthält im wesentlichen folgende Parameter

<event2mail>
   <mailhost>smtp.firma.domain</mailhost>
   <smtpto>sysmsg@example.com</smptto>
   <smtpfrom>event2mail@example.com</smtpfrom>
   <maxeventperhour>20</maxeventperhour>
   <exclude server="" log="application" source="" eventid="*" severity="information" />
   <exclude server="" log="system"      source="" eventid="*" severity="information" />
</event2mail>

Die Funktion der einzelnen Parameter ist schnell erläutert:

  • <mailhost>
    Hostname oder IP-Adresse des SMTP-Servers, an den die Mail gesendet wird
  • <smtpto>
    SMTP-Adresse, an die die Mail adressiert wird
  • <smtpfrom>
    Die SMTP-Absenderadresse. Beachten Sie, dass an diese Adresse eventuell Rückläufer (NDR etc.) gehen. Sie sollte also existieren und von einem Admin gelesen werden. z.B. als sekundäre Adresse ihres Postfachs. Die Adresse wird auch als "Reply-To:"-Adresse im Header gesetzt, damit Rückläufer ankommen, auch wenn das "From"-Feld im Header z.B. den Server enthält.
  • <maxperhour>
    Das Skript zählt die versendeten Events und um ein Fluten oder Schleifen zu verhindern, sendet es maximal so viele Events pro Stunde. Wird die Grenze erreicht, wir noch ein Event gesendet, der das Erreichen der Grenze meldet. Wenn Sie z.B. Exchange überwachen und gerade diese Meldungsnachrichten selbst wieder Fehler im Eventlog erzeugen, dann wäre die Schleife perfekt.
  • <exclude log="application" source="" eventid="" severity="" />
    Diese Zeile kann mehrfach vorkommen und erlaubt schon auf dem Client eine Filterung. Ich habe mich für eine "Negativliste" entschieden, d.h. ich kann Events von der Meldung ausschließen. Per Default werden z.B. alle "Information"-Events aller Server ausgeschlossen. Da man auch nach Server filtern kann, es es kein Problem die gleiche XML-Datei für viele Server mit eigenen Filtern zu verwenden.

Filterung steuern

Damit nun nicht jede Eventlogmeldung direkt den Exchange Server "füllt", sollten die dezentralen Agenten natürlich schon vorfiltern. Die Filter können in der XML-Datei gepflegt werden. Aber niemand wird dort die Strings manuell pflegen wollen. Aber dafür haben wir den Ordner "Ignorieren" schon vorgesehen

Wenn die Agenten die Betreffs in der richtigen "Codierung" senden, könnten hier sogar mit Platzhaltern auch zukünftige Events abgewickelt werden, z.B. könnte ein Betreff einer Meldung wie folgt aussehen:

Betreff: Server:srv01;Log:Application;Severity:Warning;Source:MSExchangeIS;Id:1234; Text: Message

Natürlich kann das Skript nun daraus die Werte ermitteln. Interessanter ist aber, dass mit Outlook eine Mail auch verändert werden kann. Dann könnte ein Admin diese Zeile einfach anpassen, z.B. in

Betreff: Server:*;Log:Application;Severity:Warning;Source:MSExchangeIS;Id:1234; Text: Message

Und schon wäre der Event für alle Server gefiltert.

Andere Systeme

Natürlich die die Funktion nicht auf Windows Eventlogs beschränkt. Alles, was eine Meldung per Mail lossenden kann und vielleicht idealerweise noch die Filterfunktion unterstützt, kann integriert werden. Wer also einen Daemon schreibt, der die Syslog-Meldungen oder auch SNMP-Traps annimmt und nach einer Filterung weiterreicht, kann auch andere Dienste einbinden. Sogar die ein oder anderen aktiven Teste und Performance Counter könnte man derart einbinden, dass die Ergebnisse als Eventlog erscheinen und dann von dem normalen Agenten erfasst, gefiltert und weiter geleitet werden

Event2Mail Skript

Hier mal ein VBScript Beispiel, wie man Eventlogs überwachen und ausgeben kann. Allerdings ist es da nicht so einfach, eine SMTP-Mail zu versenden. Sie müssen CDO oder CDONTS installieren oder BLAT o.ä. aufrufen, was im .NET Framework schon "buildIn" ist. daher hier nur ein Ausschnitt, der mit VBScript das Eventlog überwacht.

Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colMonitoredEvents = objWMIService.ExecNotificationQuery _
   ("Select * from __instancecreationevent where TargetInstance isa 'Win32_NTLogEvent' ")

wscript.echo "Warte auf Events..."
Do          'Endlosschleife
                Set objLatestEvent = colMonitoredEvents.NextEvent
                wscript.echo "Event gefunden"
                wscript.echo "Time:" & evtdatetime(objLatestEvent.TargetInstance.TimeGenerated)
                wscript.echo "Source:" & objLatestEvent.TargetInstance.sourceName
                wscript.echo "EventID:" & objLatestEvent.TargetInstance.EventCode
                wscript.echo "Message:" & objLatestEvent.TargetInstance.Message
                wscript.echo "Event Ende"
Loop
 
wscript.echo WScript.ScriptName & " beendet."
WScript.quit(0)
 
 
Function evtdatetime(evttime)
' Auszug aus http://www.sadikhov.com/forum/Assistance-Requested-On-Vbscript_13254.html
' Konvertiert die Datum/Zeit Information des Eventlog in ein lesbares Format.
                Dim tmGen, dtPart,tmPart,strDt
                tmGen =  evttime & ""
    dtPart = Mid(tmGen,1,8)
    tmPart = Mid(tmGen,9,6)
    strDt = Mid(dtPart,5,2) & "/" & Mid(dtPart,7,2) & "/" & Mid(dtPart,1,4) & " " & _
            Mid(tmPart,1,2) & ":" & Mid(tmPart,3,2) & ":" & Mid(tmPart,5,2)
 
    evtdatetime = FormatDateTime(strDt,0)
End Function

Hier fehlen natürlich alle sonstige Funktionen zum zentralen Download und Anwenden einer Konfiguration und der Versand per Mail

Weitere Links