ユースケース

p99が動いた。どのリリースが動かしたかを突き止める。

SLOは、違反が何かを指し示してこそ役に立ちます。ここでは、しきい値超過から原因のコミットまで、同じ時間範囲のまま3つの画面でたどります。

signal checkout p99 380 ms · threshold 200 ms

経路

しきい値からコミットまで、3分

1つのSLOが全経路を貫きます。checkoutのp99が200ms以下であること。以下のすべての画面は、それが成り立たなくなった時間帯に絞り込まれています。

slo checkout p99 ≤ 200 ms /alerts / /services/order-service T+0:00 T+0:40 T+3:15

alert T+0:00 · slocheckout p99 ≤ 200 ms

アラートは症状ではなく違反を示す

ルールはSLOに対して書かれているため、通知にはしきい値、観測値、評価ウィンドウが含まれます。200msに対して380ms、3ウィンドウ連続で継続。
dashboard T+0:40 · slocheckout p99 ≤ 200 ms

ダッシュボードで1つのエンドポイントに絞る

p50は動いていない。p99だけが動いている。この形はサービス全体の低速化ではなく、特定ルートの遅いテールを意味し、ルート別内訳がそれを特定します。POST /checkout。
releases T+3:15 · slocheckout p99 ≤ 200 ms

2つのリリースを並べて比較

同じエンドポイントをservice.versionで分割すると、段差の原因が特定できます。abc123ではp99が120ms、def456では380ms。def456配下のトレースは50個のdb.queryスパンを持ち、以前は3個でした。

結果

T+9:20にdef456をリバート。次の評価ウィンドウでp99はしきい値を下回りました。

できること

アラートが自分のSLOを知っている: ルールはパーセンタイルとしきい値に対して書かれるため、発報したアラートには既に比較結果が含まれます。どれだけ外れているかを知るために何かを調べる必要はありません。
バージョンは属性であり、フィルタになる: service.versionはSDKが送信する全スパンに乗ります。2つのリリースの比較はGROUP BYであり、スプレッドシートへのエクスポートではありません。
パーセンタイルはトレースを保持する: p99は今も残っているスパンから計算されます。チャート上のスパイクを選択すればその中のリクエストが開くため、数値と証拠が別物になることはありません。