linux文件描述符（fd）用尽会引发进程启动失败、网络连接中断等问题，需通过zabbix或prometheus建立持续采集、统一建模、分级告警的闭环监控体系。
Linux系统文件描述符（file descriptor, FD）用尽会导致新进程无法启动、网络连接失败、日志写入中断等严重问题，但其使用率不像CPU或内存那样被默认采集。要实现全系统FD使用率监控与告警，关键不是“查一次”，而是建立持续采集、统一建模、分级告警的闭环。Zabbix 和 Prometheus 都能做，但路径不同：Zabbix 依赖 agent 主动上报或自定义脚本；Prometheus 更自然地通过 Node Exporter 的 node_filefd_allocated 和 node_filefd_maximum 指标直接拉取并计算比率。
确认当前FD使用情况与瓶颈点
排查不是为了临时救火，而是为监控打基础。先运行以下命令定位真实压力源：
-
看总量和上限：
cat /proc/sys/fs/file-nr—— 输出三列：已分配FD数、未使用数、系统最大限制（fs.file-max）；真正关心的是第一列 / 第三列的比值 -
看进程级占用：
lsof -n | awk '{print $2}' | sort | uniq -c | sort -nr | head -10—— 找出打开文件最多的前10个PID -
看用户级限制：
cat /proc/$(pgrep -f 'your_service')/limits | grep "Max open files"—— 确认是系统级瓶颈，还是某服务被 ulimit 卡住 -
检查是否泄漏：
watch -n 1 'cat /proc/sys/fs/file-nr'持续观察第一列是否缓慢上涨且不回落
Zabbix中配置FD使用率监控与告警
Zabbix 默认不采集 FD 指标，需手动添加。推荐用自定义 UserParameter 方式，轻量且稳定：
- 在被监控主机的
/etc/zabbix/zabbix_agentd.d/userparameter_fd.conf中添加：UserParameter=system.fd.utilization,awk '{print int(($1/$3)*100)}' /proc/sys/fs/file-nr - 重启 agent：
systemctl restart zabbix-agent，并在 Zabbix Server 端测试：zabbix_get -s HOST_IP -k system.fd.utilization，应返回 0–100 的整数 - 创建触发器，例如：
{HOST:system.fd.utilization.last()}>85，严重性设为“高” - 动作中可附加上下文信息，比如在告警消息里加入：
Current FD usage: {HOST:system.fd.utilization.last()}%, Max: {HOST:kernel.maxfiles.last()}（需额外采集kernel.maxfiles）
Prometheus中配置FD使用率监控与告警
Node Exporter（v1.0+）原生暴露 node_filefd_allocated 和 node_filefd_maximum，无需额外脚本。只需在 PromQL 层计算使用率：
- 在 Grafana 中验证指标：
100 * node_filefd_allocated / node_filefd_maximum，结果即为百分比 - 在
alert.rules.yml中添加规则组：groups:<br>- name: fd-alerts<br> rules:<br> - alert: HighFileDescriptorUsage<br> expr: 100 * node_filefd_allocated / node_filefd_maximum > 85<br> for: 5m<br> labels:<br> severity: warning<br> annotations:<br> summary: "High file descriptor usage on {{ $labels.instance }}"<br> description: "{{ $value | humanize }}% of file descriptors used" - 确保 Prometheus 的
prometheus.yml正确加载该规则文件，并执行curl -X POST http://localhost:9090/-/reload生效 - Alertmanager 中建议配置
group_by: ['alertname', 'instance']和repeat_interval: 1h，避免同一节点反复刷屏
补充建议：避免误报与定位根因
FD 使用率高不等于必须扩容，更可能是配置或代码问题。监控之外，还需配套机制：
- 对长期高于 60% 的节点，自动触发
lsof -P -n -i | head -50快照并存档，供事后分析 - 在 Zabbix 或 Prometheus 告警中加入跳转链接，例如 Grafana 的
http://grafana/...?var-instance={{ $labels.instance }}，一键下钻查看 FD 时间线与关联进程 - 若使用容器环境，注意 cgroup v2 下
node_filefd_*可能统计不准确，此时应改用container_fs_usage_bytes+container_fs_limit_bytes类似逻辑替代 - 不要只盯“使用率”，同步监控
node_procs_running和node_load1，高 FD 往往伴随进程堆积，二者结合更能判断是否已进入雪崩边缘
