Daemon-Protokollierung unter Linux

Ich habe also einen Daemon, der auf einem Linux-System läuft, und ich möchte eine Aufzeichnung seiner Aktivitäten haben: ein Protokoll. Die Frage ist, was ist der “beste” Weg, dies zu erreichen?

Meine erste Idee ist, einfach eine Datei zu öffnen und darauf zu schreiben.

FILE* log = fopen("logfile.log", "w");
/* daemon works...needs to write to log */
fprintf(log, "foo%s\n", (char*)bar);
/* ...all done, close the file */
fclose(log);

Ist irgendetwas grundsätzlich falsch daran, auf diese Weise zu loggen? Gibt es einen besseren Weg, z. B. ein in Linux integriertes Framework?

Unix hat seit langem ein spezielles Protokollierungs-Framework namens Syslog. Geben Sie Ihre Shell ein

man 3 syslog

und Sie erhalten die Hilfe für die C-Schnittstelle dazu.

Etwas Beispiele

#include <stdio.h>
#include <unistd.h>
#include <syslog.h>

int main(void) {

 openlog("slog", LOG_PID|LOG_CONS, LOG_USER);
 syslog(LOG_INFO, "A different kind of Hello world ... ");
 closelog();

 return 0;
}

Dies wird wohl ein war ein Pferderennen, aber ja, die Syslog-Funktion, die in den meisten, wenn nicht allen Un*x-Derivaten vorhanden ist, ist der bevorzugte Weg. Es ist nichts falsch daran, sich in eine Datei einzuloggen, aber es hinterlässt eine Reihe von Aufgaben auf Ihren Schultern:

• Gibt es ein Dateisystem an Ihrem Logging-Standort, um die Datei zu speichern?
• Was ist mit Puffern (für Leistung) vs. Leeren (um Protokolle vor einem Systemabsturz zu schreiben)
• Wenn Ihr Daemon lange läuft, was machen Sie mit der ständig wachsenden Protokolldatei?

All dies und mehr erledigt Syslog für Sie. Die API ähnelt dem printf-Clan, sodass Sie keine Probleme haben sollten, Ihren Code anzupassen.

Ein weiterer Vorteil von Syslog in größeren (oder sicherheitsbewussteren) Installationen: Der Syslog-Daemon kann so konfiguriert werden, dass er die Protokolle anstelle (oder zusätzlich zum) lokalen Dateisystem an einen anderen Server sendet, um sie dort aufzuzeichnen.

Es ist viel praktischer, alle Protokolle für Ihre Serverfarm an einem Ort zu haben, anstatt sie auf jedem Computer separat lesen zu müssen, insbesondere wenn Sie versuchen, Ereignisse auf einem Server mit denen auf einem anderen zu korrelieren. Und wenn einer geknackt wird, können Sie seinen Protokollen nicht mehr vertrauen … aber wenn der Protokollserver sicher geblieben ist, wissen Sie, dass nichts aus seinen Protokollen gelöscht wurde, sodass alle Aufzeichnungen über das Eindringen intakt bleiben.

Ich spucke viele Daemon-Meldungen an daemon.info und daemon.debug aus, wenn ich Unit-Tests durchführe. Eine Zeile in Ihrer syslog.conf kann diese Nachrichten in eine beliebige Datei einfügen.

http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/040/4036/4036s1.html hat eine bessere Erklärung der C-API als die Manpage, imo.

Syslog ist eine gute Option, aber Sie sollten sich vielleicht log4c ansehen. Das Log4[something] Frameworks funktionieren gut in ihren Java- und Perl-Implementierungen und ermöglichen es Ihnen, aus einer Konfigurationsdatei auszuwählen, ob Sie sich entweder an Syslog, Konsole, Flatfiles oder benutzerdefinierten Protokollschreibern anmelden möchten. Sie können spezifische Protokollkontexte für jedes Ihrer Module definieren und jedes Kontextprotokoll auf einer anderen Ebene haben, wie durch Ihre Konfiguration definiert. (Trace, Debug, Info, Warn, Error, Critical) und lassen Sie Ihren Daemon diese Konfigurationsdatei im Handumdrehen erneut lesen, indem Sie ein Signal abfangen, wodurch Sie die Protokollebenen auf einem laufenden Server manipulieren können.

Wie oben erwähnt, sollten Sie sich Syslog ansehen. Aber wenn Sie Ihren eigenen Protokollierungscode schreiben möchten, würde ich Ihnen raten, den Modus “a” (write append) von fopen zu verwenden.

Einige Nachteile des Schreibens Ihres eigenen Protokollierungscodes sind: Handhabung der Protokollrotation, Sperren (wenn Sie mehrere Threads haben), Synchronisierung (möchten Sie warten, bis die Protokolle auf die Festplatte geschrieben werden?). Einer der Nachteile von Syslog besteht darin, dass die Anwendung nicht weiß, ob die Protokolle auf die Festplatte geschrieben wurden (sie könnten verloren gegangen sein).

Wenn Sie Threading verwenden und die Protokollierung als Debugging-Tool verwenden, sollten Sie nach einer Protokollierungsbibliothek suchen, die eine Art Thread-sichere, aber nicht gesperrte Ringpuffer verwendet. Ein Puffer pro Thread, mit einer globalen Sperre nur bei unbedingter Notwendigkeit.

Dadurch wird vermieden, dass die Protokollierung ernsthafte Verlangsamungen Ihrer Software verursacht, und es wird vermieden, dass Heisenbugs erstellt werden, die sich ändern, wenn Sie die Debug-Protokollierung hinzufügen.

Wenn es ein komprimiertes Hochgeschwindigkeits-Binärprotokollformat hat, das keine Zeit mit Formatoperationen während des Protokollierens verschwendet, und einige nette Werkzeuge zum Analysieren und Anzeigen von Protokollen, ist das ein Bonus.

Ich würde einen Verweis auf einen guten Code dafür geben, aber ich habe selbst keinen. Ich will nur einen. 🙂