Kong Gateway 中上游响应时间指标异常问题分析

问题背景

在使用Kong Gateway 3.6版本进行API性能测试时，开发团队发现Prometheus插件报告的kong_upstream_response_time指标与实际上游服务延迟存在显著差异。这一现象在之前的2.8版本中并未出现，当时指标数据与实际延迟基本吻合。

问题表现

测试数据显示，在Kong 3.6版本中：

• Prometheus插件报告的上游延迟比实际测量值高出约100ms甚至更多
• 而在2.8版本中，这一差异不超过10ms

排查过程

开发团队首先怀疑是自定义的中间件插件影响了指标报告。该插件的主要功能是拦截每个请求并向自定义授权服务发送HTTP POST请求。初步测试发现：

1. 移除该插件后，指标差异问题得到改善
2. 但理论上插件应该影响的是Kong整体延迟，而非上游延迟指标

进一步分析发现，插件实现中存在几个可能影响性能的关键点：

1. 使用了非优化的JSON解析库
2. 使用了不推荐的HTTP客户端实现
3. 缺少连接池管理

解决方案

团队对插件进行了以下优化：

1. 将JSON解析替换为更高效的cjson实现
2. 使用lua-resty-http替代原有HTTP客户端
3. 添加了连接池管理功能

优化后测试结果显示：

• 上游延迟指标与实际测量值基本吻合
• 但发现Kong代理延迟的P95值高于请求延迟的P95值

技术原理分析

深入分析Kong Gateway的指标采集机制：

1. kong_latency指标：记录从连接建立到负载均衡器确定上游服务的时间
2. request_latency指标：基于nginx的$request_time变量，记录从接收第一个字节到发送最后一个字节的完整请求处理时间
3. upstream_latency指标：记录从选择上游服务到接收响应第一个字节的时间

指标准确性可能受到以下因素影响：

1. Kong Gateway的负载情况
2. 底层nginx对socket数据的响应时间
3. 请求处理进程的调度延迟

最佳实践建议

基于此案例，建议Kong Gateway用户：

1. 自定义插件应优先使用Kong推荐的库实现（如lua-resty-http）
2. 性能测试时应监控多个维度的指标进行交叉验证
3. 关注插件对整体性能的影响，而不仅仅是功能实现
4. 重要指标出现异常时，应进行分层测试定位问题根源

总结

Kong Gateway的指标采集机制在正常情况下能够准确反映系统性能，但插件的实现方式可能对指标准确性产生意想不到的影响。开发团队应充分理解各指标的技术含义，并在插件开发中遵循性能最佳实践，确保监控数据的可靠性。