RE: [logs] EventLog library

From: Rainer Gerhards (rgerhardsat_private)
Date: Tue Jan 07 2003 - 00:57:35 PST

  • Next message: Rainer Gerhards: "RE: [logs] Syslog payload format"

    > > * character set?
    > >   should we support different character sets? I think we 
    > should but I'm not
    > >   sure.
    > I think both are not required for the minimal/lowest common 
    > denominator standard API, as they are part of the 
    > "presentation layer".
    We have done work with logging Japanese messages and we have learned
    that it is not so easy to say "its just the upper layer". But I think
    this should be postponed until we have something 1.0ish...
    > > * output modules character conversion
    > >   should we use a single character encoding on the wire 
    > (UTF8?) would it be
    > >   mandatory or it should be configurable?
    > Just one. I prefer plain ASCII ;)
    I opt for confgurable. ANSI does not work for double-byte character
    sets. For example, in some encodings sare like this:
    The Lead-Byte is typically a value above 128, the DBCS chars can than be
    any value (including control-character like value like 0x0a or 0x0d),
    the trail byte is again typiallxy above 128. I am just saying this to
    level ground. As I wrote, I don't see any immediate need for action.
    > > * how to store the (prio, tagname) tuple?
    > >   I assigned a priority to tags to support tag ordering. 
    > This is done by
    > >   using functions like this:
    > >     evt_tag_str(e, 10, "testtag", "value")
    > > 
    > >   Currently I defined macros like this:
    > >     #define EVT_TAG_TESTTAG     10, "testtag"
    > > 
    > >   which can be substituted in function calls like this:
    > >     evt_tag_str(e, EVT_TAG_TESTTAG, "value")
    > > 
    > >   However I don't like this too much. Maybe a separate 
    > struct to specify
    > >   tags should be defined, but that would bloat the caller's code.
    > See above.
    > > * syslog facility/priority mapping?
    > > 
    > >   The syslog facility and priority values are currently 
    > mandatory, they
    > >   might be converted to simple tags, but how to send 
    > messages which do not
    > >   specify them?
    > I'd prefer it optional, so that the new API is not 
    > permanently tied to syslog. Actually the same holds for the 
    > second field of evt_open
    Well - but if it is absent, an intelligent mapping to syslog might be
    much more of an issue to map them onto syslog. We have build a similar
    protocol for our interal use in the products and we decided to provide a
    syslog pri/fac in any case. It doesn't hurt that much when developing
    and greatly helps to keep things consistent. Also, admins are very used
    to the pri/fac, so you might get an acceptance gain. I am not suggesting
    an API extension right now as I am not sure how the rest of the group
    feels about this... Comments anyone?
    > > And finally:
    > >   * applications, applications, applications
    > > 
    > > To help the final step, I'm going to convert syslog-ng to emit 
    > > messages
    > > using eventlog, and also schedule it into our Zorp project.
    > If we can get the common denominator we will have two 
    > implementations, 
    > which should be a nice start.
    We'll implement it in our products (EventReporter, MonitorWare Agent,
    WinSyslog) as soon as it evolves to relatively stable. So also support
    on Win32. 
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 08:09:07 PST