Contents
Datadog の新 UI とモニター作成画面へのアクセス
Datadog は 2023 年第4四半期に実施した UI リフレッシュを、2024 年初頭から段階的にロールアウトしました（公式リリースノート: https://docs.datadoghq.com/release_notes/ui/）。この新 UI は左サイドバーと上部検索バーが統合されたシンプルなレイアウトで、操作性の向上と検索体験の高速化が主目的です。本節では、刷新後の画面構成とモニター作成までの具体的な手順を解説します。
新 UI の全体構造
新 UI では次の３つの領域に機能が集約されています。
- 左サイドバー：
Monitors、Dashboards、Eventsなど主要メニューが常時表示されます。 - 上部検索バー：全画面検索が可能で、モニター名やクエリ文字列を即座にフィルタリングできます。
- 右側設定パネル：選択中のモニター作成ステップに応じて項目が展開され、別ウィンドウへ遷移せずに完結します。
モニター作成フローの概要
Monitors → New Monitor をクリックすると、右側パネルに「Create a monitor」ウィザードが表示されます。以降は画面左上のタブで Log・Metric・Trace のいずれかを選択し、順次項目を入力していくだけです。
ログ・メトリクス・トレースのモニター設定手順
ログ・メトリクス・トレースはそれぞれ取得方法や評価ロジックが異なるため、共通で重要になるのが「対象範囲（Scope）の正確な定義」と「アラート条件」の設定です。この章では実務で頻出する２つのステップに絞って解説します。
スコープ（対象範囲）定義のポイント
スコープはモニターが監視すべきデータを限定する最初のフィルタです。正確なスコープ設定はノイズ削減とインシデント検知精度向上に直結します。
- ログの場合：構造化されたフィールド（例:
@service、@env）を組み合わせることで検索対象を絞ります。公式ドキュメント (https://docs.datadoghq.com/logs/explorer/search_syntax/) に示されている構文を利用します。 - メトリクスの場合：タグベースのフィルタ（例:
service:my-app,env:production）で対象ホストやコンテナを限定します。
具体的なログ検索クエリ例
|
1 2 |
@message:"ERROR" AND @service:my-app AND @env:production |
上記は「本番環境の my‑app サービスで出力された ERROR メッセージ」のみを対象にします。
アラート条件と評価ウィンドウの設定指針
アラート条件は数値閾値と評価期間（window）で構成され、通知タイミングを細かく制御できます。以下の表は一般的なベストプラクティスです。
| 項目 | 推奨例 | 補足説明 |
|---|---|---|
| 閾値（threshold） | > 100 requests/min |
1 分間に 100 リクエスト超過でトリガー |
| 評価期間（window） | 5 minutes |
最近 5 分の平均で判定し、バーストへの過敏さを抑制 |
| アラートレベル | warning → 80% 、 critical → 95% |
警告と重大アラートを段階的に分けることで対応負荷を最適化 |
※ 評価期間は監視対象の変動パターンに合わせて調整してください（例: 高頻度 API は 1‑2 分、バッチ系は 10‑15 分が目安）。
通知チャネルの設定と優先度制御
アラート通知はインシデント対応速度を左右します。ここでは公式にサポートされている Slack・Webhook の連携手順と、優先度管理の代替案について説明します。
Slack / Webhook 連携手順の概要
Datadog の UI から数クリックで外部ツールへの通知設定が完了します。以下は標準的な手順です。
- モニター作成画面の Notifications タブを開く
- Add Notification Channel →
Slackを選択し、ワークスペース認証を実行 - 通知したいチャンネル（例:
#alerts) を指定して保存 - 同様に Webhook を選び、カスタム URL を入力して保存
この操作は公式ドキュメント (https://docs.datadoghq.com/monitors/notifications/ ) に沿ったものです。
優先度管理の代替案（公式未サポート機能への注意）
記事中で紹介した {{override_priority}} 構文は、2024 年時点の Datadog 公式テンプレートエンジンには記載がありません。そのため、本番環境での利用は推奨できません。代わりに以下の方法を検討してください。
- severity タグの活用：メッセージテンプレート内で
{{severity}}を参照し、外部ツール（PagerDuty, Opsgenie 等）のエスカレーションポリシーと連動させる。
text
{{#is_alert}}[CRITICAL] {{message}}{{/is_alert}}
{{#is_warning}}[WARNING] {{message}}{{/is_warning}} - PagerDuty のインテグレーション設定：Datadog → Integrations → PagerDuty で「Urgency」マッピングを行い、Critical／Warning に応じたインシデントレベルが自動付与されます。
このアプローチは公式ドキュメント (https://docs.datadoghq.com/integrations/pagerduty/) が明示しているため、信頼性が高く運用リスクを低減できます。
設定の再利用：JSON エクスポート／インポート
モニター設定をチーム間で共有したり、ステージング環境へ展開したりする際に便利なのが JSON 形式によるエクスポート・インポート機能です。
エクスポート手順の概要
- 任意のモニター詳細画面右上メニューから Export as JSON を選択
- ダウンロードされた
monitor.jsonがローカルに保存されます
エクスポートファイルには名前、クエリ、閾値、通知チャンネルなど全設定が含まれます。
インポートとバージョン管理のベストプラクティス
- 左サイドバー → Monitors → New Monitor → Import タブを開く
Choose fileで先ほどエクスポートした JSON を指定し、Import をクリック- 必要に応じて API キーや環境固有のタグ（例:
account_id）を修正
インポート後は Git リポジトリ等で JSON ファイルを管理すれば、変更履歴が追跡できるだけでなく CI/CD パイプラインから自動デプロイも可能です。
代表的な JSON スニペット（抜粋）
|
1 2 3 4 5 6 7 8 |
{ "name": "Error rate alert", "type": "log_alert", "query": "@message:\"ERROR\" AND @service:my-app", "thresholds": [{ "critical": 100 }], "notifications": ["slack://#alerts?channel=..."] } |
※ type やフィールド名は公式スキーマ（https://docs.datadoghq.com/api/v1/monitors/）を参照してください。
実装チェックリストとテストフロー
設定ミスや想定外の挙動を防ぐために、作成したモニターを本番環境へ投入する前に必ず実施すべき項目と手順をまとめました。
チェック項目（Epona ガイドベース）
- 対象スコープ：ログクエリ・メトリクスタグが正しく記述されているか
- 閾値設定：critical / warning の数値と評価ウィンドウが意図通りか
- 通知チャネル：Slack／Webhook が有効化され、テストメッセージで届くことを確認
- 優先度制御：公式サポート外の構文は使用していないか、代替手段（severity タグ等）が正しく設定されているか
- JSON 再利用性：エクスポートしたファイルがインポート時に構文エラーを起こさないか
テスト実行手順の流れ
- モニター画面左下の Test ボタンで手動トリガーし、アラートが期待通りに発火することを確認
- Slack／Webhook へ届いたテスト通知の内容をチェックし、
[CRITICAL]や[WARNING]といったタグが正しく付与されているか検証 - 問題がなければ Export as JSON → 別環境（ステージング）で Import して同様のテストを実施。
- 本番環境へインポート後は、実際のトラフィックでアラート発火頻度をモニタリングし、必要に応じて閾値や評価ウィンドウを微調整
まとめ
2024‑2025 年版 Datadog UI はシンプルかつ高速なナビゲーションを提供し、モニター作成・管理のハードルを大幅に下げました。本稿で紹介した スコープ定義、閾値設定、公式サポート済みの通知連携、そして JSON による再利用 のフローを順守すれば、信頼性の高いアラート体制を迅速に構築できます。ぜひ本チェックリストとテスト手順を活用し、運用開始前に徹底的な検証を行ってください。