Proposal to Extend Kong Tracing API for Tracer Plugin Integration

[dmehala]

Hello Kong Team 👋 ,

I am a developer at Datadog, working on a Kong plugin integrating our tracing solution with Kong. I wanted to propose an enhancement to Kong's recently introduced tracing API that could greatly benefit both Kong users and tracer providers like us.

Proposal

Currently, Kong's tracing API provides a solid foundation for tracing within the platform. I believe it can be extended to act as a more generic interface that allows third-party tracer implementations to seamlessly integrate with Kong.

This would involve defining a standard interface within the tracing API that plugins can implement. With this approach, you would continue to handle all the instrumentation, while third-party plugins like ours would provide the specific tracer logic.

Shared Interests and Advantages

1. Enhanced User Experience: By standardizing the tracing API, Kong can provide its users with a more streamlined and consistent tracing experience across different tracers. Users won’t need to worry about inconsistent implementations or varying levels of support across tracing solutions (exemple of a confused customer: [Bug]: It limits the span to only 2 unlike OTEL DataDog/kong-plugin-ddtrace#66).
2. Broaden Kong’s Ecosystem: A tracing interface would lower the barrier for other tracing solutions to integrate with Kong. This would expand Kong’s ecosystem, making it even more attractive to users who might have specific preferences or requirements for tracing solutions.
3. Leverage Existing Instrumentation: As Datadog, we’re excited about the possibility of leveraging Kong’s existing, well-maintained instrumentation rather than re-implementing similar logic in our plugin. This approach would reduce duplication of effort, ensuring that the instrumentation remains optimized and up-to-date within Kong itself.
4. Strengthen Collaboration: By collaborating on this interface, Kong and tracing providers like Datadog can work together to ensure that the interface is robust and meets the needs of all parties involved.
5. Performance and Maintenance: Centralizing instrumentation logic within Kong means that performance optimizations can be handled more effectively. This also reduces the maintenance burden on both the Kong team and plugin developers, as the core tracing logic would be unified and maintained by the Kong community.

Call to Action

We believe this enhancement would be a win-win for both the Kong community and third-party tracer providers. I would be thrilled to discuss this proposal further and contribute to the design and implementation of the tracing interface.

Looking forward to your thoughts and any feedback you might have!

[samugi]

Hi @dmehala , thank you for opening this discussion and apologies for responding with some delay.

I'm interested in your proposal and would like to get a better understanding of the gaps you encountered in the existing tracing PDK.
As a quick reference, the tracing pdk today provides plugin the ability to create new spans.
At the moment, spans live within the ngx.ctx.KONG_SPANS table; reporting of such spans and header propagation are done by the OTel plugin, so a custom implementation would have to replicate those behaviors.
Enabling tracing_instrumentations and tuning tracing_sampling_rate appropriately would result in the internal spans to be collected and populated in the above mentioned table. At the moment the only interface in the PDK that provides access to such spans is the process_span processor, (the ngx.ctx.KONG_SPANS table is still accessible from any plugin, but I see how the interface for accessing such spans has room for improvement on this aspect).

Feel free to let me know in case I missed anything and thanks again for posting.