Re: [logs] Syslog payload format

bazsiat_private

On Thu, Jan 02, 2003 at 11:44:09PM +0200, marc wrote:
> You wrote:
> > We are about to implement a client side library to be used on syslog
> > clients. It will be shipped with syslog-ng and as syslog-ng is quite popular
> > I think it has a slight chance of getting acceptance.
> 
> Neato. Can I have a look at it ? How different 
> is the API from idsa_set() and how much effort
> would it be to create a conversion wrapper 
> between the two (in either direction) ?

It exists in my brain only, but I'm thinking about a multi-layer API, where
the lowest level would be something like your IDSA API (or Marcus's
eventlog_* suggestion).

I am thinking along the following lines:

1) low level API, something resembling to Marcus's and your API
2) a convinience API with format strings and varargs, calls 1) functions
3) a syslog compatible wrapper (probably in an LD_PRELOAD-able shared object)

As an event record is created it is processed by two orthogonal modules:

1) formatting, format the description+tag/value pairs into a message,
   possible to inject into syslog. The method used to map a message is user
   selectable:
   - a simple non-XML format
   - a couple of different XML format we were discussing (syslog tags as
     attributes, syslog tags as XML tags, etc.)

   These formatting options would be linked into the library, to extend the
   set of supported mappings one would need to add the code and recompile the
   library. I don't want to introduce dynamic loading here for simplicity.

2) output, send the formatted message to 
   - local syslogd
   - RFC3164 via UDP
   - RFC3164 via TCP
   - RFC3195 via TCP

   Output should support flow-control where possible (e.g. block the calling
   program when the message cannot be sent), but this is optional.

   Output modules should again be linked into the library statically, though
   the set would be extendable.

Output format and output protocol should be controlled by the administrator,
thus I might introduce a configuration file in /etc. Alternatively
environment variables could also be used.

I'm thinking about a blocking API, but in the long run I also want to
support non-blocking operation (in a non-intrusive way, probably like in
OpenSSL).

I do not want to rely on anything except libc, and I also don't want to be
intrusive to the main program.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis