Insightsで問題を検出する

備考

ベータ版

この機能はベータ版です。使用するには、ワークスペース管理者が [Previews] ページから Lakebase Insights を有効にする必要があります。Databricksプレビューの管理を参照してください。

知見は、system.lakebase から Lakebase プロジェクトのテレメトリを確認し、ユーザーからの問い合わせを必要とせずに問題や早期警告を表面化させるバックグラウンドエージェントです。これはプロジェクトごとに、管理された Databricks システム ID で、設定したスケジュールに従って、またはオンデマンドで 1 回、独立して実行されます。このページでは、プロジェクトの知見を有効にする方法を説明し、見つかった内容、それが重要な理由、対応方法など、実際の知見のエンドツーエンドの流れを順に説明します。

以前の監視構成でスケジュールされた知見ジョブは停止されており、スケジュールは移行されません。これらの構成は、テレメトリを Unity Catalog の配信先に書き込まなくなりました。ダッシュボードはヒストリカルデータを保持しますが、新しいデータは受け取りません。引き続き知見を取得するには、 設定 で知見をオンにし、各プロジェクトの分析頻度を設定します。「システムテーブルの Lakebase テレメトリ」を参照してください。

知見が問題を検出し、診断します。通常、次のステップとしてGenie でこれを解決します。 Genie は診断内容を受け取り、お客様が確認した修正を実行します。また、知見を待たずに、Genieに直接問題について質問することもできます。

注記

7日間の保存期間内における取得したテレメトリの保存に対する追加料金はありません。その他の費用は、すでにご利用中の製品にまとめられています。テレメトリのクエリーの実行は、クエリーを実行するコンピュートのカウント対象になります。Insightsの各ランは、アカウント内で消費されるコンピュートおよびモデルのトークンのカウント対象となるため、設定した分析の頻度によってその頻度が決まります。Genieへの質問は、Genieの使用量のカウント対象になります。

前提条件

• ワークスペースで Lakebase知見 プレビューを有効にする必要があります。ワークスペース管理者は、 プレビュー ページから有効にできます。
• AWS または Azure 上に Lakebase プロジェクトがあり、コンピュートが実行されている必要があります。
• インサイトを構成してその結果を表示するには、プロジェクトに対する CAN MANAGE 権限が必要です。プロジェクトの権限を管理する」を参照してください。

知見の有効化と使用

プロジェクトの知見を有効にする

知見を設定するには、次のステップを完了してください：

1. Lakebase Insights プレビューがまだ有効になっていない場合は、ワークスペース管理者にプレビューページから有効にするように依頼してください。以前に知見を使用したワークスペースには既にこのプレビューがあります。以前の名前は Lakebase Advanced Postgres Telemetry でした。知見はsystem.lakebaseのテレメトリを分析するため、このプレビューを有効にすると、そのプレビューがまだ有効になっていない場合、 システムテーブルでのLakebaseの可観測性 も有効になります。
2. 分析したいプロジェクトごとに、その 設定 を開き、 知見 をオンにします。知見の実行頻度を設定したり、オンデマンドで実行したりできます。

分析頻度 のdefaultは24時間ごとです。スケジュールされたランをスキップし、オンデマンドでランをTriggerしたときにのみプロジェクトを分析するには、 [ スケジュールなし、手動でTrigger ] を選択します。エージェントの分析指示は構成できません。

知見を見つける

知見は設定したスケジュールでテレメトリを評価するため、問題の発生と知見の表示の間に遅延が発生します。特に新しく構成されたプロジェクトでは顕著です。オンデマンドで知見をランするには、プロジェクトの [ モニタリング ] ページで [ 今すぐラン ] をクリックします。

プロジェクトの知見を確認するには、プロジェクトを開き、 [モニタリング] に移動して、 [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 秒）など、具体的な数値でそれを裏付けています。

推奨事項：

1. idle_in_transaction_session_timeout を安全な値 （30～60秒など）に調整して、アイドル状態のセッションが、他のクエリーを何分もブロックすることなく、ロックを迅速に解放するようにしてください。
2. 未クローズのトランザクションを監査し、短いチェックアウトタイムアウトで接続プーリングを使用してください 。これにより、トランザクションを開いてアイドル状態になったクライアントが無期限にロックを保持することができなくなります。

証拠によって、関与したセッション、ロックを保持していた時間、および他のクエリーに発生させた待ち時間が特定されます。重要度は利用可能なデータから推測されるため、重要度だけで判断する前に「証拠」を読んで根本原因を確認してください。

知見に対応する

知見を読み取った後は、次の 3 つのいずれかの方法で応答します。

• エビデンスと推奨事項をガイドとして使用して、 推奨事項を自分で適用してください。
• 知見の詳細ページで Click Fix with Genie をクリックして、インタラクティブエージェントに引き渡し、会話形式での調査を継続します。これは、アクションを実行する前に推奨事項により多くのコンテキストが必要な場合や、修正にデータベース側の変更が伴う場合に役立ちます。 Genie を使用した問題の調査と修正を参照してください。
• 対応が完了したら [Status] を [Resolved] に設定し、対応が不要な場合は [Not an issue] に設定します。

検出結果が自動的に消えることがあります。

知見は独自のスケジュールで再評価を行うため、ステータスを変更していなくても、検出結果がリストから消えることがあります。たとえば、1 回限りの一括ロードなどの一時的なイベントは後のウィンドウでは再発生しない可能性があり、その背後にあるコンピュートがゼロにスケールダウンして、問題のあったセッションが消えた状態で新しく再開される場合があります。検出結果がアクティブなリストから外れたからといって、誰かがそれを [Resolved] や [Not an issue] にマークしたわけでも、何か問題が発生したわけでもありません。これは、最新の評価ウィンドウに条件がもはや存在しないことを反映しています。

次のステップ

• Genie の問題の調査と修正 : 知見で検出された問題を解決するか、新しい調査を起動します。
• システムテーブルでの Lakebase テレメトリ : Insights が読み取るテーブルと現在の制限事項。
• 可観測性 ：その他の Lakebase 可観測性ツール。