docs: fine tune legacy alert condition docs and monitor downtime docs (…

…#2527)
newrelic · Dec 20, 2023 · 30e0287 · 30e0287
1 parent 760ae08
commit 30e0287
Show file tree

Hide file tree

Showing 4 changed files with 51 additions and 32 deletions.
diff --git a/website/docs/r/alert_condition.html.markdown b/website/docs/r/alert_condition.html.markdown
@@ -10,7 +10,7 @@ description: |-
 
 Use this resource to create and manage alert conditions for APM, Browser, and Mobile in New Relic.
 
--> **NOTE:** This is a legacy resource. The [newrelic_nrql_alert_condition](nrql_alert_condition.html) resource is preferred for configuring alerts conditions. In most cases feature parity can be achieved with a NRQL query. This condition type may be deprecated in the future.
+-> **WARNING:** The `newrelic_alert_condition` resource is deprecated and will be removed in the next major release. The resource [newrelic_nrql_alert_condition](nrql_alert_condition.html) would be a preferred alternative to configure alert conditions - in most cases, feature parity can be achieved with a NRQL query.
 
 ## Example Usage
 

diff --git a/website/docs/r/infra_alert_condition.html.markdown b/website/docs/r/infra_alert_condition.html.markdown
@@ -10,7 +10,7 @@ description: |-
 
 Use this resource to create and manage Infrastructure alert conditions in New Relic.
 
--> **NOTE:** This is a legacy resource. The [newrelic_nrql_alert_condition](nrql_alert_condition.html) resource is preferred for configuring alerts conditions. In most cases feature parity can be achieved with a NRQL query. This condition type may be deprecated in the future.
+-> **WARNING:** The `newrelic_infra_alert_condition` resource is deprecated and will be removed in the next major release. The resource [newrelic_nrql_alert_condition](nrql_alert_condition.html) would be a preferred alternative to configure alert conditions - in most cases, feature parity can be achieved with a NRQL query.
 
 ## Example Usage
 

diff --git a/website/docs/r/monitor_downtime.html.markdown b/website/docs/r/monitor_downtime.html.markdown
@@ -8,7 +8,7 @@ description: |-
 
 # Resource: newrelic\_monitor\_downtime
 
-Use this resource to create, update, and delete Monitor Downtimes in New Relic.
+Use this resource to create, update, and delete [Monitor Downtimes](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/monitor-downtimes-disable-monitoring-during-scheduled-maintenance-times/) in New Relic.
 
 ## Example Usage
 
@@ -21,52 +21,52 @@ resource "newrelic_monitor_downtime" "foo" {
   ]
   mode       = "WEEKLY"
   start_time = "2023-11-30T10:30:00"
-  end_time   = "2023-12-10T10:30:00"
+  end_time   = "2023-12-10T02:45:30"
   time_zone  = "Asia/Kolkata"
   end_repeat {
     on_date = "2023-12-20"
   }
   maintenance_days = [
-    "MONDAY",
-    "TUESDAY",
+    "FRIDAY",
+    "SATURDAY",
   ]
 }
 ```
-Monitor Downtimes are of four types; once, daily, weekly and monthly. For more details on each type and the right arguments that go with them, check out the [argument reference][#argument-reference] and [examples](#examples) sections below.
+Monitor Downtimes are of four types; **one-time**, **daily**, **weekly** and **monthly**. For more details on each type and the right arguments that go with them, check out the [argument reference](#argument-reference) and [examples](#examples) sections below.
 
 ## Argument Reference
 
 ### Arguments Common To All Four Types of Monitor Downtimes
 
-* `account_id`- (Optional) The account in which the monitor downtime would be created. Defaults to `NEW_RELIC_ACCOUNT_ID` in the environment, if not specified.
+* `account_id`- (Optional) The account in which the monitor downtime would be created. Defaults to the value of the environment variable `NEW_RELIC_ACCOUNT_ID` (or the `account_id` specified in the `provider{}`), if not specified.
 * `name` - (Required) Name of the monitor downtime to be created.
-* `mode` - (Required) One of the four modes of operation of Monitor Downtimes - `ONE_TIME`, `DAILY`, `MONTHLY` or `WEEKLY`.
-* `monitor_guids` - (Optional) A list of GUIDs of monitors the Monitor Downtime would need to be applied to.
-* `start_time` - (Required) The time at which the Monitor Downtime would begin to operate, a timestamp specified in the ISO 8601 format without the offset - for instance, `2023-12-04T14:27:07`.
-* `end_time` - (Required) The time at which the Monitor Downtime would end operating, a timestamp specified in the ISO 8601 format without the offset - for instance, `2023-12-04T14:27:07`.
-* `timezone` - (Required) The timezone in which timestamps `start_time` and `end_time` have been specified. Valid timezones which may be specified with this argument can be found in this [list](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List), in the column '**TZ identifier**'. 
+* `mode` - (Required) One of the four modes of operation of monitor downtimes - `ONE_TIME`, `DAILY`, `MONTHLY` or `WEEKLY`.
+* `monitor_guids` - (Optional) A list of GUIDs of synthetic monitors the monitor downtime would need to be applied to.
+* `start_time` - (Required) The time at which the monitor downtime would begin to operate, a timestamp specified in the ISO 8601 format without the offset/timezone - for instance, `2023-12-20T10:48:53`.
+* `end_time` - (Required) The time at which the monitor downtime would end operating, a timestamp specified in the ISO 8601 format without the offset/timezone - for instance, `2024-01-05T14:27:07`.
+* `timezone` - (Required) The timezone in which timestamps `start_time` and `end_time` have been specified. Valid timezones which may be specified with this argument can be found in this [list](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List), under the column '**TZ identifier**'. 
 
 ### Arguments Specific Only to Certain Types of Monitor Downtimes
 
-The following arguments go only with certain types of monitor downtimes, and are hence, optional, at a resource schema level. However, some of these are required to be specified with certain types of monitor downtimes - please see notes adjoining arguments in the list below.
+The following arguments go only with certain types of monitor downtimes, and are hence, optional, at a resource schema level. However, _some of these_ are **required** to be specified with certain types of monitor downtimes - please see notes adjoining arguments in the list below, and [examples](#examples) to obtain an understanding of the usage of apt arguments with each type of monitor downtimes.
 
 * `end_repeat` - Options which may be used to specify when the repeat cycle of the monitor should end. This argument comprises the following nested arguments -
-  * `on_date` - The date on which the monitor downtime's repeat cycle would need to come to an end, a string in "DDDD-MM-YY" format.
+  * `on_date` - The date on which the monitor downtime's repeat cycle would need to come to an end, a string in `DDDD-MM-YY` format.
   * `on_repeat` - An integer that specifies the number of occurrences, after which the monitor downtime's repeat cycle would need to come to an end.
 
 -> **NOTE:** `end_repeat` **can only be used with the modes** `DAILY`, `MONTHLY` and `WEEKLY` and **is an optional argument** when monitor downtimes of these modes are created. Additionally, **either** `on_date` or `on_repeat` **are required to be specified with** `end_repeat`, but not both, as `on_date` and `on_repeat` are mutually exclusive.
 
-* `maintenance_days` - A list of days on which monthly monitor downtimes would function. Valid values which go into this list would be `"SUNDAY"`, `"MONDAY"`, `"TUESDAY"`, `"WEDNESDAY"`, `"THURSDAY"`, `"FRIDAY"` and/or `"SATURDAY"`.
+* `maintenance_days` - A list of days on which weekly monitor downtimes would function. Valid values which go into this list would be `"SUNDAY"`, `"MONDAY"`, `"TUESDAY"`, `"WEDNESDAY"`, `"THURSDAY"`, `"FRIDAY"` and/or `"SATURDAY"`.
 
--> **NOTE:** `maintenance_days` **can only be used with the mode** `MONTHLY`, and **is a required argument** with weekly monitor downtimes (if the `mode` is `WEEKLY`). 
+-> **NOTE:** `maintenance_days` **can only be used with the mode** `WEEKLY`, and **is a required argument** with weekly monitor downtimes (i.e. if the `mode` is `WEEKLY`). 
 
 * `frequency` - Options which may be used to specify the configuration of a monthly monitor downtime. This argument comprises the following nested arguments -
-    * `days_of_month` - A list of integers, specifying the days of a month on which the monthly monitor downtime would function.
+    * `days_of_month` - A list of integers, specifying the days of a month on which the monthly monitor downtime would function, e.g. [3, 6, 14, 23].
     * `days_of_week` - An argument that specifies a day of a week and its occurrence in a month, on which the monthly monitor downtime would function. This argument, further, comprises the following nested arguments - 
       * `week_day` - A day of the week (one of `"SUNDAY"`, `"MONDAY"`, `"TUESDAY"`, `"WEDNESDAY"`, `"THURSDAY"`, `"FRIDAY"` or `"SATURDAY"`).
       * `ordinal_day_of_month` - The occurrence of `week_day` in a month (one of `"FIRST"`, `"SECOND"`, `"THIRD"`, `"FOURTH"`, `"LAST"`).
 
--> **NOTE:** `frequency` **can only be used with the mode** `WEEKLY`, and **is a required argument** with monthly monitor downtimes (if the `mode` is `MONTHLY`). Additionally, **either** `days_of_month` or `days_of_week` **are required to be specified with** `frequency`, but not both, as `days_of_month` and `days_of_week` are mutually exclusive. If `days_of_week` is specified, values of **both** of its nested arguments, `week_day` and `ordinal_day_of_month` **would need to be specified** too.
+-> **NOTE:** `frequency` **can only be used with the mode** `MONTHLY`, and **is a required argument** with monthly monitor downtimes (if the `mode` is `MONTHLY`). Additionally, **either** `days_of_month` or `days_of_week` **are required to be specified with** `frequency`, but not both, as `days_of_month` and `days_of_week` are mutually exclusive. If `days_of_week` is specified, values of **both** of its nested arguments, `week_day` and `ordinal_day_of_month` **would need to be specified** too.
 
 ## Attributes Reference
 
@@ -78,7 +78,7 @@ The following attributes are exported:
 
 ### One-Time Monitor Downtime
 
-The below example illustrates creating a 'one-time' monitor downtime. 
+The below example illustrates creating a **one-time** monitor downtime. 
 
 ```hcl
 resource "newrelic_monitor_downtime" "sample_one_time_newrelic_monitor_downtime" {
@@ -89,16 +89,16 @@ resource "newrelic_monitor_downtime" "sample_one_time_newrelic_monitor_downtime"
   ]
   mode       = "ONE_TIME"
   start_time = "2023-12-04T10:15:00"
-  end_time   = "2024-01-04T10:15:00"
+  end_time   = "2024-01-04T16:24:30"
   time_zone  = "America/Los_Angeles"
 }
 ```
 
 ### Daily Monitor Downtime
 
-The below example illustrates creating a 'daily' monitor downtime. 
+The below example illustrates creating a **daily** monitor downtime. 
 
-Note that `end_repeat` has been specified in the configuration; however, this is optional, in accordance with the rules of `end_repeat` specified in the [argument reference][#argument-reference] section above.
+Note that `end_repeat` has been specified in the configuration; however, this is optional, in accordance with the rules of `end_repeat` specified in the [argument reference](#argument-reference) section above. This example uses the `on_date` nested argument of `end_repeat`, however, the other nested argument, `on_repeat` may also be used _instead_, as you may see in some of the other examples below; though both `on_date` and `on_repeat` cannot be specified together, as they are mutually exclusive.
 
 ```hcl
 resource "newrelic_monitor_downtime" "sample_daily_newrelic_monitor_downtime" {
@@ -109,7 +109,7 @@ resource "newrelic_monitor_downtime" "sample_daily_newrelic_monitor_downtime" {
   ]
   mode       = "DAILY"
   start_time = "2023-12-04T18:15:00"
-  end_time   = "2024-01-04T18:15:00"
+  end_time   = "2024-01-04T07:15:00"
   end_repeat {
     on_date = "2023-12-25"
   }
@@ -119,9 +119,9 @@ resource "newrelic_monitor_downtime" "sample_daily_newrelic_monitor_downtime" {
 
 ### Weekly Monitor Downtime
 
-The below example illustrates creating a 'weekly' monitor downtime. 
+The below example illustrates creating a **weekly** monitor downtime. 
 
-Note that `maintenance_days` has been specified in the configuration as it is required with weekly monitor downtimes; and `end_repeat` has not been specified as it is optional, all in accordance with the rules of these arguments specified in the [argument reference][#argument-reference] section above.
+Note that `maintenance_days` has been specified in the configuration as it is required with weekly monitor downtimes; and `end_repeat` has not been specified as it is optional, all in accordance with the rules of these arguments specified in the [argument reference](#argument-reference) section above.
 
 ```hcl
 resource "newrelic_monitor_downtime" "sample_weekly_newrelic_monitor_downtime" {
@@ -132,7 +132,7 @@ resource "newrelic_monitor_downtime" "sample_weekly_newrelic_monitor_downtime" {
   ]
   mode       = "WEEKLY"
   start_time = "2023-12-04T14:15:00"
-  end_time   = "2024-01-04T14:15:00"
+  end_time   = "2024-01-04T23:55:00"
   time_zone  = "US/Hawaii"
   maintenance_days = [
     "SATURDAY",
@@ -143,9 +143,9 @@ resource "newrelic_monitor_downtime" "sample_weekly_newrelic_monitor_downtime" {
 
 ### Monthly Monitor Downtime
 
-The below example illustrates creating a monthly monitor downtime.
+The below example illustrates creating a **monthly** monitor downtime.
 
-Note that `frequency` has been specified in the configuration as it is required with monthly monitor downtimes, and `end_repeat` has been specified too, though it is optional, all in accordance with the rules of these arguments specified in the [argument reference][#argument-reference] section above.
+Note that `frequency` has been specified in the configuration as it is required with monthly monitor downtimes, and `end_repeat` has been specified too, though it is optional. `frequency` has been specified with `days_of_week` comprising both of its nested arguments, `ordinal_day_of_month` and `week_day`; all in accordance with the rules of these arguments specified in the [argument reference](#argument-reference) section above. 
 
 ```hcl
 resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime" {
@@ -156,7 +156,7 @@ resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime"
   ]
   mode       = "MONTHLY"
   start_time = "2023-12-04T07:15:00"
-  end_time   = "2024-01-04T07:15:00"
+  end_time   = "2024-01-04T19:15:00"
   end_repeat {
     on_repeat = 6
   }
@@ -169,7 +169,26 @@ resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime"
   }
 } 
 ```
-
+However, the `frequency` block in monthly monitor downtimes may also be specified with its other nested argument, `days_of_month`, as shown in the example below - though both `days_of_month` and `days_of_week` cannot be specified together, as they are mutually exclusive.
+```hcl
+resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime" {
+  name = "Sample Monthly Monitor Downtime"
+  monitor_guids = [
+    "<GUID-1>",
+    "<GUID-2>",
+  ]
+  mode       = "MONTHLY"
+  start_time = "2023-12-04T07:15:00"
+  end_time   = "2024-01-04T19:15:00"
+  end_repeat {
+    on_repeat = 6
+  }
+  time_zone = "Europe/Dublin"
+  frequency {
+    days_of_month = [3, 6, 14, 23]
+  }
+} 
+```
 ## Import
 
 A monitor downtime can be imported into Terraform configuration using its `guid`, i.e.

diff --git a/website/docs/r/synthetics_alert_condition.html.markdown b/website/docs/r/synthetics_alert_condition.html.markdown
@@ -10,7 +10,7 @@ description: |-
 
 Use this resource to create and manage synthetics alert conditions in New Relic.
 
--> **NOTE:** This is a legacy resource. The [newrelic_nrql_alert_condition](nrql_alert_condition.html) resource is preferred for configuring alerts conditions. In most cases feature parity can be achieved with a NRQL query. This condition type may be deprecated in the future.
+-> **WARNING:** The `newrelic_synthetics_alert_condition` resource is deprecated and will be removed in the next major release. The resource [newrelic_nrql_alert_condition](nrql_alert_condition.html) would be a preferred alternative to configure alert conditions - in most cases, feature parity can be achieved with a NRQL query.
 
 ## Example Usage