Pulling refs/heads/main into main

alerts-detectors-notifications/slo/create-slo.rst

@@ -30,20 +30,20 @@ Follow these steps to create an SLO.
 
           * - :strong:`Field name`
             - :strong:`Actions`
-          * - Metric type
+          * - :guilabel:`Metric type`
             - Select :guilabel:`Service & endpoint` from the dropdown menu
-          * - Environment
+          * - :guilabel:`Environment`
             - Open the dropdown menu and check the boxes for the environments where you want to apply this SLO
-          * - Service\:\endpoint
+          * - :guilabel:`Service:endpoint`
             - * Search for the service you want to create an SLO for
               * (Optional) Add an endpoint for the selected service
-          * - Indicator type
+          * - :guilabel:`Indicator type`
             - Select either success rate or latency to use as the measurement for your SLO target:
 
               * Request success: Measure the proportion of requests that result in a successful response over the duration of the compliance window
 
               * Request latency: Measure the proportion of requests that load within the specified latency over the duration of the compliance window
-          * - Filters
+          * - :guilabel:`Filters`
             - Enter any additional dimension names and values you want to apply this SLO to. Alternatively, use the ``NOT`` filter, represented by an exclamation point ( ! ), to exclude any dimension values from this SLO configuration.
 
     To use a custom metric as the system health indicator for your SLI configuration, follow these steps:
@@ -55,11 +55,11 @@ Follow these steps to create an SLO.
 
           * - :strong:`Field name`
             - :strong:`Actions`
-          * - Metric type
+          * - :guilabel:`Metric type`
             - Select :guilabel:`Custom metric` from the dropdown menu
-          * - Numerator metric
+          * - :guilabel:`Good events (numerator)`
             - Search for the metric you want to use for the success request count
-          * - Denominator metric
+          * - :guilabel:`Total events (denominator)`
             - Search for the metric you want to use for the total request count
 
         .. note:: Custom metric SLO works by calculating the percentage of successful requests over a given compliance period. This calculation works better for counter and histogram metrics than for gauge metrics. Gauge metrics are not suitable for custom metric SLO, so you might get confusing data when selecting gauge metrics in your configuration.
@@ -73,11 +73,11 @@ Follow these steps to create an SLO.
 
       * - :strong:`Field name`
         - :strong:`Actions`
-      * - Target (%)
+      * - :guilabel:`Target (%)`
         - Enter the target you want to set for this SLO. 
-      * - Latency (ms)
+      * - :guilabel:`Latency (ms)`
         - Only available and required for request latency SLI type. Enter the target loading time for your service requests.
-      * - Compliance window
+      * - :guilabel:`Compliance window`
         - Select a compliance window for this SLO from the dropdown menu.
 
 #. Set up alerting for your SLO. You can subscribe to get notifications for the following alerts.
@@ -89,12 +89,12 @@ Follow these steps to create an SLO.
 
       * - :strong:`Alert`
         - :strong:`Description`
-      * - Breach event
+      * - :guilabel:`Breach event`
         - | Alerts when the service level indicator (SLI) doesn't meet the target over the specified compliance window. 
           | :strong:`Note:` Breach event alerting is selected by default and always runs in the background.
-      * - Error budget
+      * - :guilabel:`Error budget`
         - Alerts when the remaining error budget is less than 10% of the estimated error budget for the compliance window.
-      * - Burn rate
+      * - :guilabel:`Burn rate`
         - Alerts when the rate of consumption of your SLO error budget exceeds a healthy threshold for the specified compliance window. To learn more, see :ref:`burn-rate-alerts`.
 
 #. Splunk Observability Cloud automatically generates a name for your SLO. You can change this auto-generated name, as long as the SLO name is unique.

alerts-detectors-notifications/slo/custom-metric-scenario.rst

@@ -0,0 +1,82 @@
+.. _custom-metric-slo-scenario:
+
+*********************************************************************************************
+Scenario: Kai configures a service level objective (SLO) based on a Synthetics check
+*********************************************************************************************
+
+
+.. meta::
+    :description: This Splunk service level objective (SLO) scenario describes how to configure an SLO based on a Synthetics check
+
+Kai, a site reliability engineer at Buttercup Games, has created a Synthetics Browser test for the Emby service on the Buttercup Games website. Kai didn't instrument the Emby service but wants to monitor the health of this service.
+
+To measure and track the health metrics of the Emby service, Kai configures a custom metric SLO based on the Synthetics Browser test.
+
+Use custom metric as service level indicator (SLI)
+======================================================
+
+From the :guilabel:`Detectors & SLOs` page, Kai configures the SLI and sets up a target for their SLO. Kai follows these steps: 
+
+#. Kai wants to use custom metrics as the system health indicators, so they select the :guilabel:`Custom metric` from the :guilabel:`Metric type` menu.
+#. Kai enters the custom metrics they want to measure in the following fields:
+
+    .. list-table::
+        :header-rows: 1
+        :widths: 10 20 30 40
+
+        * - Field
+          - Metric name
+          - Filters
+          - Description 
+
+        * - :guilabel:`Good events (numerator)`
+          - :strong:`synthetics.run.count`
+          - Kai adds the following filters for this metric:
+
+              * :strong:`test = Emby check`
+              * :strong:`success = true`
+          - Kai uses the :strong:`success = true` filter to count the number of successful requests for the Emby service on the Buttercup Games website.
+
+        * - :guilabel:`Total events (denominator)`
+          - :strong:`synthetics.run.count`
+          - Kai adds the following filter for this metric:
+
+              * :strong:`test = Emby check`
+          - Kai uses the same metric name and the :strong:`test = Emby check` filter to track the same Synthetics Browser test. However, Kai doesn't include the :strong:`success = true` dimension filter in order to count the number of total requests for the Emby service on the Buttercup Games website.
+
+#. Kai enters the following fields to define a target for their SLO:
+
+    .. list-table::
+        :header-rows: 1
+        :widths: 32 30 50
+
+        * - Field
+          - Value 
+          - Description 
+
+        * - :guilabel:`Target (%)`
+          - :strong:`99.9`
+          - Kai wants to measure the Emby service successful request rate against a 99.9% target.
+
+        * - :guilabel:`Compliance window`
+          - :strong:`Last 30 days`
+          - Kai wants to track this SLO over the past 30 days.
+
+#. Kai subscribes to receive an alert whenever there is a breach event for the SLO target.
+
+.. image:: /_images/images-slo/custom-metric-slo-scenario.png
+    :width: 100%
+    :alt: This image shows Kai's SLO configuration using the ``synthetics.run.count`` metric and appropriate filters.
+
+
+Summary
+=======================
+
+Kai set up an SLO and subscribed to breach event alerts that let them know when the Emby service on the Buttercup Games website fails to meet the request rate target. Kai managed to use custom metrics from an existing Synthetic Browser test to configure the SLO, despite not instrumenting the service themself.
+
+Learn more
+=======================
+
+For more information about creating an SLO, see :ref:`create-slo`. 
+
+For more information about the Synthetics Browser test, see :ref:`browser-test`.

alerts-detectors-notifications/slo/slo-intro.rst

@@ -15,6 +15,7 @@ Introduction to service level objective (SLO) management in Splunk Observability
     Measure and track your service health metrics with SLOs <create-slo>
     View and manage SLOs <view-slo>
     burn-rate-alerts
+    Scenario: Kai configures an SLO based on a Synthetics check <custom-metric-scenario>
 
 Service level objective (SLO) management is a service level monitoring experience that helps you align your business needs with your engineering reliability goals.