🌟
Datadog Monitor 小技集：Terraformで実現する効果的なアラート設定と運用術

2025/07/15に公開
 はじめにサービス運用におけるエラー検知と通知は、システムの健全性を保つ上で最も重要な要素の一つです。適切なアラートは迅速な対応を可能にし、ビジネスへの影響を最小限に抑えます。
本記事では、Datadogのモニター機能を最大限に活用し、Terraformを使ってエラー通知を劇的に改善する具体的な小技を、実践的な設定例を交えて解説します。DatadogのGUIでポチポチ設定するのも悪くありませんが、本番環境と検証環境で設定を揃えたり、変更履歴を追跡したりする際には、TerraformのようなInfrastructure as Code (IaC) ツールで管理することが有利になります。

 1. 「何が起きているか」を瞬時に伝えるモニター名とタイプまず、モニター名とタイプの設定から始めましょう。Terraformで記述することで、複数環境での設定の共通化や、変更管理が容易になります
resource "datadog_monitor" "xxx_backend_error_logs" {
  name = ":warning: [${local.env}] XXAPI (api.example.com) でエラーが発生しました"
  # ...
}
絵文字の活用: :warning: のような絵文字は視覚的に緊急度を伝え、他の通知と区別しやすくなります。
サービス名の特定: XXAPI (api.example.com) のように具体的なサービス名やエンドポイントを記述することで、担当者が迅速に判断できます。
モニタータイプ：適切な監視種別を選ぶ
今回はログからエラーを検知するため、"log alert" を使用します。
resource "datadog_monitor" "admin_backend_error_logs" {
  # ...
  type = "log alert"
  # ...
}
最近のDatadogでは、GUIで設定したモニターを直接Terraformコードとしてエクスポートする機能が提供されています（スクリーンショット参照）。

 2. 「次に何をすべきか」を明確にする通知メッセージ
 2-1. Slackメンションと緊急性の強調アラートメッセージは、問題発生時の状況把握と初動対応に直結する最も重要な部分です。単なるエラーメッセージの羅列ではなく、「誰が、何を、どうすれば良いか」がわかるように設計しましょう。Terraformのhere-doc記法 (<<-EOT ... EOT) を使うことで、複数行にわたる複雑なメッセージも管理しやすくなります。
message = <<-EOT
  @slack-xxx_${local.env}

  {{#is_alert}}
  <!subteam^S00000000>
  🚨 **XXXサービスでエラーが発生しました**
  {{/is_alert}}
  {{#is_recovery}}
  ✅ モニターが復帰しました
  {{/is_recovery}}
EOT
Slackチャンネル: @slack-xxx_${local.env} で、環境に応じた適切なSlackチャンネルに通知を送ります。local.envを使うことで、環境ごとに異なるSlackチャンネルへの通知を自動化できます。
サブチームメンション: <!subteam^S00000000> のように特定のSlackユーザーグループにメンションすることで、確実に担当チームに通知を届け、迅速な対応を促します。
💡小技：SlackユーザーグループIDの探し方（最新版）:

SlackのデスクトップアプリまたはWeb版で、以下の手順でユーザーグループIDをコピーできます。
左サイドバーの「その他」をクリック（点が3つ並んだアイコンの場合もあります）。
「メンバーディレクトリ」を選択。
上部のタブで「チームとユーザーグループ」を選択。
左側のメニューで「ユーザーグループ」を選択。
目的のユーザーグループを見つけてクリックし、そのグループのプロフィールを開きます。
プロフィール画面の右上にある「...」（その他）アイコンをクリック。
「ユーザーグループIDをコピーする」を選択すると、SXXXXXXXXのような形式のIDがクリップボードにコピーされます。

 2-2. アラート時と復旧時のメッセージ分岐Datadogのメッセージテンプレートでは、{{#is_alert}}（アラート発生時のみ表示）と {{#is_recovery}}（アラート復旧時のみ表示）という条件ブロックが利用できます。これらを活用することで、通知を見た人が現在の状況（問題発生中か、解決済みか）を正確に把握できるようになります。
message = <<-EOT
  # ...
  {{#is_alert}}
  🚨 **XXサービスでエラーが発生しました**
  # 🚨 エラー発生時に表示したい詳細情報
  {{/is_alert}}

  {{#is_recovery}}
  ✅ モニターが復帰しました
  📍 検知：{{first_triggered_at}} / 解消：{{last_triggered_at}}
  ⏱ 継続時間：{{triggered_duration_sec}} 秒
  {{/is_recovery}}
EOT
アラート時: 問題の詳細にフォーカスした情報（後述）を記述します。
復旧時: {{first_triggered_at}} (初回検知時刻)、{{last_triggered_at}} (解消時刻)、{{triggered_duration_sec}} (アラート継続時間) といった変数を含めることで、アラートがどのくらいの期間継続したかを一目で確認できます。これはインシデントの振り返りや、今後の改善策を検討する上で非常に役立つ情報です。

 2-3. エラー調査に役立つ詳細情報の埋め込みここが最も重要なポイントであり、運用の効率を大きく左右する「小技」です。ただ「エラーが出た」と通知するだけでなく、エラーを特定し、調査するための具体的な情報をメッセージに含めましょう。Datadogのログモニターでは、ログに含まれるカスタム属性（log.attributes.xxx）を自由にメッセージに埋め込むことができます。
message = <<-EOT
  # ...
  🏢 **影響範囲**
  ・テナント名 : {{log.attributes.tenant.companyname}}
  ・テナントID : {{log.attributes.tenant_id}}
  ・アカウントID : {{log.attributes.account_id}}

  🗒️ **リクエスト情報**
  ・URL : [{{log.attributes.method}}] {{log.attributes.uri}}
  ・Git Commit : {{log.attributes.git_commit}}

  {{log.message}}
  # ...
EOT
影響範囲の特定: tenant.companyname、tenant_id、account_id など、アプリケーションが出力するログに埋め込んだカスタム属性を通知に含めることで、「どの顧客の、どの操作で」エラーが発生したかを迅速に把握できます。これは、顧客影響の判断、再現テストの実施、関連ログの検索といった初動対応の効率を劇的に向上させます。
リクエスト情報: エラー発生時の method（HTTPメソッド）や uri（リクエストURL）、さらにはデプロイ時の git_commit（Gitコミットハッシュ）を含めることで、どのリクエストが、どのバージョンのコードでエラーを引き起こしたのかを特定しやすくなります。

 まとめ本記事では、Terraformを使ったDatadog Monitorの設定を通じて、より効果的で運用しやすいエラー通知システムを構築するための具体的な「小技」を解説しました。
はじめに

1. 「何が起きているか」を瞬時に伝えるモニター名とタイプ

2. 「次に何をすべきか」を明確にする通知メッセージ

2-1. Slackメンションと緊急性の強調

2-2. アラート時と復旧時のメッセージ分岐

2-3. エラー調査に役立つ詳細情報の埋め込み

まとめ

Discussion
