Owner Metadata for Spans. #4008
Labels
Comments
For my understanding, are there other places where these metadata will be useful, other than linking the Jaeger dashboard to the Linkerd dashboard? Since tracing is an optional addon, do we want the Linkerd dashboard to be coupled to it? |
|
@ihcsim Also, I'm thinking there will be more use-cases where these values would be needed by the proxy,
|
This was referenced Mar 25, 2020
olix0r
pushed a commit
to linkerd/linkerd2-proxy
that referenced
this issue
Apr 13, 2020
This change adds support for a `LINKERD2_PROXY_TRACE_ATTRIBUTES_PATH` configuration that, when tracing is enabled, loads metadata (especially Kubernetes labels) to be emitted with traces. Fixes linkerd/linkerd2#4008
|
Depends on at least #4199 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Feature Request
Right Now, For metrics Prometheus automatically adds the pod's labels as metric labels, giving us the capability to link grafana dashboard for that component directly in the linkerd dashboard and allowing users to jump there seamlessly.
A similar model with Jaeger would be great i.e jumping directly from the linkerd dashboard to the jaeger dashboard and showing relevant spans of the component. This would require some labels to be present that allows us to filter spans based on the selected component.
We already send some owner Metadata, for the spans as seen in the picture.
The
hostnamelabel allows us to categorize spans based on the pod that the spans came from, allowing us to directly specify a link with the queryhostnamelabel for pods. But we would also want a similar case for thekindandnameof workload.Sadly, This Information is actually not passed into the pod's env variables right now. The
hostnameis injected by k8s currently and we use that. But A similar thing is not present for workloads.What problem are you trying to solve?
More metadata for spans.
How should the problem be solved?
We already find the workload, type information during injection and add them as
podlabels.We can use the downward API https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/ to make those labels attached as volumes for the
linkerd-proxyto attach them as labels here.https://github.com/linkerd/linkerd2-proxy/blob/9faff18c8a6ffabe92afcd2a47ab169b99baa1b0/linkerd/trace-context/src/layer.rs#L142
Any alternatives you've considered?
Further reading:
https://developers.soundcloud.com/blog/using-kubernetes-pod-metadata-to-improve-zipkin-traces
@grampelberg
The text was updated successfully, but these errors were encountered: