When it comes to Docker logging methods, there’s really no best approach. Everything depends on your particular system and your team’s preferences. There are more than four ways to go about the task of logging in Docker, but the following methods are not only the most common, they also rank at the top of the efficiency scale. Here’s a quick summary of each method, alongside some well-known pros and cons:

 

Using the Application

When each container uses a different system, they can be configured to send events to a central location. One challenge of logging with the app is that developers have to do the configuring within the app as well. That typically means that libraries will also face the challenge of dealing with complex delivery methods.

On the bright side, the key advantages to this style of Docker logging is that the apps are totally independent of hosts as well as the containers. Further, if the development team is accustomed to dealing with frameworks, this approach will be the easiest. Finally, no other Docker logging method offers as much potential for customization and flexibility.

Using the Logging Driver

Even though your containers will eventually become dependent on your own machine, that’s the only drawback to this method. Using the Docker driver is actually the most preferred of all four methods in common usage. Not only is this approach native to Docker, it’s surprisingly simple to configure and has the added advantage of putting all logs in one place.

Docker’s default method is to place logs directly on the host machine. The alternative is to change the Docker driver so that it forwards all the log messages to your preferred endpoint. That typically means they will be forwarded to gelf, journald or syslog.

A Dedicated Container

This is a clever way for tech teams to build a solution directly into their own architecture. Of course, the dedicated container will thereafter do nothing but its sole task: it will consume all the events.

What’s the downside? There’s just one major disadvantage to this method. You will need to make sure that logging containers are fully aware of the app containers. Likewise, app containers need to know that logging containers exist. The good news is that this method’s advantages are numerous. They include independence from the host machine and exceptionally easy scaling. In fact, whenever you need additional logging containers, all you need to do is deploy them on an ad hoc basis.

The Sidecar Method

The so-called sidecar method is very similar to using a dedicated container (see above section), except that every container is associated with a specific app container. The sidecar system can be a challenge to set up, and it means you’ll need to treat each app and its associated container as if they were one unit. On the bright side, when you choose the sidecar method, you have free reign to customize every app’s logging system. The biggest plus, however, is that the sidecar method is simple to maintain because all the tasks take place efficiently and automatically.