Insightsで問題を検出する
ベータ版
この機能はベータ版です。使用するには、ワークスペース管理者が [Previews] ページから Lakebase Insights を有効にする必要があります。Databricksプレビューの管理を参照してください。
知見は、system.lakebase から Lakebase プロジェクトのテレメトリを確認し、ユーザーからの問い合わせを必要とせずに問題や早期警告を表面化させるバックグラウンドエージェントです。これはプロジェクトごとに、管理された Databricks システム ID で、設定したスケジュールに従って、またはオンデマンドで 1 回、独立して実行されます。このページでは、プロジェクトの知見を有効にする方法を説明し、見つかった内容、それが重要な理由、対応方法など、実際の知見のエンドツーエンドの流れを順に説明します。
以前のオブザーバビリティ構成が引き続き設定されているプロジェクトでは、system.lakebase からではなく、その構成が書き込む Unity Catalog の送信先から読み取ります。「システムテーブルでの Lakebase テレメトリ」を参照してください。
知見が問題を検出し、診断します。通常、次のステップとしてGenie でこれを解決します。 Genie は診断内容を受け取り、お客様が確認した修正を実行します。また、知見を待たずに、Genieに直接問題について質問することもできます。
7日間の保存期間内における取得したテレメトリの保存に対する追加料金はありません。その他の費用は、すでにご利用中の製品にまとめられています。テレメトリのクエリーの実行は、クエリーを実行するコンピュートのカウント対象になります。Insightsの各ランは、アカウント内で消費されるコンピュートおよびモデルのトークンのカウント対象となるため、設定した分析の頻度によってその頻度が決まります。Genieへの質問は、Genieの使用量のカウント対象になります。
前提条件
- ワークスペースに対して Lakebase Observability in System Tables および Lakebase Insights のプレビューの両方が有効になっています。取得は知見の前提条件です。知見は
system.lakebaseテレメトリを読み取るため、エージェントが分析を行う前にデータが存在している必要があります。 - AWS または Azure 上の Lakebase プロジェクト（コンピュート実行中）。
知見の有効化と使用
プロジェクトの知見を有効にする
知見を有効にするには、次の 2 つのステップがあります。
- ワークスペース管理者は、 プレビュー ページから Lakebase 知見 プレビューを有効にすることができます。また、知見 では、取得したテレメトリを読み取るため、 システムテーブル での Lakebase オブザーバビリティのプレビューも必要になります。
- 分析対象とする各プロジェクトで、プロジェクトの Settings を開き、 analysis frequency を含む知見を構成します。知見は、そこで構成されるまでプロジェクトの分析を開始しません。プレビューを有効にしただけでは、すべてのプロジェクトが分析対象になるわけではありません。
エージェントの分析指示は設定できません。
知見を見つける
知見は設定したスケジュールでテレメトリを評価するため、特に新しく構成されたプロジェクトでは、問題が発生してからそれに対する知見が表示されるまでに遅延が生じる場合があります。次のスケジュールされたランを待つ代わりに、オンデマンドでエージェントを1回実行することもできます。
プロジェクトの知見を確認するには、プロジェクトを開き、 [モニタリング] に移動して、 [Insights] tab を選択します。各行には、 [Severity] （例：Minor または Moderate）、 知見 タイトル、問題が該当する [Time window] 、およびその [Status] が表示されます。
知見を読む
知見をクリックして、詳細ページを開きます。すべての知見は次の構造に従います。
- 概要 : 何が起きているのかを平易な言語で説明します。
- エビデンス ：診断を裏付ける特定のシグナルと値（テーブル形式）。
- 推奨事項 : それぞれの根拠を伴う、具体的な次のステップ。
Insightsで見つかる内容は独自のテレメトリによって異なるため、表示される知見は以下のものとは異なる場合があります。これは実際の知見であり、期待される詳細なレベルを示すために含まれています。
この例「Idle session locked out 4 updates（アイドルセッションが 4 つの更新をロックアウトしました）」では、サブタイトルに確認すべき箇所が示されています。「Idle session held locks; UPDATE waits totalled 749 s.（アイドルセッションがロックを保持していました。UPDATE 待機時間の合計は 749 秒です）」サマリーには発生した事象が説明されています。セッションがトランザクションを開き、行ロックを保持したままアイドル状態になり、データベース独自のアイドル・イン・トランザクションのタイムアウトによって強制終了されるまで、約 9.5 分間その状態が続きました。Evidence テーブルは、終了ログエントリや、4 回の呼び出しにわたる合計 749 秒の UPDATE 待機時間（通常はミリ秒単位で完了する更新に対して平均 187 秒）など、具体的な数値でそれを裏付けています。
推奨事項：
idle_in_transaction_session_timeoutを安全な値 （30～60秒など）に調整して、アイドル状態のセッションが、他のクエリーを何分もブロックすることなく、ロックを迅速に解放するようにしてください。- 未クローズのトランザクションを監査し、短いチェックアウトタイムアウトで接続プーリングを使用してください 。これにより、トランザクションを開いてアイドル状態になったクライアントが無期限にロックを保持することができなくなります。
証拠によって、関与したセッション、ロックを保持していた時間、および他のクエリーに発生させた待ち時間が特定されます。重要度は利用可能なデータから推測されるため、重要度だけで判断する前に「証拠」を読んで根本原因を確認してください。
知見に対応する
知見を読み取った後は、次の 3 つのいずれかの方法で応答します。
- エビデンスと推奨事項をガイドとして使用して、 推奨事項を自分で適用してください。
- 知見の詳細ページで Click Fix with Genie をクリックして、インタラクティブエージェントに引き渡し、会話形式での調査を継続します。これは、アクションを実行する前に推奨事項により多くのコンテキストが必要な場合や、修正にデータベース側の変更が伴う場合に役立ちます。 Genie を使用した問題の調査と修正を参照してください。
- 対応が完了したら [Status] を [Resolved] に設定し、対応が不要な場合は [Not an issue] に設定します。
検出結果が自動的に消えることがあります。
知見は独自のスケジュールで再評価を行うため、ステータスを変更していなくても、検出結果がリストから消えることがあります。たとえば、1 回限りの一括ロードなどの一時的なイベントは後のウィンドウでは再発生しない可能性があり、その背後にあるコンピュートがゼロにスケールダウンして、問題のあったセッションが消えた状態で新しく再開される場合があります。検出結果がアクティブなリストから外れたからといって、誰かがそれを [Resolved] や [Not an issue] にマークしたわけでも、何か問題が発生したわけでもありません。これは、最新の評価ウィンドウに条件がもはや存在しないことを反映しています。
プロジェクトのインサイトの設定とインサイトの表示の両方に、そのプロジェクトでの CAN MANAGE 権限が必要です。See Manage project permissions.
次のステップ
- Genie の問題の調査と修正 : 知見で検出された問題を解決するか、新しい調査を起動します。
- システムテーブルでの Lakebase テレメトリ : Insights が読み取るテーブルと現在の制限事項。
- 可観測性 ：その他の Lakebase 可観測性ツール。