A levelez�m azt hiszi, hogy Darren Reed a k�vetkez�eket �rta:
> In some email I received from Magosanyi Arpad, sie wrote:
[]
> > The greatest problem with log analizing is that the message part is free-form.
> 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.
Don't be offending, why would anyone look into NT event log? :)
There is no information there.
Seriously, what I am doing daily is looking at logs which try to explain
the same types of information in wildly different formats. All of the
formats are equally (un)readable than the above but they can't be filtered
for the same information in the same way.
What about the following?
process=login account=root src=1.2.3.4 count=3 event=login failure
>
> 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.
I think that the free form message tag should not contain any variable
information.
>
> 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.
What about the following?
"$process: $count $event for $account from $src"
I guess that a conversion script from ulm/unalog format to plain old unparseable
log would take no more than 10 perl lines and a config file where the keys are
facility and event.
For backward compatibility we can't escape the old->new format conversion,
which is more computational intensive and a hackery anyway, but please don't
mandate it.
--
GNU GPL: csak tiszta forr�sb�l
