Receiving events from Datadog libraries

[jean]

Hi all .. we currently have code instrumented using https://github.com/DataDog/dd-trace-js and https://github.com/DataDog/browser-sdk .. what's the best way to get them into the Collector?

Do we need to switch the client code to use https://github.com/open-telemetry/opentelemetry-js/tree/main/packages/opentelemetry-tracing instead?

[bogdandrutu]

Hi @jean,

First thing first: I would move this to contrib.

If you already using that we should be able to support them if there is enough interest in having this, I would like to make sure that if we invest in writing/reviewing/maintaining this will be used by a large number of users.

If you can switch to the opentelemetry solution, that would be great, but that may not be that easy, but let me know if you need help with that because I know some folks from the js library /cc @dyladan :)

[jean]

Hi @bogdandrutu , thanks for the answer :-)

Sorry, I'm not sure what you would move to contrib ^_^"

Yes, we're already using the Datadog libraries. It's probably doable to switch to the opentelemetry libs, we'll need to try.

Since OTel has a Datadog exporter, I'm sure there must be tons of people already using Datadog, but who would like to introduce additional backends, who would benefit from a Datadog receiver.

[jkowall]

This brings up a bigger question. We have good agents which are Apache 2.0 licensed from Datadog and New Relic. Neither vendor is going to write a receiver for Otel as it's against their business model and goals for revenue protection. It might make sense for the community to build these so that more robust agents can be used with Otel. This would be pretty complex without understanding the protocols from those services to add in Otel. I know all companies are building exporters.

New Relic stated they wanted to "support Otel" but I'm not sure if that included building receivers.

[ericmustin]

Hello there, chiming in from Datadog here.

@jean. If you're using the browser-sdk and dd-trace-js, @bogdandrutu is correct, at present the current solution if you'd like to use opentelemetry-collector would be to migrate to the opentelemetry-sdks.

I should point out that the approach taken regarding RUM by Datadog does not, to the best of my knowledge, neatly translate 1-to-1 with what Opentelemetry-js for the browser does. That's not a statement of judgement regarding one solution over the other, I just am pointing out that the telemetry data may be different. On the other hand, transitioning from dd-trace-js to opentelemetry-js on the node side is probably more straightforward, as a significant portion of opentelemetry-js-contrib's instrumentation is based on the donated datadog instrumentation, and generally the tracing approach is similar.

Regarding Datadog's interest in writing a receiver, I don't necessarily agree with the framing @jkowall presents although I certainly appreciate the perspective of another vendor. At present, Datadog is not prioritising a Datadog receiver in the OpenTelemetry collector. This is because there has not yet been significant end user interest in it that would warrant a commitment to both its implementation (which would be non-trivial) as well as its maintenance. Additionally, the OpenTelemetry-Collector is not yet at 1.0 itself, so it's still early innings imo. Because of that, we're focusing on the Otel-sdk => (collector or agent) => datadog backend platform experience first. I assume this is a similar logic behind why a variety of other vendors have not yet written receiver's. I certainly expect these sorts of feature requests to occur more as adoption grows post 1.0.

I'd encourage you @jean to reach out to your customer success manager or through support to raise this feature request so that we can accurately track interest in it.

I hope that helps!

Cheers,
Eric Mustin

[jean]

Hi @ericmustin , thanks! I don't think the RUM approach really matters in our case: the PWA client app I'm mainly concerned with is not interactive, and currenly emits custom events (no automatic tracing). We'd just need to port this to use OTel. Regarding the Node side, I'll follow up with support.