こんにちは！プロダクトの成長とともに増えていく「監視設定のジャングル」に、一人で迷い込んでため息をついていませんか？
「ダッシュボードをポチポチ手動で作ったけれど、誰が何の目的で作ったか分からない…」
「ステージング環境と本番環境でモニターの設定が微妙にズレていて、本番障害を見逃した…」
そんな地獄のような運用からあなたを救い出すのが、TerraformによるDatadogの完全コード管理（IaC）です。
これをマスターすれば、監視の変更もすべてPull Request（PR）のレビュー経由で行えるようになり、毎日の作業が劇的に楽になりますよ。今日は、現場で即効性のあるベストプラクティスを、優しく丁寧に紐解いていきましょう。
—
1. なぜDatadogをTerraformで管理すべきなのか？
まず前提として、DatadogのUIからポチポチとモニターやダッシュボードを作るのは、小規模なうちは手軽で良いのですが、システムがスケールするにつれて以下の「技術的負債」を生みます。
- ブラックボックス化: 「なぜこのアラート閾値になっているのか」のコンテキストが消える。
- 環境間のドリフト: 本番と検証で設定が異なり、テストの意味がなくなる。
- 復旧の困難さ: 障害時にうっかり設定を消してしまった場合、手動での復旧はヒューマンエラーの元。
コード（Terraform）で管理すれば、「監視のバージョン管理」「レビュー文化の適用」「環境の複製（マルチテナント・マルチリージョン対応）」が一気に手に入ります。オブザーバビリティの信頼性は、監視基盤自体の信頼性の上にしか成り立たないのです。
—
2. 準備：Datadog Providerの基本セットアップ
まずは、TerraformからDatadogを操作するための認証設定を行います。
Datadog側で以下の2つのキーを発行しておいてください。
1. API Key: Datadogにデータを送ったり設定を操作したりするため。
2. App Key: DatadogのAPIを通じてリソース（モニターやダッシュボード）を読み書きするため。
ディレクトリ構成のベストプラクティス
大規模化しても破綻しない、モジュール化を見据えた王道のディレクトリ構成はこれです。
terraform-datadog/
├── modules/
│ ├── monitor_http/ # 再利用可能なHTTP監視モジュール
│ └── dashboard_app/ # アプリケーション用ダッシュボードモジュール
├── environments/
│ ├── stg/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── terraform.tfvars
│ └── prd/
│ ├── main.tf
│ ├── variables.tf
│ └── terraform.tfvars
└── versions.tf # プロバイダーのバージョン固定
基本のプロバイダー設定 (`versions.tf`)
まずはTerraformとDatadog Providerのバージョンを固定します。ここをサボると、将来のアップデートで突然Applyが通らなくなる事故が起きるので必ず書きましょう。
versions.tf
terraform {
required_version = “>= 1.5.0”
required_providers {
datadog = {
source – “DataDog/datadog”
version = “~> 3.30.0”
}
}
}
provider “datadog” {
# APIキーとAppキーは環境変数（DATADOG_API_KEY, DATADOG_APP_KEY）から自動読み込みさせます
# ベアの文字列をここに直書きするのは絶対にNGですよ！
api_url = “https://api.datadoghq.com/” # 欧州リージョンの場合は .eu に変更
}
—
3. HelloWorld：モニターとダッシュボードをコード化する
それでは、実際に最も重要で基礎的なセットアップとして、「HTTPステータスコードエラーを検知するモニター」と「最低限のサービス概要ダッシュボード」をコード化してみましょう。
`environments/stg/main.tf` に以下のように記述します。
environments/stg/main.tf
1. 接続断や5xxエラーを検知するモニターの定義 ローカルで動くだけではまだプロの仕事とは言えません。チーム全員で安全に監視をアップデートするために、GitHub Actionsを使ったCI/CDパイプラインを組みましょう。 ここで重要なのは、「PR作成時に `terraform plan` の結果をコメントで自動投稿させ、マージされたら自動で `terraform apply` する」というフローです。 .github/workflows/terraform-datadog.yml on: paths: pull_request: paths: jobs: steps: uses: actions/checkout@v3 uses: hashicorp/setup-terraform@v2 env: id: plan # PRの場合は、Planの結果をコメントしてレビューしやすくする uses: actions/github-script@v6 \`\`\`hcl\n `; if: github.ref == ‘refs/heads/main’ && github.event_name == ‘push’ このパイプラインを導入すれば、「誰がいつ監視アラートの閾値を変更したか」がGitの履歴として完全に残り、コードレビューという安全網を通すことができます。 — TerraformによるDatadog管理に慣れてきたら、次のステップとして「モジュール化（`modules/` の活用）」に挑戦してください。 監視設計をコード化することは、チームの心理的安全性を高める最高の投資です。
resource “datadog_monitor” “http_check_fail” {
name = “[Stg] API Gateway HTTP Error Rate is High”
type = “metric alert”
message = <
name: “Datadog Terraform CI/CD”
push:
branches:
branches:
terraform:
name: “Terraform Apply / Plan”
runs-on: ubuntu-latest
defaults:
run:
working-directory: environments/prd
with:
terraform_version: 1.5.0
DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
DATADOG_APP_KEY: ${{ secrets.DATADOG_APP_KEY }}
run: terraform init
env:
DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
DATADOG_APP_KEY: ${{ secrets.DATADOG_APP_KEY }}
run: terraform plan -no-color
continue-on-error: false
if: github.event_name == ‘pull_request’
with:
script: |
const output = `Terraform Plan 📝\`${{ steps.plan.outcome }}\`
Show Plan
${{ steps.plan.outputs.stdout }}
\`\`\`
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: output
})
env:
DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
DATADOG_APP_KEY: ${{ secrets.DATADOG_APP_KEY }}
run: terraform apply -auto-approve先輩エンジニアからのアドバイス：さらなる高みを目指すあなたへ
例えば、「どのマイクロサービスでも共通して持たせるべき標準モニター（CPU高騰、メモリ高騰、HTTP 5xxエラー）」をモジュール化しておけば、新しいサービスを生み出すときはたった数行のコードを呼び出すだけで、全社基準の高品質なオブザーバビリティが即座に担保できるようになります。
今日からあなたのプロジェクトでも、ポチポチ作業を卒業して、美しいIaCの世界へ踏み出してみませんか？応援しています！