[rabbitmq-discuss] lager vs sasl error log

Gotthard, Petr Petr.Gotthard at Honeywell.com
Tue Apr 30 12:30:38 BST 2013

As I said earlier, the lager plugin at https://github.com/hyperthunk/rabbitmq-lager is perfect for me.


-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Tim Watson
Sent: 29. dubna 2013 12:23
To: Discussions about RabbitMQ
Subject: Re: [rabbitmq-discuss] lager vs sasl error log

Folks - we have heard back from three of four people about this feature. Currently, that's not really what I'd call a 'critical mass' and certainly not enough for me to argue that we ought to provide lager support as part of the core broker ootb - Simon or Matthias may have a different opinion, but I wonder whether just providing this via a plugin is 'good enough' if it was included in the umbrella?

Thoughts on a postcard please - the more votes the more likely something will happen (one way or another).


On 26 Mar 2013, at 19:53, Tim Watson wrote:

> I have set up an experimental repository at https://github.com/hyperthunk/rabbitmq-lager that supports logging to lager via its built in error_logger redirection. You enable via `rabbitmq-plugins enable lager` and configure it in the RabbitMQ config file just like any other plugin, under the key 'lager'. In the morning I'll chat with the guys about integrating this as experimental plugin for the time being, so people can play around and see if it offers the required functionality.
> Cheers,
> Tim
> On 23 Mar 2013, at 23:06, Ben Hood wrote:
>> Hey Tim,
>> On Friday, 22 March 2013 at 07:55, Tim Watson wrote:
>>> Yeah with the current implementation you'd need to install your own log handler to make that work. In terms of changing the output format though, allowe to play devil's advocate for a moment...
>>> The info/progress/error reports have a lot of data in them, process stats, stack traces, etc. are you wanting to see all that plonked on one single long line? Because I can see how that'd make parsing/aggregating easier, but not reading them. Does the lager output fit exactly with what you want (I've not looks at it or a couple of years)?
>> I don't think that everything needs to fit on one line. Longer traces 
>> which provide good context should probably remain as multiline 
>> entries. However, info items, for example,
>> Mar 22 22:33:01 a rabbit3:  =INFO REPORT==== 22-Mar-2013::22:33:01 
>> === Mar 22 22:33:01 a rabbit3:  Setting permissions for 'guest' in '/' to '.*', '.*', '.*'
>> need not get split up over two lines.
>> With regard to longer traces, it would be nice if they could be handled in such a way that the generic portion of the call stack were trimmed down to something nearer the actual call site, rather that the entire generic call trace. As inspiration, logback mitigates the default "root cause comes last" behavior in Java with the reverse depth layout modifier (rEx{depth}). Lot's of hand waving here though.
>> Finally, I do have to concur with Gavin on people's perception about Rabbit due to logging - I've have many conversations with people over the years who ask why Rabbit has such bizare logging - I've generally answered that this is an Erlang-ism, and though it is strange, the server kind of serves its primary function well (i.e. delivering messages), so just put up with it.
>> Cheers,
>> Ben
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com

More information about the rabbitmq-discuss mailing list