Elastic APM 7.17.1 Intake API 非Python/PHP Agent接入超时

问题背景 #

• 部署的Elastic APM Server版本为7.17.1，当前仅接入2个Django应用，服务运行内存占用约140MB，处于正常水位
• 接入新APM Agent时出现超时问题：Python技术栈（Flask、Django）、PHP应用可正常完成注册；Node.js、Java、Go语言Agent接入失败，触发报错时APM服务端无关联日志输出

报错详情 #

Node.js 端报错 #

{"log.level":"error","@timestamp":"2022-07-07T23:15:34.033Z","log":{"logger":"elastic-apm-node"},"ecs":{"version":"1.6.0"},"message":"APM Server transport error: intake response timeout: APM server did not respond within 10s of gzip stream finish"}

Java 端报错 #

2022-07-07 14:31:36,503 [elastic-apm-server-reporter] ERROR co.elastic.apm.agent.report.IntakeV2ReportingEventHandler - Error sending data to APM server: Read timed out, response code is -1

Go 端表现 #

无明确错误日志，接入直接失败

排查解决步骤 #

• 优先核对Agent与Server版本匹配性
  7.17版本APM Server与8.x版本Agent存在intake接口协议不兼容问题：Java/Go/Node.js Agent如果默认安装最新8.x版本，启动时上报的元数据格式不符合7.x Server的解析规则，会导致Server直接挂起连接不返回响应，客户端触发读超时、服务端无错误日志。Python/PHP应用能正常接入，大概率是这两类服务安装的APM Agent为7.17.x同大版本。直接将所有接入失败的Agent版本降到和Server一致的7.17.x即可解决。
• 检查APM Server intake接口相关配置
  打开APM Server配置文件apm-server.yml，核对以下参数：
  • apm-server.read_timeout、apm-server.write_timeout：默认值为30s，如果被手动修改为10s及以下，Java/Go启动时上报的较大元数据包会触发超时，将两个参数调整为30s以上即可
  • apm-server.max_event_size：默认值为300KB，如果被调小到100KB以下，Java/Go启动时的上报包超过阈值会被Server直接丢弃，不返回响应，将该参数恢复为默认300KB即可
• 检查前置代理/防火墙拦截规则
  如果APM Server前端部署了Nginx、负载均衡、WAF类设备，核对以下配置：
  • 代理的proxy_read_timeout、proxy_send_timeout是否小于10s
  • 代理/WAF的请求体大小限制是否小于200KB
  • 是否开启了gzip请求体解压检测，导致大gzip包被拦截
    这类拦截不会把请求转发到后端APM Server，因此服务端查不到相关日志。可在部署失败Agent的机器上直连APM Server 8200端口发测试请求验证，直连正常则调整前置设备对应参数即可。测试命令参考：

  curl -v -X POST -H "Content-Type: application/x-ndjson" --data-binary @test_payload.ndjson http://<apm-server-ip>:8200/intake/v2/events
  

• 临时开启debug日志定位根因
  如果以上步骤都未解决问题，在apm-server.yml中添加配置logging.level: debug，重启APM Server后重新触发Agent接入，debug日志会打印所有被拦截、丢弃的请求的具体原因，可直接根据日志提示修复。

内容的提问来源于stack exchange，提问作者Brandon Kauffman