Re: [logs] Syslog payload format

From: Balazs Scheidler (bazsiat_private)
Date: Fri Jan 03 2003 - 01:32:45 PST

  • Next message: marc: "Re: [logs] Syslog payload format"

    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
       - 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
    I do not want to rely on anything except libc, and I also don't want to be
    intrusive to the main program.
    PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 09:11:14 PST