In some email I received from Magosanyi Arpad, sie wrote:
[...]
> 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
For me the problem is that presenting a bunch of values doesn't necessarily
tell a complete story.
> > 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.
Why not ? Like you say, it is "free form", and what goes in it should not
be controlled either way.
> > 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"
That doesn't quite match, but sure, I don't have a problem with how it
is represented.
> 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.
Errh, that's not quite what I was getting at. I was talking about the
programmer's interface. If I send a syslog message now, I do:
syslog(LOG_INFO|LOG_AUTH, "login: 3 login failures for root from 1.2.3.4");
What I was trying to say, above, in that last paragraph that I shouldn't
need to write X lines of code building up some array of tag/values to pass.
If we can tell some sort of library routing what's what in a string we're
already sending, why can't it "do the right thing" for us ? USing my above
example, it would be:
syslog_new(LOG_INFO|LOG_AUTH, "%P: %# login %r for %a from %s",
"login: 3 login failures for root from 1.2.3.4");
and this would be allowed too:
syslog_new(LOG_INFO|LOG_AUTH, NULL,
"login: 3 login failures for root from 1.2.3.4");
Darren
