Eventlog-Backup mit Log Parser

Das Ereignisprotokoll (Eventlog) eines Windows-Computers füllt sich manchmal sehr schnell – besonders dann, wenn ein schwerer Fehler vorliegt. Windows protokolliert dann sehr viele Ereignisse, die sich oft wiederholen, bis das Problem abgestellt ist. Das Problem: Auf diese Weise überschreibt das System das Protokoll, wenn es vollläuft, sodass ältere Ereignisse gar nicht mehr im Protokoll stehen.

In solchen Situationen empfiehlt es sich, das Ereignisprotokoll regelmäßig in eine Datenbank zu exportieren, damit man die Ereignisse über einen längeren Zeitraum hinweg lückenlos nachvollziehen kann. Führt man beispielsweise eine Umstellung oder eine Migration durch, kann es erforderlich sein, das Eventlog täglich oder gar stündlich zu exportieren, um nichts zu verpassen. Als kostengünstige Lösung hierfür bietet sich Microsofts Log Parser an.

Unsere Lösung nutzt eine Batchdatei und zwei SQL-Befehlsdateien, um Log Parser fernzusteuern. Die Batchdatei kann man über die Windows-Aufgabenplanung (Task Scheduler) so oft aufrufen, wie man es benötigt. Die Batch-Logik sorgt dafür, dass jeweils nur die neuen Events in die Datenbank exportiert werden. Dadurch entsteht eine leistungsfähige Lösung: Je öfter man das Skript aufruft, desto weniger Daten exportiert es in jedem Durchgang. Erreicht man eine regelmäßige Ausführung, so erhält man eine lückenlose Datensammlung der Ereignisse in der Datenbank.

Als Datenspeicher nutzt die Lösung einen SQL Server. Für kleinere Umgebungen oder eine übergangsweise Protokollierung (z.B. bei einer Migration) kann dabei SQL Server Express völlig ausreichen. Will man viele Rechner auswerten und die Ereignisse lange aufbewahren, kann die Datenmenge aber so groß werden, dass ein “vollwertiger” SQL Server nötig ist (denn SQL Server Express ist auf maximal 4 GB begrenzt, bei SQL Express 2008 R2 sind es 10 GB). 25.000 Ereignisse belegen etwa 10 MB an Speicher – dadurch hat eine Menge Daten in einer Datenbank Platz.

Das folgende Beispiel setzt voraus, dass auf einer lokalen Instanz von SQL Express eine Datenbank namens “Eventlog” eingerichtet ist. Die nötige Tabelle legt das Skript bei Bedarf selbst an.

Vorbereitung

Hat man die Datenbank auf einem SQL-Server erzeugt, so muss man noch Log Parser auf allen Servern einrichten, deren Ereignisprotokolle man exportieren möchte. Log Parser ist in wenigen Momenten installiert und beeinträchtigt das System nicht. Man kann sich notfalls sogar die Installation sparen und nur die Programmdateien des Log Parser in einen geeigneten Ordner kopieren.

Download Log Parser:

[Download details: Log Parser 2.2]
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07

Log Parser läuft auf allen 32- und 64-Bit-Varianten von Windows seit Windows NT.

Download der Skriptdateien:

  Eventlog-Backup mit Log Parser (1,0 KiB, 1.976-mal heruntergeladen, letzte Änderung am 24. Juli 2014)

Das Batch-Skript

Update 24. Juli 2014: Die ursprüngliche Fassung hatte einen logischen Fehler. Dieser ist nun korrigiert.

Dieses Batch-Skript schaut zunächst, ob es bereits Events exportiert hat. Dazu prüft es eine lokale Datei (MaxID.txt), in der die Nummer des letzten exportierten Events vermerkt ist. Gibt es diese Datei noch nicht, so beginnt der Export bei Nummer 0, sonst bei der Nummer aus der Datei.

Danach ruft das Skript Log Parser mit der ersten SQL-Datei auf, um die höchste verfügbare Ereignisnummer zu finden und diese in der Datei MaxID.txt zu hinterlegen. Danach startet es Log Parser mit der zweiten SQL-Datei, um alle aktuellen Events auszulesen und in die SQL-Datenbank zu kopieren.

@echo off
chcp 1252

SET LP="%ProgramFiles%\Log Parser 2.2\logparser"
SET WORK=C:\Daten

rem letztes vorheriges Event bestimmen aus MaxID.txt
if exist "%WORK%\MaxID.txt" (
  for /F "usebackq tokens=1 delims=" %%i in ("%WORK%\MaxID.txt") do SET Min=%%i
  goto read
)

rem kein vorheriges Event - also bei 0 beginnen
SET Min=0

:read
rem letztes Event auslesen und nach NewMaxID.txt schreiben
%LP% file:"%WORK%\MaxEventID.sql" -o:NAT -headers:OFF -stats:off
for /F "usebackq tokens=1 delims=" %%i in ("%WORK%\NewMaxID.txt") do SET Max=%%i
del %WORK%\NewMaxID.txt

echo Letztes exportiertes Event: %Min%
echo Höchstes zu exportierendes Event: %Max%
if %Min% GEQ %Max% (
   echo Keine neuen Events!
   goto :eof
)

rem nächstes zu exportierendes Event setzen
SET /A Min=%Min%+1

%LP% file:"%WORK%\Get-EventsBetween.sql?Min=%Min%+Max=%Max%" -stats:on -o:SQL -createTable:ON -server:.\SQLEXPRESS -database:Eventlog -driver:"SQL Server"
if not %errorlevel%==0 (
    echo Fehler beim Export!
    goto :eof
)

rem letztes exportiertes Event als neue MaxID setzen
echo %Max%>"%WORK%\MaxID.txt"

Anpassung der Datei:

• In den beiden SET-Zeilen am Anfang sind die lokalen Pfade anzupassen: “LP” gibt den Speicherpfad von Log Parser an. Normalerweise liegt dieser unter %ProgramFiles% (bei 32-Bit-Systemen) bzw. unter %ProgramFiles(x86)% (bei 64-Bit-Systemen). “WORK” ist das lokale Arbeitsverzeichnis, in dem die Batch-Datei und die SQL-Dateien liegen.
• In der letzten Zeile müssen die Angaben zur Datenbank angepasst werden. Die vorliegende Zeile schreibt in die Datenbank “Eventlog” auf dem lokalen SQL Express. Möchte man in die Datenbank “MeineEvents” auf dem “echten” SQL Server “SQL01” schreiben, so lautet die Zeile wie folgt:%LP% file:“%WORK%\Get-EventsBetween.sql?Min=%Min%+Max=%Max%“ -stats:on -o:SQL -createTable:ON -server:SQL01 -database:MeineEvents -driver:“SQL Server“

Die erste SQL-Datei

Die SQL-Datei “MaxEvent.sql” bestimmt die letzte Ereignisnummer im lokalen Protokoll. In der INTO-Zeile ist der tatsächliche Pfad zur Datei NewMaxID.txt anzugeben, also dasselbe WORK-Verzeichnis wie in der Batchdatei.

SELECT MAX(RecordNumber)
INTO 'C:\Daten\NewMaxID.txt'
FROM Application

Die zweite SQL-Datei

Die SQL-Datei “GetEventsBetween.sql” liest dann die tatsächlichen Ereigniseinträge aus und schreibt sie in den Datenspeicher. Hier sind keine Anpassungen nötig.

SELECT *
INTO ServerEvents
FROM Application
WHERE RecordNumber BETWEEN %Min% AND %Max%

Mehrere Protokolle auslesen

Diese Lösung liest nur das Application-Protokoll aus. Möchte man noch weitere Protokolle berücksichtigen, etwa das System-Protokoll, so empfiehlt es sich, den ganzen Batch-Ordner mit allen Skripts zu kopieren. In der zweiten Kopie ändert man in den SQL-Dateien dann die FROM-Zeile, sodass dort nicht “Application” steht, sondern “System”. Die Batch-Datei muss dann mit dem korrekten WORK-Verzeichnis angepasst werden. Die Datenbank selbst muss man nicht ändern; alle Protokolle können in derselben Datenbanktabelle landen (dort ist der Protokollname hinterlegt). Für jede so erzeugte Skript-Kombination legt man dann in der Aufgabenplanung einen eigenen Job an.

Die Jobs selbst laufen meist nur wenige Sekunden lang.

Auswertung der Protokolle

Die Auswertung der Protokolldaten aus der SQL-Datenbank kann mit dem SQL Server Management Studio oder mit einem beliebigen anderen SQL-Client erfolgen, beispielsweise mit Access. Das erfordert natürlich ein paar Grundkenntnisse in SQL, aber dafür reicht wirklich Basis-Know-how aus.

Alle Fehler, die auf dem Server “FILE01” zwischen dem 20.2.2011 und dem 28.2.2011 aufgetreten sind, gibt etwa folgendes SQL-Kommando aus der Datenbank aus:

SELECT * FROM dbo.ServerEvents
WHERE ComputerName LIKE 'FILE01%'
AND EventTypeName = 'Error Event'
AND TimeGenerated BETWEEN '20.2.2011' AND '28.2.2011'

Zwar kann man mit Log Parser die Ereignisse auch in einem anderen Format ausgeben als in eine SQL-Datenbank, beispielsweise in CSV-Dateien. Leider aber sind die Ereignisdaten dann nicht gut lesbar, weil das CSV-Format nicht gut zu den Daten passt. Zudem ist SQL Server für die große Menge zu erwartender Daten am besten geeignet.

Lässt man die hier vorgestellte Lösung länger laufen, so sammeln sich viele Daten an. Je nach verfügbarem Speicher sollte man dann noch über eine zweite Stufe nachdenken und von Zeit zu Zeit die Daten aus der Haupt-Tabelle löschen, um die Datenbank zu verkleinern.