Skip to content
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

Fix apiserver calculations not matching resource correctly #917

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jalev
Copy link

@jalev jalev commented Apr 26, 2024

The current behaviour of scope=~"resource|" does not match anything even if there is a resource label, and so will always return vector(0). This makes the calculations go into negative numbers which makes the availability numbers return a value >1 :

Screenshot 2024-04-26 at 16 20 13 Screenshot 2024-04-26 at 16 23 32

When you change the matcher to scope="resource" :

Screenshot 2024-04-26 at 16 21 23 Screenshot 2024-04-26 at 16 23 42

This is also true for other things with the scope=~"resource|". E.g. the error burndown:

Screenshot 2024-04-26 at 16 28 53

and after fixing the query:

Screenshot 2024-04-26 at 16 29 04

@jalev jalev changed the title Fix matcher for apiserver burn rate calculation not matching resource correctly Fix matcher for apiserver calculations not matching resource correctly Apr 26, 2024
@jalev jalev changed the title Fix matcher for apiserver calculations not matching resource correctly Fix apiserver calculations not matching resource correctly Apr 26, 2024
@lorenzofelletti
Copy link

Hi @jalev this is weird as in my case scope=~"resource|" matches exactly both when the scope label equals resource and when it is empty. I'm experiencing a greater than 100% availability sporadically too, though I've tracked it down to a difference between cluster_verb_scope_le:apiserver_request_sli_duration_seconds_bucket:increase30d{le="+Inf"} and cluster_verb_scope:apiserver_request_sli_duration_seconds_count:increase30d, while they should be equal (still I am not sure of the issue, but it might be related to this one here. Did you check this is not your case too?

@jalev
Copy link
Author

jalev commented Jul 1, 2024

I'll take a look and come back 👍

Copy link

github-actions bot commented Sep 4, 2024

This PR has been automatically marked as stale because it has not had any activity in the past 30 days.
The next time this stale check runs, the stale label will be removed if there is new activity. The issue will be closed in 7 days if there is no new activity.
Thank you for your contributions!

@github-actions github-actions bot added the stale label Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants