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

问题背景

在使用Kong网关3.7版本时，开发人员遇到了一个关于分布式追踪的特殊场景。当同时使用OpenTelemetry(OTEL)插件和AWS Lambda插件时，追踪链出现了断裂现象。具体表现为：虽然Kong和Lambda的追踪数据都出现在同一个追踪会话中，但它们呈现为平行关系而非预期的父子关系。

典型配置场景

典型的配置流程包含四个插件按顺序执行：

1. OpenID Connect插件用于身份验证
2. Rate Limiting Advanced插件用于限流
3. OpenTelemetry插件用于分布式追踪
4. AWS Lambda插件用于调用后端服务

其中AWS Lambda插件配置为使用Event调用类型，并启用了aws_gateway_compatible兼容模式。

问题现象分析

最初OTEL插件在AWS Lambda插件之后执行，导致w3c标准的追踪头(traceparent和tracestate)未能正确注入请求头。调整执行顺序后，虽然traceparent头被成功注入，但追踪链仍然不完整。

深入分析发现，问题根源在于OpenTelemetry的默认传播机制。OTEL在access阶段执行头传播时，会转发父span的ID。在标准配置下，这个父span是balancer阶段的span。然而当使用AWS Lambda插件时，由于没有配置实际的上游服务，balancer span不会被创建，导致传播的父span ID实际上不存在。

解决方案

解决此问题的关键在于调整Kong的追踪instrumentation配置。通过从tracing_instrumentations配置中移除balancer选项，可以强制Kong传播根span而非balancer span。这样就能确保在AWS Lambda场景下，追踪链能够正确建立。

最佳实践建议

1. 对于使用AWS Lambda插件的场景，建议检查并调整tracing_instrumentations配置
2. 确保OTEL插件在access阶段优先于AWS Lambda插件执行
3. 在Lambda函数中实现正确的追踪头提取和上下文传播
4. 监控工具中验证追踪链的完整性

总结

这个案例展示了在复杂集成场景下分布式追踪可能遇到的挑战。理解Kong插件执行顺序和OTEL传播机制对于构建完整的可观测性体系至关重要。通过适当的配置调整，可以确保即使在无上游服务的Lambda调用场景下，也能维护完整的追踪链。