This repository aims to provide a base of generic and pre configured monitors for Datadog templated thanks to Terraform and the Datadog Provider.

• This repository provide multiple Terraform modules which could be imported, you must choose the one(s) you need.
• Each of these modules contains the most commons monitors, but they probably do not fulfill all your needs.
• You still can create some specific DataDog monitors after importing a module, it's even advisable to complete your needs.
• You will find a complete README.md on each module, explaining how to use it and its specificities if there.
• The alerting-message module could be used to easily generate a templating message to re-use and could be used multiple times to suit different use cases.
• Some monitors are disabled by default because not generic or "plug and play" enough, if you use them you will need to tweak them or in some cases disabled another one which could "duplicate" the check.

Here are the minimum versions required to use these modules of integrations.

terraform {
  required_providers {
    datadog = {
      source = "DataDog/datadog"
      version = ">= 3.1.2"
    }
  }
  required_version = ">= 0.12.31"
}

Note: if you want to use Datadog provider v2, you need to use version 3 of the modules in this repository.

Here is the last tester terraform provider version for datadog but next versions should work too.

provider "datadog" {
  api_key = var.datadog_api_key
  app_key = var.datadog_app_key
}

Both of the datadog_api_key and datadog_app_key are unique to the each datadog account. You can define them in terraform.tfvars file:

datadog_api_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
datadog_app_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Some variables need to be declared.

variable "environment" {
  type    = string
  default = "dev"
}

variable "datadog_api_key" {
  type = string
}

variable "datadog_app_key" {
  type = string
}

A quick example of alerting message module declaration:

locals {
  oncall_24x7         = "@pagerduty-MyPagerService_NBH"
  oncall_office_hours = "@pagerduty-MyPagerService_BH"
}

module "datadog-message-alerting" {
  source = "claranet/monitors/datadog//common/alerting-message"
  version = "{revision}"

  message_alert   = local.oncall_24x7
  message_warning = local.oncall_office_hours
  message_nodata  = local.oncall_24x7
}

module "datadog-message-alerting-bh-only" {
  source = "claranet/monitors/datadog//common/alerting-message"
  version = "{revision}"

  message_alert   = local.oncall_office_hours
  message_warning = local.oncall_office_hours
  message_nodata  = local.oncall_office_hours
}

module "datadog-monitors-system-generic" {
  source = "claranet/monitors/datadog//system/generic"
  version = "{revision}"

  environment = var.environment
  message     = module.datadog-message-alerting.alerting-message

  memory_message = module.datadog-message-alerting-bh-only.alerting-message
  # Use variables to customize monitors configuration
}

# Other monitors modules to declare ...
#module "datadog-monitors-my-monitors-set" {
#  source = "claranet/monitors/datadog//my/monitors/set"
#  version = "{revision}"
#
#  environment = var.environment
#  message     = module.datadog-message-alerting.alerting-message
#}

• Replace {revision} to the last git tag available on this repository.
• The // is very important, it's a terraform specific syntax used to separate git url and folder path.
• my/monitors/set represents the path to a monitors set sub directory listed below.

Contributions are always welcome.

The easiest way is to fork the repository, duplicate a module as "template" and work on it.

An internal CI will run the auto_update.sh script to compare with proposed changes and check if everything is up to date.

So, when PR is ready you will need to run this script and push its changes to pass the CI, see scripts repository for more information.

For example, this will regenerate every READMEs thanks to terraform-docs currently in v0.9.1.

• caas
  • docker
  • kubernetes
    • ark
    • cluster
    • ingress
      • vts
    • node
    • pod
    • velero
    • workload
• cloud
  • aws
    • alb
    • apigateway
    • beanstalk
    • ecs
      • common
      • ec2-cluster
      • fargate
    • elasticache
      • common
      • memcached
      • redis
    • elasticsearch
    • elb
    • kinesis-firehose
    • lambda
    • nlb
    • rds
      • aurora
        • mysql
        • postgresql
      • common
    • sqs
    • vpn
  • azure
    • apimanagement
    • app-gateway
    • app-services
    • azure-search
    • cosmosdb
    • datalakestore
    • eventgrid
    • eventhub
    • functions
    • iothubs
    • keyvault
    • load-balancer
    • mysql
    • postgresql
    • redis
    • serverfarms
    • servicebus
    • sql-database
    • sql-elasticpool
    • storage
    • stream-analytics
    • virtual-machine
  • gcp
    • big-query
    • cloud-sql
      • common
      • mysql
    • gce
      • instance
    • lb
    • memorystore
      • redis
    • pubsub
      • subscription
      • topic
• common
  • alerting-message
  • filter-tags
• database
  • elasticsearch
  • mongodb
  • mysql
  • postgresql
  • proxysql
  • redis
  • solr
  • sqlserver
  • zookeeper
• middleware
  • apache
  • kong
  • nginx
  • php-fpm
• network
  • dns
  • http
    • ssl
    • webcheck
  • tls
• saas
  • new-relic
• system
  • generic
  • unreachable