-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distributed Tracing Service Name should be dynamic #11157
Comments
I did find a workaround that might be suited for most people. transform/linkerd-proxy:
error_mode: ignore
trace_statements:
- context: resource
statements:
- |
set(
attributes["service.name"],
# TODO pick any labels you have/need here:
Concat(
[
attributes["app.kubernetes.io/part-of"],
attributes["app.kubernetes.io/name"]
],
"-"
)
) where attributes["service.name"] == "linkerd-proxy" |
This definitely sounds reasonable to me. We would be happy to accept a PR along these lines. |
Hey @adleong if no one is working on this one can I?
|
I'm looking for this feature too! I'd like to contribute if no one is working on it. |
Thanks for your interest, everyone! I'm not aware of anyone actively working on this already. And I think @whiskeysierra's suggestions above are good ones. |
Is this up for grabs? Seems it's been a few months since the last comment, and not seeing any commits to address it |
Yep, this hasn't been addressed yet. |
I'm currently looking into this |
Currently, we hard-code the trace service name to "linkerd-proxy". This allows this name to be configured through an env that can be set by the injector, annotations, etc. linkerd/linkerd2#11157 Signed-off-by: Scott Fleener <[email protected]>
Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Currently, we hard-code the trace service name to "linkerd-proxy". This allows this name to be configured through an env that can be set by the injector, annotations, etc. linkerd/linkerd2#11157 Signed-off-by: Scott Fleener <[email protected]>
Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Currently, we hard-code the trace service name to "linkerd-proxy". This allows this name to be configured through an env that can be set by the injector, annotations, etc. linkerd/linkerd2#11157 Signed-off-by: Scott Fleener <[email protected]>
Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Companion to linkerd/linkerd2-proxy#3245, exposes the configuration for the tracing service name in the proxy to the general linkerd config. Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Companion to linkerd/linkerd2-proxy#3245, exposes the configuration for the tracing service name in the proxy to the general linkerd config. Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Companion to linkerd/linkerd2-proxy#3245, exposes the configuration for the tracing service name in the proxy to the general linkerd config. Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Companion to linkerd/linkerd2-proxy#3245, exposes the configuration for the tracing service name in the proxy to the general linkerd config. Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Companion to linkerd/linkerd2-proxy#3245, exposes the configuration for the tracing service name in the proxy to the general linkerd config. Similar in concept to linkerd#12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes linkerd#11157 Signed-off-by: Scott Fleener <[email protected]>
Companion to linkerd/linkerd2-proxy#3245, exposes the configuration for the tracing service name in the proxy to the general linkerd config. Similar in concept to #12371, except the configuration lives entirely within the tracing injector config instead of going through the control plane. Fixes #11157 Signed-off-by: Scott Fleener <[email protected]>
What problem are you trying to solve?
As of today, the service name that the proxy uses to emit traces is hard coded to "linkerd-proxy":
https://github.com/linkerd/linkerd2-proxy/blob/32245601bb32fa36b2f8d5997e3d806ee388eb41/linkerd/app/src/oc_collector.rs#L40
Because different services will share this name for their proxies, it makes meaningful analysis or visualisation of a whole system unnecessarily hard. A service map will typically include one big node in the center which is the "linkerd-proxy" but it's made up of data that comes from a lot of different proxies, i.e. it represents something that doesn't exist. Also any kind of trace analysis often ends up at a "linkerd-proxy" without telling you which service it belongs to.
How should the problem be solved?
Instead of being a static string, it should be controlled by an env var, ideally a template string so that e.g. a service called "my-service" can pick a template "%s-linkerd-proxy" and the service name that is used by the proxy will then be "my-service-linkerd-proxy".
Any alternatives you've considered?
I tried to look into the opentelemetry collector to rewrite those service names, but without any kind of identifying span attributes (and I couldn't find any besides the service name itself), one can't rewrite those.
How would users interact with this feature?
Env var for the linkerd-proxy sidecar or even nicer would probably be an annotation (which could then be translated into an env var by the injector).
Would you like to work on this feature?
maybe
The text was updated successfully, but these errors were encountered: