Re: [logs] Syslog payload format

From: Mikael Olsson (mikael.olssonat_private)
Date: Fri Jan 03 2003 - 11:12:08 PST

  • Next message: wolfgangat_private: "[logs] syslog compatibility (was: Syslog payload format)"

    Rainer Gerhards wrote:
    > > Why limit to macros?
    > >
    > > I've seen loads of open source projects that include
    > > implementations of sometimes-missing routines, like e.g.
    > > various printf varients (snprintf, vfprintf, ...). Make one
    > > of the first implementations of the new logging API be a
    > > simple C version that backends onto syslog(3), and use
    > > autoconf to decide whether its needed at build time.
    > I have to admit I am a Win32 guy (and closed source too) for too long to
    > know autoconf - but I think I understand what it does. I'll keep up the
    > Windows flag (well, not the easiest stand ;)) and throw these win32
    > warnings in whenever approriate.
    > > What's more, if the implementation made a good easy-to-parse
    > > encoding onto the syslog(3) message, this could be the
    > > favoured implementation. Combine it with a syslog that fixes
    > > the grossest defects of the standard one (replace the idiot
    > > partial timestamps with ISO 8601 / RFC 3339; replace UDP with
    > > TCP plus simple newline termination to delimit records) and
    > > we'd be close to done, no?
    > I think we do not need to break RFC3164. - Let's stick with the "idiot"
    > timestamp in the header and provide an RFC3339 one as one tag. That way,
    > we keep consistent with the rest of the world. And, yes, I would
    > definitely like to see (and implement) a such simple RFC3164 over TCP as
    > you suggest: plain 3164 EXCEPT
    > - TCP is used
    > - the message format stays as in 3164
    > - if one message is sent in a TCP session, there is no modification to
    > 3164 format
    > - if multiple messages are sent in a single TCP session, the second and
    > all subsequent messages START with LF (or CRLF - well either one or the
    > other).
    I'd have to disagree, for two reasons:
    - Why not make the timestamp ISO?  The new transport obviously 
      requires new code, so ... ?
    - And here's the big one: The (CR)LF needs to _terminate_ messages,
      _not_ start new messages.  Why?  Well, consider a host that only
      sends messages a few times a day, and also consider the fact that 
      I might want to do automatic alerting for a certain event.
      Without termination, I would have to wait several hours for the
      next event to arrive before I could act on the message.
      Recognizing that EOF is termination of an event is hardly
      rocket science. All fgets() implementations do this.
    Mikael Olsson, Clavister AB
    Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
    Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
    Fax: +46 (0)660 122 50       WWW:
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:54:45 PST