OpenTelemetry metrics output

[pragmaticivan]

Feature Description

Add support for exporting metrics via OTLP in addition to Statsd

Suggested Solution (optional)

https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp

GO SDK

Already existing or connected issues / PRs (optional)

No response

[na--]

Thanks for opening the issue and sorry for the slow response! I haven't followed OpenTelemetry closely, so I am very out of touch where it's at in terms of features, stabilization and adoption. It's something we'll probably want to have support for in the k6 core in the future, but I can't give an estimate on when exactly that will be.

We have slowly been refactoring and improving the metrics internals in k6 over the last several releases to make such efforts easier and cleaner (#2071, #2330, #2426, #2463, #2433, #2442 among others), and we'll continue to do so for a while with things like #1831, #1889, #572, #2430, etc. The near-term goal is to natively support OpenMetrics / Prometheus metrics (#858) in the k6 core, though probably just through remote write initially (#1761). OTLP will probably be on the agenda relatively soon after that, though I can't make any promises yet...

The good news is that you don't have to wait for us to support it in the core before you can use it with k6! k6 supports output extensions through xk6 and you can write one for OTLP metrics yourself. It may be a bit rough or require some hacks before we've finished with all of the planned refactoring tasks I linked to above, but something should still be possible. For examples, see https://github.com/grafana/xk6-output-prometheus-remote or other output extensions in https://k6.io/docs/extensions/

[gurudatta-carbon]

any update on this? most of the grafana offered products support opentelemetry, it would be nice if k6 can support opentelemetry integration for metrics, traces.

[codebien]

We had a quick internal sync around this issue. We intend to wrap the OTel Go SDK in a metric output.
The path should be as usual to have an output extension (e.g. xk6-output-open-telemetry) then move it to the core. Potentially, directly to the core as an experimental output if we are confident enough.

The output should provide the way to configure the aggregation temporality via an option. Ideally, both, delta and cumulative will be supported but if some order of precedence is required then cumulative will be the first. As it is the natural way for supporting Prometheus.