6
Event-ID Analyse - wie findet man den Wald vor lauter Bäumen?
Wie findet man sich bei tausenden Events aus mehreren Servern zurecht und kann möglicherweise noch den Ursprung eines bereits augetretenen Problemes finden?
Wenn man in einer kleinen Firmenumgebung nur einen oder zwei Server administriert - sind die auflaufenden Eventlogs meist überschaubar und durchsichtig. Im Zuge der Umstellung auf "Windows Server 2008 R2" und dem verstärkten Einsatz von Virtualisierung wachsen die Anzahl an Systemen und damit auch die Anzahl der Auflaufenden Eventlogs.
Nun offen in die Runde gefragt. Wie werdet Ihr mit dieser Flut von Informationen fertig?
Gibt es da zu empfehlende Tools, mit denen man
a) die Eventlogs mehrerer Maschinen besser sortieren und analysieren kann
b) weiterführende Informationen oder Lösungsansätze für Fehler-Eventlogeinträge erhält
c) im Optimalfall zwischen Ursache und Wirkungsmeldungen aufschlüsselt
Alle Tools die ich bisher finden konnte oder die wir einsetzen, sammeln nur Eventlogs und triggern bei Warnungen und Fehlern entsprechende Alerts. (GFI-Max,Spiceworks)
Aber Hilfe für die Auswertung von Logs habe ich bisher noch nicht gefunden ausser per Hand auf eventid.net zu gehen und dort nach der entsprechenden ID zu suchen.
Mein Hauptproblem sehe ich darin, dass ich das "Ursprungsproblem" meist aufgrund der vielen Ereignisse nicht erkennen kann. Bei 3-5 Servern und einem schwerwiegenden Problem steigt die Anzahl an auflaufenden Logs zur Analyse auf mehrere huntert bis tausend Meldungen.
Um ein wenig Input und Erfahrungsaustausch wäre ich sehr dankbar.
Beste Grüße
anaxagoras83
Wenn man in einer kleinen Firmenumgebung nur einen oder zwei Server administriert - sind die auflaufenden Eventlogs meist überschaubar und durchsichtig. Im Zuge der Umstellung auf "Windows Server 2008 R2" und dem verstärkten Einsatz von Virtualisierung wachsen die Anzahl an Systemen und damit auch die Anzahl der Auflaufenden Eventlogs.
Nun offen in die Runde gefragt. Wie werdet Ihr mit dieser Flut von Informationen fertig?
Gibt es da zu empfehlende Tools, mit denen man
a) die Eventlogs mehrerer Maschinen besser sortieren und analysieren kann
b) weiterführende Informationen oder Lösungsansätze für Fehler-Eventlogeinträge erhält
c) im Optimalfall zwischen Ursache und Wirkungsmeldungen aufschlüsselt
Alle Tools die ich bisher finden konnte oder die wir einsetzen, sammeln nur Eventlogs und triggern bei Warnungen und Fehlern entsprechende Alerts. (GFI-Max,Spiceworks)
Aber Hilfe für die Auswertung von Logs habe ich bisher noch nicht gefunden ausser per Hand auf eventid.net zu gehen und dort nach der entsprechenden ID zu suchen.
Mein Hauptproblem sehe ich darin, dass ich das "Ursprungsproblem" meist aufgrund der vielen Ereignisse nicht erkennen kann. Bei 3-5 Servern und einem schwerwiegenden Problem steigt die Anzahl an auflaufenden Logs zur Analyse auf mehrere huntert bis tausend Meldungen.
Um ein wenig Input und Erfahrungsaustausch wäre ich sehr dankbar.
Beste Grüße
anaxagoras83
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 173710
Url: https://administrator.de/forum/event-id-analyse-wie-findet-man-den-wald-vor-lauter-baeumen-173710.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
6 Kommentare
Neuester Kommentar
Moin.
Meine Meinung ist ganz platt: Eventlogs bringen nicht viel. Analysier bitte einmal, wie Deine mit Events verbundenen Probleme aussahen, wie sie sich außerhalb der gelben oder Roten Ereignisse bemerkbar gemacht haben und welche Rolle bei der Behebung das Eventlog spielte. Ich behaupte: in den allermeisten Fällen eine kleine. Klar, auch ich lasse gewisse, wenige Events (Dienst stürzt ab, Platte zickt rum, unerwartetes Runterfahren) monitoren und mir werden Mails geschickt. Dennoch würde ich für ein Überdenken der Strategie plädieren, wie Du Server monitorst. Analysier doch mal, wie Du deren Verfügbarkeit zeitnah überprüfen kannst und was alles dazugehört.
Mein Hauptproblem sehe ich darin, dass ich das "Ursprungsproblem" meist aufgrund der vielen Ereignisse nicht erkennen kann.
Sicher, dass es an der Anzahl der Ereignisse liegt? Beschreib doch mal einen Fall, bei dem Dir das Eventlog zunächst nicht geholfen hat, weil Du da nicht durchgestiegen bist und erst nachher nach einigem Sortieren dahinter gekommen bist, bitte.Meine Meinung ist ganz platt: Eventlogs bringen nicht viel. Analysier bitte einmal, wie Deine mit Events verbundenen Probleme aussahen, wie sie sich außerhalb der gelben oder Roten Ereignisse bemerkbar gemacht haben und welche Rolle bei der Behebung das Eventlog spielte. Ich behaupte: in den allermeisten Fällen eine kleine. Klar, auch ich lasse gewisse, wenige Events (Dienst stürzt ab, Platte zickt rum, unerwartetes Runterfahren) monitoren und mir werden Mails geschickt. Dennoch würde ich für ein Überdenken der Strategie plädieren, wie Du Server monitorst. Analysier doch mal, wie Du deren Verfügbarkeit zeitnah überprüfen kannst und was alles dazugehört.
@DerWoWusste (awesome nick btw)
Nunja es sind einige Fälle: z.B. war der Secure-Channel meines DC gestört.. Es hat sich wie ein reines DNS-Problem dargestellt. Aber die Event-IDs haben immer wieder aufgezeigt, dass es sich nicht um einen timeout oder eine nicht gefundene Ressource handelt, sondern das der Zugriff verweigert wurde. In diesem Fall konnten wir (wenn auch nur mit Hilfe von MS) das Problem durch zurücksetzen des Securechannels das Problem beheben.
Weitere Fälle sind z.B. der Zugriff auf eine CIFS Ressource, die durch ein falsch ausgehandelten Handshake nicht funktionierte, oder nicht richtig angezogene Gruppenrichtlinien..
Es geht mir hier wirklich um zwei Dinge: Logische Sortierung und Gruppierung der Events aber viel wichtiger ist es den Ursprung eines Problemes festzustellen. Denn das erste was von einem Kunden kommt, nachdem ein Feher der nicht Hardwarebezogen war kommt ist: "Wie ist das passiert und was koennen wir in Zukunft tun um das zu verhindern."
Und wenn der Kunde das möchte (und ich moechte ja auch schlauer sein) dann ist es nicht verkehrt zu wissen wie man an die Ursache des Problemes kommt und nicht nur die Symptome behandelt.
Beste Grüße
anaxagoras83
Nunja es sind einige Fälle: z.B. war der Secure-Channel meines DC gestört.. Es hat sich wie ein reines DNS-Problem dargestellt. Aber die Event-IDs haben immer wieder aufgezeigt, dass es sich nicht um einen timeout oder eine nicht gefundene Ressource handelt, sondern das der Zugriff verweigert wurde. In diesem Fall konnten wir (wenn auch nur mit Hilfe von MS) das Problem durch zurücksetzen des Securechannels das Problem beheben.
Weitere Fälle sind z.B. der Zugriff auf eine CIFS Ressource, die durch ein falsch ausgehandelten Handshake nicht funktionierte, oder nicht richtig angezogene Gruppenrichtlinien..
Sicher, dass es an der Anzahl der Ereignisse liegt? Beschreib doch mal einen Fall, bei dem Dir das Eventlog zunächst nicht
geholfen hat, weil Du da nicht durchgestiegen bist und erst nachher nach einigem Sortieren dahinter gekommen bist, bitte.
Meine Meinung ist ganz platt: Eventlogs bringen nicht viel. Analysier bitte einmal, wie Deine mit Events verbundenen Probleme
aussahen, wie sie sich außerhalb der gelben oder Roten Ereignisse bemerkbar gemacht haben und welche Rolle bei der Behebung
das Eventlog spielte. Ich behaupte: in den allermeisten Fällen eine kleine. Klar, auch ich lasse gewisse, wenige Events
(Dienst stürzt ab, Platte zickt rum, unerwartetes Runterfahren) monitoren und mir werden Mails geschickt. Dennoch würde
ich für ein Überdenken der Strategie plädieren, wie Du Server monitorst. Analysier doch mal, wie Du deren
Verfügbarkeit zeitnah überprüfen kannst und was alles dazugehört.
geholfen hat, weil Du da nicht durchgestiegen bist und erst nachher nach einigem Sortieren dahinter gekommen bist, bitte.
Meine Meinung ist ganz platt: Eventlogs bringen nicht viel. Analysier bitte einmal, wie Deine mit Events verbundenen Probleme
aussahen, wie sie sich außerhalb der gelben oder Roten Ereignisse bemerkbar gemacht haben und welche Rolle bei der Behebung
das Eventlog spielte. Ich behaupte: in den allermeisten Fällen eine kleine. Klar, auch ich lasse gewisse, wenige Events
(Dienst stürzt ab, Platte zickt rum, unerwartetes Runterfahren) monitoren und mir werden Mails geschickt. Dennoch würde
ich für ein Überdenken der Strategie plädieren, wie Du Server monitorst. Analysier doch mal, wie Du deren
Verfügbarkeit zeitnah überprüfen kannst und was alles dazugehört.
Es geht mir hier wirklich um zwei Dinge: Logische Sortierung und Gruppierung der Events aber viel wichtiger ist es den Ursprung eines Problemes festzustellen. Denn das erste was von einem Kunden kommt, nachdem ein Feher der nicht Hardwarebezogen war kommt ist: "Wie ist das passiert und was koennen wir in Zukunft tun um das zu verhindern."
Und wenn der Kunde das möchte (und ich moechte ja auch schlauer sein) dann ist es nicht verkehrt zu wissen wie man an die Ursache des Problemes kommt und nicht nur die Symptome behandelt.
Beste Grüße
anaxagoras83
Hallo anaxagoras83,
Ich sehe das ähnlich wie DerWoWusste
"Mein Hauptproblem sehe ich darin, dass ich das "Ursprungsproblem" meist aufgrund der vielen Ereignisse nicht erkennen kann. Bei 3-5 Servern und einem schwerwiegenden Problem steigt die Anzahl an auflaufenden Logs zur Analyse auf mehrere huntert bis tausend Meldungen."
Ich denke die Kunst liegt darin zu finden wo das Problem begonnen hat - also könntest du dann die ersten 1000 Events pro 5 Server nach Warnungen und Fehlern Filtern,
beginnend etwas bevor das Problem begann.
Hierbei sind HP-Openview, Whatsup oder Nagios etc. erstmal hilfreicher, weil du meist schneller siehst wo es angefangen hat.
Du kannst die wesentlichen Dienste Monitoren - und suchst bei einem Problem konkret.
Dies ist eben eine Frage der Grösse der Umgebung. In kleineren Netzen ein Problem - ja.
Eben schon die Frage ob Logs nur in den Systemen oder auf einem Logserver gespeichert werden ist für kleinere ja zu teuer - zumal wer schaut das da je an.
Wenn du zu einem System kommst das Du nicht kennst kannst du ja die meisten Events gar nicht beurteilen - der Zeitaufwand würde zum Horror, der Kunde unzufrieden.
Ich sehe das im Zusammenhang mit dem Thema Verfügbarkeit. Ist die Schmerzgrenze gross genug - ist meist auch Budget und Verständniss für Monitoring da.
Ein Tool das dir das so Erleichtert wie du gefragt hast kenne ich nicht.
gruss p
Ich sehe das ähnlich wie DerWoWusste
"Mein Hauptproblem sehe ich darin, dass ich das "Ursprungsproblem" meist aufgrund der vielen Ereignisse nicht erkennen kann. Bei 3-5 Servern und einem schwerwiegenden Problem steigt die Anzahl an auflaufenden Logs zur Analyse auf mehrere huntert bis tausend Meldungen."
Ich denke die Kunst liegt darin zu finden wo das Problem begonnen hat - also könntest du dann die ersten 1000 Events pro 5 Server nach Warnungen und Fehlern Filtern,
beginnend etwas bevor das Problem begann.
Hierbei sind HP-Openview, Whatsup oder Nagios etc. erstmal hilfreicher, weil du meist schneller siehst wo es angefangen hat.
Du kannst die wesentlichen Dienste Monitoren - und suchst bei einem Problem konkret.
Dies ist eben eine Frage der Grösse der Umgebung. In kleineren Netzen ein Problem - ja.
Eben schon die Frage ob Logs nur in den Systemen oder auf einem Logserver gespeichert werden ist für kleinere ja zu teuer - zumal wer schaut das da je an.
Wenn du zu einem System kommst das Du nicht kennst kannst du ja die meisten Events gar nicht beurteilen - der Zeitaufwand würde zum Horror, der Kunde unzufrieden.
Ich sehe das im Zusammenhang mit dem Thema Verfügbarkeit. Ist die Schmerzgrenze gross genug - ist meist auch Budget und Verständniss für Monitoring da.
Ein Tool das dir das so Erleichtert wie du gefragt hast kenne ich nicht.
gruss p
moinsen,
ich sehe das ein wenig anders....
zum Thema Logs auswerten/logserver gibt es gute kostenlose Werkzeuge, die man grade in einer großen Umgebung braucht.
Das man unabhängig davon mit werkzeugen wie incinga(Nagios) und gesonderten Minibätchen seine div. Server aktiv testen kann/sollte ist in meinen Augen ein unabdingbares muß.
Bis ein AD Controller mal einen Fehler "freiwillig" herausrückt, dauert es viel zu lange - den prüft man "aktiv".
Zum Bleistift so:
"kostet" keinen Cent, nur etwas Rechenkapazität und einen geplanten Task pro DC
Und "sowas" ist nun wirklich keine Zauberei...
Gruß
ich sehe das ein wenig anders....
zum Thema Logs auswerten/logserver gibt es gute kostenlose Werkzeuge, die man grade in einer großen Umgebung braucht.
- logparser
- kiwi syslogserver
Das man unabhängig davon mit werkzeugen wie incinga(Nagios) und gesonderten Minibätchen seine div. Server aktiv testen kann/sollte ist in meinen Augen ein unabdingbares muß.
Bis ein AD Controller mal einen Fehler "freiwillig" herausrückt, dauert es viel zu lange - den prüft man "aktiv".
Zum Bleistift so:
- postie/bmail als mailer
dcdiag |find "fail" || goto end
dcdiag>c:\script\dcdiag.ini
postie.exe -host:ip.vom.mail.server -to:support@firma.de -file:c:\script\dcdiag.ini -from:DCDIAG-%computername% -s:DCDIAG_FEHLER_%computername%
:end"kostet" keinen Cent, nur etwas Rechenkapazität und einen geplanten Task pro DC
Und "sowas" ist nun wirklich keine Zauberei...
Gruß
@holy-day
Genau darum geht es mir. Ich ziehe mir wenn ein Problem aufgetreten ist die kompletten Eventlogs auf meinen Rechner und soll dann im Nachhinein nachvollziehen was der Ursprung des Problemes war.
Natürlich hat Logfile / Eventlog parsing viel mit Erfahrung und Fleiß zu tun. Jedoch ist ein visuelle oder logische Stütze für das Problem mehr als Willkommen.
Das ist richtig - wir setzen GFI-Max Remotemanagement ein und bekommen dadurch schon ein recht angenehmen Rückkanal über den aktuellen Zustand der Systeme.
Openview habe ich mir noch nicht angeschaut - sieht aber auf den ersten Blick interessant aus. Nagios und Co. haben wir aufgrund des Aufwandes eher zurückgestellt
(Ich weiß dass diese Aussage alleine schon endlosen Gesprächsstoff provoziert)
Der Umfang in dem ich mich bewege liegt zwischen einem bis drei Virtualisierungshosts oder ein bis drei klassisch installierte Server mit Microsoft Betriebssystem.
Bei uns steht momentan im Raum ob wir alle Informationen die wir bekommen können (Switch, Router, Firewall-Appliance, Server, Drucker, Telefonanlage, etc.) per Logserver speichern und via VPN mit einem großen Logserver abgleichen, einfach um die Informationen um Falle des Ausfalles zu haben - ähnlich wie eine Blackbox im Flugzeug.
Da stimme ich dir zum Teil zu. Denn die meisten nutzen ja die altbekannten Komponenten: Windows Server 200X RX + DC + FS + DNS + DHCP + Exchange + Terminalserver + IIS/Sharepoint, etc) daher sind die produzierten logs schon standardisiert oder übersehe ich an diesem Punkt etwas? Logs von anderen Produkten (Nischensoftware oder selbstgestrickten Unternehmenslösungen) kann man dann ja herausfiltern.
Natürlich. Das ist zum Großteil auch gegeben. Aber wenn der Ausfall da ist - ich werde darauf hingewiesen - ich reagiere - ich löse das Problem (oder das Symptom) dann ist immer die Frage "Wie konnte das passieren. Das beantwortet mir das Monitoring meist nicht.
Gut, vielen Dank für deinen Input.
Gruß
anaxagoras83
Ich denke die Kunst liegt darin zu finden wo das Problem begonnen hat - also könntest du dann die ersten 1000 Events pro 5
Server nach Warnungen und Fehlern Filtern,
beginnend etwas bevor das Problem begann.
Server nach Warnungen und Fehlern Filtern,
beginnend etwas bevor das Problem begann.
Genau darum geht es mir. Ich ziehe mir wenn ein Problem aufgetreten ist die kompletten Eventlogs auf meinen Rechner und soll dann im Nachhinein nachvollziehen was der Ursprung des Problemes war.
Natürlich hat Logfile / Eventlog parsing viel mit Erfahrung und Fleiß zu tun. Jedoch ist ein visuelle oder logische Stütze für das Problem mehr als Willkommen.
Hierbei sind HP-Openview, Whatsup oder Nagios etc. erstmal hilfreicher, weil du meist schneller siehst wo es angefangen hat.
Du kannst die wesentlichen Dienste Monitoren - und suchst bei einem Problem konkret.
Du kannst die wesentlichen Dienste Monitoren - und suchst bei einem Problem konkret.
Das ist richtig - wir setzen GFI-Max Remotemanagement ein und bekommen dadurch schon ein recht angenehmen Rückkanal über den aktuellen Zustand der Systeme.
Openview habe ich mir noch nicht angeschaut - sieht aber auf den ersten Blick interessant aus. Nagios und Co. haben wir aufgrund des Aufwandes eher zurückgestellt
(Ich weiß dass diese Aussage alleine schon endlosen Gesprächsstoff provoziert)
Dies ist eben eine Frage der Grösse der Umgebung. In kleineren Netzen ein Problem - ja.
Der Umfang in dem ich mich bewege liegt zwischen einem bis drei Virtualisierungshosts oder ein bis drei klassisch installierte Server mit Microsoft Betriebssystem.
Eben schon die Frage ob Logs nur in den Systemen oder auf einem Logserver gespeichert werden ist für kleinere ja zu teuer -
zumal wer schaut das da je an.
zumal wer schaut das da je an.
Bei uns steht momentan im Raum ob wir alle Informationen die wir bekommen können (Switch, Router, Firewall-Appliance, Server, Drucker, Telefonanlage, etc.) per Logserver speichern und via VPN mit einem großen Logserver abgleichen, einfach um die Informationen um Falle des Ausfalles zu haben - ähnlich wie eine Blackbox im Flugzeug.
Wenn du zu einem System kommst das Du nicht kennst kannst du ja die meisten Events gar nicht beurteilen - der Zeitaufwand
würde zum Horror, der Kunde unzufrieden.
würde zum Horror, der Kunde unzufrieden.
Da stimme ich dir zum Teil zu. Denn die meisten nutzen ja die altbekannten Komponenten: Windows Server 200X RX + DC + FS + DNS + DHCP + Exchange + Terminalserver + IIS/Sharepoint, etc) daher sind die produzierten logs schon standardisiert oder übersehe ich an diesem Punkt etwas? Logs von anderen Produkten (Nischensoftware oder selbstgestrickten Unternehmenslösungen) kann man dann ja herausfiltern.
Ich sehe das im Zusammenhang mit dem Thema Verfügbarkeit. Ist die Schmerzgrenze gross genug - ist meist auch Budget und
Verständniss für Monitoring da.
Verständniss für Monitoring da.
Natürlich. Das ist zum Großteil auch gegeben. Aber wenn der Ausfall da ist - ich werde darauf hingewiesen - ich reagiere - ich löse das Problem (oder das Symptom) dann ist immer die Frage "Wie konnte das passieren. Das beantwortet mir das Monitoring meist nicht.
Ein Tool das dir das so Erleichtert wie du gefragt hast kenne ich nicht.
Gut, vielen Dank für deinen Input.
Gruß
anaxagoras83
@timobeil
Soo.. dritter Anlauf einer Antwort auf deinen Post: Dieses mal wird es etwas
Das ist generell nicht verkehrt. Gibt eine frische Sichtweise auf die Probleme.
Gegenfrage: Hast du dir mal Splunk ( http://www.splunk.com/ ) angeschaut?
Diesen Ansatz habe ich bisher noch gar nicht ins Auge gefasst. Hast du da neben dem Nachstehenden Script noch andere Beispiele?
Definitiv - eine riesige Idee und Anwendungswürdig. Wäre ich nicht drauf gekommen. Ich danke dir.
beste Grüße
Anaxagoras83
Soo.. dritter Anlauf einer Antwort auf deinen Post: Dieses mal wird es etwas
ich sehe das ein wenig anders....
Das ist generell nicht verkehrt. Gibt eine frische Sichtweise auf die Probleme.
zum Thema Logs auswerten/logserver gibt es gute kostenlose Werkzeuge, die man grade in einer großen Umgebung braucht.
* logparser
Habe ich mir angeschaut - scheint aber sehr große Bastelarbeit zu sein - ist das richtig?* kiwi syslogserver
Nutzen wir als Windows Alternative zu Syslog-ng. Aber bisher nur um Logs von den Firewalls zu speichern.Gegenfrage: Hast du dir mal Splunk ( http://www.splunk.com/ ) angeschaut?
Das man unabhängig davon mit werkzeugen wie incinga(Nagios) und gesonderten Minibätchen seine div. Server aktiv testen
kann/sollte ist in meinen Augen ein unabdingbares muß.
Bis ein AD Controller mal einen Fehler "freiwillig" herausrückt, dauert es viel zu lange - den prüft man
"aktiv".
kann/sollte ist in meinen Augen ein unabdingbares muß.
Bis ein AD Controller mal einen Fehler "freiwillig" herausrückt, dauert es viel zu lange - den prüft man
"aktiv".
Diesen Ansatz habe ich bisher noch gar nicht ins Auge gefasst. Hast du da neben dem Nachstehenden Script noch andere Beispiele?
Zum Bleistift so:
"kostet" keinen Cent, nur etwas Rechenkapazität und einen geplanten Task pro DC
Und "sowas" ist nun wirklich keine Zauberei...
- postie/bmail als mailer
> dcdiag |find "fail" || goto end
> dcdiag>c:\script\dcdiag.ini
> postie.exe -host:ip.vom.mail.server -to:support@firma.de -file:c:\script\dcdiag.ini -from:DCDIAG-%computername%
> -s:DCDIAG_FEHLER_%computername%
>
> :end
> "kostet" keinen Cent, nur etwas Rechenkapazität und einen geplanten Task pro DC
Und "sowas" ist nun wirklich keine Zauberei...
Definitiv - eine riesige Idee und Anwendungswürdig. Wäre ich nicht drauf gekommen. Ich danke dir.
beste Grüße
Anaxagoras83
