システムテーブルのLakebaseテレメトリ
ベータ版
This feature is in Beta.To use it, a ワークスペース管理者 must turn on Lakebase Observability in システムテーブル from the Previews page.See Manage Databricks previews.
Lakebase captures its observability telemetry into the system.lakebase schema, starting with advanced Postgres signals.Capture is automatic.With that preview enabled, telemetry lands in these tables while a project's コンピュート runs.There is no configuration to create, no destination to choose, and no credentials to provide.知見 and Genie read the same tables, and you can クエリー them with any Databricks tool.
Table and column names might change before general availability.
Requirements
- ワークスペースで有効にされた Lakebase Observability in システムテーブル プレビュー。
- AWS または Azure の Lakebase プロジェクト。「Postgres データベースの取得」を参照してください。
キャプチャされる内容
Lakebase records the signals you need to explain a slow or failing database, across the following tables:
キャプチャされる内容 | テーブル名 |
|---|---|
アクティブセッションと待機イベント |
|
クエリープランおよびクエリーごとの実行統計 |
|
スキーマの変更:変更内容、変更日時、変更者 |
|
データベース統計:サイズ、読み取りおよび変更された行数、セッション数 |
|
コンピュートリソースの使用状況: CPU、メモリ、キャッシュ、接続 |
|
失敗の背後にあるエラーを含む、生の Postgres Logs メッセージ |
|
レコードは 7 日間保持されます。このページの残りの部分では、各テーブルのすべての列について説明します。これらのテーブルが他のシステムテーブルの中でどのような位置づけにあるかについては、Lakebase システムテーブルリファレンスを参照してください。
アクセス
The system.lakebase tables are governed by Unity Catalog.Users with both the アカウント admin and metastore admin roles can read the telemetry and manage access to it.See Manage privileges in Unity Catalog.
アクセスはスキーマレベルで適用されるため、system.lakebaseを読み取ることができるユーザーはアカウント内のすべてのプロジェクトのテレメトリを確認できます。
マスクされたステートメントテキスト
Columns that hold statement text return <REDACTED> unless you are an アカウント admin or a member of the databricks_pii_access アカウント-level グループ.An アカウント admin creates and manages that グループ.See Create and manage the databricks_pii_access グループ and Access masked statement text.
すべてのテーブルに共通の列
以下の各テーブルには、行の取得元を識別する列が含まれています。
列 | Type | 説明 |
|---|---|---|
| STRING | 行が取得されたLakebaseプロジェクトです。 |
| STRING | 行が生成されたBranch。 |
| STRING | 行の発生元のコンピュート Endpoint。 |
| STRING | 特定のコンピュートインスタンス。コンピュートがゼロにスケールされ、再開すると、これが変更されます。 |
| TIMESTAMP | 行が記録されたとき。 |
| STRING | 当時のコンピュートのモード。たとえば、読み取り/書き込みまたは読み取り専用です。 |
_countersで終わる名前のテーブルには、行の値が累積された間隔の起動を示すprevious_ts列も含まれています。これらは、その間隔の累積値であり、ポイントインタイムの読み取り値ではありません。_gaugesで終わるテーブルは代わりにポイントインタイムの読み取りであり、previous_tsはありません。
以下のテーブルには、これらの共通列を除く列のみが一覧表示されます。
セッションアクティビティ
すべてのアクティブなバックエンドの継続的にサンプリングされたスナップショットです。これは、AWS Performance Insights や Oracle の Active Session History (ASH) と同じパターンです。セッションが待機中を含め、何らかの処理を行っている場合、ここに表示されます。
active_session_history
列 | Type | 説明 |
|---|---|---|
| LONG | このサンプルのバッチ内での順序。 |
| LONG | バックエンドのプロセス ID です。 |
| LONG | データベースのオブジェクトID。 |
| LONG | 接続しているロールのオブジェクトIDです。 |
| LONG | 実行中のクエリーを識別します。 |
| LONG | 待機イベントの内部エンコーディング。 |
| STRING | 待機イベントのカテゴリ。たとえば |
| STRING | 特定の待機イベント。例えば、 |
| LONG | バックエンドの状態。例えば、アクティブまたはアイドル。 |
| LONG | バックエンドプロセスのタイプ。 |
| LONG | 現在のトランザクションがオープンしている期間です。 |
| LONG | 現在のクエリーの実行時間。 |
| LONG | このセッションをブロックしているセッションの PID です (存在する場合)。 |
| LONG | このバックエンドが並列ワーカーである場合、並列クエリーリーダーのPID。 |
| LONG | 内部ステータスフラグ |
| LONG |
|
| LONG | 接続中のアプリケーション名のハッシュです。 |
待機イベント
集計された待機イベントのカウントと時間(active_session_historyのサンプルごとのビューを補完)。
ウェイト イベント カウンター
列 | Type | 説明 |
|---|---|---|
| LONG | 待機イベントの内部エンコーディング。 |
| STRING | 待機イベントのカテゴリー。 |
| STRING | 特定の待機イベント。 |
| LONG | この待機イベントがその間隔で何回発生しましたか。 |
| DOUBLE | この間隔における、この待機イベントに費やされた合計時間です。 |
クエリープラン
各実行のクエリープランの記録であり、完全なプランと Neon 固有のストレージ統計が含まれます。これが最も詳細なテーブルであり、通常は低速クエリーの調査の最後にたどり着く場所です。
plan_history
列 | Type | 説明 |
|---|---|---|
| LONG | この行のバッチ内での序数位置。 |
| BOOLEAN | プランに実際の実行統計 ( |
| BOOLEAN | プランにバッファの使用状況統計が含まれるかどうか。 |
| STRING | クエリーテキストを識別するハッシュ。 |
| LONG | クエリーを特定します。 |
| DOUBLE | クエリーの実行にかかった時間です。 |
| DOUBLE | プランナーが推定したクエリーのコストです。 |
| LONG | プランナーの見積もり行数です。 |
| LONG | 返された実際の行数です。 |
| LONG | この特定のプランの形状を識別します。 |
| DOUBLE | ロックの待機に費やされた時間。 |
| DOUBLE | クエリー計画の所要時間(実行とは別)。 |
| LONG | この実行における共有バッファーキャッシュのアクティビティです。 |
| LONG | 仮テーブルのローカルバッファアクティビティ。 |
| LONG | 一時ファイルのアクティビティ(例えば、大規模なソートやハッシュによるものなど)。 |
| LONG | pageserverに送信されたページリクエスト数。 |
| LONG | ページサーバーの代わりにローカルファイルキャッシュから提供されるページ数。 |
| LONG | ページサーバーのページリクエストの待機に費やされた時間 (マイクロ秒単位)。 |
| LONG | このクエリーを実行したバックエンドプロセスID。 |
| LONG | この実行がロックを待機した回数。 |
| LONG | 接続ロールとデータベースのオブジェクトID。 |
| STRING | クエリーテキスト。マスキング済み。マスクされたステートメントテキストを参照してください。 |
| STRING | The full クエリー plan, as JSON.Masked.See Masked statement text. |
| STRING | 接続ロールとデータベースの名前。 |
| STRING | 接続しているアプリケーション名とクライアントアドレス。 |
| STRING | この実行中に観測された待機イベント。 |
| STRING | クエリーで使用されているパラメーター (存在する場合) をバインドします。マスキング済み。マスクされたステートメント テキストを参照してください。 |
| STRING | この実行をブロックしたセッションのPID (存在する場合)。 |
| STRING | Branch、Endpoint、およびタイムラインの内部 Neon 識別子。 |
| DOUBLE | この実行によって消費されたCPU時間をユーザー時間とシステム時間に分割したもの。 |
| LONG | この実行中のコンテキストスイッチ |
| STRING / STRING / LONG / STRING | クエリーがトレースされたリクエストの一部であった場合の、OpenTelemetry形式のトレース識別子。 |
| LONG | 内部タイムライン識別子。 |
| BOOLEAN | この行のデータ(たとえば、大規模なプラン)が書き込まれる前に切り捨てられたかどうか。 |
クエリーの統計情報
標準のpg_stat_statements拡張機能から取得される、クエリーごとの集計統計情報。
pg_stat_statements_counters
列 | Type | 説明 |
|---|---|---|
| LONG | 接続ロールとデータベースのオブジェクトID。 |
| LONG | クエリーを特定します。 |
| BOOLEAN | この行が、PL/pgSQL関数またはプロシージャ内にネストされたものではなく、トップレベルのステートメントであるかどうか。PL/pgSQLの制限事項を参照してください。 |
| STRING | クエリーテキスト。マスキング済み。マスクされたステートメントテキストを参照してください。 |
| LONG | このクエリーが指定された間隔で実行された回数です。 |
| LONG | このクエリーが間隔内で計画された回数。 |
| LONG | 返された、または影響を受けた合計行数。 |
| DOUBLE | このクエリーの、間隔内での実行および計画に費やされた合計時間。 |
| LONG | 共有バッファキャッシュのアクティビティ。 |
| LONG | 仮テーブルのローカルバッファアクティビティ。 |
| LONG | 一時ファイルのアクティビティ。 |
| LONG | このクエリーによって生成されたライトアヘッドlogのボリューム。 |
| 混合 | このクエリーでJITが使用された場合のJIT (Just-in-Time) コンパイル統計です。 |
スキーマの変更
スキーマの変更:何が、いつ、誰によって変更されたか。これは、デプロイからでも手動編集からでも、Genie がインシデントをスキーマ変更にまで遡って追跡するために読み取るものです。
ddl_history
列 | Type | 説明 |
|---|---|---|
| LONG | この行のバッチ内での序数位置。 |
| STRING | たとえば |
| STRING | 変更されたオブジェクトの種類と名前。 |
| STRING | オブジェクトが属するPostgresスキーマです。 |
| STRING | 完全な DDL ステートメントです。マスキング済み。See Masked statement text. |
| DOUBLE | DDLステートメントの実行にかかった時間。 |
| LONG / STRING | 接続ロールのオブジェクトIDと名前。 |
| STRING | 接続アプリケーションの名前。 |
| LONG | ステートメントを実行したバックエンドプロセスID。 |
| LONG | データベースのオブジェクトID。 |
| STRING | 当時のセッションの検索パス。 |
| STRING | DDL ステートメントの構造化および解析された表現。マスキング済み。マスクされたステートメント テキストをご覧ください。 |
DDLキャプチャには実際のギャップがあります: コンピュートがゼロへのスケールから再開する直前に行われた変更が見逃される可能性があります。スキーマの変更が発生したことがわかっているにもかかわらずここに表示されない場合は、それが最も可能性の高い理由です。制限事項を参照してください。
Postgres Logs
障害の原因となる特定のエラーを含む、生のPostgres Logsメッセージ。
postgres_Logs
列 | Type | 説明 |
|---|---|---|
| LONG | この行のバッチ内での序数位置。 |
| LONG | 内部ログレベルのエンコーディング。 |
| STRING | The Logs severity, for example |
| STRING | 未定義の列を示す |
| LONG | バックエンドプロセスID、および該当する場合は並列クエリーリーダーのPID。 |
| LONG / STRING | 接続ロールのオブジェクトIDと名前。 |
| LONG / STRING | データベースのオブジェクトIDと名前。 |
| STRING | 接続しているアプリケーション名とクライアントアドレス。 |
| STRING | エラーによって参照されるスキーマ、テーブル、列、制約、またはデータ型 (Postgresに存在する場合)。 |
| STRING | 該当する場合、エラーが発生した関数。 |
| 文字列 / ロング | エラーの発生元であるPostgresソースファイルと行。 |
| STRING | ログメッセージのテキスト。 |
| STRING | Postgresで利用可能な場合は、追加の詳細、推奨される修正、およびエラーのコンテキスト。 |
| STRING | 該当する場合、エラーに関連する内部生成クエリーです。 |
| STRING | このログエントリの作成を Trigger したステートメント。マスキング済み。マスキングされたステートメントテキストを参照してください。 |
| LONG | 書き込み前に切り捨てられたフィールドがあるかどうかを示します。 |
すべてのエラータイプに対して、構造化された schema_name、table_name、column_name フィールドは入力されていません。たとえば、「列が存在しません」という解析エラー(SQLSTATE 42703)の場合、message が直接列を指定しているにもかかわらず、それらを空のままにします。これらのフィールドが入力されていることを当てにしないでください。まず message を確認してください。
コンピュートメトリクス
コンピュートレベルのリソース使用量: CPU、メモリ、ディスクおよびネットワークI/O、ローカルファイルキャッシュ (LFC)、そしてページサーバーの前に配置されるLakebaseのコンピュート側キャッシュ。
compute_counters
列 | Type | 説明 |
|---|---|---|
| DOUBLE | この間隔で、ストレージ層が書き込みの抑制に費やした時間。非ゼロ値は、書き込み量がストレージが吸収できる許容量を超過したことを意味します。 |
| DOUBLE | 最もビジーなコアおよび合計で消費されたCPU時間。 |
| DOUBLE | ディスクI/Oボリューム。 |
| DOUBLE | ネットワーク IO ボリューム。 |
| LONG | この期間のローカルファイルキャッシュのアクティビティ。 |
| LONG | このコンピュートが読み取りレプリカである場合、レプリカの再実行によってローカルファイルのキャッシュが強制排除されます。 |
compute_gauges
列 | Type | 説明 |
|---|---|---|
| LONG | 現在の先行書き込み log の位置。 |
| LONG | このコンピュートが読み取りレプリカである場合の、WALのリプレイおよび受信位置。 |
| LONG | 設定された接続制限。 |
| LONG | 過去5分、15分、60分間の推定ワーキングセットサイズ。 |
| LONG | ローカルファイルキャッシュの容量と現在の使用量。 |
| LONG | 全体のストレージ容量および現在の使用量。 |
| LONG / DOUBLE | このコンピュートがリードレプリカである場合、レプリケーションラグが発生します。 |
| DOUBLE | コンピュートのプロビジョニングされた CPU とメモリ。 |
データベースメトリクス
データベースごとのアクティビティ:変更された行、トランザクション、セッション、およびvacuumの状態。テーブルの肥大化と自動バキュームシグナルはここで確認できます。
データベースカウンター
列 | Type | 説明 |
|---|---|---|
| LONG / STRING | データベースのオブジェクトIDと名前。 |
| DOUBLE | アクティブ状態、オープンなトランザクションでのアイドル状態、および全体的な接続に費やされた時間。 |
| LONG | 検出されたデッドロック数。 |
| LONG | その期間の行レベルのアクティビティ。 |
| LONG | セッションライフサイクル数。 |
| LONG | 共有バッファキャッシュのアクティビティ。 |
| LONG | コミット済みおよびロールバック済みのトランザクション。 |
database_gauges
列 | Type | 説明 |
|---|---|---|
| LONG / STRING | データベースのオブジェクトIDと名前。 |
| LONG | このデータベースへの現在の接続数です。 |
| LONG | データベースのディスク上のサイズ。 |
| LONG | 最も古い凍結されていない行のトランザクションIDとマルチザクトIDの経過時間。上昇する値は、テーブルサイズで肥大化が視認できるようになるはるか前に、vacuumが遅れていることの最も初期の兆候です。 |
制限事項
ステートメントのキャプチャ時にパスワードがマスキングされるため、キャプチャされた CREATE ROLE には PASSWORD '***' が表示されます。マスキングはステートメント内のパスワードの検出に依存しているため、不正な形式のステートメントでは検出をすり抜ける可能性があります。
Databricksでは、OAuthロールの使用を推奨しています。これにより、Databricks IDがトークンで認証され、パスワードを入力する必要がなくなります。
次の制限が適用されます:
-
COPY操作はクエリープラン履歴にキャプチャされません。 -
PL/pgSQL関数またはプロシージャ内で実行されたクエリーは、トップレベルのステートメントとしても実行されない限り、クエリーレベルのテレメトリにはキャプチャされません。Postgres独自のステートメント追跡では、defaultでトップレベルのステートメントのみがカウントされます。
-
BranchやEndpointは、表示名(「本番運用」など)ではなく、内部ID(例:
br-odd-mud-y2icrn1h)でテレメトリや知見に表示されます。知見またはテーブルの行がどのBranchまたはEndpointを参照しているかを確認する必要がある場合は、Lakebase UIでIDをクロスリファレンスしてください。 -
テレメトリの取得を有効にするGUCは、既存のコンピュートに自動的に伝播されない場合があります。プレビューを有効にした後でテレメトリが表示されない場合は、プロジェクトに接続して次を確認してください。
SQLSHOW neon_monitor.log_capture_enabled;
SHOW databricks.o11y_exporter_enabled;両方とも
onを返す必要があります。いずれかがoffを返す場合は、コンピュート Endpoint を再起動してください。
Legacy observability configurations
テレメトリがシステムテーブルに移行する前は、独自の Unity Catalog 内のカタログおよびスキーマにテレメトリを取り込み、事前構築済みダッシュボードを提供するオブザーバビリティ設定を作成できました。既存の設定は引き続き機能し、そのダッシュボードも利用可能なままになります。新しいオブザーバビリティ設定を作成することはできなくなり、システムテーブルへの取り込みではダッシュボードが作成されません。
次のステップ
- Detect issues with 知見 : the agent that reviews this telemetry on a schedule.
- Genieに関する問題の調査と修正 :このテレメトリに関する質問をご自身の言葉で入力してください。
- Lakebaseシステムテーブルのリファレンス :他のシステムテーブルの中でこれらのテーブルがどのように位置づけられるかを示します。