可観測性ダッシュボードを使用する
ベータ版
この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。
プロジェクトのオブザーバビリティを構成すると、Lakebaseはテレメトリテーブル上にすぐに使えるLakeviewダッシュボードを作成するため、自分で構築することなくPostgresアクティビティの豊富なインタラクティブチャートを取得できます。これらは、知見 と Genieが使用するのと同じ Unity Catalog内のDeltaテーブル を読み取ります。
プロジェクトの モニタリング ページには2つのtabがあります。メトリクスtabは常に表示されており、単一コンピュートのライブグラフ（CPU、メモリ、接続、キャッシュヒット率）を使用して、「現在データベースは正常か？」という問いに対するセットアップ不要の回答を提供します。 Advanced Postgres Telemetry tabは、オブザーバビリティを構成すると表示され、各ダッシュボードへのリンクカードが配置されます。これらはDeltaテーブルにキャプチャされたテレメトリ上で実行されるため、再起動後も保持され、メトリクスでは答えられない質問（どのクエリーが遅いか、プランが変更されたかどうか、2つの時間間隔で何が異なるか）に回答します。
前提条件
- 可観測性が構成され、コンピュートが実行されている Lakebase Autoscaling プロジェクト。
- ダッシュボードは構成がテレメトリを最初に書き込んだときに作成されるため、オブザーバビリティを最初に設定してから数分待ってください。テーブルと同様に、テレメトリが少なくとも一度流れるまでは表示されません。
ダッシュボードを開く
Advanced Postgres Telemetry tabからプロジェクトのダッシュボードを開きます：
- プロジェクトを開き、 モニタリング に移動します。
- Advanced Postgres Telemetry tabを選択します。プロジェクトのオブザーバビリティ構成によって作成された各ダッシュボードのカードが一覧表示されます。
- カードをクリックすると、そのダッシュボードがDatabricks SQLの新しいtabで開きます。ダッシュボードは、Branchのプライマリ（読み取り/書き込み）Endpointでフィルタリングされた状態で開きます。
tabにカードではなく空の状態が表示される場合、次の2つのいずれかが欠落しています：
- 構成が割り当てられていません — プロジェクトはまだモニタリングされていません。まず、プロジェクト設定で可観測性構成を割り当てるか、作成してください。「レイクハウスへのテレメトリのキャプチャ」を参照してください。
- ダッシュボードがまだありません — 構成は割り当てられていますが、ダッシュボードはまだ作成されていません。これらは構成によってプロビジョニングされると、テレメトリが最初に流れた直後に表示されます。
ダッシュボードを直接開くこともできます。ワークスペースで [ダッシュボード] に移動し、 [Lakebase Overview] または [Lakebase Time Interval Comparison] を検索します。これらのダッシュボードはワークスペース内の通常の Lakeview ダッシュボードであるため (「The dashboards are yours」を参照)、他のダッシュボードと同様に検索可能です。
defaultのダッシュボード
可観測性構成ごとに2つのダッシュボードが作成されます。各ダッシュボードにはビューの範囲を絞り込むフィルターがあるため、必要な時間枠とコンピュートに絞り込むことができます。以下の説明のとおり、正確なフィルターとその配置場所は2つのダッシュボード間で異なります。
Lakebaseの概要
1 つ以上の Endpoint について、期間全体にわたるプロジェクトの正常性とパフォーマンスを広範に表示します。3 つのページがあります。
[概要] ページでは、コンピュート、接続、クエリー、待機状態を一目で確認できます。
グラフ | 表示内容 | 読み取り元 |
|---|---|---|
CPUとRAMの推移 | 選択した期間におけるコンピュートのCPUおよびメモリ使用量。 |
|
CPU 使用率の推移（使用コア数） | 使用コア数の推移。割り当てられたCPUに近い状態が長時間続く場合は、そのコンピュートがCPUバウンドであることを示しています。 |
|
ディスクI/Oの経時変化（MB/s） | ディスクの読み取り/書き込みthroughputの推移。 |
|
ネットワーク I/O の推移（MB/s） | 時間の経過に伴うネットワークのthroughput。 |
|
Endpoint ごとの接続数 | Endpoint別に分類された、時間経過に伴う接続数。 |
|
アクティブセッションの推移 | 期間別の並列アクティブセッション数。 |
|
経時的なクエリー実行ボリューム | 時間の経過に伴い実行されたクエリーの数。 |
|
平均クエリー実行時間（ミリ秒） | 経時的な平均クエリーレイテンシー。 |
|
呼び出し回数別のクエリー上位20件 | ウィンドウ内で最も頻繁に実行されたクエリー。 |
|
上位10クエリー：実行時間の経時変化 | 期間全体で追跡された、合計実行時間が最も長いクエリー。 |
|
上位10クエリー：平均実行時間の変化率（平均との比較） | 平均レイテンシが自身の平均から最も乖離しているクエリー（リグレッションを表面化させるため）。 |
|
クラス別の待ち時間の推移 | 待機クラス（ロック、I/Oなど）別に分類された、時間経過に伴う待機時間。どのクラスが支配的であるかは、クエリーがどこでブロックされているかを示しています。 |
|
実行速度が遅いクエリー上位 25 件 (プラン履歴) | プラン履歴にキャプチャされた、最も実行時間の遅い個別の実行。 |
|
Endpoint 別 LFC メモリ概要 | Endpoint別のローカルファイルキャッシュメモリ使用量。ワーキングセットサイズの指標となります。 |
|
クエリー分析 ページでは、単一のクエリー（ページの クエリーID フィルターで選択）を詳細に調査します：
グラフ | 表示内容 | 読み取り元 |
|---|---|---|
クエリー呼び出し数と平均実行時間の推移 | 選択したクエリーの時間の経過に伴う呼び出し回数と平均レイテンシー。 |
|
プランハッシュごとの実行時間 | プランハッシュ別の実行時間。これにより、クエリーのプランがいつ変更されたか、各プランがどのように実行されるかを確認できます。突然の遅延は、多くの場合、より低速な新しいプランハッシュとしてここに表示されます。 |
|
クエリー期間の統計 | 選択したクエリーの実行に関する期間統計。 |
|
経時的な平均I/O統計 | 選択したクエリーが時間の経過に伴い実行した平均 I/O。 |
|
実行時間が長い上位5件 | 選択したクエリーの実行速度が遅い上位 5 件。 |
|
グローバルフィルター ページには、他のすべてのページのスコープを決定するコントロール（ 日付範囲 、 Endpoint 、 Postgresデータベースを含める ）があります。
Lakebase 時間間隔の比較
選択した 2 つの時間間隔 （「前」と「後」）にわたる Endpoint のアクティビティを比較し、デプロイ後やトラフィックの急増後などの変化や回帰を明らかにします。日付範囲ピッカーで 期間 A と 期間 B を設定し、Endpoint を選択すると、2 つの期間を並べて確認できます：
グラフ | 表示内容 | 読み取り元 |
|---|---|---|
主要な待機イベント — 期間 A / 期間 B | 各期間における主要な待機イベント（横に並べて表示されたバー形式）。 |
|
時系列の待機イベント — 期間 A / 期間 B | 各期間内における待機イベントの推移。 |
|
待機イベント比較表 | 1つのテーブルに2つの期間の待機イベントを表示することで、変化が際立つようにしています。 |
|
クエリー比較テーブル | 2 つの期間のクエリー統計を並べて表示し、どのクエリーの処理が遅くなったか、または負荷が増加したかを特定します。 |
|
これらのテーブルの各列の意味については、「テレメトリテーブルリファレンス」を参照してください。
ダッシュボードを共有する
ダッシュボードは所有する下書きとして作成されるため、すぐに開いて使用できます。
他のユーザーとダッシュボードを共有する場合は、公開してください。公開時に、閲覧者に対してクエリーをどのように実行するかを選択します：
- 埋め込み資格情報 — クエリーはパブリッシャーとして実行され、アクセス権はダッシュボードレベルで管理します。これがよりシンプルなオプションです。
- 閲覧者の資格情報 — クエリーは各閲覧者として実行されるため、基盤となるテレメトリテーブルに対する権限を閲覧者に付与します。手間はかかりますが、他のユーザーが同じデータに対して独自のカスタムクエリーを実行できるようになります。
ダッシュボードのカスタマイズと拡張
ダッシュボードは自由に変更できます。それぞれが通常の Lakeview ダッシュボードであるため、他のダッシュボードと同様に編集できます。グラフのタイトル変更や削除、ビジュアライゼーションの変更、defaultフィルターの調整、あるいは同じテレメトリテーブルに基づいた（または Unity Catalog 内の他のデータと結合した）独自のグラフやページの追加が可能です。Lakeview ダッシュボードの編集方法については、ダッシュボードを参照してください。
オリジナルをそのままにしておきたい場合は、まずダッシュボードのクローンを作成し、そのコピーをカスタマイズしてください。
完全に新しいビューを構築するには、任意の Databricks SQL ツールを使用して テレメトリテーブル に対する独自のクエリーを記述します。データは、お客様自身の Unity Catalog 内の標準的な Delta です。
ダッシュボード
ダッシュボードとテレメトリテーブルは ユーザー所有 です。Lakebaseがこれらを作成しますが、所有者はユーザー自身であり、構成を削除してもこれらが削除されることはありません：
- 可観測性構成を削除しても、これらは削除されません。 構成を削除または再割り当てしても、そのダッシュボードとテレメトリテーブルはそのまま残ります。ダッシュボードに加えた編集内容は保持されます。不要になった場合は、ご自身で削除してください。
- 構成の書き込み先を変更する （カタログ、スキーマ、またはテーブルの接頭辞）場合、既存のダッシュボードはそのまま残り、新しい宛先を指す新しいダッシュボードが作成されます。以前のダッシュボードは、スタンドアロンのコンテンツとして残ります。
これらは標準的なLakeviewダッシュボードであり、お客様自身のUnity Catalog内のDeltaテーブルであるため、別の可観測性製品にロックされることなく、所有する他のコンテンツと同様に動作します。データの場所を参照してください。
次のステップ
- Lakehouse へのテレメトリの取得 — これらのダッシュボードを作成するための可観測性構成を設定します。
- テレメトリテーブルリファレンス — グラフが読み取るすべてのテーブルと列。
- 知見 を使用して問題を特定および解決する — バックグラウンドエージェントに同じテレメトリから問題を表面化させます。
- Genie を使用して問題を診断および修正する — 会話形式で問題を調査します。