Onboard "SLO burn rate" rule type with FAAD #178922
Conversation
ersin-erdal
added
release_note:skip
ersin-erdal
force-pushed
the
169867-slo-burn-rate-faad
branch
from
9a57685 to
a241edc
Compare
|
/ci |
# Conflicts: # x-pack/plugins/observability_solution/observability/server/lib/rules/register_rule_types.ts # x-pack/plugins/observability_solution/slo/server/lib/rules/slo_burn_rate/executor.ts
|
/ci |
|
Pinging @elastic/response-ops (Team:ResponseOps) |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]History
To update your PR or re-run it, just comment with: cc @ersin-erdal |
| @@ -256,7 +238,8 @@ describe('BurnRateRuleExecutor', () => { | |||
| getTimeRange, | |||
| }); | |||
|
|
|||
| expect(alertWithLifecycleMock).not.toBeCalled(); | |||
| expect(servicesMock.alertsClient?.report).not.toBeCalled(); | |||
There was a problem hiding this comment.
Out of curiosity, what is the difference between servicesMock.alertsClient! and servicesMock.alertsClient?? Is there any difference in this case?
There was a problem hiding this comment.
No difference indeed, alertsClient! could be used everywhere as we are sure that it exists.
| fields: { | ||
| actionGroup: windowDef.actionGroup, | ||
| state: { | ||
| alertState: AlertStates.ALERT, |
There was a problem hiding this comment.
Is this instead of alert.replaceState({ alertState: AlertStates.ALERT });? What was the reason to have replaceState previously?
There was a problem hiding this comment.
We had different methods to set different fields in the alert such as state and context, but realised that they have never been used separately, so combined them in .report
Towards: #169867
This PR onboards "SLO burn rate" rule type with FAAD.
To verify
Create an SLO by using a test index (create a dataview for it), use very low
budget consumed %The rule bound to the SLO should create an alert and save it under
.internal.alerts-observability.slo.alerts-default-000001