可観測性の構成

備考

ベータ版

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

可観測性構成 は、詳細な Lakebase Postgres テレメトリを Unity Catalog 内の Delta テーブルとしてキャプチャします。知見、 Genie、およびダッシュボードはすべてこのデータ上で実行されます。構成が添付されるまで、プロジェクトにはこれらは含まれません。

構成は、1つまたは複数のプロジェクトをカバーできる単一のオブジェクトです。IDを関連付けるには2つの方法があり、それらは設計上共存しています：

• ワークスペース管理者 がService Principalの構成をワークスペースのdefaultとして設定することで、すべての新規プロジェクトで自動的に可観測性が得られるようになります。
• 個々のプロジェクト所有者 は、ユーザーIDの認証情報を使用して自身のプロジェクトを構成します。

ワークスペースでは通常、ほとんどのプロジェクトが共有のdefaultを使用し、一部が独自の構成を持つという混在状態になります。このページでは、どちらのパスについても完全なセットアップ手順を説明します。自身が所有する単一のプロジェクトをセットアップするには、 クイックスタートを参照してください。

前提条件

• ワークスペースで Lakebase Advanced Postgres Telemetry プレビューが有効になっています。ワークスペース管理者がプレビューページから有効にします。
• AWSまたはAzure上のLakebaseオートスケールプロジェクト。「Postgresデータベースの取得」を参照してください。
• テレメトリを受信するUnity Catalogのカタログとスキーマ。スキーマはすでに存在している必要があり、カタログでは defaultストレージ を使用できません。

構成を設定する

IDを選択します。 この構成では、ウィザードで選択したIDとしてテレメトリがUnity Catalogに書き込まれます。その選択によって、構成の適用範囲と有効期間が決定されます：

• 特定の個人のアカウントに紐付かない永続的な構成には、 Service Principal を選択します。これは可観測性を標準化するのに最適です。ワークスペースの default として設定し、既存のプロジェクトに割り当てます。Service Principalの選択はワークスペース管理者に限定されており、最初にプロビジョニングする必要があります（以下のステップ1）。
• ユーザーレベルの資格情報 を選択して、プロビジョニングなしで、自身のアクセス権の下でプロジェクトを構成します。これは、自身が所有する個々のプロジェクトに適しています。これはユーザーの権限にスコープ設定されているため、Service Principalのプロビジョニングステップをスキップし、「構成ウィザードを開く」から開始してください。

Service Principalをプロビジョニング

ユーザーレベルの資格情報を使用している場合は、構成ウィザードを開くに進んでください。

構成を作成する前に、以下の 4 つの権限を Service Principal に付与してください。これにより、ウィザードで選択できるようになります。これらは独立しており、それぞれ異なる場所で付与されます。いずれかが欠けている場合でも構成は保存されますが、テレメトリは記録されず、知見も生成されません。また、原因を示すエラーも表示されません。構成でテレメトリが生成されない場合は、まずこれらを確認してください。

Grant	Where to set it	Why it's needed
Workspace access	The principal's Configurations tab, under Entitlements	Lets the service principal act in the workspace at all. Without it, Lakebase writes telemetry as an identity that can't do anything, so every telemetry table stays empty.
Workspace admin	Settings > Identity and access > Groups: open the admins group and add the principal	The background agent currently requires admin access to write telemetry and generate insights.
CAN USE	The principal's Permissions tab	Lets you select the principal in the wizard. Creating a service principal grants CAN MANAGE, which doesn't include CAN USE, so you grant it explicitly. See Roles for managing service principals.
Unity Catalog privileges	The destination catalog and schema (see the SQL below)	Lets the principal create and write the telemetry tables: USE CATALOG on the catalog, USE SCHEMA and CREATE TABLE on the schema.

Grant	Where to set it	Why it's needed
Workspace access	The principal's Configurations tab, under Entitlements	Lets the service principal act in the workspace at all. Without it, Lakebase writes telemetry as an identity that can't do anything, so every telemetry table stays empty.
Workspace admin	Settings > Identity and access > Groups: open the admins group and add the principal	The background agent currently requires admin access to write telemetry and generate insights.
CAN USE	The principal's Permissions tab	Lets you select the principal in the wizard. Creating a service principal grants CAN MANAGE, which doesn't include CAN USE, so you grant it explicitly. See Roles for managing service principals.
Unity Catalog privileges	The destination catalog and schema (see the SQL below)	Lets the principal create and write the telemetry tables: USE CATALOG on the catalog, USE SCHEMA and CREATE TABLE on the schema.

設定 > ID とアクセス > Service Principal で、ワークスペースへのアクセス権と CAN USE 権限を付与します。カタログエクスプローラまたは SQL で Unity Catalog の権限を付与します：

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>`;

注記

Requiring workspace admin is a current Beta constraint and may be narrowed in a later release. Grant it for now so that telemetry and insights work.

構成ウィザードを開く

どちらの場所からでもウィザードを開くことができます。どちらも同じウィザードを開きます：

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

以下の3つのウィザードステップを順番に完了し、ステップ間で 次へ をクリックします。

構成

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

• 新規プロジェクトのdefault構成にする を選択すると、これがワークスペースのdefaultになります。ワークスペース内で作成されるすべての 新しい プロジェクトに、作成者が何もしなくてもこの構成が自動的に割り当てられます。ワークスペース全体でオブザーバビリティを標準化するには、これを有効にします。ワークスペースにはdefaultが最大1つしかなく、そのdefaultはそれ以降に作成されたプロジェクトにのみ適用されるため、プロジェクトへの割り当てステップで既存のプロジェクトにも割り当てる必要があります。この構成をワークスペース全体ではなく特定のプロジェクトに適用したい場合は、オフのままにしてください。
• Identity （ Authorize Lakebase to write your data の下）は、Choose an identityで行った選択に従って、Lakebase がテレメトリを書き込む際のアカウントです。 Use service principal を選択してプロビジョニングしたプリンシパルを選択するか、 Use user-level credentials を選択して自分自身として実行します。ワークスペース管理者のみがService Principalを選択できます。

Send telemetry to Unity Catalog の下で、テーブルを格納する カタログ と スキーマ を選択し、必要に応じてテーブルのプレフィックスを指定します。宛先を選択しているだけであり、設計しているわけではありません。Lakebase は、テレメトリを初めて書き込む際に キャプチャされる内容 にリストされているテーブルを作成します。スキーマは既に存在している必要があり、カタログは defaultストレージを使用できません 。カタログエクスプローラーでカタログを作成する際、 defaultストレージを使用 がdefaultで選択されているため、ここで使用するカタログについては必ずチェックを外してください。

知見を有効化

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

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

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

プロジェクトに割り当てる

この構成を適用する既存の Lakebase プロジェクトを選択し、保存します。前のステップでワークスペースのdefaultとして設定すると、今後作成されるプロジェクトに適用されます。ここで割り当てることで、既存のプロジェクトも同じ構成の下に置かれます。

保存後:

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

次のステップ

• Insightsで問題を見つけて解決する: プロアクティブなモニタリングを有効にし、検出結果の読み取り方法を学習します。
• Genieで問題を診断して修正する: 会話形式で問題を調査し、復旧までの一連のプロセスを実行します。