Merge pull request #13686 from mverde11/develop

Update create-slm.mdx

src/content/docs/release-notes/service-levels-release-notes/service-levels-20230626.mdx

@@ -0,0 +1,19 @@
+---
+title: 'Wildcards'
+subject: Service levels
+releaseDate: '2023-06-26'
+---
+
+import slmWildcards from 'images/slm-wildcard.png';
+
+## Support for wildcards
+
+New Relic service levels is now supporting the use of wildcards in SLI queries.
+
+<img
+  title="wilcards"
+  alt="wildcards"
+  src={slmWildcards}
+/>
+
+Learn how you can configure SLIs and SLOs in [our docs](/docs/service-level-management/create-slm).

src/content/docs/service-level-management/create-slm.mdx

@@ -81,22 +81,14 @@ As an example of taking the granularity too far, adding a chart widget in a dash
 
 In summary, use a top-down approach and start with the least granular service levels. Create more granular service levels only if necessary.
 
-First of all, identify a "system boundary", which is the part of your system your user perceives as a "black box" of functionality. Some examples: 
-
-* In the case of an API, it might simply be a service.
-* For a data pipeline, it might be a chain of services necessary to process data end-to-end.
-
-Once you have established the "top level SLs", you might find out that not all the endpoints of your service behave in the same way, and might want to split it further. The examples would be:
-
-* Login transactions might need higher SLO on errors than browsing transactions
-* Duration of some operations is much higher than the rest
-
 ### The related entity [#sli-entity]
 
 In the New Relic ecosystem, every service level is linked to another [entity](/docs/new-relic-one/use-new-relic-one/core-concepts/what-entity-new-relic/), which is any element in your stack that reports data to us, or that generates data that we have access to. The entity that a service level is related to determines where the SLI/SLO results show.
 
 You can define SLIs on any NRDB event or dimensional metric that is reported to New Relic. Most custom events are not related to a single New Relic entity, but provide higher level business and user experience insights. In this case, you can still relate the SLI to a specific entity or to a workload.
 
+Keep in mind that the SLI queries will need to be under the scope of the same account where the related entity lives in.
+
 ### SLI queries [#sli-queries]
 
 SLIs are defined as the percentage of good responses out of the total number of valid requests. Most often you’ll set up your SLIs by defining the valid and good pieces:
@@ -110,63 +102,11 @@ Alternatively, you can define what you consider to be the bad responses instead:
 
 Request-based SLOs are based on an SLI defined as the ratio of the number of good requests to the total number of requests. A request-based SLO is met when that ratio meets or exceeds the target for the compliance period.
 
-#### Viewing the queries that define an SLI from the UI [#view-query-ui]
-
-To view the queries that define an SLI, you can click on the **...** menu on the SLI row, then select the **Edit** option. The queries will show at the top-right corner.
-
-<img
-  title="SLI edit menu.png"
-  alt="SLI edit menu"
-  src={slmEditMenu2}
-/>
-
-You can also find them through the summary page, by clicking Edit.
-
-<img
-  title="Edit SLIs summary page.png"
-  alt="Edit SLIs summary page"
-  src={slmSummaryEdit}
-/>
-
-#### Viewing the queries that define an SLI through the API [#view-query-api]
-
-To view the queries that define an SLI through the API, use [Nerdgraph](/docs/apis/nerdgraph/examples/nerdgraph-slm/#retrieve-config). In order to view the SLI configuration, you'll need to know the GUID of the entity the SLI is attached to, and replace it in the following query:
-
-```graphql
-{
-  actor {
-    entity(guid: "{entityGuid}") {
-      serviceLevel {
-        indicators {
-          events {
-            badEvents {
-              where
-              from
-            }
-            goodEvents {
-              from
-              where
-            }
-            validEvents {
-              from
-              where
-            }
-          }
-          name
-        }
-      }
-    }
-  }
-}
-```
-
-As a response you are going to receive all the SLIs attached to the entity, the SLI name, and the queries. Keep in mind that either `goodEvents` or `badEvents` is going to have content, depending on the configuration of the SLI.
-
 ## Suggested SLIs [#suggested-sli]
 
 In this section you’ll find some SLIs that are typically used to measure the performance of services and browser applications. 
 
-### SLIs for APM services instrumented with the New Relic agent [#sli-apm]
+### SLIs for APM services and key transactions instrumented with the New Relic agent [#sli-apm]
 
 Based on `Transaction` events, these SLIs are the most common for request-driven services:
 
@@ -234,7 +174,7 @@ Based on `Transaction` events, these SLIs are the most common for request-driven
   </Collapser>
 </CollapserGroup>
 
-### SLIs for APM services instrumented with OpenTelemetry [#sli-otel]
+### SLIs for APM services and key transactions instrumented with OpenTelemetry [#sli-otel]
 
 Based on OpenTelemetry spans, these SLIs are the most common for request-driven services:
 
@@ -442,12 +382,44 @@ The following SLIs are based on Google's Browser Core Web Vitals.
   </Collapser>
 </CollapserGroup>
 
+### SLIs for synthetic checks [#sli-synthetic]
+
+Based on OpenTelemetry spans, these SLIs are the most common for request-driven services:
+
+<CollapserGroup>
+  <Collapser
+    className="freq-link"
+    id="synthetic-success"
+    title="Success"
+  >
+    Success is the ratio of the number of successful synthectic checks to the number of all checks.
+
+    **Valid events fields**
+
+    ```sql
+    FROM: SyntheticCheck
+    WHERE: entity.guid = '{entityGuid}' 
+    ```
+
+    Where `{entityGuid}` is the service's GUID.
+
+    **Good events fields**
+
+    ```sql
+    FROM: SyntheticCheck
+    WHERE: entity.guid = '{entityGuid}' AND result='SUCCESS' 
+    ```
+
+    Where `{entityGuid}` is the service's GUID.
+  </Collapser>
+</CollapserGroup>
+
 ## Create and edit service levels [#create-edit]
 
 You can create SLIs and SLOs from several places on [in our UI](https://one.newrelic.com):
 
 * Go to **[one.newrelic.com](https://one.newrelic.com/all-capabilities) > Service levels**. You can associate the SLI with any entity across your accounts, including workloads.
-* From the **Service levels** page in any <InlinePopover type="apm" /> Service, Browser application, or Synthetic monitor. The SLI will be associated with that specific entity.  If you use this starting point, New Relic will automatically create the most common service level indicators for this entity type, based on the latest available data.
+* From the **Service levels** page in any <InlinePopover type="apm" /> Service, key transactions, Browser application, or Synthetic monitor. The SLI will be associated with that specific entity.  If you use this starting point, New Relic will automatically create the most common service level indicators for this entity type, based on the latest available data.
 * From the **Service levels** tab in any workload. You can associate the SLI with any entity in the workload, or the whole workload. 
 
 Data doesn't appear right away after creating an SLI. Expect a few minutes delay before seeing the first SLI attainment results. The data has 13 month retention by default.    
@@ -462,7 +434,7 @@ To create service levels, follow these steps:
     id="select-sli-source"
     title="Select the SLI data source"
   >
-    In order to define your new SLI, choose one of these two options:
+    In order to define your new SLI, choose one of these three options:
 
     * **Entity data**: Base the SLI on standard data coming from our agents or your own custom events. This is the most common option. If this is your choice, select the entity (for example, APM service) you want to use.
     * **Custom data**: Alternatively, you can base the SLI on your custom NRDB events or dimensional metrics. Use this option when you can't relate the service level data to a specific entity, or when you want to relate the service level directly to a workload.
@@ -499,7 +471,6 @@ To create service levels, follow these steps:
 
     Here’s an example of the percentage-based success rate for a dimensional metric, let’s convert it into the valid/good events for SLI:
 
-  </Collapser>
     ```sql
     FROM Metric
     SELECT percentage(sum(scrooge_do_expire_count), 
@@ -527,7 +498,7 @@ To create service levels, follow these steps:
     AND status = 'success'
     ```
 
-    Currently, the two aggregation functions that we support are `count()` and `sum()`. The `count()` function is recommended to be used with event data, when you just count the number of valid/good/bad events, while sum() would be helpful if you have pre-aggregated counters in event data or dimensional metrics.
+    Currently, the two aggregation functions that we support are `count()` and `sum()`. The `count()` function is recommended to be used with event data, when you just count the number of valid/good/bad events, while `sum()` would be helpful if you have pre-aggregated counters in event data or dimensional metrics.
 
     Example using `count()`:
 
@@ -544,7 +515,14 @@ To create service levels, follow these steps:
     SELECT sum(provider.errors.Sum) 
     WHERE awsAccountId = 'XXX'  And provider LIKE 'LambdaFunction%'
     ```
+You can also use wildcards in your SLI queries, here's an example:
+ ```sql
+    FROM ServerlessSample 
+    SELECT sum(provider.goldenmetrics.infra%) 
+    WHERE awsAccountId = 'XXX'
+    ```
 
+ </Collapser>
   <Collapser
     className="freq-link"
     id="set-slo"