チケットを作成する
CLI から次を実行します。source を cli に設定します。--diagnostics が追加するのは、バイナリ名、CLI のバージョン、オペレーティングシステム、アーキテクチャだけです。すべてのフラグは logbrew support --help で確認できます。
CLI は、チケットを作成するときに再試行キーを送信しません。結果がはっきりしない場合は、コマンドをもう一度実行する前に logbrew support list --json を実行してください。そうしないと、2件目のチケットが作成されることがあります。
API からは、source、category、title、description を指定して POST /api/support/tickets を送信します。再試行を安全にするには、報告ごとに再試行キーを1回だけ作成し、Idempotency-Key ヘッダーで送信します。次の例では架空の値を使っています。
Idempotency-Key ヘッダーは省略できます。省略すると、リクエストを繰り返したときに別のチケットが作成されることがあります。
省略できるフィールドは、project_id、environment、runtime、framework、sdk_package、sdk_version、release、trace_id、event_id、diagnostics です。特定のプロジェクトに関する問題でない場合は、project_id を省略します。project_id は、アカウントのアクティブなプロジェクトを指す必要があります。
リクエストが成功すると、HTTP
200 が返ります。
sup_ で始まります。next は人への案内として、next_action はプログラムの制御に使います。
プロジェクトを削除するには、プロジェクトの設定または logbrew projects delete を使います。サポートチケットでプロジェクトの削除を依頼しないでください。
役立つ報告を書く
- 1件のチケットには1つの問題だけを報告します。
- 最も近い
categoryを選びます。どれも当てはまらない場合だけotherを使います。 titleには、1つの症状と1つの対象を書きます。descriptionには、手順を書き、次に期待した結果と実際の結果を書きます。- プロジェクト、リリース、トレース、イベントの ID は、同じ障害を指す場合だけ追加します。
diagnostics には次のキーを使います。
diagnostics は、秘匿処理後に 16 KB までの JSON オブジェクトです。キーが認証情報、セッション、メールアドレスを示す場合、LogBrew はその値を [redacted] に置き換えます。認証情報、URL、ローカルのパスに見えるテキストも置き換えます。さらに、長い文字列を短くし、入れ子の深さ、キーの数、リストの項目数を制限します。この秘匿処理に頼らないでください。リクエストを送信する前に、非公開のデータを取り除いてください。
チケットを追跡する
一覧では
project_id、status、source、category、release、limit を指定できます。limit のデフォルトは 100 で、最大は 500 です。カーソルベースのページネーションを使うには、pagination=cursor を送信します。2ページ目以降では、同じフィルターを繰り返し、next_cursor の cursor_time と cursor_id を送信します。カーソル ID は sup_ で始まるチケット ID です。next_cursor が null になったら止めます。CLI では --project、--status、--source、--category、--release、--limit、--pagination、--cursor-time、--cursor-id のフラグを使います。
ステータスの値は open、routed、in_progress、waiting_on_user、resolved、closed です。設定できるのは open と closed だけです。チケットを閉じるリクエストや再開するリクエストを繰り返しても成功し、何も変わりません。そのため、同じリクエストをそのまま再試行できます。返されたステータスと next_action に従います。
求められたコンテキストを追加する
チケットでコンテキストを求められたら返信します。そのチケットのステータスはwaiting_on_user で、next_action.code は provide_context です。
context と、省略可能な diagnostics を入れます。context のテキストは 1〜4,000文字にします。context には、認証情報、URL、ホスト名、ローカルのパスを入れないでください。API はそのようなテキストを 422 で拒否します。Idempotency-Key ヘッダーで再試行キーを送信します。コンテキストのルートでは、このヘッダーが必須です。キーは、スペースを含まない、表示可能な ASCII 文字 1〜128文字です。返信ごとに新しいキーを使います。キーを再利用するのは、同じ返信を再試行するときだけです。
API がコンテキストを受け付けるのは、チケットが open、routed、in_progress、waiting_on_user のいずれかの間です。チケットの状態ごとに受け付ける返信は1件です。返信した後は、ステータスが変わるのを待ってから次のコンテキストを送信します。waiting_on_user のチケットに返信すると、チケットは open になります。この変化を前提にせず、返された status を読んでください。
返信に成功すると、ticket_id、context_id、status、created_at、next、next_action が返ります。context_id は ctx_ で始まります。後から別の依頼に答える前に、チケットをもう一度読んでください。
GET /api/support/tickets/{ticket_id}/context は、最新のコンテキストを 20件まで、古い順に返します。各エントリーには context_id、context、diagnostics、created_at があります。この一覧にはカーソルがありません。
resolved または closed のチケットに返信すると、code: "validation_failed" とともに 422 が返ります。ユーザーがそのサポートリクエストを続けたい場合だけ、チケットを再開します。next_action は、エージェントにアカウントの状態を変更する権限を与えるものではありません。
エラーから復旧する
エラーレスポンスには
error、code、next、next_action が含まれます。API エラーを参照してください。