Performance Monitoring Powered by OpenTelemetry

[danielkhan]

Hello everyone! 

We are excited to share that we are working on a new blend of Performance (tracing) SDKs that combine the ease of use of Sentry with the broad technology support of OpenTelemetry.

Now that we've just finished our MVP for Node.js and Python, we'd like your feedback.
Below are some FAQs and answers that should help you understand what this is all about and how to get started.

What do I get?

Our goal was to combine the ease of use of Sentry with the tech coverage of OpenTelemetry. 

OpenTelemetry offers built-in support for many backend platforms, protocols, and libraries, providing a two to three times wider coverage than you'd get with our current tracing SDKs. Additionally, we will expose the OpenTelemetry API for easy auto-instrumentation, allowing you to install any OpenTelemetry-compatible third-party instrumentation plugin.

How is the SDK different from using vanilla OpenTelemetry?

We released our OpenTelemetry span processor in early 2023, and users with existing OpenTelemetry setups can start sending traces to Sentry by adding three lines of code.

OpenTelemetry is a highly modular set of libraries built for extensibility and flexibility and is often not trivial to set up. 
Here are all the dependencies that you need to combine and keep track of when instrumenting your application with OpenTelemetry and Jaeger.

Until now, you had to choose between the OpenTelemetry SDK or Sentry’s - this is no longer necessary as our new SDK bundles OpenTelemetry into a curated distribution -> You don't have to know OpenTelemetry to use it.

Does this also affect Errors and Profiling?

Sentry’s Error monitoring and Profiling capabilities are better than what OpenTelemetry provides today. Consequently, we use our existing instrumentation to collect these signals. All that happens transparently for our users.

What about Browser and Mobile monitoring?

Sentry’s browser and mobile monitoring capabilities are better. While we are considering simplifying the manual instrumentation API to make it similar to OTel, we don't intend to change these SDKs.

Can I mix old and new SDKs throughout my services?

Yes, the SDKs can be mixed (e.g., frontend-backend), and traces collected by them will be connected.

I used the old Sentry SDK for manual instrumentation. Will this still work?

We are still trying to figure that out. There will likely be caveats.

What prompted Sentry's shift to OpenTelemetry for Tracing?

At the time of Sentry's initial performance product development, OpenTelemetry was in the nascent stages of its lifecycle and still needed to be optimized for our requirements. Nevertheless, we maintained similarities in our data models and paradigms with OpenTelemetry. Since then, OpenTelemetry has significantly matured, passed the test of time, and has been generally available (GA) for over a year. It now boasts an extensive ecosystem of integrations spanning multiple technologies, including databases, queues, and protocols. When creating our SDK, we aimed to leverage OpenTelemetry's excellent technology coverage for our customers while staying true to our key paradigms: Easy usage, efficient data storage, and developer-centered performance insights.

How can I try it out?

So far, we offer experimental support for Node.js - please follow the instructions on the readme to try it out. Experimental support for Python was released in version 1.30.0 of the Python SDK - see the instructions in the release notes to check it out.

We also created a sample project comprising multiple connected Node.js services and a frontend.

While there are still some rough edges, traces should be complete and connected, and the data collected should be complete.

Where is the work happening? Where can I learn more?

You find all requirements and a trail of workstreams and issues in this meta issue.

Your feedback is appreciated

Please take the new SDKs for a swing and let us know
• if it was easy to set up
• if you encounter any errors or inconsistencies compared to the current SDKs
• if it's awesome and gives you better insights than you had before :)

[Chengshihao1018]

is there any requirement for sentry version?

[smeubank]

Your sentry version has to support the /envelope end point, but that is it, and that isn't OTel specific at all either. It is just the way we have moved to send all events to Sentry from all SDKs for some years now.

[The3fon]

Hi, i have problem with enable this feature. No detailed information on operations.

{
service.name: unknown_service,
telemetry.sdk.language: python,
telemetry.sdk.name: opentelemetry,
telemetry.sdk.version: 1.20.0
}

Name	CPython
Version	3.11.4(3.11.4 (main, Sep 28 2023, 16:43:59) [GCC 8.3.1 20191121 (Red Hat 8.3.1-6)])

[smeubank]

{
service.name: unknown_service,
telemetry.sdk.language: python,
telemetry.sdk.name: opentelemetry,
telemetry.sdk.version: 1.20.0
}

for service.name we are just taking what OTel provides us, and sending to Sentry will be according to the DSN and project that DSN is associated with. Is the issue that there are no child spans? I cannot tell from this old view in Sentry unfortunately

[smeubank]

An update regarding OTel and Sentry: 🔭

Our main goal for using OTel is leveraging the power of it's instrumentation via SDKs, to help better enable to product surface of Sentry, and grant access to larger groups of developers

We will attempt to be good citizens of the ecosystems, and contribute back as well, as is Sentry's motto for all OSS work

There are 2 ways to use OpenTelemetry with Sentry

1. Performance Powered by OpenTelemetry: 🔋
   • This is the topic of this discussion, and has officially been launched with our latest major release of our JS SDK: v8 Changelog
   • In simple terms, this is the Sentry Node SDK, and our Node.js tracing and performance monitoring features are now largely handled by OpenTelemetry "under the hood" as a dependency of our SDK
   • With these changes we added more auto-instrumentation support for Node frameworks & libraries like Hapi, Fastify, Nestjs, and more
   • We are investigating doing similar for Python, Java, .Net, and other SDKs - no ETA
2. OTel via Span Processor: GA support February 2023 Blog ♻️
   • This allows developers to take their existing instrumentation done with an OTel SDK and use the Sentry SDK to also send that data to Sentry
   • That means if you have already instrumented with OTel, and want to also send that data Sentry, you can and the Sentry SDK will take OTel span and also Send them to Sentry in the correct format
   • Supported on: Golang, Node.js, Python, Ruby, Java, and .NET)
3. collector, out of process exporters, and OTLP Endpoints ❌
   • The 3rd option is not our roadmap at the moment, this would be that Sentry would provide an OTLP native endpoint, for you to send your native OTel data from OTEL SDKs to Sentry to run our tracing and performance monitoring products
   • We have investigated it, but for now we do not have a plan to make this user facing, since it would have downsides with our Errors and other products, which OTel SDK cannot propery run today
   • We are not working on supporting the OTel collector
   • We are not working on providing any exporters