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
- [x] Create an extension repository
- [x] Apply all standards (CI, linter, etc)
- [ ] https://github.com/grafana/xk6-output-opentelemetry/pull/2
- [ ] https://github.com/grafana/xk6-output-opentelemetry/pull/3
- [ ] https://github.com/grafana/xk6-output-opentelemetry/pull/4
- [x] Histogram support, consider make histogram aggregation configuarble
- [ ] https://github.com/grafana/xk6-output-opentelemetry/pull/5
- [ ] https://github.com/grafana/xk6-output-opentelemetry/issues/7
- [ ] https://github.com/grafana/xk6-output-opentelemetry/issues/6
- [ ] https://github.com/grafana/xk6-output-opentelemetry/pull/15

TBD

Why?

OpenTelemetry output is an essential one.

[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 :+1: I've opened intermediate (there will be more configuration-related PRs in the future) which removes controversial term https://github.com/grafana/xk6-output-opentelemetry/pull/5