-----Original Message----- From: lumberjack-developers-bounces@lists.fedorahosted.org [mailto:lumberjack-developers-bounces@lists.fedorahosted.org] On Behalf Of david@lang.hm Sent: Wednesday, March 28, 2012 6:56 PM To: lumberjack logging Subject: Re: [lumberjack] connection to syslog (or equivalent)
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?
I'd still put them into wherever umberlog puts them (so let's say JSON content). My key point is that I can add this information without any help from a lib.
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.
Sure, there was no standard to follow at that time and the main point was to prove that it is doable (as journald folks said its impossible).
Rainer