[Alerting Framework] Create a new rule count/summary endpoint

[jasonrhodes]

In #116476 we were discussing how to search for rules, and @ymao1 pointed us to the GET rule by ID or FIND rules endpoints. We're going to move forward with those but I thought it might be useful to have an endpoint that could make a more efficient ES query and just return the overall counts for some things, based on the same filter/query options available int he find rules endpoint.

For example:

• Total rules that match
  • Enabled/disabled
  • Muted/not muted
  • Count per execution status

The basic idea is just that we want this above information in as performant a way as can be managed, and right now we'll have to query the rules and loop over the results to count these. Thoughts?

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[ymao1]

Alerting rules client currently has an "aggregate" API that returns a count of rules by execution status. This was implemented before the saved objects client added aggregation support so what it really does is perform a find query for each execution status and reduce the results into a single result.

kibana/x-pack/plugins/alerting/server/rules_client/rules_client.ts

Lines 646 to 683 in 998a0db

	public async aggregate({
	options: { fields, ...options } = {},
	}: { options?: AggregateOptions } = {}): Promise<AggregateResult> {
	// Replace this when saved objects supports aggregations https://github.com/elastic/kibana/pull/64002
	const alertExecutionStatus = await Promise.all(
	AlertExecutionStatusValues.map(async (status: string) => {
	const { filter: authorizationFilter } = await this.authorization.getFindAuthorizationFilter(
	AlertingAuthorizationEntity.Rule,
	alertingAuthorizationFilterOpts
	);
	const filter = options.filter
	? `${options.filter} and alert.attributes.executionStatus.status:(${status})`
	: `alert.attributes.executionStatus.status:(${status})`;
	const { total } = await this.unsecuredSavedObjectsClient.find<RawAlert>({
	...options,
	filter:
	(authorizationFilter && filter
	? nodeBuilder.and([
	esKuery.fromKueryExpression(filter),
	authorizationFilter as KueryNode,
	])
	: authorizationFilter) ?? filter,
	page: 1,
	perPage: 0,
	type: 'alert',
	});
	return { [status]: total };
	})
	);
	return {
	alertExecutionStatus: alertExecutionStatus.reduce(
	(acc, curr: { [status: string]: number }) => Object.assign(acc, curr),
	{}
	),
	};
	}

The intent was always to replace this with a real aggregation once the saved objects client supported aggregations, which it now does: #96292, so it seems like it would make the most sense to update the find API to take aggregations as an input.

[gmmorris]

I think this got forgotten and should have been added to the R&AM project board for triage.
If I read this correctly - we want to extend the find api to support aggs.

cc @XavierM

[jasonrhodes]

@simianhacker if you want to confirm for @XavierM if this is still something we'd like to have, in case they want more specific requirements?

[kdelemme]

@XavierM Do you have plans for this?