CPU Usage alert condition page is blank

[P1llus]

On the newest 7.9 stable release on ESS, when going to the Stack Management page, Alerts, Create Alert and choose CPU usage from the list of trigger types, the result is blank:

Page:

Blank:

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[elasticmachine]

Pinging @elastic/stack-monitoring (Team:Monitoring)

[Zacqary]

Need someone from the Stack Monitoring team to weigh in to confirm, but I believe the CPU Usage alert is part of the "out of the box alerting" feature for Stack Monitoring (#68805). It's an internal alert type that's only supposed to be created automatically when you set up Stack Monitoring, not user-facing. So @P1llus I think you might be looking for the Inventory alert type if you'd like to manually set up an alert on your infrastructure's CPU usage, or possibly Metric Threshold for some more advanced configuration.

So as far as I can tell I think the bug here is that the alert types

• CPU Usage
• License expiration
• Cluster health
• Nodes changed
• Elasticsearch version mismatch
• Kibana version mismatch
• Logstash version mismatch

shouldn't be showing up in this list at all.

[chrisronline]

I didn't realize this page existed, but @Zacqary is right - these are not viable "types" that can be created.

cc @elastic/kibana-alerting-services for help on how to ensure these do not show up in this list.

[mikecote]

@chrisronline this seems like a new use case where we don't want to allow users to create these types of alerts from the management page. I'll need to read more / get more clarity on the use case so we come up with a proper solution, probably worth a new issue since we don't have a way to do this at this time?

In the meantime, as a workaround, you can requiresAppContext: true and it will remove create / edit capabilities in the alerts management page.

[chrisronline]

@mikecote The edit functionality works as expected (and I think that makes sense to still maintain) but we just want to prohibit creation of that type. Is that what you were thinking too?

[mikecote]

@chrisronline

but we just want to prohibit creation of that type. Is that what you were thinking too?

Ah, no didn't think of it like that. So that would be something like a singleton alert where only one per alert type can exist?

Are these eventually moving to preconfigured alerts? and then it wouldn't be possible to create them in the UI? (just gathering the expected behaviour for your use case)

[chrisronline]

@mikecote Yup exactly. We do want to transition these to preconfigured alerts, as soon as that is supported on the alerting side. It shouldn't be possible to manually create these, as they should be enabled (by default) for all.

[mikecote]

I had a chat with @chrisronline offline (🤔) about this and agreed to go with the workaround proposed here in the meantime.

It will remove edit capabilities but at least create capabilities will be removed until the pre-configured alerts feature is developed.

In the meantime, as a workaround, you can requiresAppContext: true and it will remove create / edit capabilities in the alerts management page.