[RAM] Add window maintenance column to rule logs and rule tables

[JiaweiWu]

Summary

Resolves: #153775

This PR adds the maintenance_window_id column to the following tables:

O11Y/Security solutions Alerts table

Rule details alerts table

Rule run event log

To test:

1. Set ENABLE_MAINTENANCE_WINDOWS to true in x-pack/plugins/alerting/public/plugin.ts
2. Create 1 or more active maintenance windows in stack management
3. Create a rule, trigger some alerts
4. Go to the rule details page alerts table, assert the maintenance window column is there, and renders the maintenance window ids
5. Go to the rule details page event log table, assert the maintenance window column can enabled, and renders the maintenance window ids
6. Create a O11Y rule, trigger some alerts
7. Go to the O11Y alerts table, assert that the maintenance_window_id field can be enabled, and renders the maintenance window ids

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[mdefazio]

Can we show the MW name rather than the ID? (And not in the square brackets)
Or I suppose a more reasonable question, is the user able to select maintenance_window_name rather than _id?

[XavierM]

Can we show the MW name rather than the ID? (And not in the square brackets) Or I suppose a more reasonable question, is the user able to select maintenance_window_name rather than _id?

we are going to have to keep the maintenance ids for 8.8, We need to keep the IDs and then we we will do like what we did for cases. Because, we will need to create a bulk_get API on the window maintenance and then we will be able to show the name of the window maintenance. For this feature, we took the same approach that we did for cases. At first, we only had the ids and then we work on showing the case name. We will have the same approach here and add this feature for 8.9.

[JiaweiWu]

@elasticmachine merge upstream

[elasticmachine]

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

[ymao1]

can you just add MAINTENANCE_WINDOW_IDS_FIELD to the other top_hits aggregation?

[ymao1]

This is not directly related to this PR but while testing a rule that has alerts generating actions during a maintenance window, I see this for the triggered/generated actions count:

In my head, I was expecting to see 2 triggered actions and 0 generated, to indicate that 2 actions would have been scheduled if not for the maintenance window. Is that not how it's supposed to work?

[ymao1]

Verified I see the maintenance window ids show up in the various tables. Left one comment about optimizing the exec log aggregation but otherwise LGTM

[XavierM]

This is not directly related to this PR but while testing a rule that has alerts generating actions during a maintenance window, I see this for the triggered/generated actions count:

In my head, I was expecting to see 2 triggered actions and 0 generated, to indicate that 2 actions would have been scheduled if not for the maintenance window. Is that not how it's supposed to work?

I agree with @ymao1 on this, it seems weird because it is not representing what we do behind the scene. Honesty/Transparency is always the right answer ;) (#Dad's internet answer)

[mikecote]

I agree with @ymao1 on this, it seems weird because it is not representing what we do behind the scene. Honesty/Transparency is always the right answer ;)

++ and we should double check that the same doesn't happen with snooze (separately or at the same time).

[XavierM]

@ymao1, @JiaweiWu, @mikecote and I have a discussion around generated/triggered actions count, at first we all thought that it will be nice to add this count but when we started to see all the overhead to add this metric. Also what will be the expectation of our user around this metric and it might be correct to have 0 on generated/triggered actions count because why even try to generate these action knowing that you won't trigger them.

The Decision is to move forward the way, it is and see if our assumption is correct!

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 8aa4784

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
alerting	582	584	+2
triggersActionsUi	511	512	+1
total			+3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
triggersActionsUi	1.4MB	1.4MB	+749.0B

Unknown metric groups

API count

id	before	after	diff
alerting	603	605	+2
triggersActionsUi	540	541	+1
total			+3

ESLint disabled line counts

id	before	after	diff
securitySolution	394	397	+3

Total ESLint disabled count

id	before	after	diff
securitySolution	474	477	+3

History

• 💚 Build #121767 succeeded 7194c2f
• 💔 Build #121766 failed 030509e
• 💔 Build #121650 failed e5bb0fd
• 💔 Build #121649 failed 4aba1b0
• 💔 Build #121368 failed 4fb2fa6

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream