1.现象描述
2.问题分析
3.解决办法
4.总结
5.参考链接
1.现象描述
平台架构：Rancher,k8s,微服务
问题的香港赛马平台搭建论坛：haozbbs.com Q1446595067 出现发生在最近，当服务的数量增加到一定程度时，出现了容器日志不定期丢失的情况，通过以下方式均没有日志信息输出：
1）通过Rancher,Kubernetes UI查看容器日志
2）通过docker logs查看
2.问题分析
2.1 初步分析
由于是日志出现问题，首先考虑到的是rsyslog和journal服务是否工作正常；通过修改如下配置测试：
rsyslog配置文件：/etc/rsyslog.conf
// 日志频率限制
$IMUXSockRateLimitInterval 0
$IMJournalRatelimitInterval 0
// 打开文件数
$MaxOpenFiles 5000
1
2
3
4
5
6journal配置文件：/etc/systemd/journald.conf
[Journal]
Storage=yes
Compress=yes
// 日志频率和使用内存
RateLimitInterval=0
RuntimeMaxUse=20M(实际默认10M即可)
1
2
3
4
5
6重启组件
systemctl restart systemd-journald.service
systemctl restart rsyslog.service
1
2然而，这样的措施只是暂时的解决了问题，一段时间之后问题仍会出现。可能只是重启了服务的作用；
2.2 进一步分析
在对所有服务器做相同的配置修改时，重启服务时遇到了如下提示信息：
: Too many open files
1首先考虑的是文件句柄（fd）超出限制，所以对比以下两个命令的返回结果：
ulimit -n
100001(当前用户限制句柄数)
1
2
3
4/proc/sys/fs/file-nr
第一列值为系统总的句柄数
1
2
3发现实际当前用户是没有超过限制的；
如果超过限制，可参考这篇文章进行修改https://blog.csdn.net/sunny05296/article/details/54952009为了找到具体的问题，使用以下命令追踪journal输出：
strace -f journalctl -fn
1输出：
...
inotify_init1(O_NONBLOCK|O_CLOEXEC) = -1 EMFILE (Too many open files)
...
1
2
3于是，我们开始关注inotify的配置：
执行以下两个命令查看inotify实例创建情况：
当前限制值（默认为128）：
sysctl fs.inotify.max_user_instances
1用户级：
find /proc//fd/ -type l -lname ‘anon_inode:inotify‘ -print 2>/dev/null | cut -d/ -f3 |xargs -I ‘{}‘ -- ps --no-headers -o ‘%U‘ -p ‘{}‘ | sort | uniq -c | sort -nr
1进程级：
find /proc//fd/ -type l -lname ‘anon_inode:inotify‘ -print 2>/dev/null | cut -d/ -f3 |xargs -I ‘{}‘ -- ps --no-headers -o ‘%U %p %c‘ -p ‘{}‘ | sort | uniq -c | sort -nr
1于是，我们有了最终的解决方案。
3.解决办法
最终，通过fs.inotify.max_user_instances限制值问题得到解决，具体操作如下：
修改当前值：
sysctl fs.inotify.max_user_instances=1024
1添加配置到文件(目录/etc/sysctl.d/)：
sysctl fs.inotify.max_user_instances=1024
1
关于限制值：每一个instance大约会消耗5KB的内存，所以在内存允许的情况下可以适当增加。4.总结
虽然最终只通过修改fs.inotify.max_user_instances解决了问题，但是还是建议可适当优化rsyslog和journal的配置以应对多容器，日志量大的环境；
原文地址：http://blog.51cto.com/13857066/2137610