Docker容器日志實例代碼分析

今天小編給大家分享一下Docker容器日志實例代碼分析的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

查看容器日志

先使用  docker run -it --rm -d -p 80:80 nginx:1.15.8-alpine 命令啟動一個nginx容器。如果沒有異常，會得到容器id如  d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00  的長串。再使用  curl -i   訪問服務，確認nginx容器正常啟動運行。最后使用  docker logs -f d24  查看容器的日志輸出，大概如下：

172.17.0.1 - - [24/mar/2019:03:51:21 +0000] "get / http/1.1" 200 612 "-" "curl/7.29.0" "-"

一般來說使用容器id的前3位即可

以上就是我們查看容器日志的日常方法了，非常簡單實用。

容器日志文件存儲

容器的日志會以json文件方式存儲在本地磁盤，可以使用下面方式查看文件路徑  docker inspect d42 | grep log 可以找到:

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

注意1：mac上沒有/var/lib/docker目錄 ，因為docker for mac的運作方式不一樣，最好使用linux系統練習。

注意2:  如果logpath內容為空，大概是因為docker engine版本，升級docker版本能到docker-ce 18.09.3

查看 d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00-json.log 文件，可以看到:

{"log":"172.17.0.1 - - [24/mar/2019:03:51:21 +0000] \"get / http/1.1\" 200 612 \"-\" \"curl/7.29.0\" \"-\"\r\n","stream":"stdout","time":"2019-03-24t03:51:21.982476951z"}

這條信息的log字段內容和之前通過  docker logs  命令查看的內容一致。

容器日志會跟隨容器生命周期，容器銷毀后日志也會銷毀。使用  docker stop 24  關停測試的nginx服務。因為容器啟動使用時候用了  --rm  參數，關停后會自動清理刪除，所以會發現 /var/lib/docker/containers/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00  目錄不存在了，相應的日志文件也就刪除了。

容器日志文件滾動策略

docker容器日志默認寫入json文件，在線上運行時候會有磁盤寫滿的風險。可以調整策略，讓其進行滾動。修改/etc/docker/daemon.json（如果沒有就手工創建一個），增加下面內容：

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

修改完成后重啟docker服務：

systemctl daemon-reload
systemctl restart docker.service

測試一下新的日志策略，使用下面的命令創建一個容器：

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

這個alpine容器就是每隔10微秒輸出hello world，保持高頻度輸出，快速生產日志文件。

注：shell中的時間控制

1、sleep : 默認為秒。
sleep 1s 表示延遲一秒 
sleep 1m 表示延遲一分鐘 
sleep 1h 表示延遲一小時 
sleep 1d 表示延遲一天    

2、usleep : 默認以微秒。 

1s = 1000ms = 1000000us

按照前文中查看日志文件的方法

# pwd
/var/lib/docker/containers/aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3
# ls -lah
total 2.6m
drwx------ 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

很容易發現，日志文件的策略就是維持3個1m大小文件存在，和我們設置保持一致。

測試完成后，記得使用docker stop aa3 清理測試現場，max-size也可以按照真實需求調整大小。

nginx容器日志

了解docker容器的日志策略后，再看看常用的容器是如何處理的。先看看nginx容器。

首先  docker run -it --rm -d -p 80:80 nginx:1.15.8-alpine  創建一個nginx容器，然后  docker exec -it b6d sh  進入容器，查看/etc/nginx/nginx.conf可以看到下面內容：

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

也就是nginx會將錯誤日志和訪問日志寫入對應的日志文件。繼續查看/var/log/nginx目錄：

/var/log/nginx # ls -lah
total 0
drwxr-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/stdout
lrwxrwxrwx 1 root  root   11 jan 31 23:32 error.log -> /dev/stderr

這就發現奧秘了，access.log文件會通過軟鏈接重定向到標準輸出，而錯誤日志error.log則會重定向標準錯誤。這樣使用docker log命令就可以看到nginx的訪問日志了。

為了進一步驗證，查看nginx dockerfile文件，其中有：

# 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

可見nginx鏡像創建時候就定義好了日志文件的輸出。

同樣使用docker stop 524清理現場，以后就不再介紹清理這一步驟了。

mysql容器日志

啟動一個mysql容器

docker run --rm -e mysql_root_password=123456 mysql:5.7

不難看到mysql容器日志輸出, 截取其中片段如下:

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]  is created with an empty password ! please consider switching off the --initialize-insecure option.
2019-03-24t08:48:24.066683z 1 [warning] 'user' entry  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066730z 1 [warning] 'user' entry  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066740z 1 [warning] 'user' entry  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066756z 1 [warning] 'db' entry 'performance_schema  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066761z 1 [warning] 'db' entry 'sys  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066772z 1 [warning] 'proxies_priv' entry '@  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066814z 1 [warning] 'tables_priv' entry 'user  ignored in --skip-name-resolve mode.
2019-03-24t08:48:24.066822z 1 [warning] 'tables_priv' entry 'sys_config  ignored in --skip-name-resolve mode.
database initialized
initializing certificates
generating a rsa private key

查看mysql dockerfile  文件，可以知道mysql鏡像啟動入口在entrypoint.sh，從腳本中發現：

echo 'initializing database'
"$@" --initialize-insecure
echo 'database initialized'

以上就是“Docker容器日志實例代碼分析”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。