Datadog as Codeの極致：Terraformで構築する「自己修復する監視基盤」の真髄
監視は「守るためのもの」ではない。「システムがどう振る舞うべきかを定義する宣言」である。
GUIでポチポチと設定したダッシュボードや、誰がいつ入れたか分からないアラート設定は、技術的負債の墓場だ。監視こそがアプリケーションやインフラと同じライフサイクルを歩むべきであり、Gitのコミット履歴の中に「なぜその閾値にしたのか」という意思が刻まれていなければならない。
今日は、DatadogをTerraformで支配し、運用コストを極限まで圧縮する「監視エンジニアの最終形態」について語ろう。
—
1. ディレクトリ構造の「解剖学」：スケーラビリティの確保
IaCで最も多い失敗は、モノリスな `main.tf` に全てを詰め込むことだ。監視リソースはサービス境界に合わせて分割し、モジュール化せよ。
推奨する階層構造は以下の通りだ。
.
├── modules/
│ ├── service-standard/ # 共通モニター（CPU高負荷、メモリリーク、レイテンシ）
│ └── service-slo/ # SLO定義とエラーバジェットの計算ロジック
├── environments/
│ ├── prod/
│ │ ├── services.tf # 各マイクロサービスの監視定義をモジュール呼び出し
│ │ └── backend.tf # state管理とterraform cloud/remote設定
│ └── staging/
└── scripts/ # Datadog APIを活用したメタデータ自動注入スクリプト
極意: `service-standard` モジュール内で `tags` を強制的に注入せよ。`env`, `service`, `team` タグがないリソースは、CIでパイプラインを即座に落とす。「検索できないメトリクスは存在しないのと同じ」だ。
—
2. モニターの「アンチパターン」を排除する：Terraform活用術
モニター設定で最もやってはならないのが「ハードコーディング」だ。
賢いモニター定義の例
resource “datadog_monitor” “high_latency” {
name = “[${var.service_name}] High Latency”
type = “query alert”
query = “avg(last_5m):avg:http.request.duration{service:${var.service_name}} > ${var.latency_threshold}”
# 異常検知（Anomaly detection）を活用し、季節性を考慮する
# 単純な閾値アラートは、即座にノイズの山になる
monitor_thresholds {
critical = var.latency_threshold
}
notify_no_data = true
renotify_interval = 60
# messageにはRunbookへのリンクを必ず含める
message = “Service {{service.name}} is slow. Check runbook: https://wiki.example.com/runbook/{{service.name}}”
}
エキスパートの視点:
`notify_no_data` を軽視してはならない。監視システムが黙り込むこと（サイレントフェイラー）は、障害発生時における最悪の事態だ。「データが来ないこと」自体を監視対象に含めるのが、プロのオブザーバビリティ設計である。
—
3. SLOによる「健全性」のコード化
監視のゴールは「アラートを減らすこと」ではない。「SLO（サービスレベル目標）を満たしているか判断すること」だ。TerraformでSLOを管理し、エラーバジェットが枯渇したときだけ人間が動くフローを作れ。
resource “datadog_service_level_objective” “web_latency_slo” {
name = “Web Service Latency”
type = “latency”
description = “SLO for web service latency”
query = “ratio(avg:http.request.duration{service:web} < 200, avg:http.request.duration{service:web})" thresholds { timeframe = "30d" target = 99.9 warning = 99.95 } } ---
4. CI/CDパイプライン：監視の「自動テスト」を導入せよ
監視のデプロイを人間が確認してはならない。以下のフローを構築せよ。
1. Terraform Plan & Validate: `terraform plan` の結果をCI上でパースし、過度なアラート設定変更や、依存関係の破壊を検知する。
2. API検証: Datadog APIを叩き、定義したタグやリソースが実際にDatadog側で期待通りに反映されているか、`datadog-cli` を使って疎通確認を行うスクリプトを走らせる。
3. 自動ロールバック: デプロイ失敗時は即座に `terraform apply` の以前のステートに戻す。
—
5. 伝説のアーキテクトからの「最後のアドバイス」
監視の現場で最も重要なのは「人間が疲弊しないこと」だ。
- ノイズの排除: アラートの閾値は、メトリクスの95パーセンタイル値から動的に算出せよ。Terraformで `var` を使い、個別の環境ごとに調整可能にしておく。
- オートスケールとの同期: インフラがオートスケールする環境では、モニターもそれに追従しなければならない。タグベースのモニター設定を徹底し、新しく立ち上がったインスタンスが自動的に既存の監視枠組みに入るようにする。
- メモリ消費の最適化: 非常に高いカーディナリティ（Uniqueなタグの組み合わせ）を持つメトリクスは、Datadogの課金とメモリ消費を爆発させる。Terraformで作成するモニターのクエリが、どのタグをベースに集計しているかを常に意識せよ。
監視は、システムという巨大な生命体の「神経系」だ。
Terraformでコード化するということは、その神経系を最適化し、自律的に進化させる回路を設計することに他ならない。
さあ、GUIから卒業し、コードでシステムの「鼓動」を制御せよ。それが、真のオブザーバビリティ・エンジニアの姿だ。