Option to reduce verbosity

[lox]

By default we are getting info level messages from this container.

It would be great to have a way to set log_levels with ENV. Currently the only way seems to be overriding the entire config file via a volume mount, which seems like overkill.

Details on configuration here http://www.copernica.com/en/blog/controlling-rabbitmq-log-levels.

[MrLokans]

It is a great idea, using it with complex docker-compose development environments makes it pretty impossible to skim through the INFO log messages.

[saabeilin]

+1. I guess many people will be happy, currently RabbitMQ gives us around 60% of all logs.

[michaelklishin]

It's funny how when all is well people complain about info level logs and when they don't they suddenly want that and even debug level logging.

I would not recommend muting info level logs because they include client connection information and that can be critically important to investigating many types of issues in messaging systems. Use logrotate or similar.

[saabeilin]

I would say that in many other systems these level of logs is considered DEBUG. In addition, the way the logs are formatted in RabbitMQ is not logstash-friendly. Logrotate is a good option when running on bare metal or VPS, but in containerized solutions, people quite often (most often?) use external log aggregation technologies, pushing the log stream from all containers to centralized storage like logstash+kibana. Even more, quite often there is a limit on amount of logs daily/monthly.

That said, I would definitely vote for the ability to control the log level.

[lox]

I would not recommend muting info level logs because they include client connection information and that can be critically important to investigating many types of issues in messaging systems. Use logrotate or similar.

I can understand that point of view @michaelklishin if we were asking for the default to be silent, but all we are saying is that for some of our usecases, the default verbosity of the logs is counter-productive and obscures more key container logs. Sure we can work around this other ways, but this is why leveled logging exists, so that you can opt-into the level of verbosity that fits your use. Lots of us for instance only use this in development, where rabbitmq is a small part of an architecture.

At any rate, thank you for your efforts and the container, and feel free to take our suggestions as just that, suggestions.

[lox]

I'll leave this here: http://brson.github.io/2017/04/05/minimally-nice-maintainer

[samattridge]

I'd value the option to control the logging level via env vars too. I'd prefer not to replace the config file if I can help it.

[zoidyzoidzoid]

I've opened a PR that allows custom log levels: #156

[zoidyzoidzoid]

so you can change log levels by using one of the builtin RabbitMQ env vars

-e RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS="-rabbit log_levels [{connection,error}]"

via https://www.rabbitmq.com/configure.html and my PR.

[tianon]

Closing given that this is resolved by setting log_levels either via RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS or in the configuration file (and in 3.7, the configuration file has a much more approachable syntax 🎉).

[nhumrich]

I would like to propose reopening this issue as setting log_level via RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS no longer works. (3.8+)