|
Wenn ein Dienst den Syslog-Dienst verwendet, schickt er seine Meldungen also einfach an Syslog. Eine Meldung ist im Wesentlichen eine Textzeile. Zusätzlich enthält diese noch einige Statusinformationen, beispielsweise wie wichtig diese Meldung ist und zu welchem "Themengebiet" sie gehört bzw. von welcher Quelle sie kommt.
Syslog prüft anhand dieser Werte, ob und wie diese Meldung verarbeitet werden soll. Man kann Syslog zum Beispiel so konfigurieren, dass wichtige Meldungen in der einen und unwichtige in einer anderen Datei stehen, oder dass alle Meldungen, die vom Mailsystem kommen, auf einen anderen Rechner übertragen werden sollen und weiteres.
|
Syslog definiert eine Reihe von Quellen oder Themengebieten für Meldungen. Diese werden als facilities bezeichnet. Dabei ist es nur eine Konvention, wann welche Facility verwendet wird. Manchmal ist eine eindeutige Zuordnung nicht einfach möglich. Hier muß man nachsehen, welche Facility ein Dienst benutzt (bei manchen Diensten läßt sie diese auch einstellen).
Die nachfolgende Übersicht beschreibt die Facilities kurz:
| Name |
Bedeutung |
| auth, authpriv |
Meldungen, die zur Authentifizierung gehören, beispielsweise falsche Passwörter. |
| cron |
Meldungen, die von Cron erzeugt wurden, oder von Prozessen, die von Cron gestartet werden (die Standard-Ausgabe und Stardard-Fehler-Ausgabe werden jedoch von Cron nicht an Syslog gereicht, sondern per EMail verschickt). |
| daemon |
Meldungen von allgemeinen Diensten, wie zum Beispiel einem FTP-Server. |
| kern |
Meldungen des Systemkernels. Sollte von keinem Dienst verwendet werden. Hierzu gehören beispielsweise Hardware-bezogene Meldungen. |
| lpr |
Meldungen des Drucksystems
(Druckerspooler). |
| mail |
Meldungen des Mailsystems (beispielsweise von sendmail und fetchmail). |
| mark |
Nur für Syslog-interne Zwecke, sollte nie verwendet werden. |
| news |
Meldungen des News-Systems, zum Beispiel eines Newsservers. |
| syslog |
Meldungen von Syslog selbst. |
| user |
Meldungen von Benutzersystemen wie zum Beispiel eigenen Scripten. |
| uucp |
Meldungen von Unix-Unix-Copy (UUCP wird heute kaum noch verwendet). |
| local0 bis local7 |
Diese sind frei und können nach Belieben verwendet werden. Bei Diensten, bei denen man die zu verwendende Facility einstellen kann, kann man diese verwenden und je nach Bedarf verteilen. |
|
|
Syslog definiert eine Reihe von Namen, die die Wichtigkeit beschreiben. Diese Priorität wird englisch als priority oder severity bezeichnet. Manchmal spricht man auch vom log level. Auch diese Eigenschaft kann man verwenden, um die Meldungen differenziert zu verarbeiten, wie bereits angedeutet.
Die folgende Übersicht nennt die definierten Prioritäten:
| Name |
Beschreibung |
| debug |
Unwichtige Meldungen, dienen nur zu Debug-Zwecken (Fehlerfindung vor allem bei der Entwicklung). |
| info |
Informative, nicht weiter wichtige Meldungen. |
| notice |
Informative Meldungen, die größere Bedeutung haben als info. |
| warning |
Warnungen, also Meldungen, die nicht-fatale Fehler anzeigen. |
| err |
Fehlermeldungen, die kleine Störungen anzeigen. |
| crit |
Kritische (schwerere) Fehler, die beispielsweise Teilausfälle anzeigen. |
| alert |
Schwere Fehler, die erhebliche Störungen und Ausfälle anzeigen. |
| emerg |
Sehr schwere Fehler, die beispielweise den Totalausfall des Systems anzeigen können und schwere Kernelfehler (Hardwareausfälle). |
Als Faustregel gilt hier: Alles, was wichtiger oder gleich warning ist, verdient auf jeden Fall Aufmerksamkeit.
|
|
Zu diesen beiden essentiellen Eigenschaften kommt die Information über den Zeitpunkt der Meldung hinzu (diese wird von Syslog automatisch beigefügt), die Prozeß-ID des Prozesses, der diese Meldung erzeugte, und ein Tag, das meistens den Namen des Programmes enthält, das die Meldung erzeugte (beispielsweise verwendet Sendmail das Tag sendmail). Auch der Hostname des Systems wird hinzugefügt, was insbesondere wichtig ist, wenn man von mehreren Systemen über das Netzwerk auf ein zentrales loggt.
|
|
Beim Schreiben in Logdateien verwendet Syslog ein festes Format. Eine Meldung ist immer eine Zeile. Zu Beginn steht der Zeitstempel, dann folgt der Hostname des Systems. Das dritte Feld ist das Tag (also meistens der Programmname) und in eckigen Klammern dessen Prozeß-ID. Der Rest der Zeile ist die Textnachricht dieser Meldung. Bei einigen Meldungen weicht das Format geringfügig ab, beispielsweise kann die Prozeß-ID entfallen (wie etwa bei Kernel und syslog Meldungen).
Die Facility und Priority sind aus einer solchen Zeile leider nicht mehr erkennbar.
Ein Beispiel für eine Logmeldung:
| /var/log/messages |
Mar 10 13:30:30 atlas syslogd 1.3-3: restart.
|
Diese Meldung wurde am 10. März um 13:30 Uhr auf einem Host namens atlas erzeugt, und gibt an, dass Syslog gestartet wurde (diese Meldung erzeugt Syslog selbst beim Start).
|
|
Der Kernel verschickt seine Meldungen auf eine etwas andere Art. Der Kernel kann sich nicht wie ein normales Programm verhalten, beispielsweise weil er als erstes läuft, kein normaler Prozeß ist, und weil er aus Performancegründen nicht auf die Fertigstellung von Schreiboperationen warten kann.
Der Kernel legt alle Meldungen in einem speziellen Speicherbereich ab. Diese kann man zunächst überhaupt nicht lesen. Es gibt nun einen speziellen Dienst, den Kernel-Logger klogd. Dieser Dienst holt die Meldungen aus dem Speicherbereich ab und wandelt sie auch in menschenlesbare Meldungen um. Der Kernel-Logger kann die Kernelmeldungen in eine Datei schreiben, oder an Syslog weiterversenden. Die zweite Möglichkeit ist die Voreinstellung. Startet man den Kernel-Logger, holt er die Kernelmeldungen sofort ab, und verschickt diese an Syslog. Syslog schreibt sie dann in eine Datei. Normalerweise wird klogd automatisch direkt nach syslogd gestartet.
|
|
SelfLinux 
