This message was deleted.

Interesting question. @Vishal Sharma do we know how this would work

That is possible, what’s the issue you are facing? cc: @Srikanth Chekuri

Are you seeing the broken trace? Did you make sure to add the interceptors with grpc?

Both my API Gateway and my gRPC Services have interceptors. But somehow i dont understand how i can work with distributed context. All of them are separated into own containers. Also both the API gateway and the gPRC Service do tracing but it seems that the gRPC Service has no clue of the context of the API gateway

What do you mean switching b/w them? If the interceptors are added then they take of propagating the context to downstream service. May be you can inspect the requests see where the

traceparent

and/or

tracestate

headers are missing?

The API gateway takes a POST request and then calls a distributed gRPC Service via his client. The gRPC service receives the call and then works with it and reply the API gateway via gRPC and the API client then reply the POST request to the origin post request

You would be able to see the above mentioned header names if the trace info is propagated. Does the context.Context grpc service uses contain the parent span context info? Or is the some different context object?

nope they are empty somehow. Do i have to set them explicit? The only headers that are set are authority, content-type, user-agent

No they are set automatically. If not exists that means the context.Context object didn't have the trace info. You need to make sure the context object received is correct parent context one.

I took a look but i cant find a way to set it because the offical docs of open telemetry are 💩

That is indeed how it works. I can't tell what you might be missing.

that not works because it not accept a trace object

What do you mean it doesn't accept trace object? Here is the code which automatically inject the trace info (obtained from context.Context) into grpc request metadata https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/google.golang.org/grpc/otelgrpc/interceptor.go#L94

is the http trace context used as base for the grpc context?

Good. that should be enough to see the full trace.

yes seems like but what is the downside of the missing tracestate?

tracestate is for propagating the cloud vendor metadata

also it would be somehow cool if i can inject the context from the REST http call to the gRPC context

To reiterate, all the inject automatically happens. You just have to make sure the context.Context object received by grpc func is parent context obj from HTTP call

Seems like an issue to me i use otelgin and the needed headers are not set so i guess i try to use another http framework to get it work