Add remote syslog support

[nitomartinez]

This change adds:

• rsyslog package
• If the environment variable UDPLOGHOST or TCPLOGHOST is defined, then rsyslog is started inside the container with remote syslog to the $UDPLOGHOST or $TCPLOGHOST. If not defined rsyslog is not started

[nitomartinez]

Thanks for the feedback,

Wil close it for now, and reraise with the modifications

[jnovack]

Is rsyslog necessary in every docker container since the update?

https://docs.docker.com/engine/admin/logging/overview/#syslog

[nitomartinez]

I think that this is the logging of the container, not the logging of the application.

What I mean is that:

• If the app logs to stdout/stderr then the container will forward it to syslog/file whatever the docker logging driver uses
• If the app natively logs to syslog or to /dev/log then you will have a way to forward those logs to somewhere outside the container.

there seem to be several approaches to this, but I found starting a syslog inside the container the easiest one...

[jnovack]

there seem to be several approaches to this, but I found starting a syslog inside the container the easiest one... (emphasis mine)

That's my concern and why I raise the question.

With the syslog logging engine defined, anything logged to /dev/stdout automatically goes where it should given the settings.

It requires you to have type more on the command line each time you start a container, but you should be doing docker-compose up to take care of that anyway.

It prevents you from having to install an init or monitor process AND rsyslog on every container. I noticed you currently aren't using an init process, which means that if your rsyslog daemon fails, you won't know, and your logs are lost.

[ventz]

Just seeing this PR/thread -- not sure why github never pinged me via email.

I'll add this merge to the main one, but in a separate branch/tag, since one of the main feedbacks I have received is that people like the simplify of the current image.

That said, central logging is vital in my opinion.

[ventz]

@jnovack @nitomartinez Created a new branch ":syslog" -- can you please clean up the PR and I can merge it. Things that need some cleaning up:

1.) Please remove .dockerignore and .gitignore 2.) Dockerfile: I would add the 'rsyslog' from RUN apk --update add rsyslog on the same line as 'bind'. Same for the mkdir. As you chain, dockerhub builds faster/re-uses layers. (there is also an extra space between /var/spool/rsyslog && addgroup syslog 3.) README "run instructions", so that it follows the same syntax I had for the run - one param per line Also repo name -- see @jnovack's comment - if merging anyway 4.) named.conf.options -> name again

@jnovack @nitomartinez - If you want, I can merge the changes manually and give you credit in the README. (It might be easier/quicker.)

[ventz]

I updated with a cleaned up version.

@jnovack Brings up a few very good points there: 1.) As of recently, you can now hook STDOUT and redirect it to a logging engine. 2.) Once you are launching more than one thing - you really should use something like supervisor, which will keep track, restart, notify, etc.

I still think I will create a "syslog" branched version, but I will clean it up a bit.

I'll add another update with some sample zones/examples etc (I think that was a good suggestion).

Closing this for now, but opened an issue to keep track of this.

[ventz]

@nitomartinez, @jnovack - Have not forgotten about this either. I know there was a bit of a delay. Still need to clean up a few dir related things/examples/etc, and then i'll focus on adding a syslog branch. I just want to make sure it's against the cleaned up version.

[jnovack]

I am against syslog at this point. This past year more clearly defined the roles of containers and management in the Docker eco-system. The container should not be managing logging at all, your host/management layer should take care of logging for all containers to a central location.

[ventz]

@jnovack I am personally on the same page as you about this. Using the built in logging driver is a much better way to go, and then just making sure all the relevant messages are sent to stdout and stderr. This lets people choose either a straightforward syslog backend or something more fancy like fluentd/cloudwatch/etc. I am glad you chimed in because I was basically going to create a dedicated syslog container and allow it to "attach" itself and "monitor" the DNS logs. But that would have been a separate container in reality.

All that's really needed is something like when you launch the container:

-–log-driver syslog –-log-opt syslog-address=udp://a.b.c.d:514

I am going to leave a link to the "better option" heer for others who stumble on this: https://docs.docker.com/engine/admin/logging/overview/