[8.16] Manual rule run docs (#5631)

* First draft * Removing ESS text changes * just kidding - wrong branch stash * Fixed typo * Limitations and new field * Removing content * Fix table * Updates note * Update docs/detections/rules-ui-manage.asciidoc * Update docs/detections/rules-ui-manage.asciidoc * Update docs/detections/rules-ui-manage.asciidoc * Update docs/detections/rules-ui-monitor.asciidoc * Update docs/detections/rules-ui-monitor.asciidoc * Update docs/reference/alert-schema.asciidoc * Fixed path * Editorial feedback * Removes unecessary term (cherry picked from commit 64d64d7)
elastic · Oct 16, 2024 · e1a7807 · e1a7807
1 parent 66b23df
commit e1a7807
Show file tree

Hide file tree

Showing 6 changed files with 94 additions and 5 deletions.
diff --git a/docs/detections/api/rules/rules-api-bulk-actions.asciidoc b/docs/detections/api/rules/rules-api-bulk-actions.asciidoc
@@ -283,14 +283,24 @@ to apply.
 * `duplicate`
 * `export`
 * `edit`
+* `run`
 
 | Yes
+
+| `run` | <<bulk-manual-rule-run, BulkManualRuleRun[]>>
+| Object that describes applying a manual rule run action.
+|No.
+
+Yes, if action is `run`.
+
 | `edit` | <<bulk-edit-object-schema, BulkEditAction[]>>
 | Edit object that describes applying an update action.
 
 |No.
 
 Yes, if action is `edit`.
+
+
 | `duplicate` | <<bulk-duplicate-object-schema, BulkDuplicateAction[]>>
 | Duplicate object that describes applying an update action.
 
@@ -308,6 +318,13 @@ To enable dry run mode on a request, add the query parameter `dry_run=true` to t
 
 IMPORTANT: Dry run mode is not supported for the `export` bulk action. A `400` error will be returned in the request response.
 
+[[bulk-manual-rule-run]]
+[discrete]
+==== BulkManualRuleRun object
+
+* `start_date` field: (String, Required) Defines the start date of the manual run.
+* `end_date` field: (String, Optional) Defines the end date of the manual run.
+
 [[bulk-duplicate-object-schema]]
 [discrete]
 ==== BulkDuplicateAction object
@@ -519,14 +536,14 @@ POST api/detection_engine/rules/_bulk_action
 [discrete]
 ===== Response payload
 
-For `enable`, `disable`, `delete`, `edit`, and `duplicate` actions, a JSON object containing the action's outcome:
+For `enable`, `disable`, `delete`, `edit`, `duplicate`, and `run` actions, a JSON object containing the action's outcome:
 
 - `attributes.summary.total`: Total number of rules matching the bulk action
 - `attributes.summary.succeeded`: Number of successful outcomes (number of rules that were enabled, deleted, or updated)
 - `attributes.summary.failed`: Number of failed outcomes
 - `attributes.summary.skipped`: Number of rules that were skipped due to various reasons (explained below)
 - `attributes.results.created`: Rule objects that were created during the action's execution
-- `attributes.results.updated`: Rule objects that were updated during the action's execution
+- `attributes.results.updated`: Rule objects that were updated during the action's execution. If the action execution is `run`, it returns rule objects that were scheduled for manual runs.
 - `attributes.results.deleted`: Rule objects that were deleted during the action's execution
 - `attributes.results.skipped`: Rules that were skipped during the action's execution
 

diff --git a/docs/detections/images/manual-rule-run-table.png b/docs/detections/images/manual-rule-run-table.png
diff --git a/docs/detections/images/rule-execution-logs.png b/docs/detections/images/rule-execution-logs.png
diff --git a/docs/detections/rules-ui-manage.asciidoc b/docs/detections/rules-ui-manage.asciidoc
@@ -17,6 +17,7 @@ On the Rules page, you can:
 * <<rule-status>>
 * <<edit-rules-settings>>
 * <<manage-rules-ui>>
+* <<manually-run-rules>>
 * <<snooze-rule-actions>>
 * <<import-export-rules-ui>>
 * <<rule-prerequisites>>
@@ -104,6 +105,34 @@ NOTE: When duplicating a rule with exceptions, you can choose to duplicate the r
 * To enable or disable a single rule, switch on the rule's *Enabled* toggle.
 * To <<snooze-rule-actions,snooze>> actions for rules, click the bell icon.
 
+[float]
+[[manually-run-rules]]
+=== Run rules manually
+
+beta::[]
+
+Manually run enabled rules for a specified period of time for testing purposes or additional rule coverage. 
+
+IMPORTANT: Before manually running rules, make sure you properly understand and plan for rule dependencies. Incorrect scheduling can lead to inconsistent rule results.
+
+1. Navigate to the detection rules page, and do one of the following:
+* Select the **All actions** menu (**...**) on a rule, then select **Manual run**.
+* Select all the rules you want to manually run, select the **Bulk actions** menu, then select **Manual run**.
+. Specify when the manual run starts and ends. The default selection is the current day starting three hours in the past. The rule will search for events during the selected time range.
+. Click **Run** to manually run the rule.
++
+NOTE: Manual runs can produce multiple rule executions. This is determined by the manual run's time range and the rule's execution schedule.
+
+The manual run's details are shown in the <<manual-runs-table,Manual runs>> table on the *Execution results* tab. Changes you make to the manual run or rule settings will display in the Manual runs table after the current run completes.
+
+[NOTE] 
+=====
+Be mindful of the following:
+* Rule actions are not activated during manual runs. 
+* Except for threshold rules, duplicate alerts aren't created if you manually run a rule during a time range that was already covered by a scheduled run.
+* Manual runs are executed with low priority and limited concurrency, meaning they might take longer to complete. This can be especially apparent for rules requiring multiple executions.
+=====
+
 [float]
 [[snooze-rule-actions]]
 === Snooze rule actions

diff --git a/docs/detections/rules-ui-monitor.asciidoc b/docs/detections/rules-ui-monitor.asciidoc
@@ -37,28 +37,62 @@ For detailed information on a rule, the alerts it generated, and associated erro
 [[rule-execution-logs]]
 === Execution results
 
-Each detection rule execution is logged, including its success or failure, any warning or error messages, and how long it took to search for data, create alerts, and complete. This can help you troubleshoot a particular rule if it isn't behaving as expected (for example, if it isn't creating alerts or takes a long time to run).
+Each detection rule execution is logged, including the execution type, the execution's success or failure, any warning or error messages, how long it took to search for data, create alerts, and complete. This can help you troubleshoot a particular rule if it isn't behaving as expected (for example, if it isn't creating alerts or takes a long time to run).
 
-To access a rule's execution log, go to *Rules* -> *Detection rules (SIEM)*, click the rule's name to open its details, then scroll down and select the *Execution results* tab. You can expand a long warning or error message by clicking the arrow at the end of a row.
+To access a rule's execution log, go to **Rules** → **Detection rules (SIEM)**, click the rule's name to open its details, then scroll down and select the **Execution results** tab. Within the Execution log table, you can click the arrow at the end of a row to expand a long warning or error message.
 
 [role="screenshot"]
-image::images/rule-execution-logs.png[Rule execution results tab]
+image::images/rule-execution-logs.png[Execution log table on the rule execution results tab]
 
 You can hover over each column heading to display a tooltip about that column's data. Click a column heading to sort the table by that column.
 
 Use these controls to filter what's included in the logs table:
 
+* The **Run type** drop-down filters the table by rule execution type: 
+** **Scheduled**: Automatic, scheduled rule executions.
+** **Manual**: Rule executions that were <<manually-run-rules,started manually>>.
+
 * The *Status* drop-down filters the table by rule execution status: 
 ** *Succeeded*: The rule completed its defined search. This doesn't necessarily mean it generated an alert, just that it ran without error.
 ** *Failed*: The rule encountered an error that prevented it from running. For example, a {ml} rule whose corresponding {ml} job wasn't running.
 ** *Warning*: Nothing prevented the rule from running, but it might have returned unexpected results. For example, a custom query rule tried to search an index pattern that couldn't be found in {es}.
 
 * The date and time picker sets the time range of rule executions included in the table. This is separate from the global date and time picker at the top of the rule details page.
 
+* The **Source event time range** button toggles the display of data pertaining to the time range of manual runs.
+
 * The *Show metrics columns* toggle includes more or less data in the table, pertaining to the timing of each rule execution.
 
 * The *Actions* column allows you to show alerts generated from a given rule execution. Click the filter icon (image:images/filter-icon.png[Filter icon,18,17]) to create a global search filter based on the rule execution's ID value. This replaces any previously applied filters, changes the global date and time range to 24 hours before and after the rule execution, and displays a confirmation notification. You can revert this action by clicking *Restore previous filters* in the notification.
 
+[float]
+[[manual-runs-table]]
+==== Manual runs table
+
+beta::[]
+
+Each manual run can produce multiple rule executions, depending on the time range of the run and the rule's execution schedule. These details are shown in the Manual runs table.
+
+To access the table, navigate to the detection rules page, click the rule's name to open its details, then scroll down and select the **Execution results** tab. Scroll down again to find the Manual runs table. 
+
+To stop an active run, go to the appropriate row and click **Stop run** in the **Actions** column. Completed rule executions for each manual run are logged in the Execution log table.
+
+[role="screenshot"]
+image::images/manual-rule-run-table.png[Manual rule runs table on the rule execution results tab]
+
+The Manual runs table displays important details such as:
+
+* The status of each manual run:
+** **Pending**: The rule is not yet running. 
+** **Running**: The rule is executing during the time range you specified. Some rules, such as indicator match rules, can take longer to run.
+** **Error**: The rule's configuration is preventing it from running correctly. For example, the rule's conditions cannot be validated.
+
+* When a manual run started and the time in which it will run
+
+* The number of rule executions that are failing, pending, running, and completed for a manual run
+
+* The total number of rule executions that are occurring for a manual run
+
 [float]
 [[troubleshoot-signals]]
 === Troubleshoot missing alerts

diff --git a/docs/reference/alert-schema.asciidoc b/docs/reference/alert-schema.asciidoc
@@ -191,4 +191,13 @@ UIDs are linked to user profiles that are automatically created when users first
 
 Type: string[] 
 
+|N/A | `kibana.alert.intended_timestamp` a| 
+
+Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run:
+
+* **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `kibana.alert.rule.execution.timestamp` field, which shows when the rule was executed.
+* **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range.
+
+Type: date
+
 |==============================================