From c524b5be8e7aabfd1ec944ff84b76beca07a0342 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 29 Aug 2024 11:58:27 -0700 Subject: [PATCH 01/19] chore: minor corrections/typos --- .../create-nrql-alert-conditions.mdx | 36 ++++++++++--------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 0aacc877f25..7616c34e3c9 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -39,8 +39,8 @@ Here's the basic syntax for creating all NRQL alert conditions. ```sql SELECT function(attribute) - FROM Event - WHERE attribute [comparison] [AND|OR ...] +FROM Event +WHERE attribute [comparison] [AND|OR ...] ``` @@ -227,17 +227,17 @@ 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) from Transaction + SELECT count(foo), average(bar), max(baz) FROM Transaction ``` Decomposed: ```sql - SELECT count(foo) from Transaction + SELECT count(foo) FROM Transaction - SELECT average(bar) from Transaction + SELECT average(bar) FROM Transaction - SELECT max(baz) from Transaction + SELECT max(baz) FROM Transaction ``` @@ -265,7 +265,7 @@ 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 TIMESERIES 1 minute SLIDE BY 5 minutes + SELECT count(*) FROM Transaction TIMESERIES 1 minute SLIDE BY 5 minutes ``` You would use a data aggregation window duration of 5 minutes, with a sliding window aggregation of 1 minute. @@ -278,7 +278,7 @@ Some elements of NRQL used in charts don't make sense in the context of streamin @@ -318,7 +318,7 @@ 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 WHERE account_id in (91290, 102021, 20230) + SELECT average(duration) FROM Transaction WHERE account_id IN (91290, 102021, 20230) ``` ```sql @@ -351,6 +351,10 @@ Here are some common use cases for NRQL conditions. These queries will work for SELECT max(duration) FROM Transaction ``` + ```sql + SELECT min(duration) FROM Transaction + ``` + ```sql SELECT average(duration) FROM Transaction ``` @@ -378,7 +382,7 @@ 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 WHERE appName like '%prod%' + SELECT apdex(duration, t:0.5) FROM Transaction WHERE appName LIKE '%prod%' ``` @@ -447,7 +451,7 @@ 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 (FROM SystemSample SELECT min(cpuPercent) as 'cpu' FACET hostname) ​​​​ + SELECT max(cpu) FROM (FROM SystemSample SELECT min(cpuPercent) AS 'cpu' FACET hostname) ​​​​ ``` @@ -458,7 +462,7 @@ 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 (FROM Event SELECT min(cpuTime) as cpu TIMESERIES 30 seconds)​​ + SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds)​​ ``` @@ -599,7 +603,7 @@ Here are some tips for creating and using a NRQL condition: @@ -728,8 +732,8 @@ Loss of signal settings include a time duration and a few actions. **Loss of signal actions** Once a signal is considered lost, you have a few options: - * Close all current open incidents: This closes all open incidents that are related to a specific signal. It won't necessarily close all incidents for a condition. If you're alerting on an ephemeral service, or on a sporadic signal, you'll want to choose this action to ensure that incidents are closed properly. The GraphQL node name for this is ["closeViolationsOnExpiration](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal)" - * Open new incidents: This will open a new incident when the signal is considered lost. These incidents will indicate that they are due to a loss of signal. Based on your incident preferences, this should trigger a notification. The graphQL node name for this is ["openViolationOnExpiration](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal)" + * Close all current open incidents: This closes all open incidents that are related to a specific signal. It won't necessarily close all incidents for a condition. If you're alerting on an ephemeral service, or on a sporadic signal, you'll want to choose this action to ensure that incidents are closed properly. The GraphQL node name for this is [`closeViolationsOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal) + * Open new incidents: This will open a new incident when the signal is considered lost. These incidents will indicate that they are due to a loss of signal. Based on your incident preferences, this should trigger a notification. The graphQL node name for this is [`openViolationOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal) * When you enable both of the above actions, we'll close all open incidents first, and then open a new incident for loss of signal. * 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). @@ -816,7 +820,7 @@ You can adjust the [delay/timer](/docs/alerts-applied-intelligence/new-relic-ale For the cadence method, the total supported latency is the sum of the aggregation window duration and the delay. -If the data type comes from an [APM language agent](/docs/apm/new-relic-apm/getting-started/introduction-apm) and is aggregated from many app instances (for example, `Transactions`, `TransactionErrors`, etc.), we recommend using the event flow method with the default settings. +If the data type comes from an [APM language agent](/docs/apm/new-relic-apm/getting-started/introduction-apm) and is aggregated from many app instances (for example, `Transaction`, `TransactionError`, etc.), we recommend using the event flow method with the default settings. When creating NRQL conditions for data collected from [Infrastructure Cloud Integrations](/docs/infrastructure/infrastructure-integrations/get-started/introduction-infrastructure-integrations/#cloud) such as AWS CloudWatch or Azure, we recommend that you use the event timer method. From 4dec8d96ea1b3a4bd7b79f9252342bf49c8835d7 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 29 Aug 2024 12:13:36 -0700 Subject: [PATCH 02/19] chore: cleanup and minor fixes I'm skeptical some of these queries work too, I think this doc should be reviewed. I was unable to get a few of them to run --- .../usage-queries-alerts.mdx | 27 ++++++++++--------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx index 44d552ff428..268dddc3001 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx @@ -65,7 +65,7 @@ The [usage UI](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new This query breaks down [Metric data](/docs/telemetry-data-platform/understand-data/new-relic-data-types/#dimensional-metrics) by the top ten metric names. You could also facet by `appName` or `host` to adjust the analysis. ```sql - FROM Metric SELECT bytecountestimate()/10e8 as 'GB Estimate' + FROM Metric SELECT bytecountestimate()/10e8 AS 'GB Estimate' SINCE 24 hours ago FACET metricName LIMIT 10 TIMESERIES 1 hour ``` @@ -134,7 +134,7 @@ Here's a query for getting the current month's cost for your full platform users ```sql FROM NrMTDConsumption -SELECT latest(FullPlatformUsersBillable) * YOUR_PER_FULL_PLATFORM_USER_COST +SELECT latest(FullPlatformUsersBillable) * YOUR_PER_FULL_PLATFORM_USER_COST ``` ### User queries for organizations without core users [#queries-non-core] @@ -157,7 +157,7 @@ These queries apply for some older New Relic organizations that have only two us ```sql FROM NrMTDConsumption - SELECT latest(FullUsersBillable) + SELECT latest(FullUsersBillable) ``` This query shows how many full platform users were counted by hour. This is useful for seeing how the full platform user count changed over time. @@ -170,7 +170,7 @@ These queries apply for some older New Relic organizations that have only two us ### Projected monthly full platform user count - This query shows a projected count of monthly full platform users. This query would not be good for using in a dashboard; it requires values based on a) the days remaining in the month, b) the start of the month. Here's an example querying the projected end-of-month count with 10 days left in that month: + This query shows a projected count of monthly full platform users. This query would not be good for using in a dashboard; it requires values based on the days remaining in the month, and the start of the month. Here's an example querying the projected end-of-month count with 10 days left in that month: ```sql FROM NrMTDConsumption @@ -180,21 +180,22 @@ These queries apply for some older New Relic organizations that have only two us ### Count of full platform users and basic users - The [](/docs/accounts/accounts-billing/new-relic-one-pricing-users/pricing-billing#billing-usage-ui) shows the count of full platform users and basic users. The query used is: + The [billing and usage UI](/docs/accounts/accounts-billing/new-relic-one-pricing-users/pricing-billing#billing-usage-ui) shows the count of full platform users and basic users. The query used is: ```sql FROM NrUsage SELECT max(usage) SINCE 10 days ago WHERE productLine='FullStackObservability' - WHERE metric in ('FullUsers', 'BasicUsers') + AND metric IN ('FullUsers', 'BasicUsers') FACET metric ``` To see the count of full platform users and basic users over time: - ``` + ```sql FROM NrUsage SELECT max(usage) SINCE 10 days ago WHERE productLine='FullStackObservability' - WHERE metric in ('FullUsers', 'BasicUsers') FACET metric TIMESERIES 1 hour + AND metric IN ('FullUsers', 'BasicUsers') + FACET metric TIMESERIES 1 hour ``` ### Estimated cost @@ -203,14 +204,14 @@ These queries apply for some older New Relic organizations that have only two us ```sql FROM NrMTDConsumption - SELECT latest(FullPlatformUsersBillable)* YOUR_PER_FULL_PLATFORM_USER_COST + SELECT latest(FullPlatformUsersBillable) * YOUR_PER_FULL_PLATFORM_USER_COST ``` Here's an equivalent one for your core users: ```sql FROM NrMTDConsumption - SELECT latest(CoreUsersBillable)* YOUR_PER_CORE_USER_COST + SELECT latest(CoreUsersBillable) * YOUR_PER_CORE_USER_COST ``` @@ -323,14 +324,14 @@ Here are some query recommendations for helping you understand the estimated cos ```sql FROM NrMTDConsumption - SELECT latest(GigabytesIngestedBillable)*YOUR_PER_GB_COST + SELECT latest(GigabytesIngestedBillable) * YOUR_PER_GB_COST ``` Here's an example of this query using a [per-GB cost of $0.35](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing/#data-prices): ```sql FROM NrMTDConsumption - SELECT latest(GigabytesIngestedBillable)*.35 + SELECT latest(GigabytesIngestedBillable) * .35 ``` @@ -416,7 +417,7 @@ Here are some NRQL alert condition examples. ```sql FROM NrMTDConsumption - SELECT latest(GigabytesIngestedBillable)*YOUR_PER_GB_COST + SELECT latest(GigabytesIngestedBillable) * YOUR_PER_GB_COST ``` From 68a6ed05e45b4aca1167d2452b5d66d8132e411f Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 29 Aug 2024 12:17:40 -0700 Subject: [PATCH 03/19] chore: add language identifier --- .../understand-use-data-infrastructure-integrations.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/infrastructure/infrastructure-integrations/get-started/understand-use-data-infrastructure-integrations.mdx b/src/content/docs/infrastructure/infrastructure-integrations/get-started/understand-use-data-infrastructure-integrations.mdx index 345aa7277c0..830774e65ef 100644 --- a/src/content/docs/infrastructure/infrastructure-integrations/get-started/understand-use-data-infrastructure-integrations.mdx +++ b/src/content/docs/infrastructure/infrastructure-integrations/get-started/understand-use-data-infrastructure-integrations.mdx @@ -143,7 +143,7 @@ Here are some examples of [NRQL queries](/docs/insights/nrql-new-relic-query-lan > Here's an example of a query that groups inventory change events from the last day by the type of change: - ``` + ```sql SELECT count(*) FROM InfrastructureEvent WHERE format='inventoryChange' FACET changeType SINCE 1 DAY AGO ``` From 65901941fe3127e7b0c8b27f906e4ac697891edb Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 19 Sep 2024 09:16:15 -0700 Subject: [PATCH 04/19] Update src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx Co-authored-by: Rob Siebens --- .../new-relic-one-pricing-billing/usage-queries-alerts.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx index 268dddc3001..51ffb274fe0 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx @@ -170,7 +170,7 @@ These queries apply for some older New Relic organizations that have only two us ### Projected monthly full platform user count - This query shows a projected count of monthly full platform users. This query would not be good for using in a dashboard; it requires values based on the days remaining in the month, and the start of the month. Here's an example querying the projected end-of-month count with 10 days left in that month: + Here's an example of querying the projected end-of-month count of monthly full platform users with 10 days left in that month. Note that this query would not be good for using in a dashboard because it requires values based on the days remaining in the month and the start of the month. ```sql FROM NrMTDConsumption From 7c416bdf0f007cd4228fc95a3f91b404d63df0e5 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 19 Sep 2024 09:17:54 -0700 Subject: [PATCH 05/19] fix: typo Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 7616c34e3c9..6bb2f5c4fe7 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -732,7 +732,7 @@ Loss of signal settings include a time duration and a few actions. **Loss of signal actions** Once a signal is considered lost, you have a few options: - * Close all current open incidents: This closes all open incidents that are related to a specific signal. It won't necessarily close all incidents for a condition. If you're alerting on an ephemeral service, or on a sporadic signal, you'll want to choose this action to ensure that incidents are closed properly. The GraphQL node name for this is [`closeViolationsOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal) + * Close all current open incidents: This closes all open incidents that are related to a specific signal. It won't necessarily close all incidents for a condition. If you're alerting on an ephemeral service, or on a sporadic signal, you'll want to choose this action to ensure that incidents are closed properly. The GraphQL node name for this is [`closeViolationsOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal). * Open new incidents: This will open a new incident when the signal is considered lost. These incidents will indicate that they are due to a loss of signal. Based on your incident preferences, this should trigger a notification. The graphQL node name for this is [`openViolationOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal) * When you enable both of the above actions, we'll close all open incidents first, and then open a new incident for loss of signal. * 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). From 8573ccf77347d520a1eb071ef2705ca5f6aa0279 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 19 Sep 2024 09:18:35 -0700 Subject: [PATCH 06/19] fix: typo Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 6bb2f5c4fe7..e261b8f2982 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -733,7 +733,7 @@ Loss of signal settings include a time duration and a few actions. Once a signal is considered lost, you have a few options: * Close all current open incidents: This closes all open incidents that are related to a specific signal. It won't necessarily close all incidents for a condition. If you're alerting on an ephemeral service, or on a sporadic signal, you'll want to choose this action to ensure that incidents are closed properly. The GraphQL node name for this is [`closeViolationsOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal). - * Open new incidents: This will open a new incident when the signal is considered lost. These incidents will indicate that they are due to a loss of signal. Based on your incident preferences, this should trigger a notification. The graphQL node name for this is [`openViolationOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal) + * Open new incidents: This will open a new incident when the signal is considered lost. These incidents will indicate that they are due to a loss of signal. Based on your incident preferences, this should trigger a notification. The graphQL node name for this is [`openViolationOnExpiration`](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/#loss-of-signal). * When you enable both of the above actions, we'll close all open incidents first, and then open a new incident for loss of signal. * 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). From 643d2c472103348f1d245e6efdf17423b9eca8f9 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:14:04 -0700 Subject: [PATCH 07/19] chore: add lang identifier --- .../get-started/activate-azure-integrations.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/infrastructure/microsoft-azure-integrations/get-started/activate-azure-integrations.mdx b/src/content/docs/infrastructure/microsoft-azure-integrations/get-started/activate-azure-integrations.mdx index ec2a616a737..c3c8a316238 100644 --- a/src/content/docs/infrastructure/microsoft-azure-integrations/get-started/activate-azure-integrations.mdx +++ b/src/content/docs/infrastructure/microsoft-azure-integrations/get-started/activate-azure-integrations.mdx @@ -65,14 +65,14 @@ To get your Azure account's subscription `id` and `tenantId`, use your local ter 1. Open a terminal with access to your Azure account. 2. Type the following: - ``` + ```sh az account show ``` 3. Copy and save the subscription `id` and `tenantID` from the output response for later use. The response should look similar to the response below. The subscription `id` and `tenantID` are highlighted. -```js lineHighlight=4,8 +```json lineHighlight=4,8 @Azure:~$ az account show { "environmentName": "AzureCloud", From a34bfb674339c3af7232eefda2844a19708f5070 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:18:24 -0700 Subject: [PATCH 08/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index e261b8f2982..a92f78c8520 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -265,7 +265,9 @@ 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 TIMESERIES 1 minute SLIDE BY 5 minutes + SELECT count(*) + FROM Transaction + TIMESERIES 1 minute SLIDE BY 5 minutes ``` You would use a data aggregation window duration of 5 minutes, with a sliding window aggregation of 1 minute. From 2312ebce569ba318155c81e0f1bbadca1d88d389 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:18:41 -0700 Subject: [PATCH 09/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index a92f78c8520..46f95e3441c 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -320,7 +320,9 @@ 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 WHERE account_id IN (91290, 102021, 20230) + SELECT average(duration) + FROM Transaction + WHERE account_id IN (91290, 102021, 20230) ``` ```sql From 4b3cab51d9fd6fdaea83a23d2263b50401e5ac18 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:18:59 -0700 Subject: [PATCH 10/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 46f95e3441c..7523c814c12 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -227,7 +227,8 @@ 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) FROM Transaction + SELECT count(foo), average(bar), max(baz) + FROM Transaction ``` Decomposed: From 498a578787e5cc61c38f9a3b0c04bd0aa362f4e3 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:19:08 -0700 Subject: [PATCH 11/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 7523c814c12..1c9f67c4007 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -353,7 +353,8 @@ 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) FROM Transaction + SELECT max(duration) + FROM Transaction ``` ```sql From d334840ea62233b096ca702ffb6c38ec7ba17d1d Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:19:57 -0700 Subject: [PATCH 12/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 1c9f67c4007..e5511b1080e 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -388,7 +388,9 @@ 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 WHERE appName LIKE '%prod%' + SELECT apdex(duration, t:0.5) + FROM Transaction + WHERE appName LIKE '%prod%' ``` From 5f3d8c204ac5f7c7bb27ae923cdcb5166f512e72 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:20:18 -0700 Subject: [PATCH 13/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-alert-condition/create-nrql-alert-conditions.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index e5511b1080e..23bf0d24370 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -358,7 +358,8 @@ Here are some common use cases for NRQL conditions. These queries will work for ``` ```sql - SELECT min(duration) FROM Transaction + SELECT min(duration) + FROM Transaction ``` ```sql From 34fd43ed96d56314ee36d9f31eceaabc50a29430 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:54:00 -0700 Subject: [PATCH 14/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-nrql-alert-conditions.mdx | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 23bf0d24370..c5584c5728c 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -460,7 +460,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 (FROM SystemSample SELECT min(cpuPercent) AS 'cpu' FACET hostname) ​​​​ + SELECT max(cpu) + FROM + ( + SELECT min(cpuPercent) AS 'cpu' + FROM SystemSample + FACET hostname + ) ``` From b59cca6865434d5d6cda9ccb5fc5bd12f981f8d1 Mon Sep 17 00:00:00 2001 From: Brian Hensley <48165493+brnhensley@users.noreply.github.com> Date: Thu, 26 Sep 2024 10:54:09 -0700 Subject: [PATCH 15/19] Update src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx Co-authored-by: Rob Siebens --- .../create-nrql-alert-conditions.mdx | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index c5584c5728c..1ecd190b7a0 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -477,7 +477,12 @@ 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 (FROM Event SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds)​​ +SELECT max(cpu) +FROM + ( + SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds + FROM Event + ) ``` From 9efb44a2a372684268a87217f8455a055802a036 Mon Sep 17 00:00:00 2001 From: Rob Siebens Date: Thu, 26 Sep 2024 11:25:49 -0700 Subject: [PATCH 16/19] fix(alerts): Reformatted some queries --- .../create-nrql-alert-conditions.mdx | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 1ecd190b7a0..ed9a86a4dd9 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -338,11 +338,13 @@ 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) FROM Transaction + SELECT percentile(duration, 95) + FROM Transaction ``` ```sql - SELECT percentile(databaseDuration, 75) FROM Transaction + SELECT percentile(databaseDuration, 75) + FROM Transaction ``` @@ -363,7 +365,8 @@ Here are some common use cases for NRQL conditions. These queries will work for ``` ```sql - SELECT average(duration) FROM Transaction + SELECT average(duration) + FROM Transaction ``` @@ -427,7 +430,8 @@ 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) FROM MyCoolEvent +SELECT average(MyCoolAttribute) +FROM MyCoolEvent ``` If, in the aggregation window being evaluated, there's at least one instance of `MyCoolEvent` and if the average value of all `MyCoolAttribute` attributes from that window is equal to zero, then a `0` value will be returned. If there are no `MyCoolEvent` events during that minute, then a `NULL` will be returned due to the order of operations. From ecea9a3075ecd0f2fa93c2c02fd790ef560f8324 Mon Sep 17 00:00:00 2001 From: Rob Siebens Date: Thu, 26 Sep 2024 11:50:42 -0700 Subject: [PATCH 17/19] fix(alerts): Format snippets with WHERE inside SELECT. --- .../create-nrql-alert-conditions.mdx | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index ed9a86a4dd9..ad1392e72e4 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -377,7 +377,8 @@ 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) FROM Transaction + SELECT percentage(count(*), WHERE duration > 2) + FROM Transaction ``` ```sql @@ -445,7 +446,9 @@ 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 WHERE monitorName = 'My Favorite Monitor' +SELECT filter(count(*), WHERE result = 'FAILED') +FROM SyntheticCheck +WHERE monitorName = 'My Favorite Monitor' ``` In this example, a window with a successful result would return a `0`, allowing the condition's threshold to resolve on its own. From dcc09fbaba42ab5835e77c9821496ddcbb3ad383 Mon Sep 17 00:00:00 2001 From: Rob Siebens Date: Thu, 26 Sep 2024 14:05:35 -0700 Subject: [PATCH 18/19] fix(alerts): Add more snippet formatting --- .../create-nrql-alert-conditions.mdx | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index ad1392e72e4..9fee9976b82 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -175,7 +175,9 @@ Some elements of NRQL used in charts don't make sense in the context of streamin Example: ```sql - SELECT percentile(largestContentfulPaint, 75) FROM PageViewTiming WHERE (appId = 837807) SINCE yesterday + SELECT percentile(largestContentfulPaint, 75) + FROM PageViewTiming + WHERE (appId = 837807) SINCE yesterday ``` NRQL conditions produce a never-ending stream of windowed query results, so the `SINCE` and `UNTIL` keywords to scope the query to a point in time are not compatible. As a convenience, we automatically strip `SINCE` and `UNTIL` from a query when creating a condition from the context of a chart. @@ -327,7 +329,9 @@ Here are some common use cases for NRQL conditions. These queries will work for ``` ```sql - SELECT percentile(duration, 95) FROM Transaction WHERE name LIKE 'Controller/checkout/%' + SELECT percentile(duration, 95) + FROM Transaction + WHERE name LIKE 'Controller/checkout/%' ``` @@ -382,7 +386,8 @@ Here are some common use cases for NRQL conditions. These queries will work for ``` ```sql - SELECT percentage(count(*), WHERE http.statusCode = '500') FROM Transaction + SELECT percentage(count(*), WHERE http.statusCode = '500') + FROM Transaction ``` @@ -413,7 +418,9 @@ 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 WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED' +SELECT count(*) +FROM SyntheticCheck +WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED' ``` If there are no failures for the aggregation window: From 56aad669ea9dc5d999c8937e6b07981fc1d4bd23 Mon Sep 17 00:00:00 2001 From: Rob Siebens Date: Thu, 26 Sep 2024 15:38:20 -0700 Subject: [PATCH 19/19] fix(alerts): Fix indentation of subquery again --- .../create-nrql-alert-conditions.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx index 9fee9976b82..e37fa3dd4a1 100644 --- a/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx +++ b/src/content/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions.mdx @@ -491,13 +491,13 @@ 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 min(cpuTime) AS cpu TIMESERIES 30 seconds - FROM Event - ) - ``` + SELECT max(cpu) + FROM + ( + SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds + FROM Event + ) + ```
- In NRQL queries, the `LIMIT` clause is used to control the amount of data a query returns, either the maximum number of facet values returned by `FACET` queries or the maximum number of items returned by `SELECT \*` queries. + In NRQL queries, the `LIMIT` clause is used to control the amount of data a query returns, either the maximum number of facet values returned by `FACET` queries or the maximum number of items returned by `SELECT *` queries. `LIMIT` is not compatible with NRQL alerting: evaluation is always performed on the full result set. - In order for a NRQL alert condition [health status display](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/view-entity-health-status-find-entities-without-alert-conditions) to function properly, the query must be scoped to a single entity. To do this, either use a WHERE clause (for example, `WHERE appName = 'MyFavoriteApp'`) or use a FACET clause to scope each signal to a single entity (for example, `FACET hostname` or `FACET appName`). + In order for a NRQL alert condition [health status display](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/view-entity-health-status-find-entities-without-alert-conditions) to function properly, the query must be scoped to a single entity. To do this, either use a `WHERE` clause (for example, `WHERE appName = 'MyFavoriteApp'`) or use a `FACET` clause to scope each signal to a single entity (for example, `FACET hostname` or `FACET appName`).