Shulou(Shulou.com)06/01 Report--

This article shares with you the content of a sample analysis of Docker container logs. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

View container log

Start a nginx container with the docker run-it-- rm-d-p 80:80 nginx:1.15.8-alpine command. If there is no exception, you will get a long string of container ID such as d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00. Then use curl-I http://127.0.0.1 to access the service to confirm that the nginx container is up and running normally. Finally, use docker logs-f d24 to view the log output of the container, which is roughly as follows:

172.17.0.1-[24/Mar/2019:03:51:21 + 0000] "GET / HTTP/1.1" 200612 "-" curl/7.29.0 ""-"

Generally speaking, you can use the first three bits of the container ID.

The above is our daily method to view the container log, which is very simple and practical.

Container log file storage

The container log is stored as a json file on the local disk. You can check the file path docker inspect D42 in the following way | grep Log can find it:

"LogPath": "/ var/lib/docker/containers/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00-json.log"

Note that there is no / var/lib/docker directory on 1:mac, because docker for mac works differently, so it's best to use the linux system to practice.

Note 2: if the LogPath content is empty, probably because of the docker engine version, upgrade the docker version to docker-ce 18.09.3

Looking at the d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00-json.log file, you can see:

{"log": "172.17.0.1-- [24/Mar/2019:03:51:21 + 0000]\" GET / HTTP/1.1\ "200612\" -\ "curl/7.29.0\" -\ "\ r\ n", "stream": "stdout", "time": "2019-03-24T03:51:21.982476951Z"}

The log field content of this message is the same as what was previously viewed with the docker logs command.

The container log follows the container life cycle, and the log is also destroyed after the container is terminated. Use docker stop 24 to shut down the tested nginx service. Because the container uses the-rm parameter when it is started, it will be automatically cleaned and deleted after shutdown, so the / var/lib/docker/containers/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00 directory will no longer exist and the corresponding log files will be deleted.

Container log file scrolling policy

The docker container log is written to the json file by default, and there is a risk that the disk will be full when running online. You can adjust the policy to scroll. Modify / etc/docker/daemon.json (create one manually if you don't have one) and add the following:

{"log-opts": {"max-size": "1m", "max-file": "3"}}

Restart the docker service after modification:

Systemctl daemon-reloadsystemctl restart docker.service

Test the new logging policy and create a container using the following command:

Docker run-d-rm alpine:3.6 sh-c "while true; do echo hello world; usleep 10; done"

This alpine container outputs hello world every 10 microseconds to maintain high frequency output and quickly produce log files.

Note: time control in shell

1. Sleep: the default is seconds.

Sleep 1s means a delay of one second

Sleep 1m means a delay of one minute

Sleep 1h means a delay of one hour

Sleep 1d means a delay of one day

2. Usleep: microseconds by default.

1s = 1000ms = 1000000us

Follow the method of viewing the log file in the previous article

# pwd/var/lib/docker/containers/aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3# ls-lahtotal 2.6 Mdrwx-4 root root 4.0K Mar 24 16:22. Drwx-3 root root 4.0K Mar 24 16:21.-rw-r- 1 root root 647K Mar 24 16:22 aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3-json.log-rw-r- 1 root root 977K Mar 24 16:22 aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3-json.log.1-rw-r- 1 root root 977K Mar 24 16:21 aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3-json.log.2

It is easy to find that the strategy for log files is to maintain the existence of three 1m files, consistent with our settings.

After the test is complete, remember to use docker stop aa3 to clean up the test site, and max-size can also be resized according to real needs.

Nginx container log

After you understand the logging policy of the docker container, take a look at how commonly used containers are handled. Take a look at the nginx container first.

First, docker run-it-- rm-d-p 80:80 nginx:1.15.8-alpine creates a nginx container, then docker exec-it b6d sh enters the container, and check / etc/nginx/nginx.conf to see the following:

Error_log / var/log/nginx/error.log warn;access_log / var/log/nginx/access.log main

That is, nginx writes the error log and access log to the corresponding log file. Continue to check the / var/log/nginx directory:

/ var/log/nginx # ls-lahtotal 0drwxr-xr-x 2 root root 39 Mar 4 07:54. Drwxr-xr-x 3 root root 18 Mar 4 07:54.. lrwxrwxrwx 1 root root 11 Jan 31 23:32 access.log-> / dev/stdoutlrwxrwxrwx 1 root root 11 Jan 31 23:32 error.log-> / dev/stderr

This reveals the secret: the access.log file is redirected to standard output via a soft link, while the error log error.log redirects standard error. This allows you to see the access log of nginx using the docker log command.

For further verification, look at the nginx dockerfile file, which includes:

# forward request and error logs to docker log collector & & ln-sf / dev/stdout / var/log/nginx/access.log\ & & ln-sf / dev/stderr / var/log/nginx/error.log

It can be seen that the output of the log file is defined when the nginx image is created.

Docker stop 524 is also used to clean up the site, and this step will not be introduced in the future.

Mysql container log

Start a mysql container

Docker run-rm-e MYSQL_ROOT_PASSWORD=123456 mysql:5.7

It is not difficult to see the mysql container log output, and the snippet is intercepted as follows:

Initializing database

2019-03-24T08:48:19.102726Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use-explicit_defaults_for_timestamp server option (see documentation for more details).

2019-03-24T08:48:20.241459Z 0 [Warning] InnoDB: New log files created, LSN=45790

2019-03-24T08:48:20.414933Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.

2019-03-24T08:48:20.509897Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 935a6ee7-4e11-11e9-b135-0242ac110002.

2019-03-24T08:48:20.519148Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.

2019-03-24T08:48:20.519843Z 1 [Warning] root@localhost is created with an empty password! Please consider switching off the-- initialize-insecure option.

2019-03-24T08:48:24.066683Z 1 [Warning] 'user' entry' root@localhost' ignored in-- skip-name-resolve mode.

2019-03-24T08:48:24.066730Z 1 [Warning] 'user' entry' mysql.session@localhost' ignored in-- skip-name-resolve mode.

2019-03-24T08:48:24.066740Z 1 [Warning] 'user' entry' mysql.sys@localhost' ignored in-- skip-name-resolve mode.

2019-03-24T08:48:24.066756Z 1 [Warning] 'db' entry' performance_schema mysql.session@localhost' ignored in-- skip-name-resolve mode.

2019-03-24T08:48:24.066761Z 1 [Warning] 'db' entry' sys mysql.sys@localhost' ignored in-- skip-name-resolve mode.

2019-03-24T08:48:24.066772Z 1 [Warning] 'proxies_priv' entry' @ root@localhost' ignored in-skip-name-resolve mode.

2019-03-24T08:48:24.066814Z 1 [Warning] 'tables_priv' entry' user mysql.session@localhost' ignored in-- skip-name-resolve mode.

2019-03-24T08:48:24.066822Z 1 [Warning] 'tables_priv' entry' sys_config mysql.sys@localhost' ignored in-- skip-name-resolve mode.

Database initialized

Initializing certificates

Generating a RSA private key

If you look at the mysql Dockerfile file, you can see that the mysql image startup entry is in entrypoint.sh, and you can find it in the script:

Echo 'Initializing database' "$@"-- initialize-insecureecho' Database initialized'

This corresponds to the output of the mysql container at startup. Entrypoint.sh is more complex, the main function is to start mysqld, and log output, because it is not the focus of this article, it will not be described in detail.

Summary

The docker container is output to the local json file by default, and its size and quantity can be controlled.

The application container log can be converted into a log file, and then softly connect the application log file to standard output. For example, nginx; can also print the log directly to standard output at startup, such as mysql.

Thank you for reading! This is the end of this article on "sample Analysis of Docker Container Log". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.