メインコンテンツまでスキップ
に最終更新

テレメトリをLakehouseにキャプチャします。

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

知見とGenieの両方は、 オブザーバビリティ構成 に依存しています。これは個々のプロジェクトの上位にあるオブジェクトです。これは意図的です。1つの構成を複数のプロジェクトにアタッチすると、単一のセットアップを再利用でき、また、知見がそれらすべてにわたる結果をワークスペース全体の1つのリストに表示できるようになります。これにより、各プロジェクトの所有者が各自で最初から設定する必要がなくなります。

テレメトリが流れた後に知見とGenieが何を行うかについては、AI支援トラブルシューティングを参照してください。

前提条件​

  • AWSまたはAzure上のLakebaseオートスケールプロジェクト。「Postgresデータベースの取得」を参照してください。
  • テレメトリを受信するUnity Catalogのカタログとスキーマ。スキーマはすでに存在している必要があり、カタログでは defaultストレージ を使用できません。
  • テレメトリのエクスポートを実行するID に関する決定。LakebaseはこのIDとしてUnity Catalogにテレメトリを書き込むため、エクスポートが書き込み可能な宛先カタログとスキーマ、および知見のワークスペースフォルダーが保存される場所を決定します。開始する前に決定してください。共有Service Principalは、再利用またはdefaultとしてマークする構成には耐久性のある選択肢ですが、独自のユーザー資格情報はテストにはより高速です。ステップ1で設定し、Service Principalを使用する場合、Service Principalアクセスを付与するの権限が必要です。

Service Principalにアクセスを付与する​

ステップ1でIDとして Service Principalを使用 を選択した場合、構成に依存する前に、以下の権限をプリンシパルに付与してください。それらは独立しており、それぞれ異なる場所で付与されます。構成は、それらが適切に設定されているかどうかにかかわらず保存されます。いずれかが欠落している場合、テレメトリはサイレントに到達せず、知見は生成されず、原因を示すエラーも表示されません。設定した構成がテレメトリを生成しない場合、まずここでそれぞれを確認してください。

設定 > IDとアクセス > Service Principal でCAN USEとワークスペースアクセスを付与し、次にプリンシパルを選択します。

ワークスペースのアクセス​

プリンシパルの**Configurations** tabで、**Entitlements**の下にある**ワークスペース access**を選択します。これにより、Service Principalがワークスペース内で完全に機能できるようになります。これがなければ、Lakebaseは何もできないIDとしてテレメトリーを書き込むため、他のすべてが正しく設定されていても、すべてのテレメトリーテーブルは空のままになります。

ワークスペース管理者​

Service Principalをワークスペースの**admins**グループに追加します。 **設定 > Identity and access > グループ**で、**admins**グループを開き、プリンシパルをメンバーとして追加します。 現在、バックグラウンドエージェントがテレメトリを書き込み、知見を生成するには、管理者アクセスが必要です。それがないと、パイプラインは実行されますが、何も生成しません。

注記

管理者アクセス権を必須とすることは現在のベータ版の制約であり、後続のリリースで対象が絞られる可能性があります。テレメトリと知見が機能するように、今はそれを許可してください。

Service Principal での CAN USE​

プリンシパルの [権限] tab で、 CAN USE を付与します。これにより、構成ウィザードでプリンシパルを選択できるようになります。Service Principal を作成または管理すると CAN MANAGE が付与されますが、これには CAN USE が含まれないため、明示的に付与する必要があります。Service Principal を管理するためのロールを参照してください。

宛先に対するUnity Catalogの権限​

Service Principalに、宛先のカタログとスキーマにテレメトリテーブルを作成および書き込みするために必要な権限を付与します：

  • USE CATALOG カタログで
  • USE SCHEMA スキーマで
  • CREATE TABLE スキーマで

これらは Catalog Explorer で、または SQL を使用して付与できます:

SQL
GRANT USE CATALOG ON CATALOG <catalog> TO `<service-principal-id>`;
GRANT USE SCHEMA ON SCHEMA <catalog>.<schema> TO `<service-principal-id>`;
GRANT CREATE TABLE ON SCHEMA <catalog>.<schema> TO `<service-principal-id>`;

構成を作成​

2か所のいずれかからウィザードを開きます:

  • [Lakebase] > [知見] > [構成の管理] > [新しい構成の追加] から
  • プロジェクト独自の**設定> Observability config > 新しい構成を作成**から

どちらも同じウィザードを開きます。3つのステップを順に完了し、それぞれの間で 次へ をクリックします。

ステップ1: 構成​

構成に名前を付け、テレメトリの送信先を選択します。ここで注目すべき選択肢は2つあります。

  • この設定を新しいプロジェクトのdefault構成にする と、プロジェクト作成者による操作なしに、ワークスペースで作成されるすべての 新しい プロジェクトにこの構成が自動的に割り当てられます。ワークスペース全体にわたる default を 1 つ設定したい場合にのみ、これを有効にします。そうでない場合は、これを無効にし、ステップ 3 で特定のプロジェクトに構成を割り当てます。
  • Lakebase がテレメトリーを書き込む際のアカウントが、**Identity** (「**Lakebase にデータの書き込みを許可する**」の下) です。 Use Service Principal is the durable choice: it doesn't depend on any one person's アカウント, so it's right for a configuration you'll share across projects or mark as default. ユーザーレベルの資格情報を使用する と、ご自身でのテストがより迅速に行われます。既存の権限に依存するため、プロビジョニングするプリンシパルはありませんが、アクセス権の範囲内であり、テスト期間を超えて使用されることを意図したものではありません。

**Service Principal を使用**を選択した場合、Service Principal のアクセス許可を付与する に記載されている権限が必要です。ワークスペース管理者のみが Service Principal を選択できます。他のユーザーは、「ユーザーレベルの資格情報を使用」を選択します。

テレメトリをUnity Catalogに送信 の下で、テーブルが格納される カタログ と スキーマ 、およびオプションでテーブルプレフィックスを選択します。宛先を選択するのであって、設計するのではありません。Lakebaseは、テレメトリを最初に書き込むときに仕組みに記載されているテーブルを作成します。スキーマはすでに存在している必要があり、カタログは default storageを使用できません 。Catalog Explorerでカタログを作成する際、 defaultストレージを使用 がdefaultで選択されているため、ここで使用するカタログでは必ずクリアしてください。

ステップ 2: 知見を有効にする​

知見を有効にする がオンになっていることを確認してください。それがバックグラウンドの知見エージェントを実行します。これがないと、構成はテレメトリをUnity Catalogに書き込みますが、何も積極的には表示しません。2つの関連フィールドが表示されます：

  • 指示 は、エージェントが各分析パスの前に読み取る自由形式のテキストです。例として、「テーブルサイズに関する知見を生成しないでください。」これをガイダンスとして扱ってください。保証されたフィルターではありません。LLMに与えられる指示と同様に、それは通常は従われますが、厳密には強制されません。
  • 分析頻度 は、知見がテレメトリーを推論する頻度 (例: 1時間ごと) を制御します。これは、生テレメトリーが Unity Catalog にどれだけ速く取り込まれるかとは別です。それは常に継続的に発生します。

知見は、上記のUnity Catalogの宛先とは異なる ワークスペースの場所 にその結果を保存します。生のテレメトリはDeltaテーブルとして着地しますが、知見自体は独自のDatabricks Workspace内のファイルです。

ステップ 3: プロジェクトに割り当てる​

この構成を適用するLakebaseプロジェクトを選択してから、保存します。

保存したら、コンピュートが実行中であることを確認します。すでに実行中のインスタンスで観測性を有効にした場合は、変更を有効にするためにインスタンスを再起動してください。ベータ版では、すでに実行中のインスタンスでは、再起動するまでテレメトリの流れは開始されません。

次のステップ​

このページの見出し