-----Original Message----- From: lumberjack-developers-bounces@lists.fedorahosted.org [mailto:lumberjack-developers-bounces@lists.fedorahosted.org] On Behalf Of david@lang.hm Sent: Tuesday, March 27, 2012 10:17 PM To: lumberjack logging Subject: Re: [lumberjack] connection to syslog (or equivalent)
On Tue, 27 Mar 2012, William Heinbockel wrote:
On Tue, Mar 27, 2012 at 3:18 PM, david@lang.hm wrote:
I posted some of this at the bottom of a long message yesterday that
nobody
replied to, so I broke it out to a separate thread
The traditional syslog interface has been a write-only interface,
with the
only feedback being that the write could block.
With the new formats and new syslog replacement library, does there
need to
be some rethinking of this interface?
JSON can be pushed through the traditional syslog interface with no
changes
(which is one of the attractions of using JSON), but when we support additional formats, especially ones with type information, we need
to have a
way to tell what format to use when writing the log.
I don't think this is right approach. The end goal is to support structured log messages. The first step is to introduce the capability to sent structured events via existing capabilities (read: JSON over Syslog)
The next steps would be the ELAPI/selog API that would introduce a
new
logging interface, probably maintaining at least minimal
compatibility
with the syslog daemon (not the syslog API or syslog protocol). This would allow us to define and support more feature-rich log protocols and other features.
But does this mean that unless applications are re-written, they will never send structured logs at all?
I see there being value in having the cee-syslog replacement library that sends the metadata structured around the existing unstructured log data. It's not as good as a full structured log, but it's a lot better than the existing situation.
Well, I think if you want just this, it can be obtained right now without een a new lib or so. Actually, this is the focus of liblognorm and syslog-ng's patterndb, to extract nv pairs from semistructured data. I think this *is* pretty important stuff. Other metadata you can get via SCM_CREDENTIALS (and I still think this is the preferred way from a trust perspective).
Rainer