Ist eine zentralisierte Protokollierung eine gute Idee?

Derzeit verfügt meine Organisation über eine Lösung mit mehr als 10 Komponenten, und einige verfügen über eine Protokolldatei pro Thread. Da die Dateien stündlich gewechselt werden, ist das Verfolgen all dessen mühsam.

Ist es eine gute Idee, die gesamte Protokollierung auf einem bestimmten Computer zu zentralisieren (mithilfe von rsyslog oder ähnlichem)? Würde ich nicht Einfachheit gegen Hektik eintauschen? Gibt es gute Protokollbetrachter für diesen Anwendungsfall mit hohem Volumen?

Wir sind übrigens ein direkter Microsoft-Shop.

Vielen Dank für alle Antworten!

Ich würde vorschlagen, dass Sie sich Splunk ansehen .

Ich habe es derzeit in Produktion, mit mehr als 30 Netzwerkgeräten, die sich daran anmelden. Es ist wirklich nützlich, Protokolle an einem Ort zu haben, für die ich meine eigenen Abfragen schreiben, vordefinierte Berichte ausführen usw. kann.

Ein großer Vorteil der zentralisierten Protokollierung ist folgender:

• Wenn einer Ihrer Computer jemals kompromittiert wird und die Protokolle geändert werden, um diese Tatsache zu verbergen, befindet sich auf Ihrem zentralen Protokollierungsserver immer noch eine nicht manipulierte Kopie.

Ein anderer ist:

• In meinem Fall habe ich auch einen dedizierten Monitor an meiner Workstation, der vom zentralen Protokollierungsserver ausgeführt wird und alle Protokolle mit der Priorität "Warnung" oder höher in Echtzeit anzeigt, damit ich Probleme sofort beheben kann, sobald sie auftreten. (hoffentlich bevor der Endbenutzer es bemerkt :)). Dies ist ohne einen zentralen Server nur schwer möglich.

Schauen Sie sich auch evententry an, das für wenige Lizenzen nicht sehr teuer ist, gute Filter und Warnungen usw. einrichten kann.

Eine zentralisierte Protokollierung ist immer eine gute Idee, vorausgesetzt, Ihr Protokollserver befindet sich an einem sicheren Ort.

Haben Sie sich Splunk und / oder Spiceworks angesehen?

www.splunk.com www.spiceworks.com

Unsere AD DC-Sicherheitsprotokolle durchlaufen in Stoßzeiten täglich zwischen 3 und 5 GB Protokolle, und es gibt auf dieser Erde einfach keine Möglichkeit, mit ihnen über native Tools etwas zu tun. Eine Art Log-Parser wird benötigt, um sie zu verstehen. Ich habe eine in PowerShell von Grund auf neu geschrieben, und wir haben uns kürzlich Splunk angesehen. Splunk kann mit der Flut Schritt halten und auch mit unseren Syslog-Daten für Netzgeräte Schritt halten (fast so groß wie das Volumen). Alles in einer Datenbank. Es wird einen bulligen Server brauchen, um diese Art von Datenlast zu bewältigen, aber das ist ein lösbares Problem. Wir warten derzeit auf die richtigen Dark Rites, damit wir die Finanzierung für eine zentralisierte Protokollierungsumgebung erhalten können.

Es ist eine gute Sache, eine "einzelne Glasscheibe" als Blick in die Daten zu haben. Was Sie nicht bekommen, ist eine aktualisierte Textdatei, die Sie dann im Syslog-Stil beenden können. Was Sie erhalten, ist eine Schnittstelle mit einem umfangreichen Abfragesystem und (glaube ich) eine API zum Schreiben Ihrer eigenen Web-Frontends für Ihre eigenen schändlichen Bedürfnisse.

Wenn es um Windows-Ereignisprotokolldaten geht, ruft Splunk nicht die XML-Version dieser Ereignisse heraus, sondern die Textversion der "Detailansicht" jedes Ereignisses und analysiert diese. Ich hatte einige echte Bedenken hinsichtlich der Skalierung, aber ich war angenehm überrascht, als es trotzdem gelang, mit unseren Protokollierungslasten Schritt zu halten. Ich musste mit meinem PowerShell-Skript auf XML umsteigen, da das Parsen von Text viel zu lange dauerte.