Making experimental opentelemetry output

[olegbespalov]

What?

This umbrella task aims to collect all requirements (sub-tasks) needed to make the open telemetry output an experimental output in k6.

Tasks

Beta Give feedback

1. Create an extension repository
2. Apply all standards (CI, linter, etc)
3. Base docker-compose #2
   +0
   
4. Minimal working version #3
   +0
   
5. Implement rate as counter #4
   +0
   
6. Histogram support, consider make histogram aggregation configuarble
7. Align configuration with OpenTelemetry SDK, HTTP exporter #5
   +0
   
8. Introduce more configuration options #7
   1 of 3
   +0
   
9. Fix demo dashboards #6
   +0
10. Passing metrics unit when available #15
    +0
    

TBD

Why?

OpenTelemetry output is an essential one.

Closes grafana/k6#2557

[cwegener]

This is really exciting progress.

May I suggest that the extension should follow the following OpenTelemetry standards:

• Use standardized OpenTelemetry terms and terminology as documented here: https://opentelemetry.io/docs/concepts/glossary/
• Use the configuration provided by the Default SDK from the OTel spec: https://opentelemetry.io/docs/specs/otel/configuration/sdk-configuration/

The terminology is important, because as the extension stands right now, it is a bit confusing to read through the structs and functions in the config.go file because the use incorrect terminology.

[olegbespalov]

Hi @cwegener !

Sure, it's a good suggestion, and we'll try to consider it while implementing the Improve output configuration possibility.

Just ensure that I'm getting this statement right:

because as the extension stands right now, it is a bit confusing to read through the structs and functions in the config.go file because the use incorrect terminology.

Do you have concrete renaming examples? I am asking to ensure what the expectations are since some configurations will be coming from K6 (like flushing right now).

[cwegener]

The main concern is the term receiver, which is wrong. https://opentelemetry.io/docs/concepts/glossary/#receiver

I know that the terminology between k6 and OTEL needs to be reconciled. I.e. k6 has the seemingly informal input and output extension terms. So, this extension whilst being a k6 "output" extension makes use of the OpenTelemetry "exporter" components. https://opentelemetry.io/docs/concepts/glossary/#exporter
So, I think it's fine to use the term OTEL Exporter as part of this k6 output extension. Especially considering that the term "export" / "exporting" is already established in many other k6 output plugins.

[olegbespalov]

@cwegener yeah, totally makes sense 👍 I've opened intermediate (there will be more configuration-related PRs in the future) which removes controversial term #5