本文へスキップ
Pathrule

ドキュメント

検証とライフサイクル

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のページを参照してください。