Make alerting navigation more consistent with serverless docs (#3640) (…

…#3644)

(cherry picked from commit e64842f)

Co-authored-by: DeDe Morton <dede.morton@elastic.co>

docs/en/observability/create-alerts.asciidoc

@@ -15,8 +15,13 @@ Alerts and rules related to service level objectives (SLOs), and {observability}
 You can also manage {observability} app rules alongside rules for other apps from the {kibana-ref}/create-and-manage-rules.html[{kib} Management UI].
 
 [discrete]
+== Next steps
+
+* <<create-alerts-rules>>
+* <<view-observability-alerts>>
+
 [[create-alerts-rules]]
-== Create rules
+== Create and manage rules
 
 The first step when setting up alerts is to create a rule.
 To create and manage rules related to {observability} apps,
@@ -56,14 +61,14 @@ tie into other third-party systems. Connectors allow actions to talk to these se
 
 Learn how to create specific types of rules:
 
+* {kibana-ref}/apm-alerts.html[APM rules]
 * <<custom-threshold-alert,Custom threshold rule>>
-* <<logs-threshold-alert,Logs threshold rule>>
+* <<logs-threshold-alert,Log threshold rule>>
 * <<infrastructure-threshold-alert,Infrastructure threshold rule>>
-* <<metrics-threshold-alert,Metrics threshold rule>>
+* <<metrics-threshold-alert,Metric threshold rule>>
 * <<monitor-status-alert,Monitor status rule>>
 * <<tls-certificate-alert,TLS certificate rule>>
 * <<duration-anomaly-alert,Uptime duration anomaly rule>>
-* {kibana-ref}/apm-alerts.html[APM rules]
 * <<slo-burn-rate-alert,SLO burn rate rule>>
 
 [discrete]
@@ -157,20 +162,18 @@ xpack.observability.unsafe.alertingExperience.enabled: 'false'
 ----
 
 
-include::threshold-alert.asciidoc[leveloffset=+1]
-
-include::logs-threshold-alert.asciidoc[leveloffset=+1]
+include::threshold-alert.asciidoc[leveloffset=+2]
 
-include::infrastructure-threshold-alert.asciidoc[leveloffset=+1]
+include::logs-threshold-alert.asciidoc[leveloffset=+2]
 
-include::metrics-threshold-alert.asciidoc[leveloffset=+1]
+include::infrastructure-threshold-alert.asciidoc[leveloffset=+2]
 
-include::monitor-status-alert.asciidoc[leveloffset=+1]
+include::metrics-threshold-alert.asciidoc[leveloffset=+2]
 
-include::uptime-tls-alert.asciidoc[leveloffset=+1]
+include::monitor-status-alert.asciidoc[leveloffset=+2]
 
-include::uptime-duration-anomaly-alert.asciidoc[leveloffset=+1]
+include::uptime-tls-alert.asciidoc[leveloffset=+2]
 
-include::slo-burn-rate-alert.asciidoc[leveloffset=+1]
+include::uptime-duration-anomaly-alert.asciidoc[leveloffset=+2]
 
-include::view-observability-alerts.asciidoc[leveloffset=+1]
+include::slo-burn-rate-alert.asciidoc[leveloffset=+2]

docs/en/observability/index.asciidoc

@@ -168,6 +168,7 @@ include::profiling-troubleshooting.asciidoc[leveloffset=+2]
 
 // Alerting
 include::create-alerts.asciidoc[leveloffset=+1]
+include::view-observability-alerts.asciidoc[leveloffset=+2]
 
 //SLOs
 include::slo-overview.asciidoc[leveloffset=+1]

docs/en/observability/infrastructure-threshold-alert.asciidoc

@@ -1,5 +1,8 @@
 [[infrastructure-threshold-alert]]
 = Create an infrastructure threshold rule
+++++
+<titleabbrev>Infrastructure threshold</titleabbrev>
+++++
 
 Based on the resources listed on the *Inventory* page within the {infrastructure-app},
 you can create a threshold rule to notify you when a metric has reached or exceeded a value for a specific

docs/en/observability/logs-checklist.asciidoc

@@ -109,7 +109,7 @@ Refer to <<application-logs>>.
 
 [discrete]
 [[logs-alerts-checklist]]
-== Create a logs threshold alert
+== Create a log threshold alert
 
 You can create a rule to send an alert when the log aggregation exceeds a threshold.
 

docs/en/observability/logs-threshold-alert.asciidoc

@@ -1,5 +1,9 @@
 [[logs-threshold-alert]]
-= Create a logs threshold rule
+= Create a log threshold rule
+++++
+<titleabbrev>Log threshold</titleabbrev>
+++++
+
 
 . To access this page, go to **{observability}** -> **Logs**.
 . Click **Alerts and rules** -> **Create rule**.
@@ -128,7 +132,7 @@ You can add more context to the message by clicking the icon above the message t
 and selecting from a list of available variables.
 
 [role="screenshot"]
-image::images/logs-threshold-alert-default-message.png[Default notification message for logs threshold rules with open "Add variable" popup listing available action variables,width=600]
+image::images/logs-threshold-alert-default-message.png[Default notification message for log threshold rules with open "Add variable" popup listing available action variables,width=600]
 
 [discrete]
 [[performance-considerations]]

docs/en/observability/metrics-threshold-alert.asciidoc

@@ -1,5 +1,8 @@
 [[metrics-threshold-alert]]
-= Create a metrics threshold rule
+= Create a metric threshold rule
+++++
+<titleabbrev>Metric threshold</titleabbrev>
+++++
 
 Based on the metrics that are listed on the **Metrics Explorer** page within the {infrastructure-app},
 you can create a threshold rule to notify you when a metric has reached or exceeded a value for a specific
@@ -93,14 +96,14 @@ You can add more context to the message by clicking the icon above the message t
 and selecting from a list of available variables.
 
 [role="screenshot"]
-image::images/metrics-threshold-alert-default-message.png[Default notification message for metrics threshold rules with open "Add variable" popup listing available action variables,width=600]
+image::images/metrics-threshold-alert-default-message.png[Default notification message for metric threshold rules with open "Add variable" popup listing available action variables,width=600]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
 [discrete]
 [[metrics-alert-settings]]
 == Settings
 
-With metrics threshold rules, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from
+With metric threshold rules, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from
 *Metrics indices* on the <<configure-settings,Settings>> page of the {infrastructure-app}.
 
 With each execution of the rule check, the *Metrics indices* setting is checked, but it is not stored when the rule is created.

docs/en/observability/monitor-status-alert.asciidoc

@@ -1,8 +1,11 @@
 [[monitor-status-alert]]
 = Create a monitor status rule
+++++
+<titleabbrev>Monitor status</titleabbrev>
+++++
 
 Within the {uptime-app}, create a **Monitor Status** rule to receive notifications
-based on errors and outages. 
+based on errors and outages.
 
 . To access this page, go to **{observability}** -> **Uptime**.
 . At the top of the page, click **Alerts and rules** -> **Create rule**.
@@ -19,15 +22,15 @@ If you already have a query in the overview page search bar, it's populated here
 
 You can specify the following thresholds for your rule.
 
-|=== 
+|===
 
 | *Status check* | Receive alerts when a monitor goes down a specified number of
 times within a time range (seconds, minutes, hours, or days).
 
 | *Availability* | Receive alerts when a monitor goes below a specified availability
 threshold within a time range (days, weeks, months, or years).
 
-|=== 
+|===
 
 Let's create a rule for any monitor that shows `Down` more than three times in 10 minutes.
 

docs/en/observability/slo-burn-rate-alert.asciidoc

@@ -1,8 +1,7 @@
 [[slo-burn-rate-alert]]
 = Create a service-level objective (SLO) burn rate rule
-
 ++++
-<titleabbrev>Create an SLO burn rate rule</titleabbrev>
+<titleabbrev>SLO burn rate</titleabbrev>
 ++++
 
 include::slo-overview.asciidoc[tag=slo-license]

docs/en/observability/threshold-alert.asciidoc

@@ -1,5 +1,8 @@
 [[custom-threshold-alert]]
 = Create a custom threshold rule
+++++
+<titleabbrev>Custom threshold</titleabbrev>
+++++
 
 beta::[]
 
@@ -151,4 +154,4 @@ You can add more context to the message by clicking the icon above the message t
 and selecting from a list of available variables.
 
 [role="screenshot"]
-image::images/logs-threshold-alert-default-message.png[Default notification message for logs threshold rules with open "Add variable" popup listing available action variables,width=600]
+image::images/logs-threshold-alert-default-message.png[Default notification message for log threshold rules with open "Add variable" popup listing available action variables,width=600]

docs/en/observability/uptime-duration-anomaly-alert.asciidoc

@@ -1,5 +1,8 @@
 [[duration-anomaly-alert]]
 = Create an uptime duration anomaly rule
+++++
+<titleabbrev>Uptime duration anomaly</titleabbrev>
+++++
 
 Within the {uptime-app}, create an *Uptime duration anomaly* rule to receive notifications
 based on the response durations for all of the geographic locations of each monitor. When a
@@ -20,7 +23,7 @@ The _anomaly score_ is a value from `0` to `100`, which indicates the significan
 compared to previously seen anomalies. The highly anomalous values are shown in
 red and the low scored values are indicated in blue.
 
-|=== 
+|===
 
 | *warning* | Score `0` and above.
 
@@ -30,7 +33,7 @@ red and the low scored values are indicated in blue.
 
 | *critical* | Score `75` and above.
 
-|=== 
+|===
 
 [role="screenshot"]
 image::images/response-durations-alert.png[Uptime response duration rule]

docs/en/observability/uptime-tls-alert.asciidoc

@@ -1,5 +1,8 @@
 [[tls-certificate-alert]]
 = Create a TLS certificate rule
+++++
+<titleabbrev>TLS certificate</titleabbrev>
+++++
 
 Within the {uptime-app}, you can create a rule that notifies
 you when one or more of your monitors has a TLS certificate expiring
@@ -18,15 +21,15 @@ The threshold values for each condition are configurable on the
 
 You can specify the following thresholds for your rule.
 
-|=== 
+|===
 
 | *Expiration threshold* | The `expiration` threshold specifies when you are notified
 about certificates that are approaching expiration dates.
 
 | *Age limit* | The `age` threshold specifies when you are notified about certificates
 that have been valid for too long.
 
-|=== 
+|===
 
 Let's create a rule to check every 6 hours and notify us when any of the TLS certificates on sites we're monitoring are close to expiring.