Can't override service using opentracing_tag

[sanglt]

I'm using the nginx for proxy to our microservices.

I want to using dd-opentracing-cpp as nginx plugin.

I also using the opentracing_tag "service" "service_name" to change the service name, like this documents tell:
https://github.com/opentracing/specification/blob/master/semantic_conventions.md#span-tags-table

The service name for a span, which overrides any default "service name" property defined in a tracer's config. The meaning of service should correspond to the value set in peer.service, except it is applied to the current span. This tag is meant to only be used when a tracer is reporting spans on behalf of another service (for example, a service mesh reporting on behalf of the services it is proxying, or an out-of-band reporter which reads in log files). This tag does not need to be used when reporting spans for the service the tracer is running in.

But the issue is all of tracer reports in apm-ui is only show the nginx service name (Which defined in /etc/datadog-config.json).

For example:

How can I override the service_name for some span? (We also have a plan to implement dd-trace to all sub services), but its take time and I want to implements this way first.

Thanks,

[willgittoes-dd]

Try service.name! It's a Datadog convention (so other tracers should support it)

If it makes it easier, I can add in 'service' as a special tag name too, as per OpenTracing. But until that's merged in, 'service.name' as your span key should work :)

[sanglt]

Thanks @willgittoes-dd

We now can have correct service list.

I got other issue with the error and environment

Create other issue for that: #74

[willgittoes-dd]

Seems like OpenTracing might not adopt that tag after all: opentracing/specification#135

I'm going to leave the PR to add it here open, until we see if the revert passes. However none of that will stop 'service.name' from working!

[sanglt]

Thanks @willgittoes-dd,

That's mean I will just stick with service.name tag.

[cgilmour]

I think this issue can be closed. The PR referenced above was merged, and a solution was provided (setting service.name)

[sanglt]

Agreed with @cgilmour. We can close this issue.