|
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 anzeuigen.
|
| 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 
