ユースケース

誰もデプロイしていない。それでもレイテンシは倍になった。

分散システムでは、遅くなったサービスが壊れたサービスであることはまれです。マップはどのエッジが最初に劣化したかを示し、トレースは待ちがどこまで波及したかを示します。

signal api-gateway p95 1.9 s · was 0.9 s, no deploy

経路

症状から原因まで2ホップ

payment-svc@1.4.2は、症状の4時間前にリリースされたバージョンです。これが全経路を貫きます。マップ、トレース、ログはすべてこれで絞り込まれています。

deploy payment-svc@1.4.2 /service-map /traces /logs T+0:00 T+1:10 T+2:40

map T+0:00 · deploypayment-svc@1.4.2

マップは遅いサービスではなく、遅いエッジを示す

呼び出されているのはapi-gatewayですが、そのスパン自体に問題はありません。劣化しているエッジは2ホップ先、payment-svcからuser-dbで、平均が12msから210msに悪化しています。
trace T+1:10 · deploypayment-svc@1.4.2

トレースは処理ではなく待ちを示す

遅いリクエストを開くと、そのほとんどがdbスパンです。クエリ自体は4ms、スパンは210ms。その差は、クエリが実行される前に費やされた時間です。
logs T+2:40 · deploypayment-svc@1.4.2

ログがリリースを名指しする

そのスパンのログ行にはpool wait 206ms、3回目の試行で取得と記録されています。service.versionで絞り込むと1.4.2から始まっており、このリリースはプールを増やさずに並列度だけを上げていました。

結果

新しい並列度に合わせてプールサイズを拡張。エッジのp95レイテンシは、ロールバックなしで14msに戻りました。

できること

エッジは固有のレイテンシを持つ: マップは呼び出し元と呼び出し先のペアごとに個別に計測します。ある呼び出し元にだけ劣化した依存関係は、サービス全体の平均ではなく、1本のエッジとして見えます。
dbスパンは待ちと処理の合計: クライアントスパンは実行だけでなく接続取得も含むため、プールの枯渇は、単一の数値の中に隠れるのではなく、スパン所要時間とクエリ所要時間の差として現れます。
デプロイしていないつもりでもデプロイである: 全スパンにservice.versionが付いていれば、問いは「誰がデプロイしたか」から「このスパンはどのバージョンのものか」に変わります。4時間前のリリースも4分前のものと同じように見つかります。