Der Corba-Logger

Motivation und Zweck

sieht man in Unix das Syslog neu, so werden dort Ereignisse geloggt.
Bei einer objektorientierten Rekonstruktion liegt es also nahe, alle Ereignisse in einem Eventchannel zu leiten. Von diesem aus können filternde Ereigniskanäle interessierende Ereignisse auswählen und dahinter können dann Systemmanagementprogramme angesiedelt werden.
Damit können dann auch betriebssystemübergreifend Ereignisse verarbeitet werdden. Es ist auch eine SNMP-Brücke denkbar.

Der klassische Syslogdamon von UNIX wird aufgeteilt in

Systemereignisquelle: diese liest die Kernereignisse aus und dient als Brücke für nicht-Corba- Subsysteme
Ereignisverteiler und Filter: Diese werten im prinzip die syslog.conf aus
persistente Ereignisrecoder: diese sammeln alle Ereignisse aus einem Ereigniskanal

Der UNIX-Syslog kann nur die einkompilierten Subsysteme KERN,MAIL,LPR,UUCP,NEWS,AUTHPRIV,DAEMON,LOCAL0-7,USER behandeln. Wir ersetzen die Facility durch eine beliebige Zeichenkette und sind nun viel flexibler.

Brücke zum UDP/Syslog-Service (sinnvoll ?)
Brücke vom UDP-Syslogservice
Brücke von named Pipe: Im sysklog kann man eine named Pipe angeben. Damit kann der gewöhnliche Syslog filtern ...

Schnittstelle für CORBA-Programme

ist die Klasse CorbaLog.
Jedes CORBA-Programm kann diese als Bibliothek einbinden.

Eine einfache Implentierungsmöglichkeit ist, eine Stuktur IDL:Syslog/LogRecordUnix:1.0 zu füllen und einem PushConsumer zu übergeben.

Zusätzlich könnte man eine ähnliche Struktur IDL:Syslog/LogRecordCorba:1.0 definieren.

Mit dem Dynamic Any haben wir noch mehr Flexibilität. Nun kann der Administrator im Interfacerepository eine Struktur umdefinieren.

Da aber

ohnehin die Strukturen definiert sein müssen
die Schnittstelle zu kompliziert würde
die Komplexität steigt

bleiben wir doch bei den statischen Version. (Die Experimentierversion brachte im Test zusätzliche Probleme Race-Conditions und so weiter )

facility (string): Name des Subsystems in dem das Programm/Objekt arbeitet
prog (string): Name des Programms
location (string): Ortsangabe (Rechnername)
pid (long): UNIX-Prozeßnummer
obj (Objektreferenz): Objektreferenz des aufrufenden Objektes
time (long): Zeitstempel (von tv_sec von gettimeofday)
priority (Aufzähltyp wie bei Syslog): Priorität
message (string): Nachricht, wie bei syslog(3), auch %m wird mit der UNIX_Fehlermeldung ersetzt

Logger als ostream

(Klasse logbuf in logbuf.h)

Da man in C++ mit den Klassen potentiell unendlich viele Typen hat, die man ausgeben bzw. loggen will, hat man als Ersatz der printf(3)-Familie die Ausgabe über den <<-Operator geschaffen. Aus diesem Grund wollen wir den Logger auch als ostream haben.

Dazu ist der CorbaLog eine Unterklasse von ostream.
Die Loggingfunktionalität bekommen wir durch das Setzen des logbuf-Streams im Konstruktor.
Diese Idee folgt gradlinig der GNU-Dokumentation. Beim experimentieren zeigte sich, daß bei jedem Buchstaben die Übernahmefunktion aufgerufen wird, was sicherlich nicht das gewünschte Verhalten ist. Es gelang nicht, dieses abzustellen.
Die streambuf-Klassen sind in der libc implementiert, in der libstdc++ sind nur Wrapper. Man muß also aus der Literatur oder aus der libc die Tricks herausfinden.
Bis jemand eine bessere Idee hat, freuen wir uns an der Funktionalität.

Unser logbuf sammelt die Eingabe bis zum Zeilentrenner, dann ruft er eine Callbackfunktion auf. In unserm Falle wird das Logereignis fertiggebaut und abgesendet.
Da die Klasse logbuf unabhängig von CORBA ist, kann man hiermit auch einen Loggingstream mit syslog(3) bauen und in herkömmliche Programme einbauen.

Stichworte

syslog.idl definiert Typen

#pragma prefix ""

module Syslog
{
    typedef string Facility;
    typedef string Prog;
    enum Priority { Alert,   // action must be taken immediately
		    Crit,    // critical conditions
		    Err,     // error condition
		    Warning, // warning Condition
		    Notice,  // normal, but significant, condition
		    Info,    // informational message
		    Debug    // debug message
                  };
    
    typedef string Location;  // Ip-Adresse, Rechnername
    typedef long   Timestamp;
    typedef long   Pid;

    struct LogRecordUnix
    {
	Facility  facility;
	Prog      prog;
	Location  location;
	Pid       pid;
	Timestamp time;
	Priority  priority;
	string    message;
    };

    struct LogRecordCorba
    {
	Facility  facility;
	Prog      prog;
	Location  location;
	Pid       pid;
	Timestamp time;
	Object    obj;
	Priority  priority;
	string    message;
    };
};

log macht UnixLogrecords, Aufruf wie printf
vlog auch, aufruf wie printf
clog macht CorbaLogRecords, Aufruf wie printf
vclog auch, Aufruf wie vprintf
Priorität wird wieder zurückgesetzt

Ideen

Eigener Startcode für Daemons

In C++ wird immer eine cout,cin und cerr geöffnet wie in C stdin,stdout und stderr. Dieses ist für terminalbasierte Programme und für Filter sinnvoll.

Für Daemons sollte lieber standartmäßig unser syslog-Stream geöffnet werden.

Für GUI-Programme sind zwar beim Entwickeln die Standardkanäle sinnvoll, für den Endnutzer nicht in allen Fällen.