-----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 5:49 PM To: lumberjack-developers@lists.fedorahosted.org Subject: Re: [lumberjack] connection to syslog (or equivalent)
"Rainer Gerhards" rgerhards@hq.adiscon.com writes:
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.
Correct.
In that sense, I do not see any difference between syslog(,,nam1,val1,...,nameN,valN,NULL) and ul_syslog().
That is also correct.
The core intent was to make passing nv pairs *from the app* possible.
..while maintaining backwards compatibility with legacy syslog(), which still is the main selling point of umberlog, imo. The rest is cool and useful, but imo less so.
If you like and think of other features as more important, that's also fine! I find them useful aswell, just our priorities seem to differ. The end result is pretty much the same =)
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?
Not if you LD_PRELOAD the lib on the whole network (which I've done on my systems). In that case, you can get rid of the cookie check.
I know you have Zorp, but... what if there is a single PIX, Cisco Switch or other gear? ;)
For me, that's a win, because I can just shoehorn everything into Solr pretty much as-is, legacy logs and properly structured logs alike. My config became simpler, just by LD_PRELOADing a lib.
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.
Lovely! Then we hit two birds with the same stone, and we won't even have to argue about which one each of us eats, as we both choose a different one! :D
Jup, can perfectly live with that. But I have to admit had I correctly understood the intent in the first place, I'd probably not withdrawn my initial idea. Anyhow, umberlog still has everything that's needed, we just lock from a different angle. But depending on how it is sold, it will probably not achieve what *I* had hoped for, that is being real structured app-generated logs (vs. metadata, which I already have).
Nevertheless, still very useful work and thanks for putting the effort into it :-)
Rainer