Add distributed tracing support

[dgzlopes]

This feature is inspired by the existing xk6-distributed-tracing extension.

The idea is to add distributed tracing support to k6.

That means, that if your system under test is instrumented, k6 will be able to start the trace itself and propagate it downwards.

For the first version of this feature, would be interesting to have:

• Support for HTTP (we can take a look at gRPC in the future).
• Support for multiple propagators (w3c, b3, jaeger, ot).
• Support to enable tracing/a propagator for the whole test run, or on a specific request (useful in case someone wants to use different propagators on different requests).
• The ability to inject "tracing" information into the response object that k6 exposes to the user (example: traceID).

What this feature doesn't cover:

• Exporting internal spans generated by k6 to a wide array of backends (Tempo, Zipkin, Jaeger).
  • This is something supported by the extension right now, but it's out of scope for this first version. We might want to add this in future iterations of this feature.

Also, we should inject some information about k6 and the test on the traces that we start. That will be handy in case someone wants to apply different retentions or sampling strategies to the traces started by a k6 instance.

[dgzlopes]

To implement this feature, the OpenTelemetry Go instrumentation is one of the best options.

The main benefit versus other instrumentation libraries, is that it supports multiple propagators out of the box! For reference, I created a small repo showcasing all of them: https://github.com/dgzlopes/kicktrace

Anyway, this needs some research :)

[adeniyistephen]

@dgzlopes Hello, this is a very nice feature for k6. I would be so honored to work on this, I read and studied the reference code you wrote it's awesome.
please kindly provide pointers so we could start. 👍

[dgzlopes]

Hi @adeniyistephen! Thanks for your interest in the project and this feature. And sorry for my late response (these days, my notification feed is a mess!)

Sadly, I think that we are not ready to accept contributions in this area.

Even if the feature looks straightforward and well-defined, sadly, it's not! It will require further discussions on the core team and dedicated time from a maintainer to design/implement the initial iteration.

Having said that, we have some issues tagged as good first issues that you might find interesting! In case you want to take a stab at one of them.

Another good way to get into k6 is by developing k6 extensions. These can be as big/complex as you want while adding a lot of functionality to k6 and its ecosystem. For example, the community has developed extensions to load test/interact with Kafka, Redis, Docker registries, Kubernetes clusters, relational databases, and tons of things.

I've some extension ideas for load testing distributed tracing backends (Jaeger, Tempo, Zipkin). Feel free to reach me on Slack or email (dgzlopes at grafana dot com) if that sounds interesting! Or you want to chat a bit :)

[adeniyistephen]

Interesting 👍

[kempsterc]

@dgzlopes
I'm looking for away to be able to use datadog ci.
Would this help support dd-trace ?

[imiric]

@oleiade Can this issue be closed now that #2853, #2854 and #2855 have been merged?

For everyone else: this will be released in the upcoming v0.43.0. 🚀