You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During scalability testing efforts leading crossplane-contrib/provider-kubernetes#203, I noticed that the controller runtime metrics like workqueue_depth and workqueue_queue_duration_seconds are not accurate or not reflecting the state of the system as expected.
See the workqueue depth and duration graphs for "1m, 10" here.
Ah - maybe rate limiters calling AddAfter (as in "add to queue after some duration") means reconciles are spending time in limbo. They're not yet being processed, but also not yet even in the work queue?
What happened?
During scalability testing efforts leading crossplane-contrib/provider-kubernetes#203, I noticed that the controller runtime metrics like
workqueue_depth
andworkqueue_queue_duration_seconds
are not accurate or not reflecting the state of the system as expected.See the workqueue depth and duration graphs for "1m, 10" here.
How can we reproduce it?
Checkout https://github.com/turkenh/provider-kubernetes-scalability/tree/repro-xp-no-metric
What environment did it happen in?
Crossplane version: v1.14.5
Provider Kubernetes: v0.11.4
The text was updated successfully, but these errors were encountered: