双API部署下API Gateway偶发请求超时问题求助

一、MongoDB连接池与连接管理排查 #

• 检查两个API的MongoDB连接池配置，确认maxPoolSize参数设置，计算两个API的总连接池上限是否超过MongoDB实例的maxConnections（可通过db.serverStatus().connections查询当前连接数及上限）。若总连接数接近上限，会导致新请求无法获取连接而超时，而复用已有连接的请求则能正常执行。
• 排查Serverless Lambda的连接泄漏问题：Lambda容器复用可能导致旧连接因长时间闲置被MongoDB主动断开，但代码未实现连接失效重连逻辑。重新部署后，新容器初始化的连接都是有效状态，因此一段时间内无超时；后续容器复用增多，失效连接积累，开始出现超时。
• 检查Express应用的连接池复用逻辑：确认EB上的Express应用是否正确维护连接池，是否存在未释放的连接导致池资源耗尽。

二、网络与VPC配置排查 #

• 验证两个服务的网络路径：EB实例和Serverless Lambda是否在同一VPC？MongoDB的安全组是否允许这两个来源的连接？排查是否存在NAT网关端口耗尽（Lambda通过NAT访问MongoDB时，端口资源有限，高并发下可能无法建立新连接）或子网IP耗尽的情况。
• 检查DNS解析：确认两个API是否能正常解析MongoDB的域名，可在代码中添加DNS解析日志，排查超时请求是否卡在DNS解析阶段。

三、API Gateway与服务运行环境排查 #

• 检查API Gateway的超时配置：两个API的集成超时时间是否合理（API Gateway默认最大超时29秒），查看CloudWatch日志中超时请求的阶段标识，确认是在API Gateway层面超时还是后端服务超时。
• 排查Lambda冷启动与容器复用影响：虽然重新部署后初期正常，但可监控Lambda的初始化时间与执行时间，确认超时请求是否集中在冷启动场景；同时验证复用容器中的连接有效性，测试强制冷启动（如更新Lambda代码）后的请求是否正常。
• 检查EB实例的资源状态：查看EB实例的CPU、内存使用率，确认是否存在资源耗尽导致请求阻塞的情况，但结合“第一个请求超时第二个正常”的现象，此可能性较低。

四、并发与隔离测试 #

• 临时隔离单个API的流量：暂停其中一个API的生产流量，仅保留另一个运行，观察超时是否消失。若消失，说明两个API的连接池总负载超过MongoDB承受上限；若仍存在超时，则排查单个服务的内部问题。
• 模拟并发场景：使用压测工具（如ab、artillery）模拟高并发请求，复现超时问题，同时实时监控MongoDB的连接数、CPU负载及API的日志，定位触发超时的临界并发量。

五、日志与监控强化 #

• 增加代码级日志：在两个API的MongoDB连接、查询逻辑中添加详细日志，记录连接开始/结束时间、查询开始/结束时间、错误信息（如连接超时、查询超时），明确超时发生的具体阶段。
• 开启MongoDB日志：启用MongoDB的连接日志与慢查询日志，排查是否存在连接拒绝、慢查询或连接中断的记录。
• 利用CloudWatch监控：配置API的请求数、错误率、Lambda执行时间、EB实例性能指标的告警，实时捕捉超时发生时的系统状态。

内容的提问来源于stack exchange，提问作者dc-mpo