✨ Where is Profiling on the Spring Boot / Java feature roadmap?

[bjornharvold]

Problem Statement

As a fan of OpenZipkin, I am also a Sentry fanboy. Wondering when the Profiling feature will hit Spring Boot. According to your docs, it's currently only available for Android [which should make it an easy port to the rest of the Java ecosystem].

Also, Sentry Performance for webflux / reactive Spring Boot apps is highly desired.

A Feature Roadmap for each language ecosystem would be nice.

Regards,
Bjorn

Solution Brainstorm

No response

[romtsn]

hi @bjornharvold, thanks for using and loving Sentry. There's some work going on wrt JVM profiling right now, you can track the progress and discussions in #2635. It's not quite the same as Android profiling, because Android has its own VM and profiler, but certainly some ground work has been performed for ingesting profiles from the Java SDK.

I'm going to close this as dupe of #2635 but feel free to comment here (or on the linked issue) if you'd need more information.

[adinauer]

Hello @bjornharvold, we've added Sentry Performance for WebFlux in 6.16.0 and improved it since - just in case you missed that.

[bjornharvold]

Hi @adinauer

Yes, I can see Sentry uses OpenTelemetry for capturing performance in a webflux environment. The instructions are a bit blurry though. Could you possibly add an example of this here: https://github.com/getsentry/sentry-java/tree/main/sentry-samples. Currently, I read through this post https://www.baeldung.com/spring-boot-opentelemetry-setup and there seems to be a lot going on to get OpenTelemetry started.

Is it as simple as adding:

        <dependency>
            <groupId>io.sentry</groupId>
            <artifactId>sentry-opentelemetry-agent</artifactId>
        </dependency>
      
      <!-- OpenTelemtry 1.29.0 -->
      <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-api</artifactId>
        </dependency>

  OR

      <!-- OpenTelemetry 1.29.0-alpha -->
       <dependency>
            <groupId>io.opentelemetry.instrumentation</groupId>
            <artifactId>opentelemetry-spring-boot-starter</artifactId>
        </dependency>

to my Maven project and adding

sentry.dsn & sentry.traces-sample-rate to my application.properties file?

Thank you,
Bjorn

[adinauer]

@bjornharvold while it's still possible to use Sentry and OpenTelemetry for Spring WebFlux, you no longer need OpenTelemetry as of 6.16.0 of the Sentry Java SDK. You can find examples for using WebFlux for Spring Boot 2 and Spring Boot 3 in the samples you linked - those have performance enabled (sentry.enable-tracing=true in application.properties).

[adinauer]

Oh and if you'd still like to go ahead with OpenTelemetry, we have some docs available.

[bjornharvold]

Thank you. That was NOT clear in the documentation here: https://docs.sentry.io/platforms/java/guides/spring-boot/webflux/. No, I do not want to use OpenTelemetry if not necessary. So enabling Sentry Performance in webflux is now the same as a regular Spring Boot non-reactive configuration?

Cheers 🍺

[adinauer]

So enabling Sentry Performance in webflux is now the same as a regular Spring Boot non-reactive configuration?

Yes. Docs apply to both WebMVC and WebFlux now.

I've opened a PR to remove the OTEL sentence from the docs to avoid confusion.

[Kah0ona]

So we are running Clojure web app and loving Sentry. Since Clojure runs on the JVM, is there any future roadmap towards supporting profiling for 'other JVM languages'?

Or can it never be so generic, as in, do you always need information about what framework is used etc, seeing the mention of Spring Boot and others.

[adinauer]

@Kah0ona are you interested in our Performance product including distributed tracing or Profiling?

For Performance we'd either need to add support for each specific framework to create transactions / spans and forward / receive tracing information or you can try our OpenTelemetry integration which supports more libraries.

For Profiling it should work framework agnostic as it only shows you which methods are slow. Whether this would require extra integrations for each framework depends on implementation details of a feature not yet implemented (#2635 ). As far as I know you need a transaction for it.