Important
この機能は ベータ版です。 ワークスペース管理者は、[ プレビュー] ページからこの機能へのアクセスを制御できます。 Manage Azure Databricks プレビューを参照してください。
プロジェクトで 観測可能性を設定する と、Lakebaseはテレメトリーテーブルの上に既製の Lakeview ダッシュボードを作成し、自分で作成しなくてもPostgresの活動を豊かでインタラクティブに表示できます。 彼らはInsightsやGenieが使うのと同じDeltaテーブルをUnity Catalogで読みます。
プロジェクトの モニタリング ページの メトリクス タブには、単一の計算(CPU、メモリ、接続、キャッシュヒット率)のライブグラフが表示されており、「今のデータベースは健康ですか?」というゼロセットアップの回答が得られます。 Advanced Postgresのテレメトリ タブも常に存在しますが、観測可能性を設定するまでは空のままです。 テレメトリが流れると、これらのダッシュボードそれぞれにリンクするカードが保持されます。 これらはDeltaテーブルにキャプチャされたテレメトリを処理するため、再起動後も持続し、Metricsが解き明かせない質問、すなわちどのクエリが遅いか、計画が変わったか、2つの時間区間で何が異なるかという疑問に答えます。
前提条件
- Lakebaseのオートスケーリングプロジェクトで 、観測可能性を設定し 、計算も実行中です。
- ダッシュボードは設定が初めてテレメトリを書き込むときに作成されるので、観測可能性を設定してから数分待ってください。 テーブルと同様に、テレメトリが少なくとも1回受信されるまでは表示されません。
ダッシュボードを開く
Advanced Postgres Telemetryタブからプロジェクトのダッシュボードを開きます:
- プロジェクトを開き、 モニタリングに行ってください。
- Advanced Postgres Telemetry タブを選択してください。プロジェクトのオブザーバビリティ設定によって作成される各ダッシュボードごとにカードが一覧表示されます。
- カードをクリックすると、Databricks SQLの新しいタブでそのダッシュボードを開きます。ダッシュボードはブランチのプライマリ(読み書き)エンドポイントにフィルタリングされて開きます。
タブにカードではなく空の状態が表示されている場合、2つの要素のいずれかが欠けています。
- 設定は割り当てられていません — プロジェクトにはまだ高度なテレメトリが設定されていません。 まずはプロジェクトの設定で観測可能性の設定を割り当てるか作成してください。 「 観察可能性の設定」を参照してください。
- まだダッシュボードはありません — 設定は割り当てられていますが、ダッシュボードはまだ作成されていません。 これらは、構成設定によってプロビジョニングされると、テレメトリが最初に流れ始めてまもなく表示されます。
Note
ダッシュボードを直接開くこともできます。 ワークスペースでダッシュボードに移動し、「Lakebase Overview 」または「Lakebase Time Interval Comparison」を検索してください。 ダッシュボードはあなたのワークスペース内の通常のLakeviewダッシュボードなので(「 ダッシュボードはあなたのもの」を参照)、他のものと同じように検索可能です。
デフォルトのダッシュボード
各観測可能性構成ごとに2つのダッシュボードが作成されます。 各ダッシュボードにはビューの範囲を限定するフィルターがあり、関心のある時間帯と計算範囲に絞ることができます。 フィルターの種類や設置場所は、以下に説明するように2つのダッシュボードで異なります。
Lakebase の概要
1つ以上のエンドポイントに関するプロジェクトの健全性とパフォーマンスを、一定期間にわたって幅広く把握すること。 3ページあります。
概要ページは、計算、接続、クエリ、待機を一目でカバーしています:
| Graph | 表示される内容 | 読み取り元 |
|---|---|---|
| CPUとRAMの時間経過 | 選択したウィンドウ全体でCPUとメモリの使用量を計算します。 | compute_gauges |
| CPU使用率(使用中のコア数) | 時間をかけて使用されているコア。 割り当てられたCPUの近くに持続的な時間がかかる場合は、計算がCPUに縛られていることを示します。 | compute_counters |
| ディスクI/Oの時間経過(MB/s) | 時間の経過に伴うディスクの読み取り/書き込みスループット | compute_counters |
| ネットワークI/Oの時間経過(MB/s) | 時間経過に伴うネットワーク スループット | compute_counters |
| エンドポイントごとの接続 | 時間の経過に伴う接続数（エンドポイント別）。 | active_session_history |
| 時間経過のアクティブセッション | 時間をかけて同時にアクティブなセッションを行ってください。 | active_session_history |
| クエリ実行ボリュームの時間経過 | 時間をかけて実行されたクエリの数。 | pg_stat_statements_counters |
| 平均クエリ実行時間(ms) | 時間経過に伴う平均クエリ遅延 | pg_stat_statements_counters |
| 通話数によるトップ20クエリ | ウィンドウで最も頻繁に実行されるクエリ。 | pg_stat_statements_counters |
| トップ10クエリ: 総実行時間の推移 | 最も多くの実行時間を消費するクエリがウィンドウ上で追跡されます。 | pg_stat_statements_counters |
| 上位10件のクエリ: 平均実行時間の変化率（平均比） | 平均レイテンシが自身の平均から最も大きく逸脱し、表面回帰にかけられるクエリです。 | pg_stat_statements_counters |
| クラス別の待ち時間の推移 | 時間の経過に伴う、待機クラス（ロック、I/O、その他）ごとの待機時間。 どのクラスが支配的かが、クエリがブロックされる場所を示します。 | wait_event_counters |
| 最も遅いクエリトップ25(プラン履歴) | プラン履歴に記録された中で最も遅い個々の実行。 | plan_history |
| エンドポイント別LFCメモリ概要 | エンドポイントごとのローカルファイルキャッシュメモリ使用量は、ワーキングセットサイズの指標となります。 | compute_gauges |
クエリ分析ページは、1つのクエリ(ページのクエリIDフィルターで選択)にドリルします:
| Graph | 表示される内容 | 読み取り元 |
|---|---|---|
| 時間経過に伴うクエリ呼び出し回数と平均実行時間 | 選択したクエリの通話量と平均レイテンシが時間をかけて変わったことです。 | pg_stat_statements_counters |
| プランハッシュごとの実行時間 | 実行時間をプランハッシュで示すので、クエリのプランがいつ変更されたのか、各プランのパフォーマンスを確認できます。 突然の遅延は、しばしば新しい、より遅いプランハッシュとして現れます。 | plan_history |
| クエリ期間統計 | 選択されたクエリの実行時間統計。 | plan_history |
| 平均I/Oの時間経過統計 | 選択したクエリが時間をかけて実行した平均I/O。 | plan_history |
| 実行時間が最も長い上位5件 | 選択したクエリの最も遅い5つの個別実行。 | plan_history |
グローバルフィルターページには、Date Range、Endpoint、Include Postgresデータベースの各ページをスコープするコントロールがあります。
湖底時間区間比較
エンドポイントのアクティビティを、選択した2つの期間（「前」と「後」）で比較し、たとえばデプロイ後やトラフィック急増後の変化やリグレッションを明らかにします。 日付範囲選択器で 期間A と 期間B を設定し、終了点を選び、2つの期間を並べて読みます:
| Graph | 表示される内容 | 読み取り元 |
|---|---|---|
| トップ待機イベント — A期 / 期B | 各期間の主な待機イベントを、横並びの棒グラフで表示します。 | wait_event_counters |
| 待機イベントの時間経過 — A期 / 期B | 各期間内での待機イベントの傾向。 | wait_event_counters |
| 待機イベント比較表 | 2つの期間の待機イベントを1つの表にまとめることで、変化が際立ちます。 | wait_event_counters |
| クエリ比較表 | 2つの期間のクエリ統計を並べて、どのクエリが遅くなったか、忙しくなったかを特定しましょう。 | pg_stat_statements_counters |
これらの表の各列が何を意味するかについては、 テレメトリ表の参照を参照してください。
ダッシュボードを共有する
ダッシュボードは自分で所有するドラフトとして作成されているので、すぐに開いて使えます。
他のユーザーとダッシュボードを共有したい場合は、公開してください。 公開時には、そのクエリの実行方法を閲覧者に選びます:
- 埋め込み資格 情報 — クエリはパブリッシャーとして実行され、アクセスはダッシュボードレベルで管理されます。 これがよりシンプルな方法です。
- ビューワーの認証情報 — クエリは各ビューアごとに実行されるため、基盤となるテレメトリーテーブルに対して権限を与えます。 これは手間がかかりますが、他の人が同じデータに対して独自のカスタムクエリを実行できるようにします。
ダッシュボードのカスタマイズと拡張
ダッシュボードはあなた自身が変更できます。 それぞれ普通のLakeviewダッシュボードなので、他のものと同じように編集が可能です。グラフのタイトル変更や削除、可視化の変更、デフォルトのフィルター調整、同じテレメトリーテーブルで支えた独自のグラフやページの追加(またはUnity Catalog内の他のデータと結合)などです。 Lakeviewダッシュボードの編集方法については「 ダッシュボード」をご覧ください。
元のものを手つかずに残したいなら、まずダッシュボードをクローンしてコピーをカスタマイズしてください。
まったく新しいビューを構築するには、Azure DatabricksのSQLツールでテレメトリーテーブルに対して独自のクエリを書きましょう。 データはあなたのUnityカタログ内の標準的なDeltaです。
ダッシュボードはあなたのものです
ダッシュボードとテレメトリーテーブルは ユーザー所有です。 Lakebaseはそれらを作成しますが、それらはあなたのものであり、設定を解除しても削除されません:
- 観察可能性の設定を削除しても、その設定自体は削除されません。 設定を削除または再割り当てしても、そのダッシュボードやテレメトリーテーブルはそのまま残ります。 ダッシュボードに加えた編集はすべて保存されます。 もう使いたくなければ自分で外してください。
- 構成の書き込み先 (カタログ、スキーマ、テーブルプレフィックス)を変更すると、既存のダッシュボードはそのままにし、新しい目的地を指す新しいダッシュボードが作成されます。 以前のダッシュボードは独立したコンテンツとして残ります。
これらは標準的なLakeviewダッシュボードやDeltaテーブルとして自分のUnity Catalogにあるため、他のコンテンツと同様に動作し、別の観察可能性製品に閉じ込められることはありません。
次のステップ
- Lakehouseへのテレメトリをキャプチャ し、これらのダッシュボードを作成するための観測可能性設定を整えます。
- テレメトリーテーブル参照 — グラフが読み取るすべてのテーブルと列。
- Insightsで問題を見つけて解決しましょう — バックグラウンドエージェントが同じテレメトリから問題を検出してもらうことができます。
- Genie に関する問題を診断して修正 します。問題を会話で調査します。
