プロジェクトキーの種類
プロジェクトキーは、それぞれ1つのプロジェクトに属します。キーでできることは、その種類で決まります。種類は、logbrew projects keys create を実行するときに --kind で選びます。
sdk、server、cli、browser の種類は取り込みキーです。キーを動かす場所を表す種類を選びます。ブラウザーで動くコードには browser を使います。読み取りキーは、ブラウザーのコード、モバイルアプリ、公開されるバンドルに入れないでください。
アカウントのアクセス権は、これとは別のものです。logbrew login を実行すると、CLI はアカウントのアクセス権を使えるようになります。アカウントのアクセス権を SDK の設定に使わないでください。読み取りキーでは、CLI にもダッシュボードにもサインインできません。
テストイベントを読み戻す
1
読み取りキーを作成する
この手順には、アカウントのアクセス権が必要です。CLI は、所有者専用の新しいファイルにキーを書き込みます。キーもファイルのパスも出力しません。
logbrew status --json を実行し、認証済みのアカウントのアクセス権が報告されることを確認します。--ingest-key-file は、どの種類のキーにも使うファイルのオプションです。保存先のファイルは、まだ存在していてはいけません。確認ポイント:結果に status: "created" と ingest_key.kind: "read" が含まれます。ingest_key.id を記録します。キーを無効化するときに必要です。2
3
イベントを読み戻す
読み取りキーを、このシェルだけの どの読み取りも、キーが属するプロジェクトのデータだけを返します。そのため、
LOGBREW_TOKEN に読み込みます。次に、プロジェクトを読み取ります。--project は必要ありません。テストイベントに合わせて、--service、--environment、--release を追加します。確認ポイント:テストログが、サービス、環境、リリースとともに表示されます。テストエラーは課題として表示されます。これは、LogBrew がイベントを保存し、それを読み取れることを示します。終わったら、unset LOGBREW_TOKEN を実行します。CLI は、再びアカウントのアクセス権を使います。4
読み取りキーを無効化する
不要になったキーは無効化します。この手順にはアカウントのアクセス権が必要なので、先に 確認ポイント:結果に
LOGBREW_TOKEN を解除します。status: "revoked" が含まれます。キーは次のリクエストから使えなくなります。CI ジョブやエージェントに読み取りのアクセス権を与える
1つのプロジェクトを読み取る CI ジョブやコーディングエージェントには、専用の読み取りキーを用意します。キーは、CI システムやエージェント環境のシークレットストアに保存します。キーをLOGBREW_TOKEN として使えるようにします。キーをプロンプト、リポジトリ、コマンドの出力に入れないでください。
これで、ジョブやエージェントは、logbrew issues --json、logbrew issue "<issue_id>" --json、logbrew read trace "<trace_id>" などの読み取りを実行できます。プロジェクト、キー、アカウントのコマンドには、アカウントのアクセス権が必要です。API クライアントは、テレメトリ API のテレメトリの読み取りに、キーを Bearer トークンとして送信します。
ジョブやエージェントごとに、別々のキーを使います。そうすれば、1つのキーを無効化しても、ほかのキーには影響しません。
読み取りに失敗したときに回復する
それでもテレメトリが見つからない場合は、最初のテレメトリの確認を使います。取り込みキーを置き換えるには、取り込みキーのローテーションを参照してください。
