我在 Proxmox 集群上运行大约 60 个网络服务器(使用 KVM)。这些虚拟机运行最新版本的 Debian 11。它们使用 nginx、不同版本的 PHP-FPM 和 MariaDB。我遵循基础设施即代码的方法,除了基础设施中的一些例外(例如 jitsi)之外,所有服务器均由 ansible 提供,因此几乎相同。我托管标准 Typo3 安装以及通常在 Laravel 中开发的更复杂的应用程序。不久前,我开始在 CheckMK 中为我们的基础设施和已上线的客户项目配置主动检查(这些检查使用 Nagios 的一个名为 check_http 的插件),这意味着可以从外部访问。
此后,我开始以每天大约一到两个的频率出现超时错误,这些错误似乎随机分布在我通过主动检查进行监控的二十台服务器上。起初我认为这只是误报,但上周五它发生在 Jitsi 会议期间,并由一位同事向我报告。我检查了 nginx 的日志,发现以下条目显示了 Checkmk 无法到达服务器的确切时间段,该时间段不到一分钟(检查之间的时间,下一次检查总是负数,意味着没有错误),并且可能只需几秒钟。这个问题的原因是什么?我该如何解决它?您对我如何重现并进一步分析问题有什么建议吗?
检查mk错误消息:
摘要连接到地址 195.34.XXX.XXX 和端口 443:连接被拒绝详细信息 HTTP 严重 - 无法打开 TCP 套接字
检查mk-恢复消息:
摘要 HTTP OK:HTTP/1.1 200 OK - 0.008 秒响应时间内 59404 字节
Nginx 错误日志:
2022/09/16 11:18:42 [警报] 3212994#3212994:*2590 打开套接字 #18 留在连接 5 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2494 打开套接字 #15 留在连接 8 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2533 打开套接字 #16 留在连接 9 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2534 打开套接字 #17 留在连接 10 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2591 打开套接字 #20 留在连接 11 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2573 打开套接字 #24 留在连接 12 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2532 打开套接字 #10 留在连接 13 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*3230 打开套接字 #28 留在连接 14 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2467 打开套接字 #19 留在连接 15 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2535 打开套接字 #21 留在连接 16 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*3233 打开套接字 #27 留在连接 17 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2771 打开套接字 #30 留在连接 22 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*2770 打开套接字 #29 留在连接 23 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*3234 打开套接字 #22 留在连接 24 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*3229 打开套接字 #11 留在连接 26 中
2022/09/16 11:18:42 [警报] 3212994#3212994:*3231 打开套接字 #32 留在连接 28 中
2022/09/16 11:18:42 [警报] 3212994#3212994:正在中止
2022/09/16 11:20:19 [错误] 3295994#3295994: *153 读取响应时上游超时(110:连接超时)>
此致
斯特凡·马尔特·舒马赫
答案1
这可能是由于“最大打开文件软限制数”太小造成的。我看到 Debian 中的默认值从 65536 更改为 1024。这对于 nginx 来说可能不够。通过键入以下内容在控制台中验证这一点:
ulimit -n
要确定 nginx 使用的限制,请输入以下命令检查其实例的 PID:
ps aux |grep nginx
您会获得一些行,例如:
www-data 148105 0.0 0.1 59100 5492 ? S Feb09 0:00 nginx: worker process
获取一个进程的 PID(第二列),然后:
cat /proc/[PID]/limits
cat /proc/148105/limits # in this example
搜索行:
Max open files 8192 8192 files
如果你得到 1024 而不是 8192,请在 ngnix 配置文件 (nginx.conf) 的开头(主要部分)添加以下行:
worker_rlimit_nofile 8192;
你可以观察一下。使用更大的数字。最后,重新启动 ngnix 守护进程并使用上述过程检查新值。