必须从进程和系统层面监控nginx文件句柄：逐个检查worker进程的fd数量及软限制，阈值预警设为soft limit的85%，结合stub_status与系统指标分析泄漏根源并接入prometheus长期观测。
不能靠 Nginx 内置变量查文件句柄使用情况，因为变量只反映请求路径、状态等上下文，不暴露操作系统级的 fd 编号或生命周期事件。真实监控必须落到进程和系统层面。
查单个 worker 进程当前打开的句柄数
这是最直接、最可靠的起点。Nginx 每个 worker 进程独立管理自己的 fd，需逐个检查：
- 获取任一 worker 的 PID：
pgrep -f "nginx: worker" | head -n1 - 查看该进程已打开的 fd 数量：
ls -l /proc/PID/fd/ 2>/dev/null | wc -l - 同时查它的软限制（实际生效值）：
cat /proc/PID/limits | grep "Max open files"，重点关注 Soft Limit 列 - 若要批量检查所有 worker：
for pid in $(pgrep -f "nginx: worker"); do echo "PID $pid: $(ls -l /proc/$pid/fd/ 2>/dev/null | wc -l)"; done
设阈值预警，别等报错才行动
“Too many open files”不是预警信号，是故障已发生的标志。应基于实时占用率主动干预：
- 当任意 worker 的 fd 占用数持续超过其 Soft Limit 的 85%，就该触发告警
- 结合
nginx_stub_status中的 Active connections 和 Waiting 状态判断异常类型：Waiting 高 + fd 高 → keepalive 堆积；Reading 高 + fd 高 → SSL 握手或慢请求卡住 fd - 定期看全系统句柄水位：
cat /proc/sys/fs/file-nr，第二列（已使用）占第三列（最大）超 70%，说明全局资源紧张，不单是 Nginx 的问题
识别隐性泄漏源，从配置入手
很多 fd 持续增长并非代码缺陷，而是配置与业务不匹配：
-
日志写入方式：access_log 未加
buffer=64k flush=5s，每次请求都 open/write/close，快速耗尽 fd -
上游连接复用失效：proxy_http_version 设为 1.0，或误删
proxy_set_header Connection ''，导致后端连接无法 keepalive - 文件缓存配置过激：open_file_cache max 设过大（如 2M）、inactive 时间却太短（如 10s），缓存频繁失效重载，反复 open 文件
- SSL 会话缓存缺失：ssl_session_cache 未启用或 size 过小，迫使大量全握手，间接增加临时 fd 和内存分配
长期监控要接入指标体系
人工查一次只能看瞬时状态，真正预判瓶颈需要趋势分析：
- 把每个 worker 的 fd count 接入 Prometheus（可用 node_exporter 的
process_open_fds或自定义 exporter） - 在 Grafana 中画出各 worker fd 使用率曲线，并设置规则：>85% 持续 2 分钟即告警
- 关联
nginx_stub_status的 Active、Reading、Writing、Waiting 四项，交叉分析资源占用模式 - 配合
vmstat观察 wa（I/O 等待）和 bi/bo（块设备读写），判断是否因日志刷盘或静态文件读取引发 fd 波动
