Sentry tracing with automatic instrumentation

[mmailaender]

Description

Sentry extended his error reporting service with a tracing approach: https://docs.sentry.io/platforms/java/performance/

There is already a Quarkus plugin that is supporting the logging part but not tracing: https://quarkus.io/guides/logging-sentry

It would be great if this plugin could be extended to support also tracing with automatic instrumentation.

Maybe it helps to have the sentry tracing reference documentation for Spring Boot: https://docs.sentry.io/platforms/java/guides/spring-boot/performance/instrumentation/automatic-instrumentation/

Implementation ideas

I found the tracing reference implementation of Sentry Spring boot, maybe that's a good orientation: https://github.com/getsentry/sentry-java/tree/main/sentry-spring/src/main/java/io/sentry/spring/tracing

[quarkus-bot]

/cc @Ladicek, @kenfinnigan

[geoand]

cc @maciejwalkowiak

[maciejwalkowiak]

@geoand I added it to our backlog, can't promise at the moment what priority it will get.

[geoand]

Thanks

[bruno-garcia]

Lets see if more 👍 comes in on this issue so we can push this up the priority list

[LaurentTreguier]

After looking into this, I found that an approach can be to leverage the already existing OpenTelemetry support in Quarkus, since OpenTelemetry is also supported in Sentry. I managed to have a project setup sending some transactions to Sentry this way. It took me a little while, but mostly because I'm just getting started (with both Quarkus and OpenTelemetry) and not because of the final amount of code

[smeubank]

It took me a little while, but mostly because I'm just getting started (with both Quarkus and OpenTelemetry) and not because of the final amount of code

Hey @LaurentTreguier

PM for SDK at Sentry here, if you have any thoughts to share on the setup of the Sentry SDK with OTel or with the quality of the data being sent to Sentry, I'd be happy to chat with you. Just let me know and happy to send you an invite!

Glad to hear the OTel support worked out for you :D

[LaurentTreguier]

Being a beginner in both Quarkus and OpenTelemetry, I don't think I have all that much to say on the topic

Regarding the setup: a lot of things I had trouble with probably won't be a problem for more experienced folks. I've never done a project with Quarkus before; and I learned about the existence of OTel itself by reading the Sentry docs when trying to get the both of them to work together!

Regarding the quality of the data: I have never really worked with performance metrics and such before, so it's hard for me to know what to look for. One thing I did notice though is that the link is properly made between the URL in errors and the one in traces; so the failure rate is correctly calculated; which is nice

[geoand]

cc @brunobat

[brunobat]

Looks like this is a popular one. Will schedule for next quarter.
This comment from @LaurentTreguier is excellent: getsentry/sentry-java#2254 (comment)

[u6f6o]

@smeubank Sorry if the question is probably a bit naive, but why is it necessary to use the sentry-client-sdk to export the traces? Our initial assumption was that we just have to change otel related configuration values in our services and point otel towards sentry dircelty adapting quarkus.otel.exporter.otlp.endpoint and the like. ?

[u6f6o]

Doing a copy & paste of the quarkus sentry exentions provided by @LaurentTreguier worked nicely and the tracing information was successfully exported to sentry.

[brunobat]

I've researched this and it seems Sentry has simply created a custom SpanProcessor and a propagation provider. If so, this is not different from the exporters we have on Quarkiverse.
This should work fairly out of the box, but we need to test it in native mode.

@LaurentTreguier would you like to submit your extension here: https://github.com/quarkiverse/quarkus-opentelemetry-exporter. I can help.
This wouldn't be different from what I was thinking, therefore its going to speed up the solution and give visibility to your work.

[smeubank]

@smeubank Sorry if the question is probably a bit naive, but why is it necessary to use the sentry-client-sdk to export the traces? Our initial assumption was that we just have to change otel related configuration values in our services and point otel towards sentry dircelty adapting quarkus.otel.exporter.otlp.endpoint and the like. ?

Not a naive question at all. The approach we went with is an in process span processor. Meaning we convert (a copy of) the OTel data to send to sentry in our event format for performance data. We do not have an OTLP endpoint for which OTel data can be sent to. And an out of process collector-exporter is problematic to keep our errors product in sync with otel traces.

OTel SDKs today simply don't provide the same level of insights when it comes to errors as ours do. And we want to make sure they can always be used since that a primary factor for a lot of sentry users.

[u6f6o]

Thx for the clarification!

[u6f6o]

Will schedule for next quarter.

Hi @brunobat ,
Do you already know if this issue will be addressed in the current quarter?

[brunobat]

Will try @u6f6o

[antonwiens]

Any updates?

[brunobat]

Looks like Sentry is moving to support OTel. See: getsentry/sentry-java#3436
This aligns best with our roadmap.
For reference there is a Sentry side Issue to support Quarkus: getsentry/sentry-java#2254.
Will not close the issue but unless @LaurentTreguier wants to contribute his code to Quarkiverse, this issue will be parked for the near future.