Support reporting trace data to Datadog

[Diagoras]

There's already support for sending trace data to Zipkin, which is great. It'd also be nice if the monitoring service Datadog was supported, since they also have an HTTP based system for accepting trace data. I imagine this would best be done by having a separate, autoconfigured dependency just like you do for Zipkin.

Datadog trace API details can be found here: https://docs.datadoghq.com/tracing/api/

[marcingrzejszczak]

Yeah you can already do it by registering your own https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/SpanReporter.java . It would be enough to convert the Sleuth's Span into whatever Datadog understands and then use the HTTP client to send those spans to Datadog. Care for a PR? :D

[codefromthecrypt]

Depending on how you want to do it, you could add something like this https://github.com/spring-cloud/spring-cloud-gcp/tree/master/spring-cloud-gcp-trace Since you are likely to want metrics too, might make sense to make a dd repo and in there also autoconfig micrometer?

[marcingrzejszczak]

Since Sleuth has migrated to Brave (https://github.com/openzipkin/brave), I guess the first option would be now to collaborate with Brave and then Sleuth can autoconfigure Brave.

[Diagoras]

@marcingrzejszczak Hey, I notice you closed this issue because it'd be better to configure Brave to send traces to DataDog (if I understand correctly). But it looks like Spring Sleuth explicitly has a module to send traces to Zipkin itself.

Is there a reason that it makes more sense to configure Brave to send trace data to DataDog, instead of adding a new spring-cloud-sleuth-datadog module to Spring Sleuth? For example, are there plans to deprecate Sleuth's explicit Zipkin integration in favour of using Brave's?

Thanks.

[codefromthecrypt]

The zipkin-reporter interface has implementations for Amazon X-Ray and Google Stackdriver now. It is basically an export abstraction.. some use it to stuff traces into log files! More to the point, there is work in progress on a datadog reporter that could plug directly in, like those above or any other transport here tylerbenson/zipkin-datadog-reporter#1 If you want, ping that issue saying you are interested in it. Usually more people interested make things happen quicker.

[Diagoras]

@adriancole Thanks for the pointer! I'll be sure to ping that issue. It sounds like these kinds of external reporters are planned to be handled in Brave instead of in Spring Sleuth? If so, then a Datadog variant would rock. Much appreciated.

[codefromthecrypt]

@adriancole <https://github.com/adriancole> Thanks for the pointer! I'll be sure to ping that issue. It sounds like these kinds of external reporters are planned to be handled in Brave instead of in Spring Sleuth? If so, then a Datadog variant would rock. Much appreciated.

Yep, some will be zipkin-reporter specifically, but some will have data policy concerns which may have Brave hooks. Solving at this level also allows legacy spring apps to leverage external non-zipkin systems.

[masoncj]

Just came here to say that we spent a little while trying to get Spring Sleuth/Brave to integrate well with Datadog's java agent, and eventually gave up and fell back to using open tracing direct to Datadog. It seems like Spring Sleuth is pretty tightly coupled to Brave so substituting other Tracers seems challenging. The datadog reporter approach would seem to work but would require forgoing other features in the datadog java agent (submitting trace data directly to datadog's monitoring agent).

[codefromthecrypt]

datadog's agent does not just configure opentracing, rather it also wants to control the tracer itself. since sleuth controls the tracer, this is a conflict. datadog could choose to support brave. opentracing itself is deprecated, and brave is not and existed prior to opentracing.