RUM-4055 Report Opentelemetry data in the configuration Telemetry

mariusc83 commented 4 months ago

What does this PR do?

Following the iOS Pr we are going to report the usage of the OpenTelemetry API in our configuration telemetry as follows: hasTrace:true | false, tracerApi: OpenTracing | OpenTelemetry | null, traceApiVersion: [openTelemetryApiVersion] | null

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

codecov-commenter commented 4 months ago

Codecov Report

Attention: Patch coverage is 90.47619% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 63.92%. Comparing base (478ba84) to head (a0e5b5f). Report is 1 commits behind head on feature/otel-support.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## feature/otel-support #2006 +/- ## ======================================================== + Coverage 63.88% 63.92% +0.05% ======================================================== Files 752 752 Lines 28368 28382 +14 Branches 4680 4686 +6 ======================================================== + Hits 18121 18143 +22 + Misses 9043 9036 -7 + Partials 1204 1203 -1 ``` | [Files](https://app.codecov.io/gh/DataDog/dd-sdk-android/pull/2006?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=DataDog) | Coverage Δ | | |---|---|---| | [...in/com/datadog/android/trace/OtelTracerProvider.kt](https://app.codecov.io/gh/DataDog/dd-sdk-android/pull/2006?src=pr&el=tree&filepath=features%2Fdd-sdk-android-trace%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fdatadog%2Fandroid%2Ftrace%2FOtelTracerProvider.kt&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=DataDog#diff-ZmVhdHVyZXMvZGQtc2RrLWFuZHJvaWQtdHJhY2Uvc3JjL21haW4va290bGluL2NvbS9kYXRhZG9nL2FuZHJvaWQvdHJhY2UvT3RlbFRyYWNlclByb3ZpZGVyLmt0) | `95.97% <100.00%> (+0.10%)` | :arrow_up: | | [...m/datadog/android/trace/internal/TracingFeature.kt](https://app.codecov.io/gh/DataDog/dd-sdk-android/pull/2006?src=pr&el=tree&filepath=features%2Fdd-sdk-android-trace%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fdatadog%2Fandroid%2Ftrace%2Finternal%2FTracingFeature.kt&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=DataDog#diff-ZmVhdHVyZXMvZGQtc2RrLWFuZHJvaWQtdHJhY2Uvc3JjL21haW4va290bGluL2NvbS9kYXRhZG9nL2FuZHJvaWQvdHJhY2UvaW50ZXJuYWwvVHJhY2luZ0ZlYXR1cmUua3Q=) | `94.29% <100.00%> (+0.17%)` | :arrow_up: | | [...ndroid/telemetry/internal/TelemetryEventHandler.kt](https://app.codecov.io/gh/DataDog/dd-sdk-android/pull/2006?src=pr&el=tree&filepath=features%2Fdd-sdk-android-rum%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fdatadog%2Fandroid%2Ftelemetry%2Finternal%2FTelemetryEventHandler.kt&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=DataDog#diff-ZmVhdHVyZXMvZGQtc2RrLWFuZHJvaWQtcnVtL3NyYy9tYWluL2tvdGxpbi9jb20vZGF0YWRvZy9hbmRyb2lkL3RlbGVtZXRyeS9pbnRlcm5hbC9UZWxlbWV0cnlFdmVudEhhbmRsZXIua3Q=) | `81.32% <88.24%> (+6.62%)` | :arrow_up: | ... and [34 files with indirect coverage changes](https://app.codecov.io/gh/DataDog/dd-sdk-android/pull/2006/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=DataDog)

mariusc83 commented 4 months ago

Important

It feels like we need to review the way we send the configuration telemetry information for other features than RUM. Right now we detect the OT by reflection, and this PR tries to add the OpenTelemetry version in the RUM build config. This doesn't make any sense and adds noise to a feature that should not have those kind of information. Maybe we should consider a different way for features to communicate this information and RUM would be agnostic of the keys and values.

@xgouchet I understand your concern, we could send it in the Trace feature context as we do for the is_opentelemetry_enabled property. But we still need to keep the build config entry as the other option is to send it as a hardcoded value that we will definitely forget to update. What do you think ?

P.S. I think opening a RFC only for this topic only would be too much IMO. @plousada what do you think ?

xgouchet commented 4 months ago

@xgouchet I understand your concern, we could send it in the Trace feature context as we do for the is_opentelemetry_enabled property. But we still need to keep the build config entry as the other option is to send it as a hardcoded value that we will definitely forget to update. What do you think ?

P.S. I think opening a RFC only for this topic only would be too much IMO. @plousada what do you think ?

I don't have an issue having the info set by build config, it just would make more sense to do it on the otel/tracing module, instead of the RUM one

mariusc83 commented 4 months ago

@xgouchet I understand your concern, we could send it in the Trace feature context as we do for the is_opentelemetry_enabled property. But we still need to keep the build config entry as the other option is to send it as a hardcoded value that we will definitely forget to update. What do you think ? P.S. I think opening a RFC only for this topic only would be too much IMO. @plousada what do you think ?

I don't have an issue having the info set by build config, it just would make more sense to do it on the otel/tracing module, instead of the RUM one

@xgouchet I understand your concern, we could send it in the Trace feature context as we do for the is_opentelemetry_enabled property. But we still need to keep the build config entry as the other option is to send it as a hardcoded value that we will definitely forget to update. What do you think ? P.S. I think opening a RFC only for this topic only would be too much IMO. @plousada what do you think ?

I don't have an issue having the info set by build config, it just would make more sense to do it on the otel/tracing module, instead of the RUM one

Yes this is what I am changing now, makes more sense to have it there. I am pushing a commit in few seconds.

DataDog / dd-sdk-android