-
Notifications
You must be signed in to change notification settings - Fork 271
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
Include pod UID and container name as optional trace labels #3483
base: main
Are you sure you want to change the base?
Conversation
you've been clippy'ed 📎 🙀
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
besides the note about clippy lints above, this looks like a good PR to me. this should be a nice improvement to our traces!
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3483 +/- ##
==========================================
- Coverage 67.68% 66.74% -0.94%
==========================================
Files 332 388 +56
Lines 15158 18171 +3013
==========================================
+ Hits 10259 12128 +1869
- Misses 4899 6043 +1144
... and 176 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
d76fa98
to
89d0203
Compare
linkerd/app/src/env.rs
Outdated
const ENV_POD_UID: &str = "_pod_uid"; | ||
const ENV_POD_CONTAINER_NAME: &str = "_pod_containerName"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've generally been pretty adamant (and successful) about not leaking kubernetes concepts (pods, containers, uids, etc) into the proxy's codebase.
You may notice that we load a bunch of attributes from a file at starttime:
is it possible to encode these attributes into this file so the proxy doesn't need special casing for them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT, the downward API doesn't let you encode more than one field ref in a single file, nor does it give you particularly good control over the keys for the values (unless you're using labels or annotations, and I'd rather not dump all of those for a pod into each trace).
That being said, I think we can still encode these through environment variables as a list of arbitrary extra fields to add. Thoughts on linkerd/linkerd2#13544?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see your point: the file as it is only include pod labels. I agree that the next best solution is as you suggest--make the proxy generic about the specific keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I've updated this PR to reflect those changes to the attributes, PTAL
This allows us to include arbitrary values from the k8s downward API beyond just the pod labels that are included in the trace attributes file. See linkerd/linkerd2#13544 for the corresponding control plane change. Signed-off-by: Scott Fleener <[email protected]>
It's useful to include these fields in the trace span attributes to help correlate traffic within a cluster.
This propagates these labels through the trace initialization, similar to how we handle the service name (and other labels that last for the entire pod lifetime).
See linkerd/linkerd2#13501 for the corresponding control plane change.