search

cap-js / telemetry

CDS plugin providing observability features, incl. automatic OpenTelemetry instrumentation.
https://cap.cloud.sap/docs
Apache License 2.0
8 stars 7 forks source link

feat(to-dynatrace)!: @opentelemetry/exporter-trace-otlp-proto -> export via otel #213

Closed sjvans closed 3 months ago

sjvans commented 3 months ago

follow-up of https://github.com/cap-js/telemetry/pull/184

@soccermax fyi

soccermax commented 3 months ago

@sjvans I tested a bit more with the combination of OneAgent and the OTLP exporter active. In effect, if the traces are captured by OneAgent (trace initiated by an HTTP request) and also exported by OTLP, the traces are duplicated in Dynatrace. In my opinion, we need to address this with Dynatrace because we can't resolve this on our side. As long as Dynatrace + OneAgent can't handle this, I would personally prefer a flag, as before, to decide whether we want to activate the export via OTLP or just use OneAgent.

What do you think?

sjvans commented 3 months ago

hi @soccermax

presence of @opentelemetry/exporter-trace-otlp-proto in the project's dependencies is the feature flag. ;) or why is this not sufficient?

soccermax commented 3 months ago

@sjvans as we deploy the same app twice once for all activities coming from the UI and once for all background activities hence they share the same package.json. With a flag we could avoid the double traces on the UI facing app until Dynatrace is fixing it for real

sjvans commented 3 months ago

i'm not a fan... how about a custom exporter? deciding per span would be the correct approach anyhow.

soccermax commented 3 months ago

i'm not a fan... how about a custom exporter? deciding per span would be the correct approach anyhow.

Yes that sounds better! @sjvans maybe this would also be a good default, can we somehow check if oneagent already captured the span. In our case it's easy but we could try to do it generic, in that case we would not need a custom exporter. What do you think?