On Wed, 28 Mar 2012, Rainer Gerhards wrote:
it could be that I am misunderstanding things, but as I understand it, if you just do a LD_PRELOAD of umberlog with no application changes the result is log messages with structured metadata around the raw log message.
While I find this a notable effort, I personally do not see much value in these "extra" nv pairs. After all, this is metadata that I can also get hold of via SCM_CREDENTIALS, which is also a superior way in regard to trust. So to me this is just a "nice little gimmick" (not meant to upset something, I see some value in this, just not very much - *my* *personal* opinion).
If the programmer wants to add additional name/value pairs they can change individual syslog() calls to ul_syslog() and pass in parameters.
That *IMO* is the prime reason for having umberlog. We want an interface that permits apps to submit "real" nv pairs.
I actually don't expect many people to make a lot of use of this option,
then we have already lost... because everything else we (almost) already have. Remember that I hacked a PoC to get metadata via SCM_CREDENTIALS into rsyslog and it is extremely easy to extend the metadata set. No lib needed for that. I am very sure syslog-ng will take no longer than a day if it does not already have the capability. Expect the same for nxlog and...
Unless you are passing a structured log message around, how do you get the SCM_CREDENTIALS into the log message in a way that doesn't let them get confused with data that the application is writing?
That's one problem with the PoC that you did for this, by putting the data as text at the end of the message, it makes it hard for parsers to grab it and be sure they are getitng the data from rsyslog, not something provided by an app.
David Lang