検証とライフサイクル
Pathrule Signalsがイベントをどうグループ化するか、各グループのステータスと検証状態の意味、修正が検証済みと見なされるまでに必要なエビデンス、そしてLocalでグループが保持される期間を説明します。
Signalsは2つの問いを分けて扱います。何が繰り返し起きているのか、そして修正が本当に効いたのか、です。前者にはグループ化が、後者には検証が答えます。そして後者に答えられるのは実行時のエビデンスだけです。
グループ
すべてのイベントは、環境、種類(errorまたはevent)、フィンガープリントの組み合わせごとに1つのグループに属します。フィンガープリントはイベントのラベル、フロー、コードパスから導出されます。そのため、同じ場所で起きる同じ障害は何回発生しても1つのグループにまとまり、本番環境とプレビュー環境で起きた同じエラーは別々のグループのまま保たれます。各エンベロープには再送時も変わらないIDが付いているため、再送されたエンベロープは1回だけ保存されます。
ステータスと検証
グループにはステータスがあります。
active: 発生中、または再発した状態です。declared: 計測ポイントは宣言されたものの、まだ何も報告されていない状態です。resolved: 修正が効いたことを検証が証明した状態です。archived: 発生しなくなり、クローズされた状態です。archivedはresolvedではありません。
さらに検証状態があります。
| 状態 | 意味 |
|---|---|
unobserved | 修正が記録されていない、または新しいリリースがまだ観測されていない状態です。 |
observing | 新しいリリースが稼働しており、エビデンスを収集している状態です。 |
quiet | 新しいリリースで24時間経過し、3件以上のエンベロープを受信しても再発していない状態です。フローを持たないグループが到達できる最上位の状態です。 |
verified | 修正が効いた状態です。後述のエビデンス要件を満たしています。グループはresolvedになります。 |
recurred | 新しいリリースで再発した状態です。グループは再びactiveになります。 |
エビデンスとして認められるもの
修正が検証済みになるのは、修正を記録した時点のリリースより新しいリリースについて、次の3つがすべて満たされたときです。
- 60分以上の観測
- その新しいリリースからの3件以上のエンベロープ
- そのグループ自身のフローの3回以上の成功(
meta.outcome: "success"付きで報告されたもの)
一切カウントされないものもあります。ベースラインのリリース、リリース情報を持たないイベント、修正の記録前に観測されたものです。さらに新しいリリースが現れると、観測は最初からやり直しになります。新しいリリースから45分間何も届かない場合、quietの状態は古いものとして扱われます。リリース情報がない場合は検証がブロックされ、SDKはno_releaseを報告します。
修正の記録
あなたやエージェントが何かを修正すると、その修正はグループに対して記録されます(エージェント連携を参照)。記録は主張であって証明ではありません。記録だけでは何もresolvedにはなりません。そうできるのは検証だけです。手動で解決する手段はなく、新しいリリースで1回でも発生すれば、verifiedの後であってもグループはrecurredになり、activeに戻ります。
Pathrule Localでの保持期間
- ワークスペースあたり最大5,000グループです。
- 未解決のグループは、発生がないまま一定期間が過ぎると失効します。本番環境では14日、開発環境やプレビュー環境では7日、宣言では30日です。
- 解決済みのグループとその履歴は90日間保持されます。
- エンベロープのIDは2日間記憶されます。これにより再送を安全に行えます。
Cloudでの保持期間についてはCloud Signalsのページを参照してください。