-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
4.17, 4.18, 4.19
-
None
-
False
-
This is a clone of issue OCPBUGS-49764. The following is the description of the original issue:
—
The problem that I recently noticed with the existing expression is that when we compute the overall burnrate from write and read requests, we take the ratio of successful read requests and we sum it to the one of write requests. But both of these ratios are calculated against their relevant request type, not the total number of requests. This is only correct when the proportion of write and read requests is equal.
For example, let's imagine a scenario where 40% of requests are write requests and their success during a disruption is only 50%. Whilst for read requests we have 90% of success.
apiserver_request:burnrate1h
{verb="write"}would be equal to 2/4 and apiserver_request:burnrate1h
{verb="read"} would be 1/6.
The sum of these as these by the alert today would be equal to 2/4+1/6=2/3 when in reality, the ratio of successful requests should be 2/10*1/10=3/10. So there is quite a huge difference today when we don't account for the total number of requests.
- clones
-
OCPBUGS-49764 KubeAPIErrorBudgetBurn calculation is erroneous
- ON_QA
- is blocked by
-
OCPBUGS-49764 KubeAPIErrorBudgetBurn calculation is erroneous
- ON_QA
- links to