--web.max-connections 用于限制 Prometheus Web 服务（9090 端口）最大并发 HTTP 连接数，涵盖 Grafana 查询、大屏轮询、爬虫访问及 UI 操作，超限连接被直接拒绝；推荐初始设为 60~80，并需配合 --web.read-timeout、--query.max-concurrency 等参数协同防护。
直接限制 Web 层连接数是应对高并发爬虫或非标大屏频繁轮询最快速有效的手段之一。Prometheus 默认不限制 HTTP 连接总数，当大量客户端（比如每 5 秒刷新一次的 20 个大屏、或未设 User-Agent 的自动化脚本）持续建连，可能迅速耗尽文件句柄、拖慢查询响应，甚至触发 OOM。
明确 --web.max-connections 的作用
该参数控制 Prometheus 内置 Web 服务（即 :9090 端口）可同时维持的最大 HTTP 连接数，包括：
- Grafana 的实时查询请求
- 前端大屏通过 API 轮询
/api/v1/query或/api/v1/series - 爬虫、脚本直连指标接口（如抓取
/metrics） - 人工在 Web UI 上执行复杂 PromQL 查询
它不控制抓取目标（scrape）连接，只管“被访问”这一侧。超过阈值的新连接会被内核拒绝（TCP RST），不会排队等待。
合理设置值：兼顾防御与可用性
不能简单设为“10”防爆，也不能留空放任。推荐按实际负载估算：
- 先统计典型并发来源：比如 12 个大屏 × 每屏平均 2 个活跃查询 = 约 24 连接；加上 Grafana（约 5~10）、运维调试（3~5），基础水位约 40
- 预留 30%~50% 余量应对峰值，建议初始值设为 60~80
- 若已观察到
netstat -an | grep :9090 | wc -l常超 100，且process_open_fds接近系统 limit，则必须收紧
启动时加入：
--web.max-connections=70
配合其他参数形成防护闭环
单靠连接数限制效果有限，需组合使用：
-
--web.read-timeout=30s：防止慢查询长期占住连接，尤其对未加
limit的聚合查询 - --query.max-concurrency=15：限制同一时刻最多执行几个 PromQL，避免 CPU 被打满
- --query.timeout=2m：强制终止超时查询，释放关联连接和内存
- 前端加反查机制：大屏应使用
time()+ 缓存策略，避免无差别轮询；Grafana 启用 query caching
识别并隔离异常流量源
连接数限制是“闸门”，但不是“根治”。建议同步做：
- 查看
prometheus_http_request_duration_seconds_count{code=~"2..", handler="/api/v1/query"}的突增来源 IP（需开启 access log 或用 Nginx 反代） - 对高频低价值请求（如反复查
up{job="xxx"}）加 Nginx 层限流：limit_req zone=api burst=5 nodelay - 区分用途：给大屏分配专用查询账号，配合
max_user_connections（若前置 MySQL 存储元数据）或反向代理鉴权
