クイズ: 相関 id でリクエストをつなぐ

W3C traceparent 값 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 의 네 칸은 차례대로 무엇인가?

• version · trace-id · parent-id · trace-flags
• version · parent-id · trace-id · tracestate
• vendor · trace-id · span-id · sampled-rate
• protocol · request-id · session-id · priority

어떤 서비스가 00-00000000000000000000000000000000-b7ad6b7169203331-01 을 받았다. 규격에 따르면 어떻게 해야 하나?

• trace-id 가 0 이므로 parent-id 만 상관 id 로 삼아 그대로 이어 간다
• 값이 짧아진 것이므로 왼쪽을 0 으로 채워 32자로 늘려 쓴다
• trace-id 가 무효이므로 이 traceparent 를 무시해야 한다(MUST)
• 버전이 00 이므로 형식만 맞으면 값에 관계없이 그대로 전달한다

sampled 인 추적을 세려고 flags == "01" 로 비교했더니 숫자가 실제보다 적었다. 이유는?

• trace-flags 가 대문자로 올 수 있어 01 과 0A 를 같이 보아야 한다
• trace-flags 는 비트 필드라 09 나 03 처럼 다른 비트가 함께 켜진 값도 sampled 다
• sampled 는 trace-flags 가 아니라 tracestate 의 첫 항목에 들어 있다
• trace-flags 는 표본 비율을 담는 칸이라 01 은 1퍼센트를 뜻한다

한 요청이 추적 도구에 짧은 추적 두 개로 쪼개져 보인다. 가장 그럴듯한 원인은?

• 두 서비스의 시계가 어긋나 같은 추적이 두 구간으로 나뉘어 보인다
• sampled 플래그가 중간에 꺼져 뒤쪽 구간이 다른 추적으로 저장되었다
• tracestate 의 항목 수가 32개를 넘어 앞쪽 항목이 잘려 나갔다
• 중간의 한 구성 요소가 헤더를 전달하지 않아 그 뒤가 새 추적을 시작했다

추적이 끊긴 구간을 주문번호 같은 업무 키로 이어 붙였다. 이 방법의 한계로 옳은 것은?

• 업무 키는 로그에만 있고 헤더에는 없어서 시간순 정렬이 불가능해진다
• 업무 키로 이으면 원래의 trace-id 가 덮어써져 추적 도구에서 사라진다
• 업무 키는 재시도까지 같은 값이라 요청 하나를 정확히 가리키지 못한다
• 업무 키는 서비스마다 이름이 달라 같은 값이 서로 다른 주문을 가리킨다

구간별 소요 시간에서 자식 구간의 시간을 뺀 '자기 시간' 이 주문 서비스에서 유난히 크게 나왔다. 먼저 의심할 것은?

• 주문 서비스의 CPU 가 부족해 처리 자체가 느려졌다
• 주문 서비스가 부르는 하위 호출 가운데 계측되지 않아 보이지 않는 것이 있다
• 주문 서비스의 로그 수준이 DEBUG 라 기록에 시간이 더 걸렸다
• 주문 서비스의 시계가 빨라 구간의 끝 시각이 뒤로 밀렸다