"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. 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.
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). Legacy syslog() => structured thingy is somthing that's better done in a thin lib than in something a lot more complicated.