Open olegbespalov opened 1 month ago
Upon further review, I've reconsidered my initial assessment which was overly focused on OpenTelemetry compatibility. Since the extension currently follows K6's standard extension patterns, it likely doesn't require modifications to maintain compatibility with OpenTelemetry environment variables. This approach aligns with how other K6 extensions handle similar scenarios.
What could be improved instead is the UX that could come with warning's to the User when a miss match happens like pointed out in https://github.com/grafana/k6/issues/4070:
K6_OTEL_EXPORTER_TYPE=http \
K6_OTEL_GRPC_EXPORTER_ENDPOINT=prometheus:9090 \
K6_OTEL_HTTP_EXPORTER_URL_PATH=/api/v1/otlp/v1/metrics \
K6_OTEL_METRIC_PREFIX=agilob \
./k6 run --out experimental-opentelemetry main.js
The system should warn users when they've provided a GRPC exporter endpoint (K6_OTEL_GRPC_EXPORTER_ENDPOINT
) while the exporter type is set to HTTP (K6_OTEL_EXPORTER_TYPE=http
). This would help users identify configuration conflicts earlier and prevent confusion about which settings are actually being applied. This could be communicated in a fashion like so:
⚠️ Warning: Configuration mismatch detected
You've set HTTP exporter type (K6_OTEL_EXPORTER_TYPE=http) but provided a GRPC endpoint (K6_OTEL_GRPC_EXPORTER_ENDPOINT=prometheus:9090).
- To use GRPC, set K6_OTEL_EXPORTER_TYPE=grpc
What?
As pointed out in https://github.com/grafana/xk6-output-opentelemetry/pull/24, how we currently define our default configuration makes it harder to use the output and confuses users familiar with OTEL SDK configuration.
So, we must adjust our configuration and consider OTEL environment variables if they are defined. Still
K6_OTEL_
will have priority.Why?
Align with OTEL.