ダッシュボード

レイアウトは 3 系統 - Dashboards・Timeboards・Screenboards

新規作成時に選ぶレイアウトには 3 つの系統があります (2026 年 8 月時点・出典: Dashboards)。標準の Dashboards はグリッド配置で、最大幅 12 グリッドの枠に画像・グラフ・ログなど多様なオブジェクトを置けます。Timeboards は自動レイアウトで、画面全体がひとつの時間軸に固定される設計のため、トラブルシューティングで「同じ瞬間の複数指標」を突き合わせる用途に向きます。Screenboards は自由配置で、リアルタイム更新のステータスボードや報告用の見せる画面に使われます。画面の更新間隔は表示している時間幅に連動し、たとえば 1 分表示なら 10 秒ごと、1 日表示なら 3 分ごとに更新されます。実務では標準のグリッド型から始めれば十分ですが、「時間軸が全ウィジェットで揃うことに意味がある調査画面」だけは Timeboard 的な使い方を意識すると、原因と結果の前後関係を取り違えにくくなります。

時系列だけが答えではないウィジェットの選び方

ウィジェットの代表は時系列グラフ (timeseries) ですが、公式が学習コースで最初に挙げる基本セットには、単一の数値を大きく出す query value、上位 N 件を並べる top list、表形式の table、分布を見る distribution、円グラフの pie chart などが含まれます (2026 年 8 月時点・出典: Dashboards)。選び分けの軸は「読む人が何を判断するか」です。しきい値との距離を一目で知りたいなら時系列より query value が速く、「どのホストが突出しているか」を知りたいなら top list が最短です。SLO の残余エラーバジェットを見せる SLO ウィジェットや、構成図を描く architecture 系のウィジェットもあり、SLO を運用しているチームなら専用ウィジェットで残量を常時見せておくと「今リスクを取れるか」の判断が日常会話に乗るようになります。ウィジェットを増やす前に、その 1 枚で答えたい問いを 1 行で書けるか自問するのが結局いちばん効きます。

1 枚を何十枚分にも使うテンプレート変数

サービスごと・環境ごとに同じ構成のダッシュボードを複製すると、改修のたびに全部を直す羽目になります。テンプレート変数はこの複製地獄への公式の答えで、タグのキー (例: env や service) を変数として定義しておくと、画面上部のドロップダウンで値を切り替えるだけで全ウィジェットのフィルタが一斉に切り替わります (2026 年 8 月時点・出典: Template Variables)。既定値は * (全体) で、よく使う組み合わせは saved view として保存できます。ドロップダウンに出てくる候補値は、そのダッシュボード内のウィジェットが使っているデータソースと表示時間幅から補充されるため、「候補に出てこない」ときは変数が壊れているのではなく、その期間にそのタグ値のデータが無いだけ、というのがよくある勘違いです。テンプレート変数が真価を発揮する前提はタグ付けの規約が揃っていることで、この依存関係はタグ付けの解説で詳しく扱います。

公開 URL と招待制共有、棚卸しまでが運用

ダッシュボードはログインしていない相手にも見せられます。共有方法は、公開リンクを発行する shared dashboards、グラフ単体の埋め込みコード、ウィジェットを画像として共有する方法、定期メールレポートの 4 系統です (2026 年 8 月時点・出典: Sharing)。公開リンクには誰でも見られるものと招待制 (invite-only) があり、招待制ではメールアドレスまたはメールドメイン単位でアクセスを許可し、招待ごとに有効期限を設定できます。期限が来ると現地時間の午前 0 時にアクセス権が失効します。注意すべきは、公開リンクが「社内の URL 感覚」で貼り回されがちなことです。メトリクス名やホスト名自体が内部情報であるうえ、公開共有された画面は時間幅にかかわらず 30 秒ごとに更新され続けます。組織設定の Public Sharing 画面に組織内の公開ダッシュボードと公開グラフの一覧があるので、四半期に一度そこを開いて「もう見られていない公開リンク」を失効させる棚卸しをセットにして初めて、共有機能は安全に回ります。

JSON 管理 - 複製・コード化・誤消去からの復元

ダッシュボードの定義は JSON として丸ごとコピー・インポート・エクスポートできます (2026 年 8 月時点・出典: Configure Dashboards)。これが意味するのは、ダッシュボードを「手作業の工芸品」から「コードで管理する構成物」に変えられるということです。JSON を git に置けば変更履歴が残り、レビューもできます。環境を新設したときも JSON のインポートで数分で同じ画面が立ち上がります。ただしインポートは既存の内容を全て上書きする操作なので、共同編集中の 1 枚に古い JSON を流し込む事故には注意が必要です。誤って削除した場合は Recently Deleted の一覧から復元でき、そこに入ってから 30 日で完全削除されます。「大事な 1 枚が消えた」という悲鳴には 30 日の猶予がある、と知っておくだけでも初動が変わります。

「見るための 1 枚」をどう設計するか

ウィジェットを並べること自体に技術的な難所はありません。難しいのは、作った 1 枚が 3 か月後も開かれていることです。ありがちな失敗は「入れられるものを全部入れた 1 枚」で、誰の何の判断にも最適化されていない画面は、誰にも開かれなくなります。処方箋として、目的別に 3 枚へ分ける構成を提案します。

それぞれの板は「誰がいつ開くか」が言えるから生き残ります。モニターの通知文に調査板への直リンクを埋めておくと、アラートから 1 クリックで調査が始まる動線になり、ダッシュボードは「見に行く場所」から「呼ばれて開く場所」に変わります。これが定着すると板の陳腐化も自然に見つかります。開かれない板は動線から外れている板だからです。

Notebook との使い分け

似た道具に Notebook があります。Notebook は複数人で共同編集できるリッチテキスト文書で、本文の途中に Datadog のライブグラフをそのまま埋め込めます。公式はインシデント調査の記録・ポストモーテム・ランブックなどを主用途に挙げ、Incident Report や SLO Specification のテンプレートも用意しています (2026 年 8 月時点・出典: Notebooks)。使い分けの線はこう引けます。ダッシュボードは「同じ問いを毎日見る」ための定常画面、Notebook は「1 回の調査や説明を文章と一緒に残す」ための文書です。障害調査のスクリーンショットを Slack に貼り続けるより、Notebook に時系列で貼っていけばそのままポストモーテムの素材になります。逆に、Notebook を定常監視の代わりに使い始めたら、それはダッシュボードに昇格させる合図です。両者を行き来させる運用ができると、調査の知見が使い捨てにならず組織に蓄積されていきます。