Docker Logging Strategies

Loggly provides the infrastructure to aggregate and normalize log events so they are available to explore interactively, build visualizations, or create threshold-based alerting. In general, any method to send logs from a system or application to an external source can be adapted to send logs to Loggly. The following instructions provide one scenario for sending logs to Loggly.

There are several ways of getting your Docker logs to Loggly. We made this guide to help you choose the best one for your needs. For more comparison details, read our blog Top Docker Logging Methods to Fit Your Container Deployment Strategy

Option 1: Logging via the Docker Logging Driver (Recommended)

This method uses the Docker service to read stdout and stderr output generated by containers. The default configuration writes logs to a file on the host machine, but changing the logging driver lets you forward messages to syslog, journald, gelf, or other endpoints. Refer to Docker Logging Driver for more information.

Benefits	Drawbacks	When Should I Use It?
Native to Docker Easy to configure Centralizes logs in a single location	Containers become dependent on the host machine	Recommended for most common uses

Option 2: Logging via a Dedicated Logging Container

A dedicated logging container serves the sole purpose of consuming log events. Running it as a container lets you make your logging solution a part of your architecture. Refer to Docker Logging Through Syslog for more information.

Benefits	Drawbacks	When Should I Use It?
Removes dependencies on the host machine Simplifies scaling: simply deploy more logging containers when necessary	Application containers need to be aware of the logging container, and vice versa	Use when you’d like to aggregate logs locally before sending to Loggly

Option 3: Logging via the Sidecar Approach

Like the dedicated logging approach, the sidecar approach uses logging containers. The difference is that it pairs each application container with its own dedicated logging container. It can be implemented using mounted volumes to share logs between containers, as discussed in the linked blog. It can also work with a logspout container. For more information see How to implement logging in Docker with a sidecar approach from the Loggly blog.

Benefits	Drawbacks	When Should I Use It?
Lets you fully customize each application’s logging solution Easier to maintain: logging is handled automatically and seamlessly	Difficult to set up Both the application and logging container must be treated as a single unit  May consume more resources than a dedicated logging solution	Use in a large, distributed architecture where you still need fine-tuned control over your logging solution

Option 4: Logging via the Application

This method requires each container to have its own internal methods for logging. This typically involves using a logging framework such as Logback, winston, or Log4Net to send log events to Loggly. For more information, see Logging Setup.

Benefits	Drawbacks	When Should I Use It?
Easier for developers familiar with logging frameworks Applications are independent of containers and the host  Provides greater flexibility and customization	Requires developers to configure in app  Requires logging libraries to handle complexities of delivery	Use when you require a high degree of control over each application’s logging implementation