-
Notifications
You must be signed in to change notification settings - Fork 90
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
handler: Expose nmstatectl stats as k8s metrics #1221
Conversation
6aede34
to
39570e3
Compare
@machadovilaca @avlitman please see if you can help in reviewing this PR. |
39570e3
to
568ea37
Compare
13c356a
to
00cc20b
Compare
@avlitman @machadovilaca @sradco can you take another look ? |
00cc20b
to
a301a86
Compare
for _, t := range stats.Topology { | ||
monitoring.ApplyTopologyTotal.WithLabelValues(t).Inc() | ||
} | ||
for _, f := range stats.Features { | ||
monitoring.ApplyFeaturesTotal.WithLabelValues(f).Inc() | ||
} |
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.
Per https://github.com/nmstate/kubernetes-nmstate/pull/1221/files#r1431131839, as I understand, I'm afraid this will have unbound cardinality as it will contain network state information like hostnames/interfaces/address/ports, is that correct?
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.
Per https://github.com/nmstate/kubernetes-nmstate/pull/1221/files#r1431131839, as I understand, I'm afraid this will have unbound cardinality as it will contain network state information like hostnames/interfaces/address/ports, is that correct?
The cardinality is not unbound, is not like we are going to count "mycluster1" and "eth1", the topology is a combination of enumerations (that's a little unbound but not that much) and the features is a list of enums too.
Can this be a problem ?
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.
Yes, labels need to have a limited values set. Except for specific labels like VM names, pod names, namespaces and other resources etc.
See note: https://prometheus.io/docs/practices/naming/#labels
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.
so this is an example of the nmstate stdats
topology:
- static_ip4,static_ip6 -> linux-bridge -> bond -> ethernet
- static_ip4,static_ip6 -> vlan -> linux-bridge -> bond -> ethernet
features:
- sriov
- mac-based-identifier
For "features" is clear that is limited on the enum variants, maybe the main problem would be "topology".
@sradco @machadovilaca do you know what kind of limits do we have for labels bound ?
I read the following at the docs
CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.
But I don't see specific limits, also topology is going to be smaller than something like generated ID or pod names.
@machadovilaca: changing LGTM is restricted to collaborators 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. |
@qinqon I propose you to also add docs generator for the operator. I think this is really useful. We have the automation, so that when the user adds a PR with a new metric, the test runs and checks if the metric is already documented. If not the user is asked to run make generate and this automatically updated the PR with the change to the metrics.md file with the new metric, description and type. See an example to the metrics.md file here |
/approve |
/retest |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qinqon 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 |
/retest |
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like. This change add a new "Features" under nnce Status with the output of `nmstatectl st` and also create a new deployment `nmstate-metrics` that will gather the NNCEs features and reflecta that at a cluster wide gaugue prometheus metric. [1] nmstate/nmstate#2420 Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Is this a BUG FIX or a FEATURE ?:
/kind enhancement
What this PR does / why we need it:
Now that nmstatectl is able to calculate some useful stats from network configuration [1], we can bubble them up and expose them as k8s metrics so k-nmstate users can digg on them using prometheus, graphana or the like.
This change add a new "Features" under nnce Status with the output of
nmstatectl st
and also create a new deploymentnmstate-metrics
thatwill gather the NNCEs features and reflecta that at a cluster wide
gaugue prometheus metric.
This is an example of nmstate feature stat
Depends on nmstate 2.2.20, looks like it's build but still not present at centos 9 stream
[1] nmstate/nmstate#2420
TODO:
Release note: