"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.
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