監視を「作業」にするな。「コード」に昇華せよ：Datadog × Terraform によるオブザーバビリティの完全自動化
監視設定を Datadog の GUI でポチポチと設定しているようでは、現代の高速なデリバリーサイクルにはついていけない。設定変更のたびに誰がやったかわからない「野良モニター」が増殖し、いざ障害が起きたときにアラートの嵐（アラート疲労）で真のインシデントを見逃す……そんな地獄を何度も見てきた。
監視設計とは、「システムの状態をどう定義し、どう観測するか」というアーキテクチャそのものだ。これを Terraform でコード化（IaC）し、CI/CD に組み込むことは、単なる自動化ではない。システムの信頼性を守るための「規律」をチームにインストールすることだ。
本稿では、現場の生産性を劇的に引き上げる、実戦的な Datadog Provider の運用プラクティスを叩き込む。
—
1. 守るべきディレクトリ構造：コンポーネント分離の極意
Terraform の構成が崩壊すると、監視設定の変更が全環境を破壊する。モジュール化は必須だ。以下の構造をテンプレートとして推奨する。
.
├── modules/
│ ├── datadog-service-base/ # 標準的なメトリクス監視（CPU, RAM, Disk）
│ └── datadog-service-slo/ # SLO/SLI 定義のテンプレート
├── environments/
│ ├── production/
│ │ └── main.tf # モジュールを呼び出してパラメータを流し込むだけ
│ └── staging/
└── provider.tf # datadog プロバイダー設定
ポイント: `modules/` 内にビジネスロジックを隠蔽し、各環境の `main.tf` は宣言的に書く。これにより、SRE チーム以外も「必要なアラート閾値を埋めるだけ」で監視を設定できる世界観を作るのだ。
—
2. 現場で「震えるほど役立つ」神テクニック
Datadog UI をハックする「隠れたショートカット」と運用術
- `Ctrl + K` (Command + K): コマンドパレット。Dashboards や Monitor への爆速遷移は基本だが、検索窓に `filter:managed_by:terraform` と入力して、コード管理されていない野良リソースを炙り出す習慣をつけよう。
- JSON Copy: GUI で試行錯誤したモニター設定は、そのまま「Export JSON」して Terraform の `datadog_monitor` リソースの `query` に貼り付ける。これが最速のコード化フローだ。
絶対に入れるべき VS Code プラグイン
- `HashiCorp Terraform`: もはや必須。
- `Datadog Extension for VS Code`: エディタ上でアラートの確認や Dashboards のプレビューが可能になる。コンテキストスイッチを最小化せよ。
—
3. 実践的な設定例：SLO とアラートの「コード」
単なる閾値監視（メトリクス監視）は古い。我々が管理すべきは「サービスの状態」だ。以下のコードは、エラーバジェットを考慮した SLO の雛形である。
SLOの定義：エラーバジェットの枯渇を検知する
resource “datadog_service_level_objective” “http_request_slo” {
name = “API 成功率 SLO”
type = “monitor”
description = “直近30日間で 99.9% の成功率を維持する”
# モニターのIDを紐付け
monitor_ids = [datadog_monitor.api_error_rate.id]
thresholds {
timeframe = “30d”
target = 99.9
warning = 99.95
}
}
チーム開発で役立つ「タグ付け」ルール
必ずチーム名とサービス名を強制する
resource “datadog_monitor” “api_error_rate” {
name = “API Error Rate High”
type = “metric alert”
query = “avg(last_5m):sum:http.errors{service:my-api,env:prod}.as_count() > 10”
message = < コード化しても、レビューが適当なら意味がない。以下のルールをプルリクエスト（PR）の運用に組み込め。 1. `terraform plan` の自動実行: PR を出すと自動的に Plan 結果がコメントされる環境を作る。 — Terraform で Datadog を管理するということは、「監視設定をテスト可能な資産にする」ということだ。 監視は一度作って終わりではない。リリースサイクルと共に進化し、ノイズを削ぎ落とし、本当に対応が必要な異常だけをエンジニアに届ける。そのための「規律あるコード」こそが、健全なエンジニアリングチームの証だ。 さあ、GUI のポチポチ作業を今すぐ捨てて、Git に監視の未来をコミットしよう。君たちの監視設計がコード化されるとき、システムの信頼性は次のステージへ昇華する。
2. `tflint` によるバリデーション: Datadog のリソース属性のミスを防ぐため、CI パイプラインに lint を組み込む。
3. 「監視の削除は破壊的変更」という意識: 監視を削除する際は、必ず SLO の影響度を確認し、チーム全体でレビューする。
4. コードとドキュメントの同期: 監視の目的を `message` フィールドに詳細に記述すること。将来の自分が「なぜこのアラートが鳴っているのか」を即座に理解できるようにしておく。最後に：オブザーバビリティの真髄