More defensive approach to retrieving Node labels for a node #2534
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This was really impactful. I'd like to get this change into the agent |
| m[key] = map[string]string{} | ||
| } | ||
| for k, l := range result.GetLabels() { | ||
| m[key][k] = l |
There was a problem hiding this comment.
This is way better, but will still result in one value for a key "winning" in the event of a conflict. It's not really possible to avoid that. I'm wondering if, in the future, there is a way for us to preserve conflicts instead of picking one winner silently. Not for this PR.
There was a problem hiding this comment.
Right, good catch! If there are two kube_node_labels metrics describing the same node and using the same labels, the second label read wins (example below). I can't think of a simple solution right now to resolve those conflicts, but we may be able to implement something similar to the honor_labels Prometheus config (docs ref).
kube_node_labels{node="gke-qa-gcp1-default-pool-169fb9bb-0zz6", label_topology_gke_io_zone="us-east1-d"}
kube_node_labels{node="gke-qa-gcp1-default-pool-169fb9bb-0zz6", label_topology_gke_io_zone="us-east1-a"}
|
@AjayTripathy @michaelmdresser Appreciate the reviews! I don't have write access so if either of you could merge that'd be great! |
directly to the result. This protects against the case where there exist multiple `kube_node_labels` metrics for a single node. Signed-off-by: thomasvn <thomasnguyen96@gmail.com>
michaelmdresser
force-pushed
the
thomasn/nodelabels
branch
from
7da3fca
to
a84d660
Compare
|
) (#2552) directly to the result. This protects against the case where there exist multiple `kube_node_labels` metrics for a single node. Signed-off-by: thomasvn <thomasnguyen96@gmail.com> Signed-off-by: Michael Dresser <michaelmdresser@gmail.com> Co-authored-by: Thomas Nguyen <thomasvn.dev@gmail.com>
) (#2551) directly to the result. This protects against the case where there exist multiple `kube_node_labels` metrics for a single node. Signed-off-by: thomasvn <thomasnguyen96@gmail.com> Signed-off-by: Michael Dresser <michaelmdresser@gmail.com> Co-authored-by: Thomas Nguyen <thomasvn.dev@gmail.com>
What does this PR change?
kube_node_labelsmetrics for a single node.Does this PR relate to any other PRs?
How will this PR impact users?
kube_node_labelsper node in their Prometheus environment.Does this PR address any GitHub or Zendesk issues?
How was this PR tested?
kube_node_labels. Functioning as expected when querying the Assets API.Does this PR require changes to documentation?
Have you labeled this PR and its corresponding Issue as "next release" if it should be part of the next OpenCost release? If not, why not?