Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make extention configuration OTEL familiar #25

Open
olegbespalov opened this issue Oct 11, 2024 · 1 comment
Open

Make extention configuration OTEL familiar #25

olegbespalov opened this issue Oct 11, 2024 · 1 comment

Comments

@olegbespalov
Copy link
Collaborator

What?

As pointed out in #24, how we currently define our default configuration makes it harder to use the output and confuses users familiar with OTEL SDK configuration.

The current approach was likely adopted to provide k6-specific configurability. However, it creates a divergence from standard OTEL practices, potentially confusing users familiar with OTEL SDK configuration.
Moving forward, we should consider:

  • Gradually aligning our custom variables with standard OTEL naming conventions.
  • Implementing a fallback mechanism where standard OTEL variables are checked if custom ones are not set.
  • Providing clear documentation on which standard OTEL variables are supported and which are superseded by custom configurations.

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.

@olegbespalov olegbespalov changed the title Make extention OTEL SDK friendly Make extention configuration OTEL familiar Oct 11, 2024
@TimotejKovacka
Copy link
Contributor

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 grafana/k6#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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants