Logging is an essential part of application containerization, helping developers track patterns, troubleshoot problems, and fix bugs. Docker offers integrated logging solutions and additional features that ensure efficient log management.
Read on to learn about Docker container logs, the commands they relate to, and best practices that developers can apply
Where are Docker container logs stored? Docker logs
get the stdout (normal output) and stderr (error messages) sequences of the command. All output and error messages are logged, passed to the container’s log handler, and forwarded to the desired location (a file, log collector, or log management service).
The default log handler for Docker is the JSON file handler that stores the logs on the host. Locate the files in the following directory:
Replace the path ID with the container ID
. Docker command to
The docker logs command instructs Docker to retrieve logs from a running container at run time. It only works with containers that use the JSON file or the registry handler with registration.
The command syntax for retrieving
container logs is: sudo docker container logs [option] container_id
Replace container_id with the ID number of the container you want to inspect. To find the container ID, use the docker ps command to list the running containers.
In the example below, Docker is running a MySQL container with ID ebebb5c7ae0d. To display your
logs, run: sudo docker logs ebebb5c7ae0d As in the
image below, Docker responds by listing the event logs for that specific container in the
output. Docker container logs
Docker command options allows you to add options to the command to configure the output according to individual needs.
Available command options include:
Docker container logging best practices Docker
provides several logging mechanisms for tracking and managing logs, some of which are built in and configured by default
Consider the following best practices and recommended approaches that help keep container records on point and secure.
Docker registry controller
Docker provides built-in registry controllers within containers to serve as log management systems. The controller reads the output of the container (the data transmitted by its stdout and stderr streams), formats the records, and stores them in a file on the host computer or on a defined endpoint.
The type of driver determines the format of the logs and where they are stored. By default, Docker uses the JSON file handler, which writes JSON-formatted records to the container host machine. You can use other built-in controllers to forward collected logs to logging services, log senders, or a centralized management service.
If none of the existing controllers meet your requirements, Docker allows you to create a custom registry controller, add it as a plugin to a container, and even distribute it through a Docker registry.
Select a delivery mode
Delivery modes determine how
messages are prioritized and delivered to the log controller from the container
Docker has two delivery modes
- Direct, Delivery Block. Blocking is the default mode that sends all messages directly to the controller, interrupting the application when a new message occurs. This option ensures that all results are logged immediately, but can potentially affect application performance and cause latency if the log handler requires more time to crash.
- Non-blocking delivery. Non-blocking is a delivery mode that includes an intermediate ring buffer within the container where logs are stored until the log controller processes them. If the register controller is busy, the registers are stored in the ring buffer in memory and passed only until the controller is ready to process them.
Application-based Docker logging includes managing and analyzing log events using the application framework. This means that Docker logs are handled and stored within application containers.
The main advantage of using logging through the app is that developers gain more control over logging events. On the other hand, it is not recommended to keep logs inside a container due to its transient nature. If a container is closed, its file system is destroyed.
Configure persistent storage or stream logs to a remote management solution to ensure persistence
Logging using data volumes
Keeping Docker logs inside a container can result in data loss if the container is closed. One way to resolve this problem is to use data volumes as persistent storage for log events.
are file systems stored on the host and mounted in Docker containers to preserve the data generated by the running container. Volumes are independent of the container lifecycle, meaning the data is secure even if the container fails. Plus, its independence means you can easily copy, backup, and share file systems between containers.
dedicated log container
Collect and manage Docker logs using a dedicated log container that is not dependent on the host machine. This container collects log files from the Docker environment, monitors and inspects the logs before sending them to a centralized location.
As the log container is a separate unit, you can easily move it between different environments. In addition, scaling the logging infrastructure is simple: if necessary, add new log containers to the existing configuration.
Another great advantage of using dedicated registry containers is that they do not require the installation of a configuration code. On the other hand, the application and log containers must be defined correctly to ensure smooth automated logging.
Sidecar Approach The sidecar approach is one of the most popular methods for managing microservices architecture for more complex deployments
Sidecars are services deployed together with the main application within a container as a child process. They share volume and network with the main container and ultimately increase the functionality of the application.
Each application has its own dedicated container as a personalized registration service adapted to the program. The log container saves the log files to the volume, tags them, and sends them to a third-party log management solution.
Docker records management using the sidecar approach simplifies identifying and tracking the origin of each record by using custom tags. On the other hand, the sidecar method is more complex and requires more resources than the dedicated registry solution.
After reading this article, you should have a better understanding of how Docker logs work, how to use the basic commands to work with them, and what are the best practices for managing Docker logs
To learn more about the Docker commands you’re sure to use while working with containers, check out our Docker Command List: Chop.