manually instrumented traces are missing RUM details

[joshskeen]

Though AndroidTracer is configured with setBundleWithRumEnabled(true), fundamental rum details are missing in subsequently collected traces:

missing attributes: context, device, env, geo, os, and session

[jonathanmos]

hi @joshskeen, we'll look into this. Could you please provide a code sample of how you are performing initialisation?

[joshskeen]

AndroidTracer.Builder()
.setSampleRate(sampleRate)
.setBundleWithRumEnabled(true)
.build()

[mariusc83]

Hi @joshskeen , I am following up on this thread. Indeed the device, env, geo and os information is not provided into the traces as we do it for RUM events and we do not plan to offer this by default due to performance reasons. On the other hand regarding the RUM context or session you do have this information in the Span info tab: view.id, application_id, session_id.
For all the other information you could add it manually by using the global addTag method in AndroidTracer or the local method setTag at the Span object level. For more information: https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/android/?tab=kotlin

[mariusc83]

@joshskeen one small note on what I stated above, if you use the RUM2APM feature, RUM will automatically create traces for each resource request in your application. Those traces will have by default the Geo, Os and Device information generated by us. For all the other traces created manually with our API the above statement can be applied.

[joshskeen]

Thanks for the reply @mariusc83 . A few follow-up questions:
2. what is the RUM2APM feature? Can you link to the documentation for this please?
3. it appears that network traces collect context, device, env, geo, os, and session. If we omit these for performance reasons, why do we include them with these particular traces?
4. Rather than manually passing in these parameters to each manual trace, it would be ideal to specify which rum parameters would be included in each trace. Is there any mechanism to do this?
5. It appears that manually collected traces do not reference the RUM session they are collected within in the flame graph as a UI option, though setBundleWithRumEnabled is true. What additional details are required to enable this behavior in the trace flamegraph display?
Thanks!

[xgouchet]

Hi John, let me chime in here .

2. what is the RUM2APM feature? Can you link to the documentation for this please?

Sorry about the lingo, RUM2APM is our internal way of talking about the full tracing of network requests. This is due to the fact that the tracing originate through RUM instrumenting network requests via our browser and mobile SDK, and connecting it to the APM traces tracked in the backend to give a full picture. From a RUM session, one can dig into an APM trace and e.g.: understand what caused a 500 response. You can find more information about that on this page

3. it appears that network traces collect context, device, env, geo, os, and session. If we omit these for performance reasons, why do we include them with these particular traces?

In the case of RUM2APM, the root span is generated from the RUM resource, meaning it uses the aggregation of all the attributes available in the backend ingesting the RUM session event, which is then duplicating all the attributes into the span, and then is forwarded to the APM processors.
When generating non-network spans in the mobile, the span doesn't go through the RUM processors, and is sent directly to the APM processors. Getting all of the informations available in RUM would require to also go through both stacks for all spans and not just the network ones.

4. Rather than manually passing in these parameters to each manual trace, it would be ideal to specify which rum parameters would be included in each trace. Is there any mechanism to do this?

There's no mechanism to specify which parameters should be copied from RUM as of know, but if this is something important to you, feel free to open a feature request via our support channel.

5. It appears that manually collected traces do not reference the RUM session they are collected within in the flame graph as a UI option, though setBundleWithRumEnabled is true. What additional details are required to enable this behavior in the trace flamegraph display?

This is an issue that we identified (we discussed this on slack) and is in our roadmap, we plan on fixing that as soon as possible

[0xnm]

Hello @joshskeen!

Version 2.5.0 should now have a better integration of manually collected traces with RUM, you should see a link between them in Dashboard. In the meantime we are working on improving this integration for data collected by the older SDKs.

[MaelNamNam]

Hi @joshskeen! Following up on this: do you still need to get the device information at the span level? If yes, would you mind submitting a feature request so we can properly track this need plase? Cheers!