ricbra / rabbitmq-cli-consumer

Consume RabbitMQ messages into any cli program
MIT License
247 stars 49 forks source link

More logging options (v2.x) #38

Open gaspaio opened 8 years ago

gaspaio commented 8 years ago

At the moment we can only send logs to files. It would be nice (and necessary for my usecase) to be able to send them anywhere (syslog, logstash, ...).

Is this in the 2.0 roadmap somewhere ? Is this something that might be of interest ? if so, I can try to come up with a pull request.

I was thinking on using Logging. The memory logging it provides would probably allow for more extensive testing without filesystem dependency.

What d'ya think ?

ricbra commented 8 years ago

Thanks for bringing this up. I've tried the suggested Logging library while writing v1, my argument against it at the time was that it didn't implement the default Go interface Writer. Perhaps I should reconsider, if the logging stays in at all.

I've been thinking about to completely remove the logging, and just outputting stuff to stdout and stderr. Leave the logging to something like supervisord which everybody is using for running as daemon? With supervisor you can send logs to files, syslog etc.

Or am I being rude and should I keep it? The less in this library, the less I have to maintain, the less bugs there will be.

vicdelfant commented 8 years ago

If I may put my two cents in: although a logging feature with a bunch of configuration options is great, I personally think it'd be best to keep this tool as lightweight and simple as possible. Logging to the right destination and acting upon it could/should be handled by a higher layer of the application stack instead.

We use supervisor (like you said, probably like everyone else) in a Docker container, so the lesser log files are created by default, the better :)

gaspaio commented 8 years ago

You're probably right, just stdout/stderr if probably enough. One can always redirect output with another tool. I'll let @ricbra close the issue if everybody has has its two cents :-). Thanks for the discussion.