-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
add kube_*_annotations metrics #770
add kube_*_annotations metrics #770
Conversation
Welcome @qw1mb0! |
And I would like to ask for advice, perhaps it is worth removing from the annotation the mention of kubernetes_io_last_applied_configuration? If so, can you tell me how you can do this? |
I think we've recently had a similar case to this. I'm trying to understand why this is not a real field on the deployment? This being an annotation doesn't make me feel like this should be a stable metric. |
This metric appears only when manually managing deployment in kubernetes using the Then the metric will look like this:
|
hmm... maybe someone from sig cli or sig apps could explain why this is not a real field, maybe it's a prospect for an objectmeta field? |
This summary is used for the patch: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#merge-patch-calculation Now we can leave this annotation. Can I add this label to all other resources? |
Could you add examples of the annotations you intend to use in the tests? Because I don't think the result that you are currently producing is what you are looking for, as you can't do math with label values. |
I added annotations to |
Can I make a similar metric for all other resources now? |
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.
Some things stood out.
@@ -6,3 +6,4 @@ | |||
| kube_certificatesigningrequest_condition | Gauge | `certificatesigningrequest`=<certificatesigningrequest-name> <br> `condition`=<approved\|denied> | STABLE | | |||
| kube_certificatesigningrequest_labels | Gauge | `certificatesigningrequest`=<certificatesigningrequest-name>| STABLE | | |||
| kube_certificatesigningrequest_cert_length | Gauge | `certificatesigningrequest`=<certificatesigningrequest-name>| STABLE | | |||
| kube_certificatesigningrequest_labels | Guage | `annotation_CSR_ANNOTATION`=<CSR_ANNOTATION> <br> `certificatesigningrequest`=<certificatesigningrequest-name> | STABLE | |
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.
This seems incorrect.
@@ -32,6 +32,9 @@ var ( | |||
descCSRLabelsHelp = "Kubernetes labels converted to Prometheus labels." | |||
descCSRLabelsDefaultLabels = []string{"certificatesigningrequest"} | |||
|
|||
descCSRAnnotationsName = "kube_certificatesigningrequest_annotations" |
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.
What's the reasoning behind adding a variable that is only used once? Useless indirection creates confusion.
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.
That applies to all such changes.
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.
you're right
@brancz I added the metric |
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.
Additionally to skipping the pod annotations, could we mark all of these as experimental? I would like to be able to remove them if there is a cardinality problem with any of them.
docs/pod-metrics.md
Outdated
@@ -40,3 +40,4 @@ | |||
| kube_pod_spec_volumes_persistentvolumeclaims_info | Gauge | `pod`=<pod-name> <br> `namespace`=<pod-namespace> <br> `volume`=<volume-name> <br> `persistentvolumeclaim`=<persistentvolumeclaim-claimname> | STABLE | | |||
| kube_pod_spec_volumes_persistentvolumeclaims_readonly | Gauge | `pod`=<pod-name> <br> `namespace`=<pod-namespace> <br> `volume`=<volume-name> <br> `persistentvolumeclaim`=<persistentvolumeclaim-claimname> | STABLE | | |||
| kube_pod_status_scheduled_time | Gauge | `pod`=<pod-name> <br> `namespace`=<pod-namespace> | STABLE | | |||
| kube_pod_annotations | Gauge | `annotation_POD_ANNOTATION`=<POD_ANNOTATION> <br> `pod`=<pod-name> <br> `namespace`=<pod-namespace> | STABLE | |
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.
this was deemed to be too high cardinality previously, it needs more discussion I'd say, let's not add this here
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.
Good. I deleted the metric for the pods
/retest |
@qw1mb0: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/assign @tariq1890 |
Can you rebase this PR? |
done |
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.
LGTM to me. I'll defer to @brancz for the final decision. Thanks for your contribution :)!
/lgtm
/approve
/hold
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qw1mb0, tariq1890 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
lgtm :) /hold cancel |
when will this become a stable version? |
@diemus Thanks for checking in! We will wait for a period of atleast Until then, please feel free to test this feature with the 1.7.0-rc1 build and let us know if you face issues :). |
Small correction: 7 days is the normal wait time to promote from release candidate to final release. |
Thanks @brancz ! I'll amend my previous comment. |
@tariq1890 @brancz should we add this info about the release process in the docs somewhere or do we have it already? |
it is not as far as I can tell, please feel free to add it to the RELEASE.md |
What this PR does / why we need it:
In this PR, a new metrics
kube_*_annotations
is added for all Kubernetes objects, in which will be a list of all the annotation of object. This functionality is very necessary for the ability to display data on the basis of annotations in grafana and the construction of the rules, alerts.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #746