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

otelhttp: allow setting the start timestamp using go Context #5318

Open
dashpole opened this issue Mar 24, 2024 · 0 comments
Open

otelhttp: allow setting the start timestamp using go Context #5318

dashpole opened this issue Mar 24, 2024 · 0 comments
Labels
area: instrumentation Related to an instrumentation package enhancement New feature or request instrumentation: otelhttp

Comments

@dashpole
Copy link
Contributor

Problem Statement

Follow-up to open-telemetry/opentelemetry-go#4993

Context: kubernetes/kubernetes#103186

I would like otelhttp to allow me to pass the start time using the go context.Context. This lets me move my instrumentation after my auth filter in my server handler chain while preserving the start time of the request.

Proposed Solution

Similar to the Labeler, allow adding a start timestamp to a context in otelhttp. This timestamp will be used by both otelhttp metric and trace instrumentation as the start timestamp.

Alternative: Context-based StartSpanOptions

In the trace API package, add a SpanStartContext which is modeled after the current Labeler, but stores a list of SpanStartOptions, and has Add and Get options for the StartSpanOptions.

In the trace SDK, in Start, it would fetch options from the SpanStartContext, and append them to the explicitly passed options.

This would allow users to override the StartSpanOptions for any instrumentation library, including adding attributes or links, or setting the span start time without any modifications to the instrumentation library itself.

However, this would not work very well for metrics. First, there is no "start timestamp" option for metrics (nor should there be). The start timestamp is an artifact of the otelhttp instrumentation library, not of the metrics API. Second, while tracing instrumentation generally only creates one span, metric instrumentation generally makes multiple Record calls. The rule of "these options apply to the span created" doesn't work well for metrics, because we probably want them to apply to all metrics in the instrumentation library.

@dashpole dashpole added enhancement New feature or request area: instrumentation Related to an instrumentation package instrumentation: otelhttp labels Mar 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: instrumentation Related to an instrumentation package enhancement New feature or request instrumentation: otelhttp
Projects
None yet
Development

No branches or pull requests

1 participant