Otelmux span options

[mikk2168]

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.

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: hanyuancheung / name: Chester Cheung (b5ca882784f457b33cf356c07a6c17e41d3c3d38, dcd8636121f4d4700551a699b4d564afaa102d44)
• :white_check_mark: login: mikk2168 / name: Mikkel Knudsen (7ad98bf98b3ffe1845a6852c28fd9c879b765880, fa2ff9621789803b23d57d6f20e9067e4fb14a6b)

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

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

:exclamation: 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

@@           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%)	:arrow_up:

... and 2 files with indirect coverage changes

[makeavish]

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

[dmathieu]

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

[mikk2168]

@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]

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]

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)?