Datadog アラート設定方法 2024‑2025 最新UIで作成・通知手順

Datadog Web UI へのログインと Monitors 画面への遷移

Datadog にアクセスしたら最初に行うのが認証です。組織で採用している SSO（SAML、Okta、Azure AD 等）やローカルアカウントの方式に応じた手順を把握しておくと、ログインエラーによる作業遅延を防げます。また、ログイン後すぐに Monitors 画面へ移動できれば、監視設定の作成・確認がスムーズになります。本セクションでは、実際の操作フローと注意点を解説します。

シングルサインオン（SSO）でのログイン手順

SSO を利用している場合は以下の流れで Datadog に入ります。

1. ブラウザで https://app.datadoghq.com/ にアクセスする。
2. 「Sign in with SSO」 ボタンをクリックし、組織が設定した IdP（Identity Provider）の認証画面へ遷移させる。
3. ユーザー名・パスワード、必要に応じて MFA を入力して認証を完了すると、Datadog のホームダッシュボードが表示される。

ポイント：SSO 利用時はブラウザのポップアップブロックやサードパーティ Cookie が原因で認証画面が正しく開かないことがあります。事前に「ポップアップを許可」「サードパーティ Cookie を有効化」しておくとトラブルを回避できます（※公式ドキュメント: SSO 設定手順）。

左サイドメニューから Monitors へアクセスする方法

Datadog の UI は左側に固定されたサイドバーがあり、そこから主要機能へ素早く遷移できます。

1. サイドバーの 「Monitors」 アイコン（ベルマーク）をクリックする。
2. URL が https://app.datadoghq.com/monitors に変わり、モニター一覧ページが表示される。
3. 画面右上の 「New Monitor」 ボタンから新規作成ウィザードへ進める。

ポイント：Monitors へのアクセスはロールベースで制御されています。閲覧・編集に必要な権限（例: monitor_write）は、Datadog の Team Settings → Permissions で事前に確認してください（公式ドキュメント: Access Control）。

モニター作成時のタイプ選択と推奨シナリオ

Datadog では Logs、Metrics、Trace の 3 種類のモニターが提供されており、監視対象に応じた最適な設定を選ぶことが重要です。本セクションでは各タイプの特徴と典型的な利用シーンをまとめます。

Types と推奨シナリオ（表形式）

ポイント：Logs モニターは文字列検索が高速で、開発者が直感的に条件を設定しやすい点が利点です（公式ガイド: Log Monitors）。

新規モニター作成ウィザードの概要

Datadog の「New Monitor」ボタンから開始されるウィザードは、以下の 3 ステップで構成されています。

1. モニタータイプ選択 – 「Choose a monitor type」画面で Logs / Metrics / Trace のいずれかを決定する。
2. スコープと条件設定 – 選択したタイプに合わせて Scope（対象ホストやタグ）と Alert Conditions（閾値・評価期間）を入力。
3. 通知先の登録 – 必要なチャネル（メール、Slack、PagerDuty など）を追加し、メッセージテンプレートをカスタマイズする。

「Select monitor scope」でのクエリ設定と「Set alert conditions」の構成

クエリ入力画面への導入文

Select monitor scope では監視対象となるログやメトリクスを絞り込む検索クエリを記述します。正しい構文で記述しないと、期待したデータが取得できずに無駄なアラートが発生する可能性があります。

ログ検索クエリ例（status:error AND @service:api AND @env:production）

1. 「Define the search query」フィールドへ上記のように入力する。
2. Run query ボタンでプレビューを確認し、ヒット件数やサンプルログが期待通りか検証する。

参考：Datadog の公式検索構文は @attribute:value 形式です（Log Search Syntax）。

アラート条件設定画面への導入文

Set alert conditions では「何件以上でアラートとするか」や「評価期間はどのくらいにするか」を決めます。最低でも 1 条件は必須です。

設定サンプル

• Alert when: count > 5 （過去 5 分間にエラーが 5 件以上）
• Warning when: count > 3

ポイント：評価期間はログ生成頻度と合わせて設定することが重要です。公式ガイドの「Evaluation windows」章を参照してください（Alert Conditions）。

通知先登録とメッセージテンプレートのカスタマイズ

各通知チャネルの設定手順導入文

Datadog のモニターは メール、Slack、PagerDuty など複数のチャネルへ同時に通知できます。ここでは代表的な 3 つの設定方法を簡潔にまとめます。

ベストプラクティス：Critical レベルは PagerDuty のみ、Warning は Slack とメールの組み合わせといった 重大度別ルーティング を設計すると、インシデント対応が効率化します（参考: DevelopersIO 記事「Datadog での通知設計」）。

メッセージテンプレートに関する注意点導入文

通知メッセージは受取側の可読性と自動処理を考慮して作成します。ここでは公式が推奨する変数展開と、2026 年 Zenn 記事で紹介された実務テクニックを併せて解説します。

1. 公式ドキュメントでサポートされている構文

Datadog の通知テンプレートでは {{variable}} 形式の プレースホルダー が使用可能です。優先度を上書きするための専用構文は提供されていません（過去に非公式で紹介された {{override_priority}} は現在サポート外）。代わりに {{priority}} 変数 を利用して、Datadog が自動的に割り当てた重大度を参照できます【公式: Notify your team】。

2. 可読性向上テクニック（Zenn 2026 年記事）

• Markdown 整形：*bold*、code、リストで情報を階層化。
• 絵文字プレフィックス：Slack 等では先頭に絵文字を付けると視認性が向上する（例: :rotating_light:）。
• 行ごとの変数展開：{{value}}, {{host.name}}, {{timestamp}} を使い、動的データを明示的に表示。

サンプルテンプレート（Slack 用）

「Export Monitor」から取得できる JSON の管理方法

JSON エクスポート手順導入文

モニター設定をコードとして扱うことで、変更履歴や環境間の差分を可視化できます。Datadog は UI 右上の 「Export Monitor」 ボタンから現在の設定を JSON 形式で取得できるため、Git 等でバージョン管理すると便利です。

1. 作成・編集したモニター画面右上の 「Export Monitor」 をクリック。
2. 表示された JSON をコピーし、ローカルまたはリポジトリ内に monitor_<名前>.json として保存する（例: monitor_api_error.json）。

参考：JSON の構造は公式ドキュメントで詳述されています（Export / Import Monitors API）。

Git でのバージョン管理フロー例導入文

以下は JSON を Git リポジトリで管理する際の基本的なワークフローです。コードレビューを通すことで、誤設定や意図しない変更を防げます。

JSON 編集時の注意ポイント

• query フィールドはログ検索構文に完全準拠させる。
• thresholds 配列内の warning と critical それぞれに value と alert_type を正しく設定。
• notifications に記載するメッセージは上記テンプレートと同様に変数展開が可能で、{{priority}} を利用できることを確認。

ベネフィット：IaC（Infrastructure as Code）化されたモニターは CI パイプラインで自動デプロイでき、環境間の一貫性が保たれます（公式ガイド: Monitor as code）。

運用チェックリスト：設定確認・重大度別ルーティング・トラブルシューティング

動作確認テスト手順導入文

モニターを本番環境に適用する前に、意図した通りに動作するか検証します。以下のステップでログ投入から通知まで一連の流れをテストしてください。

1. 手動で対象ログを生成：例）logger "status:error @service:api test" を対象サーバで実行。
2. Datadog の Live Tail 画面でクエリがヒットするか確認。
3. モニター設定画面の 「Test Notification」 ボタンを押し、Slack / メールへテストメッセージが届くことを検証。

重大度別ルーティング設計導入文

アラートの重要度に応じた通知先を分けることで、担当者の負荷を抑えつつ迅速な対応が可能になります。以下は一般的なルーティング例です（参考: DevelopersIO 記事「Datadog で効果的なアラート設計」）。

ベストプラクティス：各重大度で別々のテンプレートを用意し、{{priority}} 変数で自動的に優先度を付与すると運用コストが削減できます。

トラブルシューティングチェックリスト導入文

設定ミスや外部要因でモニターが期待通りに機能しないことがあります。下表はよくある障害と対処法です。

まとめ

• ログイン→Monitors 画面への遷移 は SSO 設定とサイドバー操作でシンプルに完了でき、権限チェックは必ず事前に実施。
• モニタータイプ（Logs / Metrics / Trace） を用途別に選択し、ウィザードの各ステップで正しいクエリ・条件を設定すれば、効果的な監視が構築できる。
• Select monitor scope では公式検索構文に沿ったキーワードを書き、Set alert conditions は最低 1 条件＋適切な評価期間を忘れずに入力。
• 通知先はメール／Slack／PagerDuty に登録し、{{priority}} を用いたテンプレートで可読性と自動エスカレーションを実現。
• Export Monitor から取得した JSON は Git 管理し、Pull Request のレビューで変更点を追跡すれば IaC としてのメリットが最大化する。
• 運用チェックリスト を活用し、手動テスト・重大度別ルーティング・トラブルシューティングを体系的に実施すれば、安定したアラート運用が可能になる。

本稿のサンプル JSON と設定例を参考に、ぜひ自社環境で Datadog Monitors を作成・管理してみてください。質問や不明点があれば Datadog の公式サポートまたは社内 SRE チームへお問い合わせを。