-----Original Message----- From: lumberjack-developers-bounces@lists.fedorahosted.org [mailto:lumberjack-developers-bounces@lists.fedorahosted.org] On Behalf Of Gergely Nagy Sent: Wednesday, March 28, 2012 1:56 PM To: lumberjack-developers@lists.fedorahosted.org Subject: Re: [lumberjack] connection to syslog (or equivalent)
"Rainer Gerhards" rgerhards@hq.adiscon.com writes:
Second, the main purpose of umberlog is the LD_PRELOAD thing. That
it
has a few extras, is a side-effect, which I personally find convenient. But the main reason for the library's existence is its ability to change how syslog() works, with neither source changes,
nor
recompilation.
Is it really? I thought the idea was initiated when we discussed
providing
the ability to an app to pass name/value pairs, something that the
existing
syslog api cannot do. The addition of metadata nv pairs, IIRC, came
at a
somewhat later stage.
Well.. the original plan was to extend syslog() with the ability to add nv-pairs, while remaining backwards compatible.
Yes, but... As you say, the plan was to extend syslog(). So in order to make use of that extension, app changes would have been necessary. Right? So even if the name syslog() had remained, apps would have to be upgraded to emit "real" nv pairs.
In that sense, I do not see any difference between syslog(,,nam1,val1,...,nameN,valN,NULL) and ul_syslog().
The core intent was to make passing nv pairs *from the app* possible.
When that failed, ul_syslog() came, and syslog() became a @cee{"message":...}. The came the extra metadata.
But the original plan was to make syslog() emit JSON, for legacy apps Secondary to that, to add an API (that does require code change) to add nvpairs. Sadly, that could only be done with a separate function.
I don't see much value in these metadata over SCM_CREDENTIALS-
obtained
metadata. I know umberlog can do this without a syslogd, but with the
major
implementations participating in this effort is that really a big point?
Nope, it isn't. But turning legacy apps syslog() messages into a JSON-payloaded thing is already a win, imo, as the syslogds don't have to go to extra lengths to accept both legacy and @cee logs.
Where ist he win? Besides, we always must process legacy logs as they may come in via the network. And cee-enhanced syslog also comes in via the network. So cookie check and appropriate action is required in any way, isn’t it?
The metadata is a nice bonus, but it's just that, a bonus.
So IMHO the extended ul_syslog() API is the really important part.
It's not negligible, but that can be provided by something else, too (which can do better in that regard).
Sure, but to *me* this capability is what I am really after. I think we would have won almost nothing if we end up with just metadata (that we can obtain anyways) being part of JSON - and nothing else.
That's NOT what *I* envisioned when we talked about the API on the teleconference.
Rainer
Legacy syslog() => structured thingy is somthing that's better done in a thin lib than in something a lot more complicated.
-- |8]
lumberjack-developers mailing list lumberjack-developers@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/lumberjack-developers