Ability run an alert immediately

[mikecote]

Depends on #50214.

Maybe create an execute API similar to actions.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[pmuellr]

Not sure we even need to use TM to do this - we could in theory just run the code in the Kibana process that requested it be run. I think that's what action execution via http request does. We should probably be consistent between these two, in any case.

[mikecote]

The only challenge doing that with the current structure may be the alert / alert instance state that is stored in the task manager. They wouldn't have access to it. Though there may be plans to move some of it outside of TM.

[gmmorris]

Is the thinking that this would basically be like scheduling with a runAt of Date.now()?
Because it would be simple enough to do and would mean that, no matter what, the way in which actions are executed is the same in all cases, which reduces the chance of variance in behavior.... I wouldn't expect there to be a difference, but just in case 🤷‍♀️

[pmuellr]

Ya, we need to think through this - I think this would be very similar to the "test" scenario as well, so may come with caveats like "you have no state". A different thing we could do would be to change the runAt as Gidi notes, which presumably WOULD give you state. And if we change the runAt, then the subsequent intervals would be relative to that new runAt - might be what the user wants, or not ...

[peterschretlen]

In addition the 'now' case, the ability to run the alert at some time in the past for testing purposes has been requested:

...were looking for a way to test the actual alert against their historic data set to see what they'd get back. We've talked about testing alerts, but more in the context of the connection. This would be pretty valuable, particularly for user defined alerts.

So if we could run the alert 'now' but also pass a timestamp parameter, and the alert condition is checked relative to that time.

[peterschretlen]

Somewhat related to #49411

[tsullivan]

we could in theory just run the code in the Kibana process that requested it be run

Note this solution would have a gotcha: these kind of tasks would not be able to benefit from the distributed nature of multiple instances working the same task queue.

I think that gotcha gets a bit nasty when Kibana administrators would want to make finegrain controls and have "lightweight" instances that serve a UI to multiple users, and can ONLY schedule tasks (not claim them), and "heavyweight" instances that are configured only for claiming tasks and not serving UI to end-users.

I don't know if it's possible today with Task Manager to configure multiple instances for dedicated roles in tasks - but it would be a reasonable enhancement for tackling scaling a Kibana deployment.

[mikecote]

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

[ymao1]

Closing as task manager has a run now API that can be used for this.

[peluja1012]

Hi @ymao1, we are revisiting adding a "run now" functionality in Security Solution. Do you know if the alerting framework exposes this capability via the Alerting client?

[ymao1]

@peluja1012 The alerting rules client calls the task manager runNow function during rule updates (but it looks like only if the schedule interval changes) but does not expose any wrapper around it.

We could reopen this issue and update the description to add a wrapper around the task manager runNow in the alerting rules client. Alternatively, it looks like taskManager is already a required plugin for security solutions so the security solutions plugin could directly call runNow, which just takes the scheduledTaskId as an argument. Here is where it is used in the rules client:

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

Lines 938 to 949 in 0aee982

	this.taskManager
	.runNow(updateResult.scheduledTaskId)
	.then(() => {
	this.logger.debug(
	`Alert update has rescheduled the underlying task: ${updateResult.scheduledTaskId}`
	);
	})
	.catch((err: Error) => {
	this.logger.error(
	`Alert update failed to run its underlying task. TaskManager runNow failed with Error: ${err.message}`
	);
	});

[peluja1012]

Thanks, @ymao1! We'll review our use case in more detail and let you know if calling the taskManager's runNow directly would be sufficient.

[mikecote]

From #134400.

Describe the feature:
It would be fantastic to have a button on the Rule and Connectors UI ("Rules" tab) that allows running a rule add hoc.

Describe a specific use case for the feature:
A user has a Rule that is active, they make a change to the Rule that should cause it to no longer be active, but the Rule doesn't run again for several hours. Unless they modify the frequency, test it, then set the frequency back to what it was, they have to remember to come back to the Rule once it naturally runs again to make sure it is no longer active. If there was some sort of a "run now" button, it would allow much faster ad hoc testing/running of a Rule.

This could also be useful if a Rule runs infrequently, and was Active last time it ran, but before the user investigates further they want to run it ad hoc to verify if it is still active.

[mikecote]

This feature should leverage the new task manager's runSoon API that will allow any Kibana from picking up this task. The run soon API sets new Date() as the next runAt which will work for this use case. We should lookout for rule types using the rule's interval value in case running a rule more frequently may behave differently. (we should also look into discouraging the use of interval..)

[mikecote]

Linking with #138124. If the framework can run a rule to run ad-hoc anytime, the framework should also be able to auto retry when encountering a socket hangup error (or other retry-able errors).