사용 사례

결제가 실패하고 있습니다. 어느 주문이, 왜.

세일 중에 중요한 것은 에러율이 아닙니다. 어떤 고객이 장바구니를 잃었고 무엇이 그것을 막았는지가 문제입니다. 주문 ID 하나가 세 화면 모두에서 답을 실어 나릅니다.

signal POST /checkout error rate 8.4% · threshold 1%

경로

주문 하나를, 알림에서 타임아웃까지

order_8421은 실제로 실패한 주문입니다. 아래의 모든 화면이 이 주문으로 좁혀져 있어서, 두 도구 사이에서 타임스탬프를 맞춰볼 일이 없습니다.

order order_8421 /alerts /traces /errors T+0:00 T+0:25 T+2:10

alert T+0:00 · orderorder_8421

알림은 checkout 경로에서만 발생합니다

사이트 나머지는 버티는 동안 POST /checkout의 에러율만 임계값을 넘습니다. 이 범위 자체가 첫 번째 사실입니다. 세일 트래픽이 아니라 결제 경로의 문제입니다.
trace T+0:25 · orderorder_8421

트레이스는 Stripe에서 멈춥니다

실패한 주문 하나를 열면 워터폴은 분명합니다. 재시도 세 번이 맨 아래에 빨갛게 놓여 있고, 각각 정확히 1.75초에 타임아웃됩니다. 제공자 쪽이 아니라 클라이언트 자신의 마감 시간입니다.
logs T+2:10 · orderorder_8421

로그는 풀이 비어 있었다고 말합니다

그 스팬들이 실행되는 동안 기록된 줄은 같은 트레이스 ID를 갖습니다. 재시도 예산 소진, 이어서 커넥션 풀 한도 도달. 타임아웃은 Stripe가 느려서가 아니라 연결을 기다린 증상이었습니다.

결과

풀을 늘리고 재시도 예산을 두 번으로 줄였습니다. checkout 에러율은 한 평가 구간 안에 기준선으로 돌아왔습니다.

할 수 있는 일

비즈니스 ID도 그저 속성입니다: 스팬에 order.id를 한 번 설정하면 트레이스 목록, 에러 이슈, 로그 검색 등 스팬이 있는 모든 곳에서 걸러낼 수 있습니다. 따로 유지할 인덱스가 없습니다.
외부 호출도 스팬입니다: Stripe 호출은 자체 소요 시간과 상태를 가진 클라이언트 스팬입니다. 서드파티 타임아웃은 자사 에러율에서 추론하는 것이 아니라 실제로 측정됩니다.
로그는 결합되는 것이지 두 번 검색하는 것이 아닙니다: 스팬 뒤의 로그 줄에는 같은 분으로 손수 좁힌 텍스트 검색이 아니라 스팬에서 바로 도달합니다. 보통 가장 많은 시간을 잡아먹는 단계가 바로 이것입니다.