syslog in a container world
In the classic Unix world when a daemon want to log something he needs to open a log channel to the syslog daemon. This is normally done via openlog() system call.
What happen at this time is that the underlying library search for a logging device which is pre-defined in this file for the glibc.
http://sourceware.org/git/?p=glibc.git;a=blob;f=bits/syslog-path.h;hb=HEAD
This means that the device “/dev/log” MUST be available in the container, which isn’t in the most containers. It is also against the best practice to log into the local file or to syslog therefore you don’t need this device.
But to be honest there are a lot of Software out there which requires this “/dev/log” device but how can we provide this device into the container.
There are several solutions to add this device into the container but all requires root privileges which you normally not have in a PaaS.
❓ | How about to log via the syslog-remote option?
This means that you don’t need to offer the “/dev/log” Device only a small daemon is required which listen on any defined port and receives syslog messages.
Luckily DJB have created several software packages which all write there messages to stdout. Some of the called “DJB friends” liked the idea to write to stdout and process the log lines further with different tools. But as program’s does not run always in a DJB friendly environment it raises the requirements to read from “/dev/log” Device in syslog format.
Several “DJB friends” have created a solution for this. I have picked Gerrit Pape’s solution socklog to solve this issue.
There is a container on docker hub which you can use to receive logs from “/dev/log” device AND from a udp socket me2digital/alpine-socklog.
You can also use this container as a side car which ties the syslog container and the writing daemon together.
In the Readme of the git repo is a example session documented.
https://github.com/git001/alpine-socklog#run-and-test
There is also a new kid on the block which offers the option to receive syslog messages via a unix socket but not yet via network, it’s called fluent-bit.
fluent-bit have currently a issue about syslog messages which will be fixed in the future versions.
Update: This is fixed in the current versions. #240
fluent-bit is the small partner of fluentd. The main differences are documented on the fluent-bit site.
Pick a doc version => Fluentd & Fluent Bit