[erledigt] Windows Dienst: Wohin die Log-Dateien schreiben

Hallo zusammen,

ich habe mir einen Windows Dienst geschrieben, der mir im Hintergrund viel Arbeit erledigen muss. Da dabei aber auch gerne mal Fehler entstehen können, muss das ja irgendwie in eine Log Datei geschrieben sein.

Dazu habe ich mir einen TraceListener geschrieben, der mir dann eine Log Datei schreiben soll. Die Log Datei soll im selben Verzeichnis sein, wie die Exe des Dienstes. So kann man die Datei am schnellsten lokalieren und drinne nachsehen, was denn da schief geht.

Nun zu meiner Frage. Wenn ich dem Tracelistener einen FileStream zu der Datei mitgebe, die im selben Verzeichnis wie die Exe geschrieben werden soll, funktioniert das solange gut, wie ich die Exe des Dienstes von Hand starte ( klar die Exe terminiert, da der Service nicht installiert ist, aber die Log wird erstellt ).

Wenn ich den Dienst aber dann registriere, wird mir die Log in einem total falschen Verzeichnis geschrieben: C:\Windows\sysWOW64\Log.log

Da ist die Datei natürlich kaum noch auffindbar.

Nun zu meiner Frage. Wo ist es am besten die Log für einen Windows Dienst zu schreiben. Okay, man könnte das Ereignisprotokoll dazu verwenden. Aber ich möchte auch die möglichkeit haben, das ich einem Anwender dann sagen kann, gehe mit dem Explorer in Verzeichnis X und schicke mir die Logdatei per Mail zu.

Wie macht Ihr das?

Grüße
Stephan

Hallo Stipo,

warum gibts du dem TraceListener einen Stream und nicht den Dateinamen?

Ab Vista kann das Trace in Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "MeineFirma/MeinService/Logs" geschrieben werden (natürlich mit Path.Combine zusammengebaut).

in einem total falschen Verzeichnis

Aus Windows-Sicht ist das Verzeichnis schon korrekt, nur es ist halt nicht jenes was du dir erwartest 😉

mfG Gü

Hallo Gü,

warum gibts du dem TraceListener einen Stream und nicht den Dateinamen?

Hmm... ich meine, weil im Buch vom Kühnel das so drinne steht 😃 Aber gut, ich werde das mal so testen 😉

Ab Vista kann das Trace in Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "MeineFirma/MeinService/Logs" geschrieben werden (natürlich mit Path.Combine zusammengebaut).

Das dachte ich mir schon fast, das unter CommonApplicationData der beste Ort zu sein scheint. Wollte da nur mal noch die Meinung im Forum hören, wie das andere handhaben.

Aus Windows-Sicht ist das Verzeichnis schon korrekt, nur es ist halt nicht jenes was du dir erwartest 😉

Da ich noch wenig mit den Services gemacht habe, war ich dann anfangs schon verwundert, warum der mir die Log nicht so schreibt wie ich das erwartet habe 😃
Aber Du hast schon recht. Aus Sicht von Windows ist das alles korrekt, nur ist man im ersten moment dann erstmal geschockt, warum der Service auf einmal anders reagiert wie man den in der Console noch getestet hat 😃

Also dann packe ich meine Log mal in CommonApplicationData.

Grüße
Stephan

Hallo zusammen,

Okay, man könnte das Ereignisprotokoll [also das, was man über die Windows-Ereignisanzeige angezeigt bekommt] dazu verwenden.

es sei noch erwähnt, dass das die standardmäßige und bevorzugte Vorgehensweise bei Diensten ist. Natürlich kann es immer Gründe geben davon abzuweichen, aber im Normalfall sollte ein Dienst dorthin schreiben.

herbivore

PS: Das gilt auch, wenn sehr viele Log-Einträge geschrieben werden sollen. Das Windows Event Log ist darauf ausgelegt. Außerdem gibt es die Möglichkeit, eigene Quellen (=Kategorien) einzurichten, um die eigenen Log-Einträge separat zu halten.

Hallo herbivore,

Ja das weiß ich. Das steht so in der Art auch im Buch mit drinne.
Nur versuche mal einen Anwender zu sagen, der gerade mal so versteht wie ein PC funktioniert, das er dir einen Fehler aus dem Ereignisprotokoll heraus suchen soll.
Da ist es einfacher dem den Weg zu einer Datei zu sagen, die er mit rechtsklick auf die Maus in das Mailprogramm und in eine Mail bekommt 😃

Grüße
Stephan

Hallo Stipo,

dafür muss ein erfahrener Anwender erst suchen, wo die Text-Datei ist, statt einfach an am zentralen Punkt "Ereignisanzeige" zu schauen und dort alle Informationen aller Dienste auf einen Blick und ohne suchen zu haben.

Natürlich habe ich gesagt, dass es immer Gründe geben kann, davon abzuweichen. Aber diese Gründe sollten schon substantiell sein und nicht nur "weil man es lieber anders hätte".

Dazu kommt, dass Anwender nichts lernen, wenn man es ihnen zu bequem macht. Die Ereignisanzeige ist nun wirklich kein Buch mit sieben Siegel. Das kann man auch einem unbedarften Anwender ohne Weiteres zutrauen.

Die Ereignisanzeige ist schon der Standard für Meldungen von Diensten:

Zitat von: EventLog
Applications and services should write to the Application log or a custom log.

Es gibt dafür extra die Klasse EventLogTraceListener.

herbivore

Nur versuche mal einen Anwender zu sagen, der gerade mal so versteht wie ein PC funktioniert, das er dir einen Fehler aus dem Ereignisprotokoll heraus suchen soll.

Dann liefere einfach noch eine kleine Applikation mit aus, die das für den User erledigt - das Ereignisprotokoll lässt sich ja auch programmatisch auslesen.
Dann muss der User nur noch doppelklicken 😉

Also ich muss wirklich auch sagen, meinem Klientel möchte ich nicht erklären wo die Ereignisanzeige ist, wie man die bedient und was sie tut.
Es kommt drauf an wer die Logs suchen und finden soll und wie die Leute zu dieser Art von Unterstützung überhaupt stehen. Ein Admin hat damit weniger Probleme als ein gewöhnlicher User, der schon ins schwitzen kommt wenn er mal den Dateiexplorer öffnen soll oder ähnliches. Dann ists noch eine Frage wie die User das Programm an sich bewerten, wenn man "total komplizierte Dinge tun soll, die doch kein normaler Mensch verstehen kann" ...

Bei Datenbank-gestützten Programmen kann man Logs in die Datenbank schreiben. Dann stehen nicht zig andere Meldungen dazwischen so wie bei der Ereignisanzeige. Und vor allem, die Meldungen bleiben so lange drin wie man das will, sie fliegen nicht raus weil das Eventlog sonst zu groß würde.

Hallo chilic,

meinem Klientel möchte ich nicht erklären wo die Ereignisanzeige ist, wie man die bedient und was sie tut.
...als ein gewöhnlicher User, der schon ins schwitzen kommt wenn er mal den Dateiexplorer öffnen soll oder ähnliches.

Genau dem gehst du mit dem Vorschlag von winSharp93 aus dem Weg. Kein Zugriff des Benutzers auf das Eventlog notwendig und auch nicht auf den Datei-Explorer. Einfach ein paar Klicks und das sollte jeder können.

Bei Datenbank-gestützten Programmen kann man Logs in die Datenbank schreiben

Das birgt aber Gefahren. Siehe die Überlegung in Exception: Zu viele Stummelstücke in XML (ist zwar auf XML bezogen, gilt aber generell).

Dann stehen nicht zig andere Meldungen dazwischen so wie bei der Ereignisanzeige.

Es kann auch in einem Custom Log geschrieben werden - siehe oben den Link von herbivore. Der IE macht das zB auch so (zumindest auf meinem Rechner ist dafür ein Custom Log angelegt (obwohl ich den gar nicht verwende 😉)).

Und vor allem, die Meldungen bleiben so lange drin wie man das will, sie fliegen nicht raus weil das Eventlog sonst zu groß würde.

Dafür kann zusätzlich in eine DB geloggt werden. Aber primär und zur Sicherheit des Logs - Sicherheit im Sinne dass es auch ankommt - ist das EventLog zu bevorzugen.

mfG Gü

Nabend zusammen,

sehr schöne Diskussion was hier entstanden ist.
Einige aspekte werde ich mit nehmen aus der Diskussion.

Danke noch an alle. Dieser Beitrag wird sicher noch anderen weiter helfen, bei dem doch umfangreichen Thema.

Grüße
Stephan