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

Otelmux span options #5251

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

mikk2168
Copy link

@mikk2168 mikk2168 commented Mar 7, 2024

This allows setting span start and end options to the otelmux configuration, so folks can (for example), enable stack traces to record errors.

Heavily inspired by #5250.
Since otelmux differs a bit from the gin implementation, I'm not sure if adapting the traceware to include SpanStartOptions and SpanEndOptions is the right way to go. If not, please let me know how it should be adapted.

Closes #5139.

@mikk2168 mikk2168 requested a review from a team March 7, 2024 08:51
Copy link

linux-foundation-easycla bot commented Mar 7, 2024

CLA Signed

The committers listed above are authorized under a signed CLA.

Copy link

codecov bot commented Mar 7, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.2%. Comparing base (46d20ec) to head (dcd8636).

❗ Current head dcd8636 differs from pull request most recent head b5ca882. Consider uploading reports for the commit b5ca882 to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##            main   #5251     +/-   ##
=======================================
- Coverage   61.3%   61.2%   -0.1%     
=======================================
  Files        186     185      -1     
  Lines      11253   11218     -35     
=======================================
- Hits        6907    6876     -31     
+ Misses      4147    4142      -5     
- Partials     199     200      +1     
Files Coverage Δ
...mentation/github.com/gorilla/mux/otelmux/config.go 100.0% <100.0%> (ø)
...trumentation/github.com/gorilla/mux/otelmux/mux.go 89.7% <100.0%> (+0.3%) ⬆️

... and 2 files with indirect coverage changes

@makeavish
Copy link

@dmathieu @hanyuancheung Any updates on merging this PR? Since it's approved for 2 weeks

@dmathieu
Copy link
Member

Only @open-telemetry/go-maintainers can merge PRs.

Copy link
Member

@pellared pellared left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if it is good to allow users to do that much.

The user can e.g. change the span kind using https://pkg.go.dev/go.opentelemetry.io/otel/trace#WithSpanKind or create attributes which are not aligned with the semantic conventions and they others may blame that the instrumentation library does not follow semantic conventions.

so folks can (for example), enable stack traces to record errors.

I am not sure if this is a good justification. This instrumentation library is not recording any errors.

I think we can discuss during the SIG meeting if we should make instrumentation libraries so configurable.

I am aware that there is a precedent that otelhttp and otelgrpc already have WithSpanOptions but maybe we should retrospect this.

@@ -86,6 +88,22 @@ func WithSpanNameFormatter(fn func(routeName string, r *http.Request) string) Op
})
}

// WithSpanStartOption applies options to all the HTTP span created by the
// instrumentation.
func WithSpanStartOption(o ...oteltrace.SpanStartOption) Option {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In otelhttp and otelgrpc this option is called WithSpanOptions. Can we name it in the same way for sake of consistency?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely. I'll leave the code as is for now, since this may not be relevant, if it is replaced with the option to add stacktraces instead - see this comment.
I'll return to this, if we decide to keep the function.

@mikk2168
Copy link
Author

mikk2168 commented Apr 4, 2024

@pellared Thank you for the review.

I am not sure if it is good to allow users to do that much.

The user can e.g. change the span kind using https://pkg.go.dev/go.opentelemetry.io/otel/trace#WithSpanKind or create attributes which are not aligned with the semantic conventions and they others may blame that the instrumentation library does not follow semantic conventions.

This sounds like a very valid point to me. In #5250 you suggest adding the option to capture stacktraces instead. Does that apply here as well?
If so, I'm happy to try and take a stab at it, when I have the time. Since I don't know this project too well, any pointer to where this option should be added will be much appreciated.

@pellared
Copy link
Member

pellared commented Apr 4, 2024

Does that apply here as well?

No as this instrumentation library does not handle panics and does not call https://pkg.go.dev/go.opentelemetry.io/otel/trace#Span.RecordError.

Anyway, I am really grateful for your positive attitude 👍

@mikk2168
Copy link
Author

mikk2168 commented Apr 4, 2024

No as this instrumentation library does not handle panics and does not call https://pkg.go.dev/go.opentelemetry.io/otel/trace#Span.RecordError.

Ah, I see. That makes sense.
Considering your initial comment, does it make sense to continue down this path, allowing users to add SpanStartOptions and SpanEndOptions? I agree with your concerns, so I see why this might not be the best solution.
If not, does it make sense to implement the error recording/stacktrace handling in a different way, or is it something that should be left out of the library (for now)?

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

Successfully merging this pull request may close these issues.

exception.stacktrace attribute isn't included in exception events
5 participants