-
-
Notifications
You must be signed in to change notification settings - Fork 516
Description
Problem Statement
Couple of weeks ago I went on a chase to get Open Telemetry tracing library implemented for our team as we are gearing towards the open standard. I was quite happy with Sentry's support for the standard, but I did face some challenges. We are taking incremental steps towards it, and we are doing so with the care of not disrupting our existing usage of Sentry. One of the issues that we faced, right off the bat, was related to our existing sampling function implementation. When enabling OTel library with Sentry's SDK that implementation completely broke, because of 2 things:
- OTel spans are NOT translated into a Sentry transaction with high fidelity or any sort of "official" mapping between Ruby OTel instrumentation libraries and Sentry's expected transaction API - rendering the usual logic moot
- Sentry's SDK doesn't expose the OTel span in the sampling context so there is no easy way for clients to access this additional context to implement something that resembles the original Sentry's implementation
We ended up extending the SDK to expose the original OTel span so we could mimic the sampling logic that we were doing before, and respect the establish sampling paradigm. This helped ensure a smoother library transition.
Solution Brainstorm
I've put a PR up exposing that context in the same manner so it's readily available to other in the pursue of the open standard and their usage with Sentry
Metadata
Metadata
Assignees
Labels
Projects
Status