解读

1. 场景定位：国内互联网业务普遍采用微服务+容器化部署，长连接（HTTP/2、gRPC、数据库连接池、Redis 连接池）被大量复用。一旦连接池泄漏，进程 FD 数持续攀升，最终触发 “Too many open files”，导致新建连接失败、健康检查超时、容器被 K8s 杀死，引发级联故障。
2. 面试意图：考察候选人能否把“性能瓶颈”转化为“可观测+可自愈”的闭环，兼顾实时监控、告警精准度、重启代价、数据完整性，最终体现 SLA 保障能力。
3. 评分维度：指标选取合理性、监控实现成本、告警阈值可解释性、重启策略优雅性、灰度与回滚方案、生产合规（审计、变更单、发布窗口）。

知识点

1. FD 本质：Linux 下一切皆文件，socket、pipe、epollfd 均占 fd；/proc/{pid}/fd 可实时枚举；系统级限制 /etc/security/limits.conf、容器级限制 ulimit、K8s 的 maxOpenFiles。
2. 连接池泄漏根因：未正确 close、异常分支遗漏归还、连接存活探测失效、keep-alive 超时过长、下游挂起导致半开连接堆积。
3. 可观测三板斧：Metric（时序计数）、Logging（泄漏现场）、Tracing（连接生命周期）。
4. 重启代价： inflight 请求损失、缓存预热、注册中心抖动、上游重试风暴；需评估“冷启动时间”与“FD 上涨斜率”的平衡点。
5. 国内配套：Prometheus+Grafana 已成云厂商默认托管组件；阿里 SLS、腾讯 CLS 可秒级采集日志；K8s 原生支持 livenessProbe、startupProbe、preStop hook；变更合规需对接内部 OA 工单或 DevOps 平台（如蓝鲸、行云）。

答案

一、监控体系设计

1. 指标层
   1.1 进程级：每 10s 拉取 /proc/{pid}/fd 数量，记为 app_fd_used；同时采集 ulimit -n 得到 app_fd_limit；计算 fd_util=app_fd_used/app_fd_limit。
   1.2 连接池级：针对连接池组件（HikariCP、Lettuce、Netty 连接池）暴露的 MBean 或 Micrometer 指标：activeConnections、idleConnections、totalConnections、timeoutCount。
   1.3 系统级：node_fd_allocated、node_sockstat_tcp_inuse，防止节点级别耗尽。
2. 日志层
   2.1 在连接池 borrow/return 处增加 TraceId，打印连接对象哈希、线程名、堆栈深度（可采样 1%）。
   2.2 当 fd_util>0.8 时，自动 dump /proc/{pid}/fd 到 OSS，供后续离线分析。
3. 追踪层
   3.1 采用 OpenTelemetry 的 JDBC/Netty instrumentation，记录连接从 create→borrow→return→close 的耗时与状态，关联到一次业务 Trace。

二、告警阈值

1. 警告：fd_util>70% 持续 5min，通知钉钉群，不重启。
2. 严重：fd_util>85% 且 连接池 timeoutCount 环比增加 50%，触发“自愈预案”。
3. 紧急：fd_util>95% 或 1min 内上涨 10%，立即执行优雅重启。

三、自动重启机制

1. 重启决策器：Prometheus Alertmanager Webhook → 内部“自愈平台” → 调用 K8s API。
2. 优雅流程
   2.1 preStop：执行 curl -X POST localhost:8080/gracefulShutdown，等待 inflight 请求处理完（最大 30s）。
   2.2 注册中心反注册：服务主动从 Nacos/Etcd 下线，防止新流量进入。
   2.3 容器退出码固定为 42，方便 K8s restartPolicy 识别“计划内重启”。
3. 灰度与限流
   3.1 按可用区分批重启，单批不超过 20% Pod。
   3.2 重启窗口避开秒杀、大促、金融日切。
4. 兜底
   4.1 若重启后 5min 内 fd_util 再次>80%，则标记镜像版本“疑似泄漏”，自动回滚上一版本并创建 JIRA 缺陷单。

四、泄漏定位与长期治理

1. 压测复现：使用 ChaosBlade 模拟下游 200ms 延迟+5% 丢包，观察连接池是否堆积。
2. 代码扫描：引入 Sonar + 自研规则，检测 ResultSet/Statement/Channel 未关闭分支。
3. 单元测试：为每个 DAO 方法增加 @LeakTest，在测试后断言连接池 idleConnections=初始值。

五、合规与审计

1. 自愈平台调用 K8s API 需携带 IAM 角色，操作写入审计日志（符合等保 2.0）。
2. 重启记录需关联变更单号，方便后续溯源。

拓展思考

1. 如果业务是金融支付场景，重启会中断事务，如何做到“零损失”？
   答案方向：引入 Quiesce 模式，先冻结新连接，再等待已开启的分布式事务全部完成（依赖 Seata 的事务状态表），最后重启；同时备机通过数据库主备切换保证连续性。
2. 当 FD 上涨并非连接池泄漏，而是下游回调接口把大文件当临时缓存打开，如何区分？
   答案方向：在 /proc/{pid}/fd 枚举时通过 readlink 判断 fd 类型，socket 与 regular file 分别计数；同时监控 inode 号增长曲线，文件型 fd 呈阶梯式上升，连接型 fd 呈平滑上升。
3. 国内部分私有云未开放 K8s API，如何落地自动重启？
   答案方向：采用 Ansible 脚本通过跳板机下发“systemctl restart app”命令；告警触发后先锁定目标主机，再执行滚动重启；通过 CMDB 接口回写操作记录，满足企业内部安全规范。