In some email I received from Magosanyi Arpad, sie wrote:
>
> A levelez�m azt hiszi, hogy Darren Reed a k�vetkez�eket �rta:
> > and then when it is received by the syslog daemon, it may add date info.
> > at the start of the message, as well as host information. I think ULM
> > goes (perhaps) too far by describing how information should be tagged within
> > the "message part".
> >
> > Comments ?
>
> Sure:)
>
> The greatest problem with log analizing is that the message part is free-form.
> In case of "input string too long" it is nice, as far as you don't want to log
> that input string. Good old artificial ignorance is nearly adequate to handle
> it. But think of mail logs, packet filter logs, process audit, or anything
> else which have some argument in the message part. Everyone who does that
> have wildly differing message format, which turns the life of log analizers
> into a nightmare. They have to write a different analizer module for every
> type of log to be able to put them to that spiffy SQL database to do the
> statistics.
I agree, determining what is a key field, and then what it represents, in a
typical syslog message is not easy.
But at the same time, it can tell the story in a concise way that is
instantly readable:
login: 3 login failures for root from 1.2.3.4
vs.
process=login account=root src=1.2.3.4 result=failure count=3
Ever tried to read events from the event log on Windows NT ? Plenty of
information, but it's all in hex, not english, if you get what I mean.
I don't think supplying lots of data value types is a replacement for a
log message, but then neither does the message do the job of saying what
piece of text is what sort of datum. I'm tempted to say that the approach
should be this:
- logging of just a message should always be supported and this is done by
associating the message with a message tag (msg="al;asas.. asd fa").
This field must always be present and should be (in some way) composed of
all other data presented with other tags.
- other tags are supported and must have a value field associated with them
if present.
Darren
p.s. In terms of an API, the current API should only perform the former and
a new interface should provide a mechanism for translating the message
into a number of tag/value fields. i.e. "%P: %# login %r for %a from %s"
would cause the API to to generate the second line above.
