Kong网关中OTEL插件与AWS Lambda插件的追踪问题分析

在Kong网关3.7版本中，当同时使用OpenTelemetry(OTEL)插件和AWS Lambda插件时，开发者可能会遇到分布式追踪链路断裂的问题。本文将深入分析这一问题的成因，并提供解决方案。

问题现象

在典型的Kong网关配置中，请求会依次经过多个插件处理：

1. OpenID Connect插件
2. Rate Limiting Advanced插件
3. OpenTelemetry插件
4. AWS Lambda插件

当使用这种配置时，虽然OTEL插件能够生成traceparent头部并将其传递给AWS Lambda函数，但在APM工具(如NewRelic)中观察到的追踪链路显示，Kong网关的span与Lambda函数的span是平行关系，而非预期的父子关系。

根本原因分析

这个问题源于Kong网关内部处理追踪的机制与AWS Lambda插件的特殊交互方式：

1. 追踪传播时机：OTEL插件默认在access阶段执行头部传播，此时会转发父span的ID。在标准配置下，这个父span是"balancer"阶段的span。

2. AWS Lambda插件的特殊性：当配置了aws-lambda插件后，由于没有实际的上游服务，balancer阶段的span不会被创建。这导致传播的父span实际上从未被生成或报告。

3. 追踪仪器配置：默认情况下，当启用"all"仪器时，Kong会包含balancer阶段的追踪，这在AWS Lambda场景下会导致问题。

解决方案

要解决这个问题，可以通过调整Kong的追踪仪器配置来实现：

1. 修改tracing_instrumentations配置：在Kong的配置文件中，移除"balancer"仪器。这样Kong将传播根span而非balancer span。

2. 配置示例：

tracing_instrumentations: "router,access,balancer"  # 移除balancer

3. 效果：调整后，OTEL插件将传播Kong网关的根span ID，从而建立正确的父子span关系，修复追踪链路的断裂问题。

最佳实践建议

1. 插件执行顺序：确保OTEL插件在access阶段先于aws-lambda插件执行，以保证头部正确注入。

2. Lambda函数配置：在Lambda函数中确保正确提取和使用w3c格式的追踪头部。

3. 监控验证：调整配置后，应在APM工具中验证span关系是否已正确建立。

4. 性能考量：在调整追踪仪器配置时，应考虑对系统性能的影响，特别是在高流量场景下。

通过理解Kong网关内部追踪机制的工作原理，并针对AWS Lambda插件的特殊性进行适当配置，开发者可以构建完整的分布式追踪链路，这对于微服务架构下的问题诊断和性能分析至关重要。