Important
この機能は ベータ版です。 ワークスペース管理者は、[ プレビュー] ページからこの機能へのアクセスを制御できます。 Manage Azure Databricks プレビューを参照してください。
Insights は、Lakebase プロジェクトのテレメトリを定期的に確認し、質問することなく問題や早期警告を表示するバックグラウンド エージェントです。 このページでは、プロジェクトの分析情報をオンにし、実際の分析情報をエンド ツー エンドで説明します。見つかった内容、重要な理由、対応方法について説明します。
会話形式のオンデマンドの代替手段、または分析情報をさらに調査し続けるには、「 Genie の問題の診断と修正」を参照してください。
Note
可観測性に対して別途料金はかかりません。 そのコストは、すでに使用している製品の料金に含まれています。テレメトリをエクスポートするとインジェスト使用量として計上され、Lakehouse に Delta テーブルとして保存すると Databricks 管理ストレージの使用量として計上され、Genie に問い合わせると Genie の使用量として計上されます。
前提条件
- 実行中のコンピューティングを使用する、AWS または Azure 上の Lakebase 自動スケーリング プロジェクト。
- テレメトリを受信するための Unity カタログ カタログとスキーマ (既定の ストレージではありません)。
Insightsをオンにして最初の発見を読んでみてください
プロジェクトの分析情報を有効にする
Insights は、 可観測性構成によって制御されるプロジェクトごとに実行されます。 まだお持ちでない場合は、最初に作成して割り当てます。
構成ウィザードで、[ 分析情報の有効化] がオンになっていることを確認します。 これを使用しない場合、構成では、事前に何も表示することなく、Unity カタログにテレメトリを書き込むことができます。 また、Insightsがテレメトリを評価する 頻度を分析 頻度設定することもできます。
分析情報を探す
Insights は継続的ではなく定期的なスケジュールで実行されるため、実際の問題が発生してから、それに対して表示される分析情報の間に遅延が生じる可能性があります。 エージェントをオンにした後、特に新しいプロジェクトでエージェントを有効にした直後にしばらく時間を取る必要があります。
分析情報は次の 2 つの場所に表示されます。
- ワークスペース全体の一覧: 左側のナビゲーションで、[分析情報] をクリックします。 構成が適用されるすべてのプロジェクトの分析情報を集計します。 検索またはフィルターを使用して絞り込みます (プロジェクトや重大度など)。
- 1 つのプロジェクトのビュー: プロジェクトを開き、[監視] に移動し、[分析情報] タブを選択します。そのプロジェクトの分析情報のみが表示されます。
各行には、重大度 (マイナーやモデレートなど)、分析情報のタイトル (Project)、問題がカバーする時間枠、設定した状態 (開くなど) が表示されます。
生のテレメトリはUnityカタログのDeltaテーブルとして表示されますが、Insightsが生成した結果は、設定が書かれるアイデンティティのAzure Databricks Workspace内のWorkspaceフォルダにファイルとして保存されます。
洞察を読む
分析情報をクリックして詳細ページを開きます。 すべての分析情報は同じ構造に従います。これは、通知だけでなく、診断として上から下に読み取られます。
- 要約:何が起きているのか、わかりやすく説明します。
- エビデンス:診断を支持する特定のシグナルや値が表に示されます。
- 推奨事項:具体的な次のステップと、それぞれの理由を伝えましょう。
Insights が見つけたもの、および診断を示す方法は、独自のテレメトリに完全に依存するため、表示される分析情報は以下の分析情報と一致しません。 期待できる詳細レベルを示すために含まれる実際の分析情報を次に示します。
この例「Idle session locked out 4 updates」では、サブタイトルがすでにどこを探せばいいかを示しています:「Idle session held locks; UPDATE 合計749秒の待機時間でした。サマリーは何が起こったかを説明しています:セッションがトランザクションを開き、行ロックを保持したままアイドル状態になり、約9.5分間その状態が続きましたが、データベース自身のアイドルイントランザクションタイムアウトで強制的に閉じられました。 Evidence テーブルは、終了ログ エントリや、4 回の呼び出しにまたがる合計 749 秒の UPDATE 待機時間などの具体的な数値によって、その点を裏付けています。これは、通常ならミリ秒単位で完了する更新処理に対して、1 回あたり平均 187 秒かかっていることを示しています。
Recommendations:
idle_in_transaction_session_timeoutを安全な値 (30 ~ 60 秒など) に調整して、アイドル 状態のセッションでは、他のクエリを数分ブロックするのではなく、ロックをすばやく解放します。- 未クローズのトランザクションがないか確認し、チェックアウトタイムアウトを短く設定した接続プーリングを使用して、トランザクションを開始したままアイドル状態になったクライアントがロックを無期限に保持し続けられないようにします。
証拠が何を定量化しているのかに注目してください。つまり、単に「クエリが遅かった」というだけでなく、どのセッションがその原因だったのか、そのセッションがどれだけ長くロックを保持していたのか、そして他のクエリにどれだけの待機時間を生じさせたのかを正確に示しています。 重大度は使用可能なデータから推論されるため、重大度だけに対処する前に、証拠を読んで根本原因を確認してください。
インサイトに対応する
分析情報を読んだ後、ループを閉じる方法は 3 つあります。
- 証拠と推奨事項をガイドとして使用して、推奨事項を自分で適用します。
- インサイトの詳細ページで Genie で修正 をクリックして対話型エージェントに引き継ぎ、対話形式で調査を続けます。 これは、推奨事項が動作する前にコンテキストを増やす必要がある場合や、修正にデータベース側の変更が伴う場合に役立ちます。 Genie に関する問題の診断と修正を参照してください。
- 対処した後、またはアクションが必要ないと判断した後で、状態を更新します (たとえば、解決済みの状態を無視またはマークする)。
検出結果は自然に消えることがあります
Insights は独自のスケジュールで再評価されるため、状態を変更しない場合でも、結果はリストから削除される可能性があります。1 回限りの一括読み込みのような一時的なイベントが後のウィンドウで繰り返されない場合や、その背後にあるコンピューティングがゼロにスケーリングされ、問題のあるセッションがなくなった状態で新たに再開される可能性があります。 検出結果がアクティブリストから外れたとしても、それが却下されたことや、何らかの問題が発生したことを意味するわけではありません。 これは、条件が最新の評価ウィンドウに存在しなくなったことを反映しています。
Note
分析情報を表示するには、構成の作成に必要なアクセス許可とは別に、ワークスペース内のワークスペース アクセス が必要です。 ワークスペースアクセス権を持たないユーザーは、プロジェクトを表示できる場合でも、分析情報を開くことはありません。
次のステップ
- Genieの問題を診断・修正する:会話で調査を続けるか、ゼロから新しい調査を始めるか。
- テレメトリーテーブル参照:Insightsが読み取り、現在の制限を扱うテーブル。
- Lakebase プロジェクトを観察する: 残りの監視ツールを参照してください。 可観測性を参照してください。
