Expose child Spans from OpenTracing API to support tracing legacy code?
Nobody has claimed this yet.
- Dominant language
- Scala
- Stars
- 340
- Forks
- 76
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 13
Description
I have a use-case where we're using http4s to drive legacy code written in Java (which we're not ready to rewrite in the typelevel style).
I would like to be able to share a trace initiated from http4s via natchez (and code written in #5) to pass down a child OpenTracing Span to serve as the root span of my legacy Java calls.
I realize this breaks the nice abstraction / hiding provided by natchez, but there can be reasons for consenting adults to do so from time-to-time.
Are we open to adding extension methods to the entrypoint hooks (like in JaegerTracer) to construct and return a child span from the OpenTracing API, or would that ruin everything?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the entrypoint hooks and JaegerTracer implementation mentioned in the issue, along with the related work in #5. First establish whether exposing a child OpenTracing Span is an accepted direction; done would require a decided API and agreement on how legacy Java calls can use the shared trace.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, scala
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100