Re: [logs] Syslog payload format

bazsiat_private

On Fri, Dec 20, 2002 at 01:14:05PM +0100, wolfgangat_private wrote:
> Darren Reed wrote:
> > In some mail from Marcus J. Ranum, sie said:
> > [...]
> > > so how about an event logging API that vaguely resembles
> > > something like:
> 
> > The biggest problem any change is going to have is dealing with
> > convincing programmers that the extra effort is worthwhile.
> 
> > Right now, I can do:
> 
> > syslog(LOG_DAEMON|LOG_DEBUG, "debug: marcus login from %s", where);
> 
> If we think of a small, easy, painless minimalistic solution for getting
> a limited amount of semantics into the logging process, how about replacing
> the call above with something like
> 
> xnewsyslog(LOG_DAEMON|LOG_DEBUG, "debug: %u %t from %h",
>   "marcus", "login", where);
> 
> We could define a small number of tags like %u for a user id, %t for an
> event type and %h for a host id. If our "logging backend" is a new logging
> system, it could keep that information e.g. by tagging the log message
> components and if we have "classic syslog" we just treat them like %s.

I like this API a lot. I was thinking something along the lines of your
example. An extension is not to limit %x tags to a single character. Or
here's what python does to format a message:

print "%(user) logged in from %(srchost)" % values

where 'values' is a hash table indexed by strings. How about:

xnewsyslog(LOG_DAEMON|LOG_DEBUG, "debug: %(user) %(tty) from %(host)",
	   "marcus", tty, where);

Of course shortcuts for often used tags could be defined like %u for user,
though I would propose to keep compatibility with syslog() so simple
snprintf format strings could be used.

Did I mention I like varargs? :-)

By the way, we do not need to decide which API is better, the function above
can be layered on top of what Marcus and Darren has designed.

Hmm.. What I still don't know how the function call above would be mapped to
an actual message. The message format we are using currently is like this:

Dec 11 12:34:56 host prog[12345]: Human readable event description; fd='13', error='Connection reset by peer'

That is, a constant event description comes first without _any_ variable
data, semicolon and a list of tag/value pairs. This makes the message easy
to read by humans (the description itself is not a tag), and the event is
still easily parseable. So the above xnewsyslog() call would become
something like this:

xnewsyslog(LOG_DAEMON | LOG_INFO, "User logged in; %(user), %(tty), %(host)",
	"marcus", tty, where);

What about specifying priority/facility as strings?

-- 
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