RE: [logs] Syslog payload format

rgerhardsat_private

> Marcus J. Ranum wrote:
> > RULE #1:
> >         - An event record is an arbitrary collection of 
> tagged values 
> > RULE #2:
> >         - Some tags are "known" public tags, some tags are 
> application,
> >         site, or event specific - cannot know them all in advance
> >         therefore there must be some flexibility in letting app
> >         designers pick their own
> > RULE #3:
> >         - the API for tossing event records should be 
> EASIER to use than
> >         the current syslog API and should inherently discourage
> >         implementation of buffer overruns
> > RULE #4:
> >         - defaults should be used wherever possible
> 
> Works for me, as does the sketch of the API and format you suggest.
> 
> I can see a few issues with it, but I think they are pretty 
> minor. Nitpicks really, this is good stuff IMO. I'd be happy 
> to knock up a Java equivalent API for it if that is of any 
> use (there's already a Java logging framework, not sure how 
> this would fit with it though).
> 
> On to the nitpicks:
> 
> (1) You can be sure that application programmers are going to 
> do both of the following types of calls:
> 
>        eventlog_addvalue(EVENTLOG_TEXT, "memory remaining < 10M!");
> 	 eventlog_addvalue(EVENTLOG_TRADESUMMARY,
> "<trade><stock>MSFT</stock><blah>blah</blah></trade>");

This raises the question if we _really_ want to support nested XML... Do
we?

[SNIP for brevity]

> 
> (2) Needs some support for binary crap (thinking of Windows 
> event log here, but you'll also get applications wanting it). 
> Base64 I guess?
Fair chance - but mostly undoable with the 1024 [RFC3164] limit. So only
doable if the rfc is intentionally viloated (which we do in our
software). But this brings up other issues. Nevertheless, I think we
should say base64 OR HEX (for even simpler implementation and more space
taken up ;)) and leave the rest to a discussion about syslog transport.
Anyhow, we should specify that the binary field(s) should always come
last in the syslog message...

> 
> (4) You're going to get name clashes on the app-specific tags 
> if this catches on. That may or may not be an issue. If it 
> is, XML does provide a namespace mechanism to deal with such 
> things, which is probably heavier than you want for this, but 
> it would be good to be able to use available parsers. Maybe 
> app specific tags could be something like <progname:tag>, 
> either explicitly so or implicitly (smaller), and then have a 
> register of prognames if you're really worried about clashes.

Yes - and I would prefer to life with the potential clashes than to have
the whole thing held until the potential is solved (I am not sure if
that would be in my lifetime...).

> 
> (5) Probably needs some way to retrofit all of this to the syslog
> protocol(s) (without length limit, and without UDP), so that 
> any infrastructure that understands that can be glued in. I 
> guess items such as timestamp and source could be put into 
> the existing slots for those, with the remaining tagged text 
> stuffed into the message.

Agree - but I again wouldn't hold until this is fixed.

> I think it would be sensible to have some kind of register of 
> well-known optional tags, to avoid unnecessary proliferation 
> and duplication of application specific ones.

Sounds like an IANA tasks... But again this is faaar from now...

Rainer
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis