feat: add session-based sampling ratio support

[GerardPaligot]

• Integrated SessionIdRatioBasedSampler in OpenTelemetryRumBuilder.
• Enhanced SessionConfig to support sampling ratio configuration.

Issue #841

[linux-foundation-easycla[bot]]

• :x: - login: @GerardPaligot / name: Gérard Paligot . The commit (fdda96d79ca8a1ff52bba59779a96b8fd3ff3628) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[LikeTheSalad]

Hi @GerardPaligot

Thank you for your PR 🙏

We discussed this issue in yesterday's SIG meeting, and we all agreed that we need to provide a mechanism to enable your use case, though the approach of extending the session config to add a ratio param was criticised since it could break single responsibility for sessions. So we discussed some alternative approaches and the one that seems to be the most generic was making use of the SessionObserver somewhere in the builder such that a sampler can listen to the creation of a session and change its predicate based on that callback, at least that's what I understood it was the high level idea, please let me know if I missed something @breedx-splk.

[breedx-splk]

Yes @GerardPaligot I will second that this PR is appreciated and especially thanks for bringing up the problems with the sampler in #841.

In addition to the things that @LikeTheSalad mentioned that we discussed in the SIG meeting, I was also enlightened in the later logs SIG about the idea of storing the session into the otel Context. This allows us to grab the Session without the need for an observer, which I think is pretty interesting and underutilized. Please have a look at #974 and see if that approach will work for you and/or if you'd have any suggestions.

Again, we really do appreciate the work and I'm not trying to take this effort away or diminish it, just trying an alternative that is hopefully agreeable to everyone.

[GerardPaligot]

Don't worry guys, it is totally okay to not accept an external contribution. To be honest, I wasn't convince by myself about my own contribution. It seems that it breaks SOLID principles and I don't like the indirect link between the session config and the sampling.

@breedx-splk About your last contribution, yes probably but let me add some comments there.

Feel free to close this PR!

[breedx-splk]

Don't worry guys, it is totally okay to not accept an external contribution.

We don't really make an "external" or "internal" differentiation -- all are welcome! Regardless of which route we end up going, you have no idea how helpful these kinds of PRs are and how much they help us to get a better idea about what users are doing and what parts of the code they care about. Your feedback here and in the other PR is super duper valuable....thank you.

[breedx-splk]

We do require the Contributor License Agreement (CLA) to be signed though.

[GerardPaligot]

Thanks!

I'm currently building an internal SDK based on OpenTelemetry Android and OpenTelemetry Java to support features that aren’t yet available in this SDK, or that work differently. In particular, I avoid auto-instrumentation in my projects because I prefer to explicitly define what gets instrumented, maintaining a clear contract within the application.

That said, I think it could be valuable to open discussions on certain features that might be generic and reusable enough to contribute upstream.

Here are a few examples of what I’ve been working on:

• KSP compiler plugin: Observes a @Monitor annotation on Kotlin interfaces and generates a proxy class that instruments all function calls. This proxy can be injected between the interface and its implementation in a DI setup, enabling instrumentation across architectural layers.
• Lifecycle-aware observer: Similar to your activity/fragment observer, but built to be as generic as possible. In my case, it integrates with Compose’s DisposableEffect and the compose navigation library to observe screen-level navigation events.
• Coroutine entry point extensions: I created launchMonitored, withContextMonitored, and asyncMonitored as wrappers around coroutine builders to trace logic flowing from the presentation to domain and data layers.

These tools let me build a trace structure like this:

(No critical data from this capture, so it is ok to share)

We do require the Contributor License Agreement (CLA) to be signed though.

I'm not sure yet if I should sign it for a personal contribution or professional. Probably the second one so the process seems longer.

[LikeTheSalad]

That said, I think it could be valuable to open discussions on certain features that might be generic and reusable enough to contribute upstream.

Definitely! That'd be great 🙏

Also, I understand the benefits of letting people choose the automatic instrumentations that they need, without having them enabled by default. This project should allow for that use case as it's split into 3 components:

• The core component, where all the rum initialization is done and all the configs are as generic as possible.
• The automatic instrumentations, which are all independent from core, though they are installed as part of the core rum initialization.
• The agent, which is the enduser-friendly route, which also adds high-level opinionated config options. It combines core + some instrumentations, for people who want to go with our recommended configurations out of the box and avoid having to write much code to get everything up and running as quick as possible.

It seems like, for your use case, you might want to use core as base for your SDK. If you happen to spot something that's impossible to configure via core, similarly to what happened with the session sample rate, it would be very helpful to get feedback on that so that we can ensure that core is as flexible as possible to work as a generic base for any SDK.

[marandaneto]

Should this be closed because other PRs have superseded it?

[LikeTheSalad]

Should this be closed because other PRs have superseded it?

You're right. I'll close it now, @GerardPaligot, as another approach was merged here. Thank you for bringing this issue up and for your PR.