syslog-ng reference manual ========================== Version 0.9, 15.07.2000 Englische Originalfassung: Balázs Scheidler Übersetzung und deren Copyright: Dobin Rutishauser Inhaltsverzeichnis: 0) Deutsche Übersetztung 1) Einführung zu syslog-ng 2) Message Paths 2.1) Sources 2.2) Filters 2.3) Destinations 2.4) Log Paths 2.5) Options 3) Reference 3.1) Source Driver 3.2) Destinations Driver 3.3) Filter Functions 3.4) Options 4) Performance tuning in syslog-ng 4.1) Setzen des Garbage Collector Parameters 4.2) Setzen der Output Queue Grösse 4.3) Setzen des Sync Parameters 5) Anhang 5.1) Die Syslog Facilities und Priorities 0) Deutsche Übersetzung Als ich dabei war, mein System besser zu sichern war ich auf der Suche nach einem Ersatz für die Standard Dämons. Als ich aber syslog-ng kennenlernte, merkte ich, wie Primitiv und uneffektiv eigentlich das normale syslog arbeitete. Um besser verstehen zu können, wie syslog-ng arbeitet, schrieb ich diese Übersetzung. Die Original Englische Dokumentation ist imho "schlecht", viel zu klein, umständlich und zu kompliziert geschrieben (sorry.. :). Diese Übersetzung basiert Hauptsächlich aus der Englisches HTML Dokumentation zu syslog-ng 1.4.2. Ich habe es je nach dem, manchmal mehr manchmal weniger frei zu übersetzten versucht. Ich weise darauf hin, das meine Englisch kentnisse nicht gerade gut sind (manche sagen dazu auch Schlecht ;), und wie gesagt, die Original Docu nicht einfach zu verstehen war. Ich hoffe aber trotzdem, das die Übersetzung anderen hilft, syslog-ng besser zu verstehen und nutzen zu können. Fehler, Anregungen, Kritik und Berichtigungen bitte zu dobin.rutishauser@gmx.net Copyright by Dobin Rutishauser (Anthraxx). Kopieren dieses Textes erlaubt, änderungen untersagt. 1) Einfuerung zu syslog-ng Download von syslog-ng: http://www.balabit.hu/downloads/syslog-ng/ Eine der meist Vernachlässigten Arbeiten unter Unix ist das Log Monitoring. Tägliche Checks der System Logs sind entscheidend für die Sicherheit und den Zustand eines Computer Systems. System Logs beinhalten viel Schrott, also Nachrichten die überhaupt nicht wichtig sind, aber auf der gegenseite berichten sie über wichtige Ereignise, die nicht zwischen den vielen anderen Nachrichten untergehen sollten. Mit den zurzeit erhältlichen Tools ist es schwierig, zwischen wichtigen und unwichtigen Nachrichten zu unterscheiden. Syslog-ng setzt hier gerade an der Quelle an. Es hat umfangreiche Sortier und Ausscheidungsmechanismen, die einem den täglichen Umgang mit den Logs erheblich vereinfachen. Log Nachrichten werden unter Linux nach /dev/log geschickt. Von dort werden sie von syslog-ng "aufgefangen" und weiterverarbeitet, also zb in Dateien geschrieben. Zur besseren Verarbeitung der Nachrichten werden sie durch 2 Eigenschaften definiert: Facility: Es gibt 12+8 (12 reelle und 8 lokale) vordefinierte facilities (mail, news, auth etc.), und 8 verschiedene priorities (von alert bis debug). Ein grosses Problem ist, das viele Facilities viel zu Allgemein sind (deamon), und diese Facilities von vielen Programmen benutzt werden, die überhaupt nichts miteinander zu tun haben. Von da her ist es schwierig, interesante Bits in den enormen Anzahl von Nachrichten zu finden. Ein zweites Problem ist, das es viele Programme gibt bei denen man ihren "facility code" einstellen kann. Am besten ist das ein Compile Time Parameter. 2) Message Paths In syslog-ng besteht ein Message Path aus einer oder mehreren sourcen, einer oder mehreren Filter Regeln und einem oder mehreren destinations (sinks). Eine Nachricht trifft durch den source ein, wenn die Nachricht zu einem der filter passt, wird sie in die vom Filter vorgegebenen Destination geschrieben. 2.1) Sources Vom source bekommt syslog-ng seine Log Nachrichten. Nachrichten, die von Programmen erstellt wurden werden an ein solchen Source geschickt, wo syslog-ng sie dann abfängt und weiterverarbeitet. Jedes OS hat ein Standardsource, wo die Nachrichten hingeschickt werden, ein Source kann aber auch eine Netzwerkverbindung sein. Ein source ist eine Ansammlung von source drivern, die die Nachrichten nach einer bestimmten Methode verwalten. Zb gibt es ein source driver für AF_UNIX, SOCK_STREAM Sockets, das der syslog() call unter Linux benutzt. Um einen Source zu definieren, braucht man das Source Statement im Konfigurationsfile. Source hat die folgende Syntax: source { source-driver(params); source-driver(params); ... }; Der identifier gibt dem Source ein Eindeutiges Identifikationsmerkmal. Man kann genau festlegen, welche Driver man benutzt um Log Nachrichten zu bekommen, darum muss man genau wissen, wie das System und syslogd genau kommunizieren. Hier ein paar Standardkommunikationswege: Kommunikationswege zwischen syslogd und seinen Clients: Platform Method Linux A SOCK_STREAM unix socket named /dev/log BSD flavors A SOCK_DGRAM unix socket named /var/run/log Solaris (2.5 or below) An SVR4 style STREAMS device named /dev/log Solaris (2.6 or above) In addition to the STREAMS device used in versions below 2.6, uses a new multithreaded IPC method called door. By default the door used by syslogd is /etc/.syslog_door Für jede dieser Kommunikationsarten gibts einen Source Driver in syslog-ng. Um zb mit einen Unix Socket mit SOCK_DGRAM style zu kommunizieren, benutzt man den "unix-dgram" Driver. Das selbe mit SOCK_STREAM, wie er unter Linux benutzt wird, heisst "unix-stream". Source Statement auf einem Linux System: source src { unix-stream("/dev/log"); internal(); udp(ip(0.0.0.0) port(514)); }; Jeder Driver hat Parameter, manche sind Obligatorisch, andere Optimal. Die Obligatorischen Parameter müssen zuerst angegeben werden. Wie beim Beispiel oben, wo die Driver Specifikation auf /dev/log zeigt. Verfügbare Source Driver in syslog-ng: Name Description internal Messages generated internally in syslog-ng unix-stream Opens the specified unix socket in SOCK_STREAM mode, and listens for messages. unix-dgram pens the specified unix socket in SOCK_DGRAM mode, and listens for messages. file Opens the specified file, and reads messages. pipe, fifo Opens the specified named pipe and reads messages udp Listens on the specified UDP port for messages. tcp Listens on the specified TCP port for messages. sun-stream, sun-streams Opens the specified STREAMS device on Solaris systems, and reads messages. 2.2) Filters Filter führen das "log routing" in syslog-ng aus. Sobald eine Nachricht auf einen Filter passt, sagt dieser was mit ihr geschieht und wie er weitergeleitet wird. Filter haben einen klar identifizierbaren (einzigartigen) Namen, damit kann man in den Log statements auf die Filter zurückgreifen. Syntax für ein Filter statement: filter { expression; }; Expression kann die Operatoren "and", "or" und "not" beinhalten, und alle von den untestehenden Funktionen. Beispiel: Ein Filter statement das auf alle Nachrichten von Computer "blurp" mit dem Inhalt "deny" zutrifft: filter f_blurp_deny { host("blurp") and match("deny"); }; Filter Funktionen in syslog-ng: Function Description facility() Selects messages based on their facility code level() or priority() Selects messages based on their priority program() Tries to match a regular expression to the program name field of log messages host() Tries to match a regular expression to the hostname field of log messages match() Tries to match a regular expression to the message itself. 2.3) Destinations Eine destination ist der "Ausgang", wo die Nachrichten hingesendet werden wenn eine Filter Regel zutrifft. Wie bei den sources gibt es bei den destinations mehrere möglickeiten, wohin und wie eine Nachricht gesendet wird. Um eine destination in der Konfigurations Datei zu definieren, braucht man ein destnation statment, das folgende Syntax hat: destination { destination-driver(params); destination-driver(params); ... }; Verfügbare destination drivers in syslog-ng Name Description file Writes messages to the given file fifo, pipe Writes messages to the given named pipe unix-stream Sends messages to the given unix socket in SOCK_STREAM style (Linux) unix-dgram Sends messages to the given unix socket in SOCK_DGRAM style (BSD) udp Sends messages to specified host and UDP port tcp Sends messages to specified host and TCP port usertty Sends messages to specified user if logged in program Forks and launches given program, and sends messages to its standard input. Für eine Detailiertere Liste über die unterstützten driver, siehe Reference Chapter. 2.4) Log Path In den vorherigen Kapiteln haben wir gelernt, wie wir sources, filters und desinations definieren. Nun müssen wir diese Zusammenführen, was mit dem log statement vollbracht wird. Jede Nachricht, die von den aufgeführten sources kommt, und auf die Filter (auf jeden) passt, wird zu dem aufgeführten destinations gesendet. Die Syntax: log { source(s1); source(s2); ... filter(f1); filter(f2); ... destination(d1); destination(d2); ... }; 2.5) Options Es existieren viele Optionen, die das verhalten von syslog-ng verändern. Für eine vollständige Liste verfügbarer Optionen siehe Reference Chapter. Die generelle Syntax lautet: options { option1(params); option2(params); ... }; Jede Option kann Parameter besitzen, wie in der Driver Specifikation. Liste der Global unterstützten Optionen in syslog-ng: Name Accepted values Description time_reopen() number The time to wait before a died connection is reestablished sync_freq() number The number of lines buffered before written to file mark_freq() number The number of seconds between two MARK lines. NOTE: not implemented yet. log_fifo_size() number The number of lines fitting to the output queue chain_hostnames() yes or no Enable or disable the chained hostname format. use_dns() yes or no Enable or disable DNS usage. syslog-ng blocks on DNS queries, so enabling DNS may lead to a Denial of Service i attack. To prevent DoS, protect your syslog-ng network endpoint with firewall rules, and make sure that all hosts, which may get to syslog-ng is resolvable. use_fqdn() yes or no Add Fully Qualified Domain Name instead of short hostname. gc_idle_threshold() number Sets the threshold value for the garbage collector, when syslog-ng is idle. GC phase starts when the number of allocated objects reach this number. Default: 100. gc_busy_threshold() number Sets the threshold value for the garbage collector, when syslog-ng is busy. GC phase starts when the number of allocated objects reach this number. Default: 3000. 3) Reference Dieses Kapitel dokumentiert die Driver und Optionen, die man in der Konfigurationsdatei benutzen kann. 3.1) Source Drivers Der folgende Driver wird im Source Statement benutzt, wie in einem vorherigem Kapitel beschrieben. internal() Alle von syslog-ng selber generierten Nachrichten kommen von diesem speciellem Source. Wenn man die Warnungen, Errors und "Noticies" von syslog-ng selber loggen will, muss man dieses Source in einem der Source Statements einfügen. Declaration: internal() Syslog-ng wird eine sich beschweren, wenn dieser Driver nicht eingefügt wird. Beispiel: Benutzung vom internal() driver source s_local { internal(); }; unix-stream() und unix-dgram() Diese zwei Driver sind etwa identisch: sie oeffnen den gegebenen AF_UNIX Socket und warten dort auf Nachrichten. unix-stream() wird primaer auf Linux benutzt, und benutzt eine SOCK_STREAM Semantic (verbindungsorientiert, keine Nachrichten koennen verloren gehen), unix-dgram wird auf BSDs benutzt, und benutzt SOCK_DGRAM semantics, das kann beudeuten, das Nachrichten verloren gehen koennen, wenn das System ueberlastet ist. Um die Gefahr von Denial of Service Attacken beim Verbindungs Orientrierten Protokoll zu vermindern, sollte die Anzahl gleichzeitig Akzeptierten Verbindungen limitiert werden. Dies ermöglich der max-connections() parameter. Declaration: unix-stream(filename [optons]); unix-dgram(filename [options]); Die folgen Optionen sind moeglich: Name Type Description Default owner() string Set the uid of the socket. root group() string Set the gid of the socket. Default: root. root perm() number Set the permission mask. For octal numbers prefix the number with '0', e.g. use 0755 for rwxr-xr-x. 0666 keep-alive() yes or no Selects whether to keep connections opened when syslog-ng is restarted, can be used only with unix-stream(). Default: yes. yes max-connections() number Limits the number of simoultaneously opened connections. Can be used only with unix-stream(). 10 Beispiel: Benutzung des unix-stream() und unix-dgram() Drivers: source s_stream { unix-stream("/dev/log" max-connections(10)); }; source s_dgram { unix-dgram("/var/run/log"); }; tcp() und udp() Mit diesen zwei Drivern kann man Nachrichten vom Netzwerk empfangen, und wie der Name der Driver zeigt, kan man UDP und TCP als Protokoll benutzen. UDP ist ein simples Datagram Protokol, welches nach dem Prinzip "best möglicher Service" arbeitet, um Nachrichten zwischen Hosts zu verschicken. Man kann bei der Übertragung Nachrichten verlieren, und diese auf dem Protokoll Level verlorengegangenen Nachrichten werden nicht nochmal verschickt. TCP ist ein Verbindungs-Orientriert Service, was ca heisst, das es eine flow-controlled Nachrichten Pipeline ist. In dieser Pipeline wird jede Nachricht bestätigt, und jedes verlorene Packet wird nochmals gesendet, bis es angekommen ist. Im allgemeinen ist es sicherer TCP zu benutzen, weil abbgebrochene Verbindungen entdeckt werden können, und weil keine Nachrichten verloren gehen, aber das Syslogd Protokoll benutzt Traditionell UDP. Keine der tcp() oder udp() Driver benötigen Positional Parameters. In der Standardeinstellung warten sie auf 0.0.0.0/514 auf Verbindungen, das heisst das syslog-ng auf allen Verfügbaren Interfaces auf Verbindungen wartet. Um die zu Aktzeptierenden Verbindungen auf ein Interface zu beschraenken, benutzt man den localip() parameter, wie unten beschrieben. NOTE: der TCP Port 514 wird Standardmaessig von rshell benutzt, sie muessen also einen anderen Port nehmen wenn sie vorhaben, rshell und syslog-ng zur gleichzeitig zu benutzen. Declaration: tcp([options]); udp([options]); udp() und tcp() besitzen die folgenden Optionen: Name Type Description Default ip or localip string The IP address to bind to. 0.0.0.0 Beispiel: Benutzung des udp() und tcp() Drivers source s_tcp { tcp(ip(127.0.0.1) port(1999); max-connections(10)); }; source s_udp { udp(); }; file() Normalerweise schickt der Kernel seine Nachrichten zu einem Speziellen Datei (/dev/kmsg bei BSDs, /proc/kmsg auf Linu), um solche Dateien zu lesen braucht man den file() driver. NOTE: mit file() ist es nicht moeglich eine Datei wie mit "tail -f" auszugeben. Um ein wachsendes Logfile in Syslog-ng (zb access.log) zu schreiben, muss man ein solchen Script benutzen: Beispiel: Beispiels Script um ein wachsendes Logfile in syslog-ng zu übertragen #!/bin/sh tail -f | logger -p local4.info NOTE: in Linux liest der klogd Daemon die Kernel Nachrichten und leitet sie zum syslogd Prozess weiter. klogd ersetzt Teile der Kernel Nachrichten, wie zb Adressen mit ihren Symbolischen Namen (von /boot/System.map). Wenn sie diese Funktionalität benutzen wollen, müssen sie klogd zusammen mit syslog-ng laufen lassen. Declaration: file(filename); Beispiel: Benutzung des file() Drivers source s_file { file("/proc/kmsg"); }; pipe() Der pipe Driver öffnet eine Named Pipe mit dem gegebenen Namen, und wartet dort auf Nachrichten. Man benutzt ihn als Native Message Getting Protokoll in HP-UX. Declaration: pipe(filename); NOTE: Sie müssen diese pipe zuerst mit mkfif(1) erstellen. Beispiel: Benutzung des pipi() Drivers source s_pipe { pipe("/dev/log"); }; sun-streams() driver Solaris benutzt seine STREAM API um Nachrichten zum syslogd Prozess zu senden. Sie müssen syslog-ng mit diesem Driver kompilieren (siehe ./configure --help), um ihn benutzen zu können. Neuere Versionen von Solaris (2.5.1 und höher), benutzen zu STREAMS noch einen neuen IPC namens door um die Übertragung einer Nachricht zu bestätigen. Syslog-ng unterstützt diesen neuen IPC mit der door() Option (siehe weiter unten). 3.2) Destination Drivers Destination Drivers leiten die Log Nachrichten nach ausserhalb syslog-ng: entweder in eine Datei oder in ein Netztwerk Socket. file() Der File Driver ist einer der wichtigsten Destination Drivers in syslog-ng. Er erlaubt, die Log Nachrichten in eine Named Datei, oder auch in mehrere Dateien gleichzeitig auszugeben. Der Destination Dateiname kann Makros beinhalten, die Expandiert werden wenn die Nachricht geschrieben wird. Das heisst, ein simpler file() Driver kann mehrere verschiedene Dateien erstellen. Makros können eingesetzt werden, indem ein "$" Zeichen vor den Makro Namen gesetzt wird, wie in Perl/PHP. Wenn der expandierte Dateiname ein nichtexistierendes Verzeichniss ist, wird es nach den create_dirs() Einstellungen erzeugt. Verfügbaer Makros bei der Dateinamen Expansion Name Description HOST The name of the source host where the message is originated from. If the message traverses several hosts, and chain_hostnames() is on, the first one is used. FACILITY The name of the facility, the message is tagged as coming from. PRIORITY or LEVEL The priority of the message. PROGRAM The name of the program the message was sent by. YEAR The year the message was sent. MONTH The month the message was sent. DAY The day of month the message was sent. Verfügbare Optionen für file() Name Type Description Default log_fifo_size() inumber The number of entries in the output fifo. Use global setting. sync_freq() number The logfile is synced when this number of messages has been written to it. Use global setting. encrypt() yes/no Encrypt the resulting file. NOTE: this is not implemented as of 1.3.14. Use global setting. compress() yes/no Compress the resulting logfile using zlib. NOTE: this is not implemented as of 1.3.14. Use global setting. owner() string Set the owner of the created filename to the one specified. root group() string Set the group of the created filename to the one specified. root perm() number The permission mask of the file if it is created by syslog-ng. 0600 dir_perm() number The permission mask of directories created by syslog-ng. Log directories are only created if a file after macro expansion refers to a non-existing directory, and dir creation is enabled using create_dirs(). 0600 create_dirs() yes/no Enable creating non-existing directories. no pipe() Dieser Driver sendet die Nachrichten zu einer Namen Pipe, wie /dev/xconsole. unix-stream() & unix-dgram() Dieser Driver sendet die Nachrichten zu einem Unix Socket, entweder in SOCK_STREAM oder SOCK_DGRAM Mode. udp() & tcp() Dieser Driver sendet die Nachrichten zu einem anderen Host im lokalen Intranet oder Internet, entweder mit dem UDP oder TCP Protokoll. usertty() Dieser Treiber schreibt die Nachrichten zu einem Terminal von einem eingeloggtem User. program() Dieser Driver fork()'s und führt das angegebene Program mit den Argumenten aus und sendet die Nachrichten als stdin zum Child. 3.3) Filter Functions Die folgenden Funktionen können bei dem Filter Statement benutzt werden, wie in den Vorherigen Kapitel beschrieben. 3.4) Options Die folgenden Optionen können beim Option Statement benutzt werden, wie in einem vorherigem Kapitel beschrieben. 4.0) Geschwindigkeits Tuning in syslog-ng Es gibt noch verschiedene Einstellungen, mit denen man syslog-ng tunen kann. Die Standardwerte sind für einen einzelnen Server oder Workstation Installation ausgelegt, sind aber für einen Zentralen Loghost der die Logs von verschiedenen anderen Hosts empängt, nicht gut genug. 4.1) Setzen des Garbage Collector Parameters Syslog-ng benutzt intern den Garbage Collector, und während der Garbage Collector läuft, werden keine Nachrichten angenommen. Das kann Probleme bereiten, wenn nicht Verbindungsorentierte Protokolle benutzt werden, wie unix-dgram() oder udp(). Es existieren zwei Einstellungen, die die Garbage Collection Phase kontrollieren: gc_threshold_idle() Mit dieser Option kann man die Idle Zeit vom GC bestimmen. Wenn die Anzahl der "Allocated Objects" diese Nummer erreichen, und das System Idle ist (keine Nachricht ist innerhalb 100msec angekommen), beginnt die GC Phase. Dadurch das dass System Idle ist, werden warscheinlich keine Nachrichten verlorengehen wenn der GC läuft. Die Nummer sollte klein sein, aber höcher als die mindestens "allocated objects". Das minimum der "Allocated Objects" variiert je nach konfiguration, aber man kann die genaue Anzahl mit der "-v" Option herausfinden. gc_threshold_busy() Dieser Wer wird benutzt wenn syslog-ng keine Nachrichten mehr annehmen kann (d.h, wenn innert 100msec ein I/O Event erfolgt). Um zu verhindern, das syslog-ng den gesamten verfügabaren Speicher isst, GC sollte auch in diesen Fällen laufen. Dieser Wert sollte so hoch sein, das die "log burstes" nicht vom GC Unterbrochen werden. /* Anm des Übersetzers: Ich versuchte, die vorherigen zwei Optionen so gut es geht zu übersetzen, aber ich denke das Teile davon falsch sind. Wer sich wirklich dafür Interesiert, sollte die Englische Original Dokumentation zur Rate ziehen. */ 4.2) Setzen der Output Queue Grösse Syslog-ng liest die ganze Zeit von seinen Log Channels, um die laufenden Dämons nicht zu blockieren. Dies kann zum Verlust von Nachrichten führen, wenn die Output Queue voll ist. Darum ist es wichtig, die Output Queze Grösse zu setzen (anzahl Nachrichten). Dieses kann man Global, oder in einer Destinatin setzen. options { log_fifo_size(1000); }; or destination d_messages { file("/var/log/messages" log_fifo_size(1000); }; Man sollte die FIFO Grösse nach der geschätzten Anzahl of Nachrichten in einem Nachrichten-Schub setzen. Wenn der "Schub" (Burst) die Bandbreite der Destination Pipe übersteigt, leitet syslog-ng die Nachrichten in die destinatin pipe, wenn der Schub fertig ist. Natürlich kann syslog-ng nicht die Bandbreite des Netzwerkes erhöhen, wenn also der Destination Host in einem gut benutzem Netzwerk steht, und der Log Traffic übersteigt die Bandbreite von diesem Netzwerk, kann syslog-ng nicht mehr tun. Aber es versucht sein bestes. 4.3) Setzen des Sync Parameters Der sync Parameter macht nicht genau das, wie sie erwarten werden. Wie sie gesehen haben, zu sendende Nachrichten werden in der Output Queue Zwischengespeichert. Der sync Parameter bestimmt die Anzahl Nachrichten in diesem Buffer bevor irgendwas geschrieben wird. Übrigens werden nicht alle zwischengespeicherten Nachrichten auf einmal geschrieben, sondern jede Nachricht einzeln mit einem write() System Call. 5) Anhang 5.1) Die Syslog Facilities und Priorities Die, unter Zuhilfname der Linux Sourcen und des Buches "Linux Hackers Guide", beschreibung der allgemeinen Syslog-Facilities und Priorities. Syslog Facilities: auth eine Sicherheitsfunktion, die Benutzerauthentifizierung in verschiedenen Diensten wie ftp, login usw verfolg. (Im Wesentlichen verfolgt die auth-Funktion jede Benutzeraktion, die indenen Benutzernamen und ein Passwort verlangt wird, um sich einzuloggen oder die Ressourcen des Zielrechners zu benutzen.) authpriv eine Sicherheitsfunktion, die Sicherheits-/Autorisierungmeldungen verfolgt daemon verfolgt Systemdämon Meldungen user verschiedene user-level Meldungen kern verfolgt Kernel Meldungen ftp verfolgt Meldungen vom ftp-System cron verfolgt Meldungen vom cron-System. lpr verfolgt Meldungen des Druckersystems mark Sollte man nicht benutzen, zu internen zwecken mail verfolgt Meldungen des Mail-Systems news verfolgt Meldungen des News Systems security dasselbe wie auth syslog für von Syslog generierte Nachrichten uucp verfolgt Meldungen des UUCP Systems Priorities: alert bezeichnet einen ernstzunehmenden Fehler, die sofortige Aufmerksamkeit verlangen crit Fatale Fehler debug Debugging Informationen zu laufenden Prozessen emerg Notfall Zustände err Meldungen bestehen aus Fehlerzuständen info Normale Informationsmeldungen von Programmen notice Standardmeldungen, aber wichtiger als nur Informationscharakter warn Standardwarungen (das System oder die Ressource konnte zb die Aufgabe nicht ausführen)