Prometheus 生产环境部署如何配置系统内核参数避免文件句柄不足

生产环境部署 Prometheus 时，避免文件句柄不足最直接有效的方案是同时调整系统全局限制和单用户进程限制，并将单进程打开文件数上限设置为 65535 或更高。

先说结论：修改系统内核参数只是基础，必须同时确认 Prometheus 启动进程的实际限制是否生效。

适合：高基数 metrics、大量 scrape 目标的生产集群
先准备：确认当前系统 fd 使用情况和 systemd 配置
验收：通过进程状态和 Prometheus 自身指标双重验证

命令速用版

如果你需要快速临时验证，可以在当前 shell 会话中执行以下命令，但重启后失效：

ulimit -n 65535

若要永久生效，需修改配置文件，以下是核心参数设置：

# /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

# /etc/sysctl.conf
fs.file-max = 2097152

为什么会这样

Prometheus 在运行时会为每个时间序列块（TSDB block）打开文件，同时每次 scrape 目标也会占用网络连接和文件描述符。Linux 默认的单进程文件打开数限制通常是 1024，在高负载下很容易耗尽。一旦耗尽，Prometheus 将无法写入数据或抓取新指标，表现为服务报错或监控中断。

分步处理

请按顺序执行以下步骤，确保配置层层生效：

1. 检查当前限制

执行以下命令查看当前 shell 的限制：

ulimit -n

查看系统级限制：

cat /proc/sys/fs/file-max

2. 修改用户限制

编辑 /etc/security/limits.conf，添加或修改以下行。注意，如果是通过 systemd 启动，此文件可能被忽略，需继续看第 3 步。

prometheus soft nofile 65535
prometheus hard nofile 65535

3. 修改 systemd 配置（关键）

大多数生产环境使用 systemd 管理 Prometheus。编辑服务文件（通常在 /etc/systemd/system/prometheus.service），在 [Service] 段下添加：

[Service]
LimitNOFILE=65535

4. 重载并重启

systemctl daemon-reload
systemctl restart prometheus

怎么验证是否生效

配置完成后，不要只看配置文件，必须检查运行中的进程：

1. 检查进程限制

找到 Prometheus 进程 PID，查看其 limits：

cat /proc/<PID>/limits | grep "Open files"

确认 Max open files 是否为 65535 或更高。

2. 检查 Prometheus 指标

访问 Prometheus Web UI 或调用 API，查询以下指标：

process_open_fds{job="prometheus"}

观察该值是否稳定，且远低于上限。同时检查是否有相关报错日志。

常见坑

systemd 覆盖限制：即使修改了 limits.conf，如果 systemd 服务文件中没有配置 LimitNOFILE，服务启动时仍可能使用默认值。
容器环境：如果在 Docker 或 Kubernetes 中运行，需要在容器启动参数中设置 `--ulimit` 或在 securityContext 中配置文件描述符限制。
软限制与硬限制：确保软限制（soft）和硬限制（hard）都足够大，否则进程可能无法提升到所需值。
系统级上限：如果 fs.file-max 设置过小，即使单进程限制大了，系统整体也无法分配更多句柄。