https://api.logbrew.co で提供される、HTTP 上の JSON API です。公開 SDK は、管理するバッチを POST /v1/events に送信します。独自のネイティブクライアントは、ネイティブのエンベロープを POST /api/telemetry/ingest に送信します。どちらの取り込みルートにも、プロジェクト単位の取り込み用の Bearer トークンが必要です。
読み取りとアカウントが所有するデータの変更には、アカウントの Bearer トークンを使います。アカウントの Bearer トークンやブラウザーのセッションを、SDK や取り込みの設定に使わないでください。取り込み用の Bearer トークンを読み取りのルートに送信しないでください。
範囲を絞ったリクエストを送信する
クライアントがリクエストを送信する前に、次のチェックリストを使います。- エンドポイントの表から、ルートと HTTP メソッドを選びます。
- 正しい Bearer トークンを使います。取り込みには取り込み用の Bearer トークン、それ以外にはすべてアカウントの Bearer トークンを使います。
- ルートが対応しているプロジェクトのスコープを選びます。レスポンスが空でも、スコープを広げないでください。
- ルートが受け付けるクエリキーだけを追加します。クエリフィルターを参照してください。
- ルートに JSON ボディがある場合は、
Content-Type: application/jsonを送信します。 - 再試行する前に、HTTP ステータスとレスポンスボディを読みます。
- Bearer トークン、フィードのチケット、レスポンスボディ全体を、ログやエージェントのプロンプトに含めないでください。
エンドポイント
取り込み
/v1/events のバッチは SDK に作らせます。手で組み立てないでください。ネイティブのエンベロープについては、SDK 連携を参照してください。
テレメトリの読み取り
デプロイ
デプロイが成功または失敗した後に、リリースの自動化からデプロイを記録します。
PUT のボディには、project_id、release、environment、service_name、status（succeeded または failed）、started_at、finished_at、省略可能な commit_sha があります。release、environment、service_name には、SDK が送信するのと同じ値を使います。アカウントがそのプロジェクトを所有している必要があります。
deployment_id は、デプロイに対して自分で付ける ID です。同じ ID と同じボディで再試行すると、保存済みのデプロイが返ります。同じ ID で異なるボディを送ると、409 と idempotency_conflict で失敗します。別のデプロイには新しい ID を使ってください。
調査
各調査ルートは、1つの対象について、範囲を絞った証拠のまとまりを返します。CLI のlogbrew explain コマンドは、これらのルートを読み、レスポンスを検証します。
プロダクト分析
POST の分析ルートは、クエリキーではなく JSON ボディを受け取ります。プロダクト分析を参照してください。
ライブフィード
アカウントとサインイン
使用量、クォータ、サブスクリプション、ログアウトのルートは アカウント APIにあります。成功時のステータスコード
200 のレスポンスは、証拠が完全であることを証明するものではありません。レスポンスのカバレッジ、一部省略、ステータスのフィールドを読んでください。
クエリフィルターとページネーション
各読み取りルートは、それぞれ独自のクエリキーを受け付けます。project、trace、user のようなわかりやすい別名は、クエリキーではありません。一覧のルートは、デフォルトでは配列だけを返し、pagination=cursor を付けるとカーソルのエンベロープを返します。デプロイの一覧は常にページのオブジェクトを返します。クエリフィルターを参照してください。
レスポンスとエラー
人向けのメッセージより先にcode を読みます。プログラムの動作には next_action を、人への案内には next を使います。error や next の文言を解析しないでください。
課題を更新する
これらのリクエストでは、アカウントの Bearer トークンを使います。これは意図的にLOGBREW_INGEST_BEARER とは別のものにしています。アカウントには、課題のプロジェクトで課題を管理する権限が必要です。権限がないと、リクエストは 403 と forbidden で失敗します。同じ権限で、ステータス、優先度、担当者の変更と、課題とログのルールを扱えます。
各リクエストでは、次のフィールドを1つ以上設定します。
これらのフィールドが1つもないリクエストは、
422 と validation_failed で失敗します。
担当者は課題ごとに最大1つで、アカウントかチームです。アカウントはそのプロジェクトを読み取れる必要があり、チームはそのプロジェクトの組織に属している必要があります。条件を満たさない場合、リクエストは 422 と validation_failed で失敗し、LogBrew は何も変更しません。割り当てられるアカウントは 担当者を一覧表示するで取得します。assignee にそれ以外の値を指定した場合も、422 と validation_failed で失敗します。
設定した優先度は固定されます。優先度を設定していない場合、優先度は課題の重大度に従います。error と critical は high、warning は medium、info は low です。
フィールドがすでに指定した値になっている場合は変わりません。タイムアウトの後は、同じリクエストをもう一度送信できます。タイムアウトしても、変更が行われなかったとは限りません。別の変更を送信する前に、課題をもう一度読んでください。
1件の課題を更新する
レスポンスでarchived、優先度、担当者を受け取るには、response_version=4 を追加します。バージョン4では、assignee は { "type": "user", "user_id", "name", "email" }、{ "type": "team", "team_id", "slug", "name" }、null のいずれかです。バージョン3では、チームの担当者は null と表示されます。
課題を一括で更新する
project_id と、そのプロジェクトの重複しない1〜100件の課題 ID を送信します。
project_id と results があり、results には課題 ID ごとに1つの結果がリクエストの順に入ります。各結果には issue_id、outcome、issue があります。issue は、レスポンスのバージョン3では現在の課題で、not_found の場合は null です。各課題をレスポンスのバージョン4で受け取るには、ボディに "response_version": 2 を追加します。
リストが空の場合、ID が100件を超える場合、ID が重複している場合は、
422 と validation_failed で失敗します。それより多い課題は、複数のリクエストに分けてください。アカウントがプロジェクトを読み取れない場合、リクエストは 404 と not_found で失敗します。
担当者を一覧表示する
プロジェクト ID を送信すると、そのプロジェクトで課題を割り当てられるすべてのアカウントを取得できます。user_id、name、email があります。アカウントに名前がない場合、name は null です。response_version=2 を追加すると、teams も受け取れます。teams には、プロジェクトが属する組織のすべてのチームが、team_id、slug、name 付きで入ります。担当者の一覧のレスポンスを参照してください。プロジェクトを読み取れるアカウントであれば、この一覧を取得できます。アカウントがプロジェクトを読み取れない場合、リクエストは 404 と not_found で失敗します。
メンバーがプロジェクトへのアクセスを失うと、そのメンバーに割り当てられた課題には担当者が表示されなくなります。メンバーが再びアクセスできるようになると、その間に誰かが担当者を変更または解除していない限り、課題には再びそのメンバーが表示されます。
オーナーシップとオーナー候補
GET /api/telemetry/issues/ownership?project_id=<project-uuid> は、rules、codeowners、updated_at、unresolved_owners を返します。プロジェクトを読み取れるアカウントであれば、読み取れます。project_id と、rules、codeowners、またはその両方を付けて PUT を送ると、そのテキストが置き換わります。これには課題を管理する権限が必要です。省略したフィールドのテキストはそのまま残り、空の文字列を送るとテキストが消去されます。各テキストは 128 KiB 以下です。無効なテキストは 422 で失敗し、問題のある行が示されます。
GET /api/telemetry/issues/{issue_id}/owners?response_version=2 は、suggested_assignee、owners、inputs を返します。各オーナーには、type（user または team）、source（ownership_rule、codeowners、recent_activity のいずれか）、rule、line、matched があります。デフォルトのバージョン1では、アカウントだけが一覧表示されます。
課題の変更履歴
GET /api/telemetry/issues/{issue_id}/activity?response_version=2 は、新しい順の activity と、next_cursor を返します。各項目には、type（status、priority、assigned、unassigned、severity_rule、first_seen のいずれか）、value、actor_id、actor、assignee_id、assignee、team、at があります。limit は 1〜200 で、デフォルトは 50 です。次のページを読むには、next_cursor の cursor_time と cursor_id を送信します。
通知
GET /api/telemetry/issues/notifications は、notifications、unread、read_at、next_cursor を返します。各通知は、ほかのアカウントがあなたやあなたのチームに課題を割り当てたことを表します。空の JSON オブジェクト、または read_at を付けて POST /api/telemetry/issues/notifications/read を送ると、既読位置が進みます。既読位置が戻ることはありません。
課題とログのルールを設定する
ルールは、一致するシグナルを LogBrew がどう表示するかを変えます。データは削除しません。取得したseverity は変わらず、レスポンスの triage にルールが表示されます。
severity は info、warning、error、critical、source のいずれかです。source は上書きを解除し、取得した重大度を再び表示します。ログのルールでは、ignored: true を指定すると、一致するログがデフォルトのログの一覧に表示されなくなります。それらのログは status=ignored または status=all で読みます。ルールは、保持済みのシグナルとこれから届くシグナルのうち、一致するものに適用されます。それ以外の値は 422 と validation_failed で失敗します。