Applications that use Docker are significantly more heavily dependent on logs. Logs are forwarded to the application's stderr and stdout output streams when they get generated by a Docker container's applications. By default, Docker employs a json-file driver, which writes JSON-formatted logs to a container-specific file on the host where the container is running.
Daemon logs and container logs are the two sorts of logs you work with while using Docker.
1. Container Logs
As the name suggests, Docker container logs are generated by the Docker containers. They need to be collected directly from the containers. Any messages that a container sends to stdout or stderr is logged then passed on to a logging driver that forwards them to a remote destination of your choosing.
The docker logs command shows information logged by a running container. The docker service logs command shows information logged by all containers participating in a service. The information that is logged and the format of the log depends almost entirely on the container’s endpoint command.
By default, docker logs or docker service logs shows the command’s output just as it would appear if you ran the command interactively in a terminal. UNIX and Linux commands typically open three I/O streams when they run, called STDIN, STDOUT, and STDERR.
STDIN is the command’s input stream, which may include input from the keyboard or input from another command. STDOUT is usually a command’s normal output, and STDERR is typically used to output error messages. By default, docker logs shows the command’s STDOUT and STDERR.
In some cases, docker logs may not show useful information unless you take additional steps.
If you use a logging driver which sends logs to a file, an external host, a database, or another logging back-end, and have “dual logging” disabled, docker logs may not show useful information.
If your image runs a non-interactive process such as a web server or a database, that application may send its output to log files instead of STDOUT and STDERR.
In the first case, your logs are processed in other ways and you may choose not to use docker logs. In the second case, the official nginx image shows one workaround, and the official Apache httpd image shows another.
The official nginx image creates a symbolic link from /var/log/nginx/access.log to /dev/stdout, and creates another symbolic link from /var/log/nginx/error.log to /dev/stderr, overwriting the log files and causing logs to be sent to the relevant special device instead.
The official httpd driver changes the httpd application’s configuration to write its normal output directly to /proc/self/fd/1 (which is STDOUT ) and its errors to /proc/self/fd/2 (which is STDERR)
2. Daemon Logs
Docker daemon logs are generated by the Docker platform and located on the host. Depending on the host operating system, daemon logs are written to the system's logging service or to a log file.
You could learn more about the state of your services if you only collected container logs. The purpose of Docker daemon logs is to use conventional logging techniques to keep track of the status of your Docker platform. They clearly depict the entire microservices architecture of your system.
The Docker daemon logs two types of events:
Events generated by the Docker service itself
Commands sent to the daemon through Docker's Remote API
Depending on your Operating System, the Docker daemon log file is stored in different locations.
With this, I'll wrap the post here.
We will discuss more about the logging in the following posts.
Thank you for reading!
*** Explore | Share | Grow ***
Comments