Merge branch 'main' into elastic#79656

.github/CODEOWNERS

@@ -194,6 +194,7 @@ x-pack/examples/files_example @elastic/kibana-app-services
 
 # Machine Learning
 /x-pack/plugins/ml/  @elastic/ml-ui
+/x-pack/plugins/ml/common/openapi/ @elastic/mlr-docs
 /x-pack/test/accessibility/apps/ml.ts  @elastic/ml-ui
 /x-pack/test/accessibility/apps/ml_embeddables_in_dashboard.ts  @elastic/ml-ui
 /x-pack/test/api_integration/apis/ml/ @elastic/ml-ui

docs/management/advanced-options.asciidoc

@@ -548,6 +548,10 @@ Disable this option if you prefer to use the new heatmap charts with improved pe
 Enables users to create, view, and edit experimental visualizations. When disabled,
 only production-ready visualizations are available to users.
 
+[[lens-sampling]]`lens:useFieldExistenceSampling`::
+**This setting is deprecated and will not be supported as of 8.6.**
+If enabled, document sampling is used to determine field existence (available or empty) for the Lens field list instead of relying on index mappings.
+
 [float]
 [[kibana-telemetry-settings]]
 ==== Usage Data

docs/user/alerting/alerting-getting-started.asciidoc

@@ -1,17 +1,15 @@
-[role="xpack"]
 [[alerting-getting-started]]
 = Alerting
 
-
 --
 
 Alerting allows you to define *rules* to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, connectors>> and <<stack-rules, rules>> (known as stack rules) for you to use.
 
-image::images/alerting-overview.png[Rules and Connectors UI]
+image::images/alerting-overview.png[{rules-ui} UI]
 
 [IMPORTANT]
 ==============================================
-To make sure you can access alerting and actions, see the <<alerting-prerequisites, setup and pre-requisites>> section.
+To make sure you can access alerting and actions, see the <<alerting-prerequisites, setup and prerequisites>> section.
 ==============================================
 
 [float]
@@ -24,7 +22,7 @@ This section describes all of these elements and how they operate together.
 [float]
 === Rules
 
-A rule specifies a background task that runs on the {kib} server to check for specific conditions. {kib} provides two types of rules: stack rules that are built into {kib} and the rules that are registered by Kibana apps. Refer to <<rule-types,Rule types>> for more information.
+A rule specifies a background task that runs on the {kib} server to check for specific conditions. {kib} provides two types of rules: stack rules that are built into {kib} and the rules that are registered by {kib} apps. Refer to <<rule-types,Rule types>> for more information.
 
 A rule consists of three main parts: 
 
@@ -46,7 +44,7 @@ The following sections describe each part of the rule in more detail.
 [[alerting-concepts-conditions]]
 ==== Conditions
 
-Under the hood, {kib} rules detect conditions by running a Javascript function on the {kib} server, which gives it the flexibility to support a wide range of conditions, anything from the results of a simple {es} query to heavy computations involving data from multiple sources or external systems. 
+Under the hood, {kib} rules detect conditions by running a JavaScript function on the {kib} server, which gives it the flexibility to support a wide range of conditions, anything from the results of a simple {es} query to heavy computations involving data from multiple sources or external systems. 
 
 These conditions are packaged and exposed as *rule types*. A rule type hides the underlying details of the condition, and exposes a set of parameters
 to control the details of the conditions to detect.
@@ -123,9 +121,9 @@ image::images/rule-concepts-summary.svg[Rules, connectors, alerts and actions wo
 
 [float]
 [[alerting-concepts-differences]]
-== Differences from Watcher
+== Differences from {watcher}
 
-Alerting and <<watcher-ui,Watcher>> are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.
+Alerting and <<watcher-ui,{watcher}>> are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.
 
 This section will clarify some of the important differences in the function and intent of the two systems.
 
@@ -137,6 +135,6 @@ Functionally, Alerting differs in that:
 * Actions are linked to *alerts* in Alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire rule.
 
 At a higher level, Alerting allows rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
-Pre-packaged *rule types* simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across {kib}.
+Prepackaged *rule types* simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across {kib}.
 
 --

docs/user/alerting/alerting-setup.asciidoc

@@ -11,15 +11,15 @@ configuration.
 [float]
 [[alerting-prerequisites]]
 === Prerequisites
-If you are using an *on-premises* Elastic Stack deployment:
+If you are using an *on-premises* {stack} deployment:
 
 * In the `kibana.yml` configuration file, add the 
 <<general-alert-action-settings,`xpack.encryptedSavedObjects.encryptionKey`>> 
 setting.
 * For emails to have a footer with a link back to {kib}, set the 
 <<server-publicBaseUrl, `server.publicBaseUrl`>> configuration setting.
 
-If you are using an *on-premises* Elastic Stack deployment with 
+If you are using an *on-premises* {stack} deployment with 
 <<using-kibana-with-security, *security*>>:
 
 * If you are unable to access {kib} {alert-features}, ensure that you have not 

docs/user/alerting/alerting-troubleshooting.asciidoc

@@ -31,7 +31,7 @@ and Task Manager <<task-manager-diagnosing-root-cause,diagnostics endpoints>>.
 [float]
 [[alerting-managment-detail]]
 === Using rules and connectors list for the current state and finding issues
-*Rules and Connectors* in *Stack Management* lists the rules and connectors available in the space you’re currently in. When you click a rule name, you are navigated to the <<rule-details,details page>> for the rule, where you can see currently active alerts. 
+*{rules-ui}* in *{stack-manage-app}* lists the rules and connectors available in the space you're currently in. When you click a rule name, you are navigated to the <<rule-details,details page>> for the rule, where you can see currently active alerts. 
 The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active.
 [role="screenshot"]
 image::images/rule-details-alerts-inactive.png[Alerting management details]
@@ -44,15 +44,17 @@ When creating or editing an index threshold rule, you see a graph of the data th
 [role="screenshot"]
 image::images/index-threshold-chart.png[Index Threshold chart]
 
-The end date is related to the rule interval (IIRC, 30 “intervals” worth of time). You can use this view to see if the rule is getting the data you expect, and visually compare to the threshold value (a horizontal line in the graph). If the graph does not contain any lines except for the threshold line, then the rule has an issue, for example, no data is available given the specified index and fields or there is a permission error.
+The end date is related to the rule interval.
+//(IIRC, 30 “intervals” worth of time)
+You can use this view to see if the rule is getting the data you expect, and visually compare to the threshold value (a horizontal line in the graph). If the graph does not contain any lines except for the threshold line, then the rule has an issue, for example, no data is available given the specified index and fields or there is a permission error.
 Diagnosing these may be difficult - but there may be log messages for error conditions. 
 
 [float]
 [[alerting-rest-api]]
 === Use the REST APIs
 
 There is a rich set of HTTP endpoints to introspect and manage rules and connectors.
-One of the http endpoints available for actions is the POST <<execute-connector-api,_execute API>>. You can use this to “test” an action.  For instance, if you have a server log action created, you can run it via curling the endpoint:
+One of the HTTP endpoints available for actions is the POST <<execute-connector-api,_execute API>>. You can use this to “test” an action.  For instance, if you have a server log action created, you can run it via curling the endpoint:
 [source, txt]
 --------------------------------------------------
 curl -X POST -k \
@@ -62,7 +64,7 @@ curl -X POST -k \
  -d '{"params":{"subject":"hallo","message":"hallo!","to":["[email protected]"]}}'
 --------------------------------------------------
 
-experimental[] In addition, there is a command-line client that uses legacy Rules and Connectors APIs, which can be easier to use, but must be updated for the new APIs.
+experimental[] In addition, there is a command-line client that uses legacy {rules-ui} APIs, which can be easier to use, but must be updated for the new APIs.
 CLI tools to list, create, edit, and delete alerts (rules) and actions (connectors) are available in https://github.com/pmuellr/kbn-action[kbn-action], which you can install as follows:
 [source, txt]
 --------------------------------------------------
@@ -75,7 +77,7 @@ The same REST POST _execute API command will be:
 kbn-action execute a692dc89-15b9-4a3c-9e47-9fb6872e49ce ‘{"params":{"subject":"hallo","message":"hallo!","to":["[email protected]"]}}’
 --------------------------------------------------
 
-The result of this http request (and printed to stdout by https://github.com/pmuellr/kbn-action[kbn-action]) will be data returned by the action, along with error messages if errors were encountered.
+The result of this HTTP request (and printed to stdout by https://github.com/pmuellr/kbn-action[kbn-action]) will be data returned by the action, along with error messages if errors were encountered.
 
 [float]
 [[alerting-error-banners]]

docs/user/alerting/create-and-manage-rules.asciidoc

@@ -10,7 +10,7 @@ central place to:
 
 * <<create-edit-rules,Create and edit>> rules
 * <<controlling-rules,Manage rules>> including enabling/disabling, muting/unmuting, and deleting
-* Drill-down to <<rule-details,rule details>>
+* Drill down to <<rule-details,rule details>>
 
 [role="screenshot"]
 image:images/rules-and-connectors-ui.png[Example rule listing in {rules-ui}]
@@ -99,7 +99,7 @@ image::images/rule-flyout-general-details.png[alt='All rules have name, tags, ch
 [[defining-rules-type-conditions]]
 ==== Rule type and conditions
 
-Depending upon the {kib} app and context, you might be prompted to choose the type of rule to create. Some apps will pre-select the type of rule for you.
+Depending upon the {kib} app and context, you might be prompted to choose the type of rule to create. Some apps will preselect the type of rule for you.
 
 [role="screenshot"]
 image::images/rule-flyout-rule-type-selection.png[Choosing the type of rule to create]
@@ -218,7 +218,7 @@ image::images/rules-imported-banner.png[Rules import banner, width=50%]
 
 [float]
 [[rule-details]]
-=== Drilldown to rule details
+=== Drill down to rule details
 
 Select a rule name from the rule listing to access the *Rule details* page, which tells you about the state of the rule and provides granular control over the actions it is taking. 
 

docs/user/alerting/rule-types.asciidoc

@@ -2,8 +2,8 @@
 [[rule-types]]
 == Rule types
 
-A rule is a set of <<alerting-concepts-conditions, conditions>>, <<alerting-concepts-scheduling, schedules>>, and <<alerting-concepts-actions, actions>> that enable notifications. {kib} provides rules built into the Elastic Stack and rules registered by one of the {kib} apps.
-You can create most rules types in <<create-and-manage-rules,Stack Management > Rules and Connectors>>. For information on creating security rules, refer to {security-guide}/rules-ui-create.html[Create a detection rule].
+A rule is a set of <<alerting-concepts-conditions, conditions>>, <<alerting-concepts-scheduling, schedules>>, and <<alerting-concepts-actions, actions>> that enable notifications. {kib} provides rules built into the {stack} and rules registered by one of the {kib} apps.
+You can create most rules types in <<create-and-manage-rules,{stack-manage-app} > {rules-ui}>>. For information on creating security rules, refer to {security-guide}/rules-ui-create.html[Create a detection rule].
 
 [NOTE]
 ==============================================
@@ -37,9 +37,9 @@ see {subscriptions}[the subscription page].
 
 [float]
 [[observability-rules]]
-=== Observability rules
+=== {observability} rules
 
-Observability rules are categorized into APM and User Experience, Logs, Metrics, Stack Monitoring, and Uptime.
+{observability} rules are categorized into APM and {user-experience}, Logs, Metrics, {stack-monitor-app}, and Uptime.
 
 [NOTE]
 ==============================================
@@ -55,16 +55,16 @@ If you create a rule in the {observability} app, its alerts are not visible in
 | Detect complex conditions in *APM* data and trigger built-in actions when the conditions are met.
 
 | {observability-guide}/create-alerts.html[Logs rules]
-| Detect complex conditions in the *Logs* app.
+| Detect complex conditions in the {logs-app}.
 
 | {observability-guide}/create-alerts.html[Metrics rules]
-| Detect complex conditions in the *Metrics* app.
+| Detect complex conditions in the {metrics-app}.
 
-| <<kibana-alerts,Stack Monitoring>>
-| Provide {kib} Alerting rules out-of-the box to notify you of potential issues in the Elastic Stack.
+| <<kibana-alerts,{stack-monitor-app}>>
+| Provide {kib} alerting rules out-of-the box to notify you of potential issues in the {stack}.
 
 | {observability-guide}/create-alerts.html[Uptime rules]
-| Detect complex conditions in the *Uptime* app.
+| Detect complex conditions in the {uptime-app}.
 
 |===
 
@@ -87,5 +87,5 @@ they are not visible in *{stack-manage-app} > {rules-ui}*.
 ==============================================
 
 include::rule-types/index-threshold.asciidoc[]
-include::rule-types/es-query.asciidoc[]
+include::rule-types/es-query.asciidoc[leveloffset=+1]
 include::rule-types/geo-rule-types.asciidoc[]

docs/user/alerting/rule-types/es-query.asciidoc

@@ -1,21 +1,20 @@
 [[rule-type-es-query]]
-[role="xpack"]
-=== {es} query
+== {es} query
 
 The {es} query rule type runs a user-configured query, compares the number of 
 matches to a configured threshold, and schedules actions to run when the 
 threshold condition is met.
 
 
 [float]
-==== Create the rule
+=== Create the rule
 
 Fill in the <<defining-rules-general-details, rule details>>, then select 
 *{es} query*.
 
 
 [float]
-==== Define the conditions
+=== Define the conditions
 
 Define properties to detect the condition.
 
@@ -38,11 +37,11 @@ Time window:: Defines how far back to search for documents, using the
 value higher than the *check every* value in the 
 <<defining-rules-general-details, general rule details>>, to avoid gaps in 
 detection.
-Exclude the hits from previous run:: Turn on to avoid alert duplication by
+Exclude matches from previous run:: Turn on to avoid alert duplication by
 excluding documents that have already been detected by the previous rule run.
 
 [float]
-==== Add action variables
+=== Add action variables
 
 <<defining-rules-actions-details, Add an action>> to run when the rule condition 
 is met. The following variables are specific to the {es} query rule. You can 
@@ -109,7 +108,7 @@ Labels:
 --
 
 [float]
-==== Test your query
+=== Test your query
 
 Use the *Test query* feature to verify that your query DSL is valid.
 
@@ -125,11 +124,12 @@ image::user/alerting/images/rule-types-es-query-valid.png[Test {es} query return
 image::user/alerting/images/rule-types-es-query-invalid.png[Test {es} query shows error when invalid]
 
 [float]
-==== Handling multiple matches of the same document
+=== Handling multiple matches of the same document
 
-This rule type checks for duplication of document matches across multiple runs.
-If you configure the rule with a schedule interval smaller than the time window,
-and a document matches a query in multiple runs, it is alerted on only once.
+By default, *Exclude matches from previous run* is turned on and the rule checks
+for duplication of document matches across multiple runs. If you configure the
+rule with a schedule interval smaller than the time window and a document
+matches a query in multiple runs, it is alerted on only once.
 
 The rule uses the timestamp of the matches to avoid alerting on the same match 
 multiple times. The timestamp of the latest match is used for evaluating the 

docs/user/alerting/troubleshooting/alerting-common-issues.asciidoc

@@ -72,7 +72,7 @@ By default, only users with a `superuser` role can query the experimental[] {kib
 
 *Solution*
 
-By default, rules have a `5m` timeout. Rules that run longer than this timeout are automatically cancelled to prevent them from consuming too much of {kib}'s resources. Alerts and actions that may have been scheduled before the rule timed out are discarded. When a rule times out, you will see this error in the {kib} logs:
+By default, rules have a `5m` timeout. Rules that run longer than this timeout are automatically canceled to prevent them from consuming too much of {kib}'s resources. Alerts and actions that may have been scheduled before the rule timed out are discarded. When a rule times out, you will see this error in the {kib} logs:
 
 [source,sh]
 --------------------------------------------------
@@ -243,7 +243,7 @@ Use the <<get-rule-api,get rule API>> to retrieve additional information about r
 
 [float]
 [[rule-cannot-decrypt-api-key]]
-==== Rule cannot decrypt apiKey
+==== Rule cannot decrypt API key
 
 *Problem*:
 
@@ -266,3 +266,23 @@ This error happens when the `xpack.encryptedSavedObjects.encryptionKey` value us
 | Generate a new API key for the rule by disabling then enabling the rule.
 
 |===
+
+[float]
+[[known-issue-upgrade-rule]]
+==== Rules stop running after upgrade
+
+*Problem*:
+
+Alerting rules that were created or edited in 8.2 stop running after you upgrade
+to later releases. The following error occurs:
+
+[source,text]
+----
+<rule-type>:<UUID>: execution failed - security_exception: [security_exception] Reason: missing authentication credentials for REST request [/_security/user/_has_privileges], caused by: ""
+----
+
+*Solution*:
+
+Upgrade to 8.3.2 or later releases, then go to *{stack-manage-app} > {rules-ui}* and multi-select the failed rules. Choose
+**Manage rules > Update API Keys** to generate new API keys. For more details
+about API key authorization, refer to <<alerting-authorization>>.

docs/user/alerting/troubleshooting/testing-connectors.asciidoc

@@ -3,7 +3,7 @@
 === Test connectors
 
 
-By using Kibana Management UI you can test a newly created Connector by navigating to the Test tab of Connector Edit flyout or by clicking "Save & test" button on Create flyout:
+In *{stack-manage-app} > {rules-ui}*, you can test a newly created connector by navigating to the Test tab of Connector Edit flyout or by clicking "Save & test" button on Create flyout:
 [role="screenshot"]
 image::user/alerting/images/connector-save-and-test.png[Rule management page with the errors banner]
 

packages/analytics/client/src/analytics_client/types.ts

@@ -169,6 +169,8 @@ export interface IAnalyticsClient {
    * Reports a telemetry event.
    * @param eventType The event type registered via the `registerEventType` API.
    * @param eventData The properties matching the schema declared in the `registerEventType` API.
+   *
+   * @track-adoption
    */
   reportEvent: <EventTypeData extends object>(
     eventType: EventType,
@@ -198,8 +200,10 @@ export interface IAnalyticsClient {
    */
   optIn: (optInConfig: OptInConfig) => void;
   /**
-   * Registers the context provider to enrich the any reported events.
+   * Registers the context provider to enrich any reported events.
    * @param contextProviderOpts {@link ContextProviderOpts}
+   *
+   * @track-adoption
    */
   registerContextProvider: <Context>(contextProviderOpts: ContextProviderOpts<Context>) => void;
   /**