Add LOGGLY_DEBUG variable to enable STDOUT logging

[vladgh]

This disables stdout logging by default and adds an optional LOGGLY_DEBUG environment variable which, when true, turns on stdout logging (FIXES #14).

[jonathan-short]

Thanks!

[ebr]

Thank you @vladgh! just got to work on this and noticed it's already fixed! :+1:

[vladgh]

No problem. I agree that having the option to turn on/off stdout is good.

However, I would argue that disabling stdout by default is probably not a very good idea. In my opinion, having a container that does not output anything to docker logs is wrong, because you don't have any debug options. You don't have an easy way to know where the issue is: either with docker or the container or even with loggly's servers.

Your loop issue and space constraints can easily be overridden multiple ways:

• you have the --log-opt max-size=[0-9+][k|m|g] to keep the size under control
• you have --log-driver=none to disable logging to a file all together
• and last but not least, you can start your container with docker run -d -e 'LOGSPOUT=ignore' image which will be ignored by the logspout container

[ebr]

@vladgh good points, and i do agree that complete lack of output may be somewhat confusing when troubleshooting. But i would also argue that this is a lesser evil than mirroring everything to stdout by default. When using logspout or any similar solution, only the --log-driver=none option is viable:

• option 1 would fix the disk space issue, but still result in incredible volume of recursive noise being pushed to Loggly. We logged over 4.5GB in less than 20 minutes while i scrambled to troubleshoot the issue.
• option 2 would result in precisely the result achieved with this PR, yet requires extra effort on user's part.
• option 3 doesn't seem to actually work with the logspout container - at least not in my testing. This was the first thing I tried, actually. Perhaps I did not test it correctly, but this feature is evidently somewhat fragile.

The overarching point however is that if someone using this image does also run logspout or similar, it is dangerous to leave them to discover this issue the hard way. It would be safer to turn on debugging in a controlled setting, if needed.

Since having all aggregated syslog being mirrored to stdout is really only useful for debugging, I feel the way this feature is implemented right now is perfect - so thanks again. But perhaps it's worth exploring how errors can be caught and written out to stderr, so that the container is not completely silent.