policy: add metric on selector cache cardinality and performance#42872
policy: add metric on selector cache cardinality and performance#42872aanm merged 1 commit intocilium:mainfrom
Conversation
|
Added some more metrics now; They are a bit duplicative, so It would probably be better to get them into two. I'm also not sure we really need a histogram here, and maybe a summary (_sum + _count) could work equally good? Its also hard to measure the time it takes for selector upserts and removals, since the I think we can mesure the time it takes inside of What do you think @christarazi ? |
Okay, so I think ^ is a decent middleground. That only counts the |
a6e358c to
120eaed
Compare
|
/test |
|
/ci-integration |
|
This looks great to me @odinuge! |
120eaed to
e2574df
Compare
This adds a new set of metrics for the selector cache. Both in terms of cardinality, but also around the performance of various operations. Contention in the selector cache can easily make regenerations slower, and potentially grind the whole agent to a halt in special cases. This allows us to use these metrics to better observe the performance of these operations. Signed-off-by: Odin Ugedal <[email protected]> Signed-off-by: Odin Ugedal <[email protected]>
e2574df to
224438e
Compare
|
/test |
This adds a new set of metrics for the selector cache. Both in terms of cardinality, but also around the performance of various operations.
Mostly opening now so we can start discussing performance around #42008. The same applies to #42580, so that we can add a separate
type="subject"value.I'm don't think we need a histogram here, and that a summary (_count + _sum) is sufficient, but can't see that used elsewhere.