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 Prometheus metrics to count ANP and ACNP Status updates #1801
Add Prometheus metrics to count ANP and ACNP Status updates #1801
Conversation
Too frequent Status updates could generate too many versions of the CRD, that would need to be stored in etcd until the next compaction by kube-apiserver. Too many updates could also cause fragmentation of the database. It is useful to have access to the number of updates over time in production clusters.
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.
I am ok with the change. Feel people might not understand what such metrics are for, but probably no harm either.
does update to the Status sub-resource generate a new version? i thought the generation count remained same. |
I believe ResourceVersion is incremented and there is definitely a write to etcd, but we can wait for @tnqn to confirm and comment on the usefulness of this PR |
Yes, generation is different from resourceVersion. Any update to any field will lead to a new version and a write to etcd. Although the original issue is not caused by status update, this metrics can help rule it out quickly and generally help us understand the overhead of status manager so I'm good to add 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.
LGTM
Thanks for the feedback @tnqn |
/test-all |
Codecov Report
@@ Coverage Diff @@
## main #1801 +/- ##
=======================================
Coverage ? 26.49%
=======================================
Files ? 179
Lines ? 15169
Branches ? 0
=======================================
Hits ? 4019
Misses ? 10625
Partials ? 525
Flags with carried forward coverage won't be shown. Click here to find out more. |
Too frequent Status updates could generate too many versions of the CRD,
that would need to be stored in etcd until the next compaction by
kube-apiserver. Too many updates could also cause fragmentation of the
database. It is useful to have access to the number of updates over time
in production clusters.