dapr / dapr/java-sdk

[PROPOSAL] First-class distributed tracing

Open
#650 10 comments 2 reactions 0 assignees View on GitHub
kind/enhancement
Dominant language
Java
Stars
300
Forks
230
Avg merge
1d 20h
Merged PRs (30d)
4

Description

Over the past weeks, I've been struggling [to get distributed tracing to work](https://github.com/dapr/java-sdk/issues/647).

My observation is that a Java application that uses the Dapr SDK for Java does not propagate the `traceparent` HTTP-header from a call it receives _from_ the sidecar back _to_ the sidecar (e.g. one that does `invokeMethod` or `publishEvent`).

Looking at the code, I think that if the sidecar would use gRPC to invoke the Java application, it wouldn't work either - the `grpc-trace-bin`, `traceparent` or `tracestate` headers are propagated but read from an empty Context, it seems. But I haven't been able to let the sidecar talk gRPC to my Java apps, so I'm not 100% sure about this.

Nevertheless, in a platform that wants to simplify distributed systems, I think tracing is an essential thing. I'd love to see the Dapr SDK for Java make it as easy as possible to leverage what Dapr has to offer in this field.

## Describe the proposal
Provide the Dapr client code (at least `DaprClientBuilder`, `DaprHttpBuilder`, `DaprClientHttp` and `DaprClientGrpc` classes, maybe more) with a "strategy" to get a `traceparent` header value. Use that strategy to enrich calls from the application to the sidecar.

The default implementation should return an empty value. A user can supply their own implementation based on the frameworks they are using. For instance, I could envision an implementation that uses OpenTelemetry's `Span` class to find the correct value for the `traceparent` header.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.