[DOCS] Minor linting issues in alerting (#140126)

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,7 +11,7 @@ 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`>> 
@@ -19,7 +19,7 @@ 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,7 +44,9 @@ 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]
@@ -52,7 +54,7 @@ Diagnosing these may be difficult - but there may be log messages for error cond
 === 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":["me@example.com"]}}'
 --------------------------------------------------
 
-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":["me@example.com"]}}’
 --------------------------------------------------
 
-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}.
 
 |===
 

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*:
 

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]