服务器 
首页 > 服务器 > 浏览文章

docker日志出现无法检索问题的解决

(编辑:jimmy 日期: 2024/11/19 浏览:3 次 )

日常检查服务的时候,从portainer那里进去看容器日志的时候,发现右上角出现红色的感叹号:Unable to retrieve container logs。

因为之前没出现过这样的问题,所以就先上服务器上用命令docker logs -f containerID看日志,发现日志也是动不了,还是停留在某个时间的日志记录上。

想了一下不应该是服务的日志打印出问题,先照着Google搜索了一遍,发现都没有跟我的问题相匹配的。因为日志有时能收集显示,有些日志不可以,应该是跟docker设置的日志引擎有问题。

本来是想整一套EFK的,但是感觉现在日志量还不够大,所以并没有修改docker的日志引擎,还是默认的journald

[root@ad-official xiaoxiao]# docker info|grep Logging
 WARNING: You're not using the default seccomp profile
Logging Driver: journald

journald的官方文档上有这么一个说明:

man journald.conf ... RateLimitInterval=, RateLimitBurst= Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitInterval=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each other's limits. Defaults to 1000 messages in 30s. The time specification for RateLimitInterval= may be specified in the following units: "s", "min", "h", "ms", "us". To turn off any kind of rate limiting, set either value to 0. ...

这里写了默认30秒内只能接收1000条日志,看到这里就能明白了,因为前阵子刚在docker发布了一个单日日志文件大小差不多达到3G的服务,导致到了其他服务的日志也受到了影响,大量的日志被journald丢弃,所以我们修改一下配置就没有问题了。

打开/etc/systemd/journald.conf文件,将RateLimitBurst从默认的1000修改成5000,根据自己目前的日志输出量进行调整:

[root@ad-official log]# cat /etc/systemd/journald.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
RateLimitBurst=5000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
ForwardToWall=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K

顺便将ForwardToSyslog和ForwardToWall设置成no,因为默认是yes,会导致我们清理了journal的日志文件,而Syslog中的没有清除掉,慢慢的就会将磁盘占满。

然后重启一下journald就可以恢复正常使用啦:systemctl restart systemd-journald.service

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

上一篇:修改Tomcat运行时jvm编码问题
下一篇:CentOS7部署19版docker(简单,可跟做)
一句话新闻
一文看懂荣耀MagicBook Pro 16
荣耀猎人回归!七大亮点看懂不只是轻薄本,更是游戏本的MagicBook Pro 16.
人们对于笔记本电脑有一个固有印象:要么轻薄但性能一般,要么性能强劲但笨重臃肿。然而,今年荣耀新推出的MagicBook Pro 16刷新了人们的认知——发布会上,荣耀宣布猎人游戏本正式回归,称其继承了荣耀 HUNTER 基因,并自信地为其打出“轻薄本,更是游戏本”的口号。
众所周知,寻求轻薄本的用户普遍更看重便携性、外观造型、静谧性和打字办公等用机体验,而寻求游戏本的用户则普遍更看重硬件配置、性能释放等硬核指标。把两个看似难以相干的产品融合到一起,我们不禁对它产生了强烈的好奇:作为代表荣耀猎人游戏本的跨界新物种,它究竟做了哪些平衡以兼顾不同人群的各类需求呢?