2016-02-08 10:00:00 +01:00
---
layout: "datadog"
page_title: "Datadog: datadog_monitor"
sidebar_current: "docs-datadog-resource-monitor"
description: |-
Provides a Datadog monitor resource. This can be used to create and manage monitors.
---
2017-04-10 18:20:16 +02:00
# datadog_monitor
2016-02-08 10:00:00 +01:00
Provides a Datadog monitor resource. This can be used to create and manage Datadog monitors.
## Example Usage
2017-04-10 18:20:16 +02:00
```hcl
2016-02-08 10:00:00 +01:00
# Create a new Datadog monitor
resource "datadog_monitor" "foo" {
2017-02-18 23:48:50 +01:00
name = "Name for monitor foo"
type = "metric alert"
message = "Monitor triggered. Notify: @hipchat -channel"
2016-02-08 10:00:00 +01:00
escalation_message = "Escalation message @pagerduty "
query = "avg(last_1h):avg:aws.ec2.cpu{environment:foo,host:foo} by {host} > 2"
thresholds {
2017-02-18 23:48:50 +01:00
ok = 0
warning = 1
critical = 2
2016-02-08 10:00:00 +01:00
}
2017-02-18 23:48:50 +01:00
notify_no_data = false
2016-02-08 10:00:00 +01:00
renotify_interval = 60
notify_audit = false
2017-02-18 23:48:50 +01:00
timeout_h = 60
2016-02-08 10:00:00 +01:00
include_tags = true
2017-02-18 23:48:50 +01:00
2016-02-08 10:00:00 +01:00
silenced {
"*" = 0
}
2017-02-18 23:48:50 +01:00
2016-12-07 12:05:57 +01:00
tags = ["foo:bar", "baz"]
2016-02-08 10:00:00 +01:00
}
```
## Argument Reference
The following arguments are supported:
* `type` - (Required) The type of the monitor, chosen from:
* `metric alert`
* `service check`
* `event alert`
* `query alert`
* `name` - (Required) Name of Datadog monitor
* `query` - (Required) The monitor query to notify on with syntax varying depending on what type of monitor
you are creating. See [API Reference ](http://docs.datadoghq.com/api ) for options.
* `message` - (Required) A message to include with notifications for this monitor.
Email notifications can be sent to specific users by using the same '@username' notation as events.
* `escalation_message` - (Optional) A message to include with a re-notification. Supports the '@username'
notification allowed elsewhere.
2016-12-05 10:52:59 +01:00
* `thresholds` - (Optional)
* Metric alerts:
A dictionary of thresholds by threshold type. Currently we have two threshold types for metric alerts: critical and warning. Critical is defined in the query, but can also be specified in this option. Warning threshold can only be specified using the thresholds option.
Example usage:
```
thresholds {
critical = 90
warning = 80
}
```
* Service checks:
A dictionary of thresholds by status. Because service checks can have multiple thresholds, we don't define them directly in the query.
Default values:
```
thresholds {
ok = 1
critical = 1
warning = 1
}
```
2016-02-08 10:00:00 +01:00
* `notify_no_data` (Optional) A boolean indicating whether this monitor will notify when data stops reporting. Defaults
2016-04-21 11:16:06 +02:00
to true.
2017-02-17 16:08:31 +01:00
* `new_host_delay` (Optional) Time (in seconds) to allow a host to boot and
applications to fully start before starting the evaluation of monitor
results. Should be a non negative integer. Defaults to 300.
2017-05-12 15:12:21 +02:00
* `evaluation_delay` (Optional) Time (in seconds) to delay evaluation, as a non-negative integer.
For example, if the value is set to 300 (5min), the timeframe is set to last_5m and the time is 7:00,
the monitor will evaluate data from 6:50 to 6:55. This is useful for AWS CloudWatch and other backfilled
metrics to ensure the monitor will always have data during evaluation.
2016-02-08 10:00:00 +01:00
* `no_data_timeframe` (Optional) The number of minutes before a monitor will notify when data stops reporting. Must be at
least 2x the monitor timeframe for metric alerts or 2 minutes for service checks. Default: 2x timeframe for
metric alerts, 2 minutes for service checks.
* `renotify_interval` (Optional) The number of minutes after the last notification before a monitor will re-notify
on the current status. It will only re-notify if it's not resolved.
2017-02-18 23:48:50 +01:00
* `notify_audit` (Optional) A boolean indicating whether tagged users will be notified on changes to this monitor.
2016-02-08 10:00:00 +01:00
Defaults to false.
* `timeout_h` (Optional) The number of hours of the monitor not reporting data before it will automatically resolve
from a triggered state. Defaults to false.
* `include_tags` (Optional) A boolean indicating whether notifications from this monitor will automatically insert its
triggering tags into the title. Defaults to true.
2016-05-19 10:29:23 +02:00
* `require_full_window` (Optional) A boolean indicating whether this monitor needs a full window of data before it's evaluated.
We highly recommend you set this to False for sparse metrics, otherwise some evaluations will be skipped.
Default: True for "on average", "at all times" and "in total" aggregation. False otherwise.
* `locked` (Optional) A boolean indicating whether changes to to this monitor should be restricted to the creator or admins. Defaults to False.
2016-08-18 17:54:44 +02:00
* `tags` (Optional) A list of tags to associate with your monitor. This can help you categorize and filter monitors in the manage monitors page of the UI. Note: it's not currently possible to filter by these tags when querying via the API
2016-12-07 12:05:57 +01:00
* `silenced` (Optional) Each scope will be muted until the given POSIX timestamp or forever if the value is 0.
2016-02-08 10:00:00 +01:00
To mute the alert completely:
2017-02-18 23:48:50 +01:00
2016-02-08 10:00:00 +01:00
silenced {
'*' = 0
}
2017-02-18 23:48:50 +01:00
2016-02-08 10:00:00 +01:00
To mute role:db for a short time:
2017-02-18 23:48:50 +01:00
2016-02-08 10:00:00 +01:00
silenced {
'role:db' = 1412798116
}
## Attributes Reference
The following attributes are exported:
* `id` - ID of the Datadog monitor
2016-08-22 06:00:05 +02:00
## Import
Monitors can be imported using their numeric ID, e.g.
```
$ terraform import datadog_monitor.bytes_received_localhost 2081
```