Chronosphere Terraform provider
Terraform (opens in a new tab) is an open source, infrastructure-as-code software tool that provides a consistent workflow for managing hundreds of cloud services as a series of configuration files. Terraform relies on plugins called providers to interact with cloud providers, SaaS providers, and other APIs, including Chronosphere.
Getting started
To use the Chronosphere Terraform provider, you must install Terraform, and then you can install the provider and ensure you're authenticated for its use. For information, see Install the Chronosphere Terraform provider.
Supported resources
You can create the following resources on your Chronosphere instance with the Terraform provider:
- Dashboards
- Derived labels
- Derived metrics
- Drop rules
- Mapping rules
- Metric pools
- Monitors
- Notification policies
- Notifiers
- Recording rules
- Rollup rules
- Service accounts
- Teams
- Trace metrics rules
Prevent changes to managed resources
When you use Terraform to manage service account, notifier, dashboard, monitor, or drop rules resources, Terraform overrides any changes to these resources that users try to make elsewhere. To avoid confusion and configuration conflicts, Chronosphere prevents users from modifying such resources outside of Terraform.
When you attempt to modify a Terraform-managed resource in the Chronosphere app, Chronosphere displays a banner that explains the required use of Terraform. It also prevents you from saving any attempted changes from the user interface.
Chronosphere also prevents any attempts to modify these resources with Chronoctl or the Chronosphere API.
Validate plans with dry runs
When you run terraform plan
to generate an execution plan, Chronosphere
automatically tests configurations for resources by submitting them as dry runs. This
helps you validate your Terraform manifests and better understand failures.
Terraform provider version | Supported types for dry-run validations |
---|---|
0.34 or later | All resources |
0.33 | All resources except notifiers |
0.29 through 0.32 | Monitors, mapping rules, rollup rules, and notification policies |
0.28 and earlier | Monitors |
Dry runs can't validate resources or configurations that rely on uniqueness or the existence of other objects, because those traits can change during the dry run or before Terraform applies the configuration. For example, a dry run can't validate whether referencing another entity's ID is valid because that ID's existence isn't guaranteed.
Dry runs can therefore provide only a best-effort attempt to confirm a resource's validity.
Disable dry run validation
To prevent the dry-run validation step, set the CHRONOSPHERE_DRY_RUN_VALIDATION_DISABLED
environment variable to 1
when running terraform plan
:
CHRONOSPHERE_DRY_RUN_VALIDATION_DISABLED=1 terraform plan
Manage v2 alerts with Terraform
Chronosphere supports alerts through monitors, which replaced deprecated v2 alerts. To manage monitors with Terraform, see the monitors documentation.
Terraform supports user-specified plugin directories as an alternative to ~/.terraform.d/plugins
.
To use a different plugin directory, set the --plugin-dir
argument when calling
terraform init
.
If you still use v2 alerts, you can create and manage them with Terraform. For example,
this resource manages a Chronosphere alert that Terraform refers to as infra
:
resource "chronosphere_alert" "infra" {
# Human readable name of the alert.
name = "Infra Example alert"
# PromQL query to evaluate for the alert.
expr = "up{}"
# Interval at which to run the query.
interval = "60s"
# Arbitrary set of labels to assign to the alert.
labels = {
"priority" = "sev-1"
}
# Arbitrary set of annotations to include in alert notifications.
annotations = {
"runbook" = "http://go/default-runbook"
}
# Threshold for triggering the alert at a given severity level.
threshold {
# Severity of the threshold.
severity = "warn"
# Value to compare against the query result.
# For EXISTS or NOT_EXISTS operators, value must be set to zero or may be omitted.
value = 1.0
# Operator to use when comparing the query result versus the threshold
# value (one of GT, LT, LEQ, GEQ, EQ, NEQ, EXISTS, NOT_EXISTS).
op = "LT"
# Amount of time the query needs to fail the threshold check before
# triggering the alert.
sustain = "120s"
}
# Can define separate warn and critical thresholds for the alert.
threshold {
severity = "critical"
value = 1.0
op = "LT"
sustain = "300s"
}
# If schedule is specified, the alert is only evaluated during specific time ranges.
# Otherwise the alert is always evaluated.
schedule {
timezone = "UTC"
range {
day = "Monday"
start = "07:00"
end = "10:10"
}
}
}