Log-Klasse/Komponente mit TCP-Schnittstelle sinnvoll?

[s.h.a.r.k]

Ich habe den Threadtitel bewusst als Frage definiert, da ich hier eine Diskussion über folgende Idee starten will: ich habe in letzter Zeit mal meine Log-Komponente überarbeitet und über die möglichen Schnittstellen nachgedacht. Bisher hatte ich eine Klasse, die nach dem Singleton-Pattern gebaut war, also global verfügbar. Über eine Methode (entweder eine globale Methode oder eine Klassen-statische Methode) kann man einen Log schreiben. Diese verteilte diese Log-Message auf mehrere Module (erkläre ich gleich, was ich hierunter verstehe) und somit wird der Log "geschrieben".

Was ist nun ein Modul: ein Modul ist eine Klasse, die sich bei der Log-Komponente anmeldet und abmelden kann. Ein Modul kapselt ein bestimmtes Ziel, wie z.B. eine Datei. Ich habe bisher folgende Log-Module: Datei-Modul, ListBox-/Memo-/ListView-Modul, Datenbank-Modul. Somit ist es sehr einfach ein weiteres Modul, d.h. Ziel der Log-Messages, hinzuzufügen, ohne den Kern der Log-Komponente ändern zu müssen.

Nun hatte ich die Idee, die Schnittstelle zwischen der Kern-Log-Klasse und den Modulen via TCP(/IP) zu managen. Mir ist die erhöhte Komplexität (und die weitere Schicht) sehr wohl bewusst, würde aber auch gerne mal eure Meinung dies bzgl hören, ob es überhaupt sinnvoll sein kann. Natürlich wäre es hier auch gut zu wissen, wie und was ihr (im weitesten Sinne) loggt? Nutzt ihr das Loggen von Meldung nur zu Debug-Zwecken, oder auch für weitere Dinge? Evtl. auch für den User sichtbar (und nützlich)?

Warum mir diese Netzwerk-Schicht eingefallen ist:

• Auf Basis eines geeigenten Protokolls kann man ohne Probleme Kern und Module unabhängig voneinander weiterentwickeln. (war bisher aber auch schon gegeben)
• Server (Log-Kern) und Client (Module) können in unterschiedlichen Anwendungen und auch auf unterschiedlichen Rechnern liegen. Natürlich funktioniert die Kommunikation innerhalb der selben Anwendung.
• Weiteführende Idee: Programmierer startet Log-Client auf seinem Rechner und verbindet sich mit entferntem Programm, um eine Problemanalyse zu starten. Nutzer klickt sich durch die Anwendung und Programmierer sieht auf seinem Screen die Log-Meldungen und somit evtl. das Problem. Es müssen keinerlei Log-Dateien mehr verschickt werden.
• Man kann so auch einen einfachen Log-Server einrichten, der dann komplett unabhängig vom Programm und dem darunter liegenden Rechner ist.

Vielleicht ist die Idee ja auch nur bei den Haaren herbeigezogen, aber vielleicht kann sowas ja auch mal nützlich sein. Lasst mich mal wissen, was ihr so darüber denkt!

[BUG]

Mir käme in den Sinn, den Sende-Netzwerkteil als Modul einzubinden und den Empfangs-Netzwerkteil mit der gleichen Möglichkeit Module einzubinden wie die Log-Komponente zu implementieren.

[sx2008]

Es gibt schon ein Protokoll namens SysLog für diesen Zweck.
Also würde es Sinn machen, genau dieses Protokoll zu implementieren und auf der Empfangsseite einfach Open Source Software einzusetzen. (siehe http://www.msxfaq.de/tools/ntsyslog.htm)

[Phoenix]

Ist Sinnvoll Und gibts auch schon. Die meisten Log-Komponenten (z.B. die von Raize Software) beherrschen das von Haus aus.
Allein wenn Du an einer Stelle Log-Ausgaben von mehreren Servern auf denen einen Anwendung läuft mit tracen willst macht es schon Sinn.

Ich würde mich da nur eher auf bereits existierende Implementierungen stützen bevor ich den schmarrn nochmal Nachimplementiere.

[mjustin]

Kann mich da nur anschliessen - gängige Open Source Bibliotheken wie Log4Net, Log4J und Log4D bieten den TcpAppender, zum Beispiel damit man auch aus mehreren Instancen einer Anwendung (auf Terminalservern z.B.) problemlos auf das gleiche Log schreiben kann. Ein TcpLogServer sammelt und schreibt die Meldungen dann 'irgendwohin'. Mit einem einfachen FileAppender geht das nicht, sobald mehrere Anwendungen die gleiche Datei benutzen.

[s.h.a.r.k]

Zitat von BUG:

Mir käme in den Sinn, den Sende-Netzwerkteil als Modul einzubinden und den Empfangs-Netzwerkteil mit der gleichen Möglichkeit Module einzubinden wie die Log-Komponente zu implementieren.

Darauf wäre ich zunächst nicht gekommen, wäre aber dann wohl etwas flexibler und eben teilweise schlanker! Danke.

Zitat von Phoenix:

Ist Sinnvoll Und gibts auch schon. Die meisten Log-Komponenten (z.B. die von Raize Software) beherrschen das von Haus aus.
Allein wenn Du an einer Stelle Log-Ausgaben von mehreren Servern auf denen einen Anwendung läuft mit tracen willst macht es schon Sinn.

Ich würde mich da nur eher auf bereits existierende Implementierungen stützen bevor ich den schmarrn nochmal Nachimplementiere.

Das hatte ich mir schon fast gedacht. Nur wusste ich nicht, ob sowas wirklich sinnvoll sein kann bzw. aktiv genutzt wird. Aber wie es scheint, gibt es wahrlich für sowas Bedarf.

Muss mir dieses SysLog-Protokoll mal näher anschauen, ebenso andere Log-Komponenten.