平臺架構：Rancher,k8s,微服務

問題的香港賽馬平臺搭建論壇：haozbbs.com Q1446595067 出現發生在最近，當服務的數量增加到一定程度時，出現了容器日誌不定期丟失的情況，通過以下方式均沒有日誌信息輸出：
1）通過Rancher,Kubernetes UI查看容器日誌
2）通過docker logs查看
2.問題分析
2.1 初步分析

由於是日誌出現問題，首先考慮到的是rsyslog和journal服務是否工作正常；通過修改如下配置測試：

rsyslog配置文件：/etc/rsyslog.conf

// 日誌頻率限制
$IMUXSockRateLimitInterval 0

1
2
3
4
5
6

journal配置文件：/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

然而，這樣的措施只是暫時的解決了問題，一段時間之後問題仍會出現。可能只是重啟了服務的作用；

在對所有服務器做相同的配置修改時，重啟服務時遇到了如下提示信息：

: 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的配置以應對多容器，日誌量大的環境；

容器數量增加香港賽馬平臺搭建導致fs.inotify.max_user_instances超過限制