この記事のポイント：Datadog DashboardのWidgetが空だったときに、Queryの問題、データ未流入、タグ条件、時間範囲、Integrationなどの前提条件を順番に確認する方法を紹介します。Dashboard JSONをimportした後の表示確認や、別環境へテンプレートを展開するときにも使える手順です。

はじめに

Datadog Dashboardを作成したり、JSONからimportしたりした後、Widgetに「No Data」と表示されることがあります。

このとき、すぐに「Queryが壊れている」と考えて修正を始めると、原因の切り分けが難しくなります。Query自体は正しくても、指定した時間帯にデータがない、選択中のタグに一致するデータがない、対象のIntegrationがまだ設定されていない、といった理由でも空表示になるためです。

一方で、「この環境にはデータがないだけ」と判断し、テンプレート変数や検索条件の誤りを見落とすこともあります。

本記事では、画面のエラー、元データ、時間範囲と絞り込み条件、収集の前提という順番で確認し、最後に結果の残し方を整理します。

Datadog Dashboardの空表示を切り分けるフロー

なお、Monitorのステータスとして表示される「NO DATA」には、評価期間や通知設定などMonitor固有の確認事項があります。本記事では主に、Dashboard Widgetが空表示になった場合の切り分けを扱います。

Agentが起動しない、ポートが競合する、外向き通信ができないといった収集経路そのものの復旧手順は、本記事の対象外です。今回は、Dashboardから確認を始めたときの切り分けに範囲を絞ります。

No DataとQuery Errorは同じ状態ではない

最初に、画面で起きている状態を分けます。

表示 考えられる状態 確認先
エラーが表示される QueryやFormulaを評価できていない可能性がある Widgetの編集画面
No Data／No Results／空表示 指定した時間範囲や条件で、表示対象のデータを取得できていない 元のExplorer、時間範囲、タグ
元データも見つからない Agent、Integration、権限、対象リソースなど、収集の前提が揃っていない可能性がある 収集設定、権限、対象環境

以降、本記事ではQueryやFormulaを評価できない状態を便宜上「Query Error」、データを表示できていない状態を「空表示」と呼びます。実際の文言はWidgetやデータソースによって異なります。

例えば、検証環境に対象のS3バケットがなければ、S3関連WidgetがNo Dataになるのは自然です。一方、対象リソースが存在してメトリクスも届いているのに、タグ条件の誤りで表示されていない場合は修正が必要です。

空表示を見ただけで合否を決めず、その理由まで確認します。

Step 1：Query Errorを先に確認する

最初にWidgetの編集画面を開き、QueryやFormulaにエラーが出ていないか確認します。

Query Errorが発生している場合は、次のような箇所を見ます。

  • メトリクス名に誤りがないか
  • 集計方法とデータ型が合っているか
  • タグ検索の構文が正しいか
  • Queryで参照しているテンプレート変数が存在するか
  • Formulaが存在しないQueryを参照していないか
  • 使用している関数が対象のデータソースで利用できるか

複数のQueryやFormulaを組み合わせている場合は、いったん最小構成へ戻します。

例えば、a / b * 100のようなFormulaを使っているなら、まずQuery aとQuery bを個別に表示します。どちらか一方が空、または評価できない状態であれば、Formulaだけを見ても原因は分かりません。

タグ検索でも同じです。DatadogのメトリクスQueryでは、AND／ORを使うBoolean形式と、カンマ／!を使う記号形式を同じQuery内で混在させません。複雑な条件を一度に直すのではなく、{*}や一つのタグだけを指定した状態から条件を戻していく方が確認しやすくなります。

Step 2：元のデータソースにデータがあるか確認する

Queryが成立している場合は、Dashboardから離れて元のデータソースを確認します。

Dashboardのデータ 確認する画面 主な確認内容
Metrics Metrics Explorer／Metrics Summary メトリクス名、時間範囲、タグ、group by
Logs Log Explorer ログの流入、属性、serviceやenv、検索構文
Monitor Monitor一覧 Monitorの存在、ステータス、検索対象タグ
Process Processes 対象プロセス、ホスト、付与タグ
クラウドIntegration IntegrationとMetrics Explorer 接続状態、権限、対象サービスのメトリクス

Metrics Explorerでは、Dashboardと同じメトリクスを、まずタグ条件なしで表示します。データが表示されたら、Dashboardで使っているタグやgroup byを一つずつ追加します。

これで、元データが届いていないのか、Dashboardの条件で除外されているのかを分けられます。

Metrics Explorerの選択欄にメトリクスが出ない場合でも、直近の報告状況によって候補に表示されていない可能性があります。正式なメトリクス名が分かっている場合は直接入力し、時間範囲を広げて確認します。

LogsやProcessも、Dashboardだけを見て判断しません。Log Widgetが空であればLog Explorerで同じ時間帯のログを探し、service、env、hostなど、絞り込みに使う属性が実際に付いているか確認します。

Step 3：時間範囲を広げ、タグ条件を一つずつ確認する

元データが存在する場合は、Dashboard側の条件を確認します。

最初に時間範囲を広げます。直近15分ではデータがなくても、1時間や24時間へ広げると表示されることがあります。クラウドサービスのメトリクスなど、収集や反映に時間差があるデータでは特に有効です。

次に、タグ条件をいったん外し、最小構成から一つずつ戻します。例えば、メトリクスQueryのスコープを次の順に確認します。

{*}
{env:staging}
{env:staging,service:sample-app}

実際のメトリクス名やタグ値は環境に合わせて置き換えてください。複数の条件を一度に変更すると、どの条件が原因だったのか分からなくなります。条件を追加するたびに表示結果を確認します。

テンプレート変数を使っている場合は、次の点も確認します。

  • 選択中の値が対象データに存在するか
  • 既定値が別環境の値になっていないか
  • 変数が意図したWidgetへ適用されているか
  • MetricsとLogsなど、異なるデータソースに同じタグが付いているか
  • Query内でタグキーを重ねて指定していないか

Datadogのテンプレート変数は、選択したタグと値をQueryへ動的に適用します。$envのようにタグと値を含む形で展開される変数へ、さらに同じタグキーを付けると、意図しない検索条件になる場合があります。値だけが必要な場所では、公式ドキュメントにある$<変数名>.valueの使い方も確認します。

テンプレート変数の候補値は、Widgetが利用するデータソースと参照期間をもとに作られます。Metricsでは直近48時間が参照されるため、ドロップダウンに値がないことだけで、タグ自体が存在しないと決めつけないようにします。

Step 4：Agent、Integration、対象リソースを確認する

Queryとタグ条件に問題がなく、元データも見つからない場合は、収集の前提を確認します。

  • Datadog Agentが稼働しているか
  • 必要なIntegrationが設定されているか
  • Integrationに必要な権限があるか
  • 対象サービスのメトリクス収集が有効か
  • 対象リソースが実際に存在するか
  • 確認期間内にトラフィックやイベントが発生しているか

クラウドIntegrationが接続済みでも、すべてのサービスのデータが自動的に表示されるとは限りません。サービスや機能によっては、追加の収集設定、権限、契約条件が必要です。

例えば、ロードバランサーのメトリクスは表示されている一方で、別サービスのWidgetはNo Dataという状態があり得ます。この場合、クラウドIntegration全体が失敗していると判断するのではなく、対象サービスのリソース、収集設定、メトリクス、ディメンションを個別に確認します。

実データ確認で空表示をどう評価したか

Dashboardテンプレートを検証環境へimportし、実データを確認した際、Widgetごとに次のような違いがありました。環境を特定できる名称や値は一般化しています。

  • ロードバランサーとOSのWidgetは表示される
  • ストレージ関連WidgetはNo Data
  • Monitorサマリーには結果が表示されない

この場合、すべてを同じ原因として扱いません。

ロードバランサーのデータが表示されているため、少なくとも対象メトリクスの流入とDashboardの描画は確認できています。ストレージ関連は、対象リソースの有無、メトリクスの収集条件、時間範囲を確認します。

MonitorサマリーはメトリクスではなくMonitor検索の結果です。検証環境に、Dashboardが検索しているタグを持つMonitorが存在しなければ、空表示でも不自然ではありません。

このように、Widgetごとにデータソースと前提条件を分けることで、クラウドメトリクスの表示成功とMonitor検索の空表示を別々に評価できます。

No Dataの理由を確認結果として残す

切り分けが終わったら、「表示された／表示されなかった」だけで終わらせず、理由を記録します。

判定 記録する内容
表示確認済み 対象データ、時間範囲、利用したタグ
想定No Data 対象リソースやイベントが存在しないなどの理由
条件不一致 修正したタグ、変数、時間範囲
Query要修正 エラー内容と修正したQuery
前提未導入 必要なAgent、Integration、権限
対象環境で再確認 検証環境では確認できない理由と次の確認方法

特にテンプレートを別環境へ渡す場合は、「検証環境ではNo Dataだったが、対象環境でIntegration設定後に確認する」といった形で、確認済み範囲と次の作業を分けます。

No Dataを無理に解消しようとして、対象を広げすぎたQueryへ変更するのは避けるべきです。意図した対象だけを表示するQueryが正しく、現在その対象が存在しないのであれば、No Dataは正常な確認結果です。

最終チェックリスト

Dashboardの空表示を確認するときは、次の順番で進めます。

  1. Widget編集画面でQuery Errorがないか
  2. 複数QueryやFormulaを個別に表示したか
  3. 元のExplorerでデータの存在を確認したか
  4. 時間範囲を広げたか
  5. タグ条件を外し、一つずつ戻して確認したか
  6. テンプレート変数の選択値と既定値を確認したか
  7. AgentやIntegration、権限を確認したか
  8. 対象リソースやイベントが存在するか確認したか
  9. 空表示の理由と次の確認方法を記録したか

まとめ

Datadog DashboardのNo Dataは、必ずしも設定失敗を意味しません。

Query Error、元データの不在、時間範囲、タグ条件、テンプレート変数、Integrationなどの前提を順番に確認することで、原因を切り分けやすくなります。

すべてのWidgetを無理に表示させるのではなく、「なぜ表示されていないのか」「どこまで確認できたのか」「次にどの環境で何を確認するのか」を説明できる状態にしておくことが、Dashboardを安全に運用・横展開するうえで重要です。

最後までお読みいただき、ありがとうございました。

参考資料