Merge pull request #19179 from akane0915/update_los_only_docs

fix(Alerts): update loss of signal docs for hostStatus: shutdown
newrelic · Nov 4, 2024 · aae2bb5 · aae2bb5
2 parents 9af9df5 + b6bc4b7
commit aae2bb5
Show file tree

Hide file tree

Showing 2 changed files with 33 additions and 33 deletions.
diff --git a/...ocs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/...ocs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx
@@ -175,8 +175,8 @@ Some elements of NRQL used in charts don't make sense in the context of streamin
         Example:
 
         ```sql
-        SELECT percentile(largestContentfulPaint, 75) 
-        FROM PageViewTiming 
+        SELECT percentile(largestContentfulPaint, 75)
+        FROM PageViewTiming
         WHERE (appId = 837807) SINCE yesterday
         ```
 
@@ -229,7 +229,7 @@ Some elements of NRQL used in charts don't make sense in the context of streamin
         Original query:
 
         ```sql
-        SELECT count(foo), average(bar), max(baz) 
+        SELECT count(foo), average(bar), max(baz)
         FROM Transaction
         ```
 
@@ -268,8 +268,8 @@ Some elements of NRQL used in charts don't make sense in the context of streamin
         For example to create an alert condition equivalent to
 
         ```sql
-        SELECT count(*) 
-        FROM Transaction 
+        SELECT count(*)
+        FROM Transaction
         TIMESERIES 1 minute SLIDE BY 5 minutes
         ```
 
@@ -323,14 +323,14 @@ Here are some common use cases for NRQL conditions. These queries will work for
     Create constrained alerts that target a specific segment of your data, such as a few key customers or a range of data. Use the `WHERE` clause to define those conditions.
 
     ```sql
-    SELECT average(duration) 
-    FROM Transaction 
+    SELECT average(duration)
+    FROM Transaction
     WHERE account_id IN (91290, 102021, 20230)
     ```
 
     ```sql
-    SELECT percentile(duration, 95) 
-    FROM Transaction 
+    SELECT percentile(duration, 95)
+    FROM Transaction
     WHERE name LIKE 'Controller/checkout/%'
     ```
   </Collapser>
@@ -342,12 +342,12 @@ Here are some common use cases for NRQL conditions. These queries will work for
     Create alerts when an Nth percentile of your data hits a specified threshold; for example, maintaining SLA service levels. Since we evaluate the NRQL query based on the aggregation window duration, percentiles will be calculated for each duration separately.
 
     ```sql
-    SELECT percentile(duration, 95) 
+    SELECT percentile(duration, 95)
     FROM Transaction
     ```
 
     ```sql
-    SELECT percentile(databaseDuration, 75) 
+    SELECT percentile(databaseDuration, 75)
     FROM Transaction
     ```
   </Collapser>
@@ -359,17 +359,17 @@ Here are some common use cases for NRQL conditions. These queries will work for
     Create alerts when your data hits a certain maximum, minimum, or average; for example, ensuring that a duration or response time does not pass a certain threshold.
 
     ```sql
-    SELECT max(duration) 
+    SELECT max(duration)
     FROM Transaction
     ```
 
     ```sql
-    SELECT min(duration) 
+    SELECT min(duration)
     FROM Transaction
     ```
 
     ```sql
-    SELECT average(duration) 
+    SELECT average(duration)
     FROM Transaction
     ```
   </Collapser>
@@ -381,12 +381,12 @@ Here are some common use cases for NRQL conditions. These queries will work for
     Create alerts when a proportion of your data goes above or below a certain threshold.
 
     ```sql
-    SELECT percentage(count(*), WHERE duration > 2) 
+    SELECT percentage(count(*), WHERE duration > 2)
     FROM Transaction
     ```
 
     ```sql
-    SELECT percentage(count(*), WHERE http.statusCode = '500') 
+    SELECT percentage(count(*), WHERE http.statusCode = '500')
     FROM Transaction
     ```
   </Collapser>
@@ -398,8 +398,8 @@ Here are some common use cases for NRQL conditions. These queries will work for
     Create alerts on [Apdex](/docs/apm/new-relic-apm/apdex/apdex-measuring-user-satisfaction), applying your own T-value for certain transactions. For example, get an alert notification when your Apdex for a T-value of 500ms on transactions for production apps goes below 0.8.
 
     ```sql
-    SELECT apdex(duration, t:0.5) 
-    FROM Transaction 
+    SELECT apdex(duration, t:0.5)
+    FROM Transaction
     WHERE appName LIKE '%prod%'
     ```
   </Collapser>
@@ -418,8 +418,8 @@ By default, the aggregation window duration is 1 minute, but you can change the
 Let's say this is your alert condition query:
 
 ```sql
-SELECT count(*) 
-FROM SyntheticCheck 
+SELECT count(*)
+FROM SyntheticCheck
 WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED'
 ```
 
@@ -438,7 +438,7 @@ If you have a data source delivering legitimate numeric zeroes, the query will r
 Let's say this is your alert condition query, and that `MyCoolEvent` is an attribute that can sometimes return a zero value.
 
 ```sql
-SELECT average(MyCoolAttribute) 
+SELECT average(MyCoolAttribute)
 FROM MyCoolEvent
 ```
 
@@ -453,8 +453,8 @@ You can avoid `NULL` values entirely with a query order of operations shortcut.
 Here's an example to alert on `FAILED` results:
 
 ```sql
-SELECT filter(count(*), WHERE result = 'FAILED') 
-FROM SyntheticCheck 
+SELECT filter(count(*), WHERE result = 'FAILED')
+FROM SyntheticCheck
 WHERE monitorName = 'My Favorite Monitor'
 ```
 
@@ -474,13 +474,13 @@ For more information, check out our [blog post](https://discuss.newrelic.com/t/r
     Without a `FACET`, the inner query produces a single result, giving the outer query nothing to aggregate. If you're using a nested query, make sure your inner query is faceted.
 
     ```sql
-    SELECT max(cpu) 
-    FROM 
+    SELECT max(cpu)
+    FROM
       (
-        SELECT min(cpuPercent) AS 'cpu' 
-        FROM SystemSample 
+        SELECT min(cpuPercent) AS 'cpu'
+        FROM SystemSample
         FACET hostname
-      ) 
+      )
     ```
   </Collapser>
 
@@ -491,11 +491,11 @@ For more information, check out our [blog post](https://discuss.newrelic.com/t/r
     With an alert aggregation window of 1 minute, the inner query would produce two smaller windows of 30 seconds. In theory, these two windows could be aggregated by the outer query. However, this is not currently supported.
 
     ```sql
-    SELECT max(cpu) 
-    FROM 
+    SELECT max(cpu)
+    FROM
       (
         SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds
-        FROM Event 
+        FROM Event
       )
         ```
   </Collapser>
@@ -772,7 +772,7 @@ Loss of signal settings include a time duration and a few actions.
   * Do not open "lost signal" incidents on expected termination. When a signal is expected to terminate, you can choose not to open a new incident. This is useful when you know that a signal will be lost at a certain time, and you don't want to open a new incident for that signal loss. The GraphQL node name for this is [`ignoreOnExpectedTermination`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal).
 
 <Callout variant="important">
-  To prevent a loss of signal incident from opening when <DNT>**Do not open "lost signal" incident on expected termination**</DNT>, you must add the tag `termination: expected` to the entity. This tag tells us that we expected the signal to end. See [how to add the tag directly to the entity](/docs/new-relic-solutions/new-relic-one/core-concepts/use-tags-help-organize-find-your-data/#add-tags).
+  To prevent a loss of signal incident from opening when <DNT>**Do not open "lost signal" incident on expected termination**</DNT>, you must add the tag `termination: expected` to the entity. This tag tells us that we expected the signal to end. See [how to add the tag directly to the entity](/docs/new-relic-solutions/new-relic-one/core-concepts/use-tags-help-organize-find-your-data/#add-tags). Note that the tag `hostStatus: shutdown` will also prevent a prevent a "loss of signal" incident from opening. For more information, see [Create a "host not reporting" condition](/docs/infrastructure/infrastructure-alerts/create-infrastructure-host-not-reporting-condition/#create-condition).
 </Callout>
 
 To create a NRQL alert configured with loss of signal detection in the UI:

diff --git a/src/content/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling.mdx b/src/content/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling.mdx
@@ -41,7 +41,7 @@ You can configure the duration of the signal loss and whether to open an inciden
 
 You also have the option to skip opening an incident when the signal is expected to be lost. To do this, use this field in NerdGraph:
 
-* `expiration.ignoreOnExpectedTermination`: If `true`, an incident will not be opened when the signal is expected to be lost. To indicate a signal is expected to be lost, the tag `termination: expected` must be present on the entity. Default is `false`.
+* `expiration.ignoreOnExpectedTermination`: If `true`, an incident will not be opened when the signal is expected to be lost. To indicate a signal is expected to be lost, the tag `termination: expected` must be present on the entity. Default is `false`. For infrastructure host entities, the tag `hostStatus: shutdown` will also indicate the signal is expected to stop and prevent an incident from opening.
 
 ### View loss of signal settings for an existing condition