퀴즈: baggage 와 tracestate

baggage 에 tenant=acme 를 넣고 하류 서비스에서 스팬을 만들었다. 그 스팬에 tenant 속성이 보이는가?

• 보인다. SDK 가 baggage 를 스팬 속성으로 자동 복사한다
• 보이지 않는다. 문맥에 있을 뿐이라 각 서비스가 꺼내서 직접 속성으로 적어야 한다
• 보인다. 단 루트 스팬에만 붙고 자식 스팬에는 붙지 않는다
• 보이지 않는다. baggage 는 같은 프로세스 밖으로 나가지 못하기 때문이다

W3C Baggage 규격이 '모든 항목을 전달해야 한다' 고 보장하는 조건은 무엇인가?

• 항목 32개 이하이고 512바이트 이하일 때
• 항목 180개 이하이고 4096바이트 이하일 때
• 항목 64개 이하이고 8192바이트 이하일 때
• 항목 수 제한 없이 헤더 하나가 16384바이트 이하일 때

파이썬 SDK 로 값이 9천 자인 항목을 baggage 에 넣고 주입했다. 무슨 일이 일어나는가?

• 그 항목만 헤더에서 빠지고 예외 없이 그대로 진행된다
• 주입 시점에 예외가 올라와 요청이 실패한다
• 값이 4096자에서 잘린 채 헤더에 실린다
• 헤더 전체가 비어 나가고 경고 없이 baggage 가 사라진다

tracestate 가 상한을 넘어 잘라야 할 때 규격이 먼저 버리라고 지목한 것은?

• 가장 오래된 항목, 즉 맨 왼쪽 항목
• 우리 벤더의 항목을 제외한 모든 항목
• 값이 비어 있거나 공백뿐인 항목
• 길이가 128자를 넘는 항목

들어온 tracestate 에 우리 항목을 새로 넣을 때 지켜야 하는 것은?

• 우리 항목을 맨 왼쪽에 두고 건드리지 않은 항목의 순서는 그대로 보존한다
• 우리 항목을 맨 오른쪽에 붙여 기존 항목의 자리를 그대로 둔다
• 열쇠 사전순으로 전체를 다시 정렬해 모든 벤더가 같은 순서를 보게 한다
• 우리 항목을 넣기 전에 우리가 모르는 항목을 모두 지워 길이를 확보한다

공개 API 앞 관문에서 들어온 baggage 를 그대로 스팬 속성으로 옮겼을 때 생긴 문제는?

• 헤더 파싱 비용이 늘어 관문의 CPU 사용률이 눈에 띄게 올라갔다
• trace_id 가 충돌해 서로 다른 요청의 스팬이 한 트레이스로 묶였다
• 값의 카디널리티를 외부 호출자가 정하게 되어 시계열이 수십만 갈래로 갈라졌다
• baggage 헤더가 응답에도 실려 브라우저의 교차 출처 정책에 막혔다