Logging on Docker has steadily evolved with each Docker release and there are some exciting new updates that have come with Docker 1.7 – for example, Docker 1.7 now includes new driver support for for Journald along with the driver support added with Docker 1.6 for JSON and syslog!  We are here on the ground at DockerCon as part of the Innovators Showcase  of Docker ecosystem partners, and have been digging into Docker’s latest release 1.7, which was announced yesterday. Naturally we have been looking at it from a logging and monitoring perspective… 

state-of-docker-1.7

So how does it work? For anyone following conversations around Docker logging over the past year or so there were quite a few proposals for a logging API driver for forwarding your logs to a centralized logging service. In the end, the new logging driver followed the exec driver and storage driver concepts that were already available in Engine.

With 1.7 you now have 4 options when it comes to specifying a driver (note, I expect to see more of these coming with subsequent releases).

  • — log-driver=none: Disables any logging for the container. 
  • — log-driver=json-file: Default logging driver for Docker. Writes any container output as JSON messages to file.
  • — log-driver=syslog: when you run the docker daemon with the –log-driver=syslog option, any output from a container goes directly to system syslog daemon – i.e. it ends up in /var/log/messages if you do not specify an end point. You can also however specify a host a port number where the driver will connect to forward your logs to a third party service or syslog server which is really nice! 
  • — log-driver=journald: This driver now writes log messages to journald; the container id will be stored in the journal’s CONTAINER_ID field. So if you are running on a host with systemd you should be able to take advantage of this – Ubuntu now ships with this, so also does CoreOs.

For more details on the logging drivers check out the Docker reference docs.

You still have a bunch of other options if for some reason the driver approach doesn’t work for you, for example:

  • logging directly from your application source code: If you have access to the source code, you can simply use a logging library to log directly from your application to a third party service or end point. This means you don’t need to worry about the underlying container or host.
  • logging using the Logentries Container:  The Logentries container is an easy way to get a complete view of what is happening across your containers. It is a specialized logging container that you can bring up and which talks to the Docker API. It can get per container logs via the API as well as per container resource usage metrics via the stats API. For more details on how to configure this check out this recent blog post on setting up the logentries container.

For more on logging from Docker check out our recent webinar which goes into a more in-depth discussion with some customers doing production logging from Docker environments and giving details on the pros and cons of each option and when it makes sense to go with one over another.