| |||||||||||||
They should be paying attention to the lumberjack projectThey should be paying attention to the lumberjack projectPosted Apr 20, 2012 7:54 UTC (Fri) by man_ls (subscriber, #15091)In reply to: They should be paying attention to the lumberjack project by dlang Parent article: Toward more reliable logging What about protocol buffers? Have they fallen out of grace already?
(Log in to post comments)
They should be paying attention to the lumberjack project Posted Apr 20, 2012 15:11 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
protocol buffers are good for some things, but they serialize into a binary format, which is not compatible with existing logging tools.
Also (as I understand them) protocol buffers require absolute agreement between the sender and the receiver on the data structures to be passed. This is hard to do for logging libraries that will be written in many different languages, multiple log transport tools, and the vast array of log analysis/storage tools.
They should be paying attention to the lumberjack project Posted Apr 20, 2012 17:23 UTC (Fri) by smurf (subscriber, #17840) [Link]
No, they're backwards compatible
From the documentation:
>> You can add new fields to your message formats without
https://developers.google.com/protocol-buffers/docs/overview
They should be paying attention to the lumberjack project Posted Apr 20, 2012 17:31 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
Ok, but in any case, they won't work with the existing (text based) logging tools.
Yes, any change to the message being logged 'breaks' existing tools that depend on exact matches of known log messages, but as long as the new log format is still text based, all the existing tools can be tweaked (new regex rules) and handle the log messages.
If you switch to something other than text streams for your messages, you will require that all logging tools be re-written to handle your new format. Since this is unlikly to happen, there is a very large emphisis in being compatible with the existing tools.
They should be paying attention to the lumberjack project Posted Apr 20, 2012 21:10 UTC (Fri) by man_ls (subscriber, #15091) [Link] Protocol buffers is a binary protocol, like BSON. If binary formats are being considered (as I deduced from your message) then protocol buffers should be considered. (I myself think that BSON has a much brighter future, but I was just wondering.)
They should be paying attention to the lumberjack project Posted Apr 20, 2012 21:37 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
nxlog already has a binary transport, but it can only be used from nxlog to nxlog. There is though of having a binary transport, but that's a bit out still as the discussion is still focusing on the right way to generate the data and what tags are going to be used.
CEE is supposed to be releasing a 1.0beta spec, and the initial fields planned are documented at https://fedorahosted.org/lumberjack/wiki/FieldList#Unifie...
for the API, the initial focus is on trying to get a good C API that can replace the syslog() call. RedHat has a largish project that they've been calling ELAPI (Enhanced Logging API https://fedorahosted.org/ELAPI/wiki/WikiPage/Architecture ) that they are now realizing largely overlaps with the capabilities of the modern syslog daemons, so they are going though the code they wrote for that and ripping out lots of it to only keep what's needed. There is some question of if the result is still in the 'sledgehammer to swat a fly' category and so you have lumberlog working from the other direction
|
|||||||||||||