tiithansen
commented
8 months ago Hi,
There is actually PR submitted by me few months back. But no one has done a code review for it so its just hanging there. There could be a lot of missed details and this solution required a somewhat a hack to adjust the span kind afterwards. Link to the PR https://github.com/open-telemetry/opentelemetry-cpp-contrib/pull/283 if someone would test it I would be willing to continue working on it.
On Wed, Nov 1, 2023 at 9:00 PM John Huffaker @.***> wrote:
For us this is a critical gap in the tracing functionality. We use nginx at our edge and a very useful feature of tracing are these client spans showing both the external latency of the upstream service, but also services that haven't adopted tracing show up as "inferred services" by using these spans to identify upstream callouts. Are there any other issues tracking this? Seems like a pretty clear miss.
— Reply to this email directly, view it on GitHub https://github.com/open-telemetry/opentelemetry-cpp-contrib/issues/278#issuecomment-1789493005, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4T2LANSMZNMGOZYHUXKHTYCKL5RAVCNFSM6AAAAAAXPMLYCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGQ4TGMBQGU . You are receiving this because you authored the thread.Message ID: @.*** com>
What is the expected behavior? To my understanding remote call spans should have
span.kind: client. Currently this module only creates one span with kind server.What is the actual behavior? Create additional span with
span.kind: clientbefore proxying request.Additional context This can cause issues for tools which try to render a service map Grafana Tempo metrics generator for example. Technically there are other means to detect remote calls but client server spans are meant to serve that purpose.