사용 사례

p99가 움직였습니다. 어느 릴리스가 움직였는지 찾습니다.

SLO는 위반이 무언가를 가리킬 때에만 쓸모가 있습니다. 여기서는 임계값 초과에서 원인이 된 커밋까지, 같은 시간 범위를 유지한 채 세 화면으로 이동합니다.

signal checkout p99 380 ms · threshold 200 ms

경로

임계값에서 커밋까지, 3분

하나의 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가 세 구간 연속으로 이어졌습니다.
dashboard T+0:40 · slocheckout p99 ≤ 200 ms

대시보드에서 엔드포인트 하나로 좁힙니다

p50은 움직이지 않았고 p99만 움직였습니다. 이 형태는 서비스 전체의 둔화가 아니라 특정 경로의 느린 꼬리를 뜻하며, 경로별 분해가 그것을 지목합니다. POST /checkout.
releases T+3:15 · slocheckout p99 ≤ 200 ms

두 릴리스를 나란히 비교

같은 엔드포인트를 service.version으로 나누면 계단식 변화의 주인이 드러납니다. abc123에서 p99가 120ms, def456에서 380ms. def456 아래 트레이스는 db.query 스팬을 50개 갖고 있고, 이전 것은 3개였습니다.

결과

T+9:20에 def456을 되돌렸습니다. 다음 평가 구간에서 p99가 임계값 아래로 돌아왔습니다.

할 수 있는 일

알림이 자신의 SLO를 알고 있습니다: 규칙은 백분위와 임계값을 기준으로 작성되므로, 발생한 알림에는 이미 비교 결과가 담겨 있습니다. 얼마나 벗어났는지 알기 위해 따로 찾아볼 것이 없습니다.
버전은 속성이므로 필터가 됩니다: service.version은 SDK가 보내는 모든 스팬에 실려 있습니다. 두 릴리스를 비교하는 일은 GROUP BY이지, 스프레드시트로 내보내는 작업이 아닙니다.
백분위는 자신의 트레이스를 갖고 있습니다: p99는 지금도 남아 있는 스팬에서 계산됩니다. 차트에서 급등 구간을 선택하면 그 안의 요청이 열리므로, 수치와 증거가 서로 다른 산출물이 되는 일이 없습니다.