obsdog

Datadog Fundamentals 認定 / 06 / 06

データの可視化と活用

このドメインで学ぶこと

このドメインでは、Agent やインテグレーションが集めたデータを「見る側、使う側」として活かす方法を学びます。柱は 5 つです。第 1 にホストマップで全体を俯瞰すること (色と大きさが何を表すか、Group by と Filter の使い方)。第 2 にダッシュボードで並べて読むこと (Timeboard と Screenboard の違い、ウィジェットの選び方、テンプレート変数、外部への共有)。第 3 にメトリクスクエリの構造を理解すること (from による絞り込み、時間集約と空間集約、関数)。第 4 にタグで絞り込みとグループ化を行うこと。第 5 にモニターで異常を通知すること (検出方式、評価窓と閾値、no data、シンプルアラートとマルチアラート、通知メッセージの変数、ダウンタイム) です。試験では「この目的にはどのウィジェットや機能を使うか」「このクエリは何を表しているか」「この設定でモニターはいつ発火し誰に届くか」という形で問われます。数値や既定値は 2026 年 9 月時点の公式ドキュメントに基づきます。

公式ガイドの内容範囲

  • ホストマップ
  • ダッシュボード
  • メトリクスの活用
  • タグの活用
  • モニターとアラート

重要ポイント

  • ホストマップの各オブジェクトの色は Fill by で選んだメトリクスを表し、既定は CPU 使用率で 0% の緑から 100% のオレンジへ変わる。大きさは Size by で決める。
  • ホストマップの Group by は複数指定できる。availability-zone、instance-type の順に入れると、先にゾーン、次にインスタンス種別で細分化される。
  • Timeboard は全ウィジェットが同じ時点を共有する自動レイアウトでトラブルシューティングと相関に向き、Screenboard は自由配置でステータスボードに向く。
  • テンプレート変数はタグの key で定義し、ウィジェットの from 欄に $名前 として使う。既定値は * で、選択に応じて URL に &tpl_var_名前=値 が付く。
  • メトリクスクエリでは時間集約 (rollup) が必ず適用され、表示時間幅が広がるほど 1 点が代表する時間が長くなる。空間集約は avg、sum、min、max でタグごとに結合する。
  • Query Value ウィジェットは集約結果を単一の値に縮約し、Top List はグループごとに 1 つの値を並べる。推移を見るなら Timeseries、分布を見るなら Heatmap が向く。
  • タグの包含は AND、除外は OR で組み合わさる。ダッシュボードでは from 欄でフィルタし、avg by 欄にタグの key を入れると値ごとに 1 本の線になる。
  • メトリクスモニターの評価窓の既定は 5 分。集約 average は期間平均、max は 1 点でも越えれば発火、min は全点が越えたときだけ発火する (above 閾値の場合)。
  • クエリにグループ化が無ければシンプルアラート (1 通)、あればマルチアラート (条件を満たしたグループごとに 1 通) が既定になる。
  • 通知の @ 記法は直前に半角スペースが必要で、{{#is_alert}} や {{#is_recovery}} などの条件変数で状態ごとに本文と宛先を切り替える。ダウンタイムは通知を止めるが状態遷移は止めない。

用語と概念

ホストマップ (Fill by と Size by)

ホストマップはホスト、Pod、コンテナ、クラスタを六角形のオブジェクトとして並べ、インフラ全体の状態を一目で把握するための画面です。各オブジェクトの色は Fill by で選んだメトリクスやシグナルを表し、既定では CPU 使用率が 0% の緑から 100% のオレンジへ変わります。メモリやエラーログ数に切り替えることもできます。Secondary resource を指定しない場合は Size by で大きさもメトリクスに連動させられるので、「色は CPU、大きさはエラーログ」のように 2 つの指標を同時に読めます。Filter 欄は AND、OR、NOT と wildcard の * に対応し、Group by は複数のタグを重ねて空間的に分けられます。

Timeboard と Screenboard

Datadog のダッシュボードには複数のレイアウトがあります。Timeboard は自動レイアウトで、ダッシュボード全体が単一の時点 (固定またはリアルタイム) を共有します。ある時刻に何が起きていたかを複数のグラフで突き合わせるため、トラブルシューティング、相関分析、データ探索に向きます。Screenboard は自由配置のレイアウトで、画像、グラフ、ログなど多様なオブジェクトを置けるため、リアルタイムに更新されるステータスボードや物語を語る用途に向きます。グリッド型の Dashboards レイアウトは最大幅 12 グリッドで、両者の中間的な使い方ができます。用途から逆算してレイアウトを選ぶのが基本です。

テンプレート変数

テンプレート変数は、ダッシュボード上のウィジェットをまとめて動的に絞り込むかグループ化する仕組みです。タグの key (env や service など) または属性で定義し、名前は選んだタグに合わせて自動で付きます。既定値は * (全ての値) で、利用可能な値の一覧にも常に * が含まれます。ウィジェットのクエリでは from 欄に $env のように書き、ドロップダウンで production を選べば $env を使う全ウィジェットが同時に production へ絞られます。選択は URL の &tpl_var_env=production として共有でき、値だけを埋め込みたいときは $env.value を使います。選択状態は Saved views として名前を付けて保存できます。

メトリクスクエリの構造 (時間集約と空間集約)

1 本のメトリクスクエリは、メトリクス名を選び、タグで絞り込み (from)、時間集約を決め、空間集約を決め、必要なら関数を掛ける、という順で組み立てます。時間集約は「点がピクセルより多い」問題を解くために必ず適用され、表示時間幅が長くなるほど 1 つの時間バケット (rollup) が広がって粒度は粗くなります。既定は avg で、sum、min、max、count も選べ、.rollup(max, 60) のように明示できます。空間集約は host や region などのタグで時系列を分け、各グループ内を avg、sum、min、max のいずれかで結合します。同じ max でも「時間方向の max」と「空間方向の max」は意味が違うため、グラフを読み違えないよう両者を区別することが大切です。

ウィジェットの選び方

ダッシュボードのウィジェットは「何を答えたいか」で選びます。時間とともに値がどう動いたかを見るなら Timeseries、時間集約と空間集約の結果を 1 つの数字 (KPI) にまとめるなら Query Value、どのホストやサービスが最も多いかを順位で見るなら Top List、タグをまたいだ値の分布や distribution メトリクスの広がりを見るなら Heatmap が向きます。インフラ全体の資源使用を面で見るには Hostmap ウィジェット、アラートの現状を一覧するには Monitor Summary が使えます。最速の始め方は、インストール済みインテグレーションに付属するプリセットダッシュボードをクローンして、自分の用途に合わせてウィジェットを調整する方法です。

タグによる絞り込みとグループ化

タグは付けるだけでなく、使うことで価値が出ます。ダッシュボードの from 欄にタグを入れると、そのタグを持つ全ソースにメトリクスが絞られ、avg by 欄にタグの key を入れると値ごとに 1 本の線に分かれます。何も指定しなければ全ホストの平均 1 本、from に region:eastus を入れれば東部リージョンの平均、さらに avg by に host を入れれば東部の各ホストの線、という段階的な読み方ができます。複数タグの包含は AND、除外は OR で組み合わさり、ダッシュボードでは NOT、IN、NOT IN のブール構文も使えます。ホストマップやインフラリストでは上部の Filter by と Group by、モニターでは from、excluding、avg by の各欄が同じ役割を果たします。

モニターの検出方式と評価

モニターの種類にはホストが報告しているかを見る Host、閾値と比較する Metric、インテグレーションの値や健全性を見る Integration、複数モニターを式で組み合わせる Composite などがあります。メトリクスモニターの検出方式は、静的な閾値と比べる Threshold、N 分前との差を見る Change、過去の挙動から期待範囲を学ぶ Anomaly、グループ内の外れ者を見つける Outliers、将来の値を予測する Forecast の 5 つです。評価窓の既定は 5 分で、窓内の点を average、max、min、sum のどれかで 1 つの値にまとめて閾値と比べます。閾値には Alert (必須) と Warning があり、回復閾値を別に指定することもできます。

シンプルアラートとマルチアラート

通知の単位はクエリのグループ化で決まります。グループ化が無いクエリはシンプルアラートになり、全ての報告元を集約した値が条件を満たしたときに 1 通だけ通知されます。全サーバーの平均 CPU が閾値を越えたら 1 通、という使い方です。avg by service のようにグループ化するとマルチアラートになり、条件を満たしたサービスごとに別々の通知が届きます。service と host でグループ化しつつ通知は service 単位にまとめたい場合は、通知のグループ化から host を外して件数を減らせます。マルチアラートのタイトルには発火したスコープのタグが自動で入り、本文でも {{host.name}} のようなタグ変数で対象を示せます。

通知メッセージと条件変数

通知メッセージは Markdown と変数で組み立てます。宛先は @slack-チャンネル名、@pagerduty-サービス名、@メールアドレスのような @ 記法で書き、直前には半角スペースが必要です (low@ops-team@example.com のように直結すると解釈されません)。条件変数は {{#is_alert}} と {{/is_alert}} のように開閉ペアで囲み、その中に本文と宛先を書くことで、アラート時と回復時 ({{#is_recovery}})、警告時 ({{#is_warning}})、データ欠損時 ({{#is_no_data}}) で内容や宛先を切り替えられます。モニターは同時に 1 つの状態しか持たないため、状態ベースの条件は別々のブロックに分けます。宛先の管理には通知ルールの利用が推奨されています。

ダウンタイムと no data

ダウンタイムは、計画的な保守やシャットダウンの間にモニターのアラートと通知を止める仕組みです。状態遷移そのものは止めないので、後から状態の履歴を確認できます。対象はモニター名またはモニタータグで選び、Group scope に service:web-store のような条件を足すと、そのサービスのグループだけを黙らせて他のサービスの通知は通常どおり届けられます。一方 no data は「データが来ない」状態の扱いで、ゼロとして評価する、最後の状態を維持する、NO DATA を表示する、NO DATA を表示して通知する、OK を表示する、から選びます。常に報告があるはずのメトリクスなら、欠損を通知する設定が安全です。

理解度チェック

学んだ内容を 5 問で確認します