[RAM] META MVP Snoozing API

[XavierM]

This Meta issue will describe what needs to be done on the API side to allow a MVP snoozing to be able to build the snoozing UI #124888.

• [RAM] Add new attribute snoozeEndTime to alert saved objects #125853

{
  "mappings": {
    "properties": {
      "snooze_end_time": {
        "type":   "date",
        "format": "strict_date_time_no_millis"
      }
    }
  }
}

• [RAM] Add telemetry around the use of the _mute_all API #126817
• [RAM] Create internal _snooze API #126818
• We need to update the /rules/_aggregate api to show new aggregation between mute_all and snooze_end_time. It will help this ticket -> [Actionable Observability] Change "mutted" to "snoozed" on for summary at on top of Alerts page. #126498
• Add new logic in the task manager to take care of the snooze logic (FYI @mikecote) -> [E&C] add snoozing MVP in alerting framework #126512
• Create a new entry in the event log to tell that the snooze was on and that’s why the system did not trigger any actions (FYI @mikecote) -> [E&C] add snoozing MVP in alerting framework #126512
• Add user facing docs for Snooze UX [R&AM] Add user facing docs for Snooze UX  #129915

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[Zacqary]

Create an internal _snooze API, maybe we can have a query params end_time: -1|ISO 8601. If end_time is set to -1, we know that our snooze is forever (set the mute_all to true), if not that’s when your snooze needs to end. ->

Not sure this is compatible with the snooze_end_time SavedObject type. Does strict_date_time_no_millis allow for the value to be -1?

[Zacqary]

Noticing there's a difference between muteAll and muteInstance in the Rules Client. Do we want to differentiate between snoozeAll versus snoozeInstance?

[XavierM]

"format": "strict_date_time_no_millis"

the muteInstance is all about the alert instance like we want to mute this alert if it show up again. For MVP, we can ignore it .

[XavierM]

Create an internal _snooze API, maybe we can have a query params end_time: -1|ISO 8601. If end_time is set to -1, we know that our snooze is forever (set the mute_all to true), if not that’s when your snooze needs to end. ->

Not sure this is compatible with the snooze_end_time SavedObject type. Does strict_date_time_no_millis allow for the value to be -1?

This was just a suggestion on the API level but not for the SO. I was thinking that if we see snooze_end_time: -1 then we will set true to the mute_all attribute and snooze_end_time will be null.

[gmmorris]

Create an internal _snooze API, maybe we can have a query params end_time: -1|ISO 8601. If end_time is set to -1, we know that our snooze is forever (set the mute_all to true), if not that’s when your snooze needs to end. ->

Not sure this is compatible with the snooze_end_time SavedObject type. Does strict_date_time_no_millis allow for the value to be -1?

This was just a suggestion on the API level but not for the SO. I was thinking that if we see snooze_end_time: -1 then we will set true to the mute_all attribute and snooze_end_time will be null.

Is there a reason to use -1 on the API rather than just omit the value in the API as well?
IMHO it will make maintenance easier if both the HTTP API and RulesClient API use the same semantics.

[XavierM]

Create an internal _snooze API, maybe we can have a query params end_time: -1|ISO 8601. If end_time is set to -1, we know that our snooze is forever (set the mute_all to true), if not that’s when your snooze needs to end. ->

Not sure this is compatible with the snooze_end_time SavedObject type. Does strict_date_time_no_millis allow for the value to be -1?

This was just a suggestion on the API level but not for the SO. I was thinking that if we see snooze_end_time: -1 then we will set true to the mute_all attribute and snooze_end_time will be null.

Is there a reason to use -1 on the API rather than just omit the value in the API as well? IMHO it will make maintenance easier if both the HTTP API and RulesClient API use the same semantics.

I will disagree, I think it is better that the user is setting snooze_end_time attribute to -1 than just omitting it and getting a side effect of the API. I feel that can just be a mistake from our user it allow us a better validation on the snooze_end_time.

[chrisronline]

Is it possible for the user to set mute_all from the API too? Why do we need to add complexity around what the attributes will change in the SO?

[gmmorris]

I will disagree, I think it is better that the user is setting snooze_end_time attribute to -1 than just omitting it and getting a side effect of the API.

Yeah, that's fair, and If the rest of the team feels comfortable with -1 I can live with it.
That said, it feels like -1 is also a sort of side effect as "negative time means forever" is not exactly intuitive to me.

I see where @chrisronline is coming from here... if the user wants to "snooze forever", why not just mute the rule? 🤔

[chrisronline]

After talking to @XavierM, my understanding is that we intend to deprecate the the mute functionality (or maybe at least the mute_all) and replace it with snoozing. Is that still the plan?

[XavierM]

After talking to @XavierM, my understanding is that we intend to deprecate the the mute functionality (or maybe at least the mute_all) and replace it with snoozing. Is that still the plan?

That's my assumption to avoid weird side effect between our _snooze and mute_all but first we need to get our _snooze API public and then we will be bale to deprecate mute_all.

[gmmorris]

Added an issue to add docs for Snooze UX (thanks @Zacqary !) as we forgot 😬