Skip to main content
課題は、同じフィンガープリントを持つエラーの発生事象をまとめたものです。ステータス、優先度、担当者を変更する前に、グループの要約と1件の発生事象を読んでください。ステータス、優先度、担当者の変更は、チームの判断を記録するものです。ソフトウェアを修復したり、取得済みのイベントを書き換えたりはしません。 始める前に、LogBrew CLI をインストールし、logbrew login を実行します。

​
課題と発生事象

課題の一覧が返すのは、グループの要約で、イベント全体ではありません。詳細を開く前に、次のフィールドを読んでください。 発生事象の件数は、影響を受けたユーザーの数ではありません。件数と時刻は、返された範囲についての値で、エラーの全履歴についての値ではありません。--since や --until のフィルターは、LogBrew が数える発生事象を限定します。件数を報告するときは、その件数を出したフィルターも報告してください。

​
ステータスの値

archived は、以前は ignored という名前でした。2つの名前は同じ課題を選び、入力ではどちらも受け付けます。logbrew read、logbrew issues、API のバージョン2と3は archived を表示します。API のバージョン1（デフォルト）、ライブ監視のストリーム、課題の調査のレスポンスは ignored を表示します。ダッシュボードでは、ステータスは「未解決」「解決済み」「アーカイブ済み」と表示されます。 ステータスは、1件の発生事象ではなく、課題全体に適用されます。重大度は緊急度を示し、ステータスは判断を記録します。この2つは分けて扱ってください。critical の課題でも、修正が検証されれば resolved にできます。archived の課題は、取得された重大度をそのまま保ちます。 LogBrew は、解決済みの課題を自動では再開しません。解決後に新しい発生事象が届くと、調査結果は lifecycle.effective_status を regressed として報告します。人が課題を再開するまで、status は resolved のままです。

​
優先度

優先度は、チームが課題をトリアージする順序を決めます。 すべての課題に優先度があります。誰も設定しない場合、優先度は課題の重大度に従います。error と critical は high、warning は medium、info は low になります。課題のルールが重大度を変更した場合、優先度は triage.effective_severity に従います。このとき priority_source は derived です。人が優先度を設定すると、その値は固定され、priority_source は manual になります。 最初に調べる課題を一覧表示するには、次を実行します。

​
課題を割り当てる

課題を割り当てて、次の手順の担当者を示します。担当者は課題ごとに最大1つで、1つのアカウントか1つのチームです。
1

割り当てられる人を確認する

assignees には、プロジェクトを読み取れるすべてのアカウントが、user_id、name、email 付きで入ります。teams には、プロジェクトが属する組織のすべてのチームが、team_id、slug、name 付きで入ります。プロジェクトを読み取れないアカウントや、ほかの組織のチームには割り当てられません。
2

課題を割り当てる

自分に割り当てるには、ユーザー ID の代わりに me を使います。担当者を外すには、logbrew issues unassign "<issue_id>" --json を使います。1つのプロジェクトの課題を最大100件まとめて変更するには、--project を追加します。
3

自分の課題を読む

自分のチームの課題は --assignee my_teams、特定のチームの課題は --assignee "team:<team_id>"、誰も担当していない課題は --assignee none で読めます。
課題を割り当てるには、プロジェクトの課題を管理する権限が必要です。同じ権限で、ステータス、優先度、オーナーシップルール、課題とログのルールも変更できます。チームを作成してメンバーを選ぶのは、組織のオーナーと管理者です。チームに入っても、プロジェクトへのアクセス権は付与されません。 メンバーがプロジェクトへのアクセス権を失うと、そのメンバーに割り当てられていた課題は、担当者なしとして表示されます。チームが削除された場合も、そのチームに割り当てられていた課題は担当者なしになります。これらの課題は --assignee none の読み取りに含まれます。そのメンバーがアクセス権を取り戻すと、その間に誰かが担当者を変更または解除していない限り、課題には再びそのメンバーが表示されます。

​
課題のオーナーを確認する

結果には、オーナー候補が有力な順に並び、suggested_assignee も含まれます。各オーナーには source があります。 inputs は、LogBrew が照合したスタックフレームのパス、モジュール、ルートテンプレート、タグ、ルールの数を示します。一覧が空で、inputs にパスが1つもない場合、オーナーがいないのではなく、照合できる証拠が課題にありません。 オーナーシップルールは、テキストファイルに1行に1つずつ書きます。
path のパターンはスタックフレームのパスの末尾に一致します。そのため src/payments/** は、どのデプロイ先ディレクトリの下にあるフレームにも一致します。* は任意のテキストに一致します。オーナーには、アカウントのメールアドレスか #team-slug を指定します。一致したルールのうち、最後のルールが最優先です。次に、ルール、GitHub の CODEOWNERS ファイル、またはその両方を送信します。
CODEOWNERS では、メールアドレスはアカウントを、@org/team-slug はそのスラッグのチームを指します。プロジェクトへのアクセス権がないアカウントや、存在しないチームを指定したルールは、422 で失敗します。CODEOWNERS のオーナーのうち、誰にも対応しないものは unresolved_owners に表示されます。空のファイルを送ると、そのテキストは消去されます。

​
課題の変更履歴を読む

変更履歴には、ステータス、優先度、担当者、重大度のルールの変更が、新しい順にすべて並び、変更したアカウントも表示されます。最後の項目は first_seen です。プロジェクトへのアクセス権を失ったアカウントは、ID だけが表示されます。続きを読むには、--limit と next_cursor の値を使います。

​
受信トレイを読む

受信トレイには、ほかの人があなたやあなたのチームに割り当てた課題が、新しい順に並びます。unread は、既読位置より後の割り当ての件数です。logbrew inbox read は、既読位置を現在の時刻に進めます。LogBrew は、これらの割り当てについてメールを送信しません。受信トレイに表示されるのは、現在読み取れるプロジェクトだけです。

​
推奨するワークフロー

1

1つの範囲で未解決の課題を一覧表示する

以降の一覧の読み取りでも、同じフィルターを使ってください。結果が空の場合、この範囲に一致する課題はありません。プロジェクトにエラーがないことの証明にはなりません。タイトルではなく、正確な課題 ID をコピーします。
2

課題の詳細を読む

続ける前に、返されたプロジェクトが正しいことを確認します。読み取りが返すのはスナップショットです。ステータスを変更する前に、課題をもう一度読んでください。
3

1件の発生事象を調査する

詳細と調査の読み取りには、一覧のフィルターは使われません。subject.project_id、event.occurred_at、リリース、環境を、調査の範囲と比較します。推奨される発生事象は、最新のものより古い場合があります。証拠をすべて確認する手順は、課題を調査するに従ってください。
4

トレースの証拠は利用できる場合にだけたどる

トレースを読むのは、correlations.trace.status が available の場合だけです。レスポンスにあるトレース ID を使います。ID を決して自分で作らないでください。
トレースの読み取りには時間のフィルターがありません。ステータスが not_linked の場合は、課題の証拠で調査を続けます。
5

候補のデプロイを検証する

調査した発生事象を基準にします。デプロイ ID は、デプロイの証拠かリリースの手順から取得します。
観測期間内に再発がなくても、恒久的な修正の証明にはなりません。status が insufficient_traffic または unavailable の場合は、課題を unresolved のままにします。返された次の操作に従ってください。
6

ステータス、優先度、担当者を変更する

コマンドを1つ実行します。これらのコマンドは確認を求めないため、先に課題 ID を確認してください。
--project を付けない場合、各コマンドは課題 ID を1つ受け取ります。終了コードと、返された status、priority、assignee を確認します。結果がない場合は、次の変更の前に課題をもう一度読んでください。古いスクリプトでは、logbrew set issue "<issue_id>" resolved や、resolve、ignore、reopen の短縮形を使えます。ignore は archived を設定します。

​
複数の課題をまとめて変更する

1つのプロジェクトの課題を、1つのコマンドで最大100件変更するには、--project を追加します。
このコマンドは、すべての課題に同じ変更を適用します。各課題 ID は1回しか指定できません。CLI は、100件を超える ID や重複した ID を、リクエストを送信する前に拒否します。結果には、課題ごとに1つの項目が、コマンドで指定した順に入ります。 各項目には issue_id、outcome、issue があります。issue は現在の課題で、not_found の場合は null です。ネットワーク障害の後は、同じコマンドをもう一度実行できます。すでに変更された課題は unchanged になります。100件を超える課題は、コマンドを分けて実行します。not_found の結果が出た場合は、そのプロジェクトの課題一覧から ID をもう一度コピーしてください。API のリクエストについては、課題を一括で更新するを参照してください。

​
次のステータスを選ぶ

  • unresolved のままにする：障害が続いている場合や、修正が検証されていない場合。トレースがないことは、課題をアーカイブする理由になりません。
  • resolved に設定する：チームが修正の証拠を受け入れた後。修正案は証拠ではありません。
  • archived に設定する：許容した状態や、テスト専用のシグナルの場合。この判断は、課題のすべての発生事象に適用されます。コマンドには理由を入れるフィールドがないため、理由はチームの作業記録に残してください。
  • unresolved で再開する：解決後に新しい発生事象が届いた場合。その発生事象は lifecycle.regression.first_reappeared_occurrence でわかります。解決に使った発生事象と比較してください。別の課題を作成しないでください。

​
調査を引き継ぐ

次の担当者には、生のイベントをそのまま渡すのではなく、参照情報を渡します。
  • 課題 ID、ステータス、優先度、担当者、重大度。
  • プロジェクト、サービス、環境、リリース。
  • 初回確認の時刻、最終確認の時刻、発生事象の件数。
  • 選択した発生事象の ID と occurrence_selection.reason。
  • fix.status、cause.status、それぞれの provenance。
  • トレースのステータスとトレース ID（利用できる場合）。
  • 再現のステータスと、欠けている証拠。
  • 候補のデプロイの検証結果。
  • レスポンスが返した次の操作。
推定した原因や修正は、案であることを明記してください。

​
CLI のエラーから復旧する

出力を解析する前に、プロセスの終了コードを確認します。成功すると、JSON は標準出力に書き出されます。解析エラーはコード 2 で終了します。実行時エラーはコード 1 で終了します。JSON のエラーは標準エラー出力に書き出され、ok: false、error、message、next を含みます。next は案内として表示してください。自動で実行しないでください。 たとえば、logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json には --project がありません。このコマンドは、リクエストを送る前にコード 2 で終了し、エラー invalid_issue_command を返します。 API がリクエストを拒否した場合、error は api_error になります。HTTP ステータスは status で、API のエラーコードは api_code で読みます。 レスポンスが失敗しても、ステータス、優先度、担当者の変更が反映されなかったことの証明にはなりません。再試行する前に、課題を読んでください。

​
役に立つ課題の条件

  • わかりやすいタイトルと、読みやすいメッセージ。
  • 安定したフィンガープリント。
  • スタックフレーム（利用できる場合）。
  • リリース、環境、サービスのコンテキスト。
  • トレースコンテキスト（発生事象と一緒に取得された場合）。
  • ペイロード全体ではなく、小さく関連性のある属性。
一覧のフィルターとレスポンスの仕様については、テレメトリ APIを参照してください。