Use service.namespace in Jager's service name if present #1710
Conversation
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
|
Some extra comments related to this #1677 (comment) |
|
Good point, but I think we should change Zipkin at the same time (there is no reason for this to apply only to Jaeger). Actually, I just noticed we have a document https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/non-otlp.md, probably this should be moved there. The semantic convention should also be changed to mention the preferred separator in cases where concatenation is needed. |
| [default](../../resource/sdk.md#sdk-provided-resource-attributes) `Resource`. | ||
| * If `service.namespace` is not present, Jaeger's field MUST be populated from the `service.name` attribute. |
There was a problem hiding this comment.
These points are a bit hard to read. IMHO a better structure would be:
- If service.name and service.namespace, ...
- Otherwise if just service.name, ...
- Otherwise (irrespective of service.namespace), ...
Also, the current wording leaves the case where service.namespace is present but service.name is not undefined. With the suggestion above it would be ignored but using {service.namespace}/{default service name} might make sense.
| [default](../../resource/sdk.md#sdk-provided-resource-attributes) `Resource`. | ||
| * If `service.namespace` is not present, Jaeger's field MUST be populated from the `service.name` attribute. | ||
| * If both `service.namespace` and `service.name` attribute are present then that field | ||
| MUST be populated as `{service.namespace} + "/" + {service.name}` |
There was a problem hiding this comment.
I think this is not a bad idea but would be good to hear from Jaeger experts. Maybe there is a commonly accepted way to model service namespaces or teams this in Jaeger? @yurishkuro do you know?
There was a problem hiding this comment.
Jaeger backend does not support the notion of namespaces. Does any backend do? What is the specific functionality that applies to namespace only and not the FQ service name?
Back at Uber we had several thousand services and did not come across a need for a namespace as a first class entity, although various teams did use certain prefixes for service names like jaeger_indexer, jaeger_ingester.
Regarding the concatenation, using slash makes many Jaeger URLs quite ugly since slash must be URL-encoded.
There was a problem hiding this comment.
Let's change it for Zipkin and also for resource labels description here: https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/resource/semantic_conventions#service
this kind of inconsistency is bothersome
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
OpenQuestion: There is a note in the https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/resource/semantic_conventions#service about not concatenating, but I think (🤔) for cases where only one value is passed like Jaeger it would be important to concatenate them.
Signed-off-by: Bogdan Drutu bogdandrutu@gmail.com