クイズ: メトリクスとトレースの対応づけ

지표에는 handler="/order/:id" 가, 스팬에는 http.target="/order/8821" 이 들어 있다. 무엇이 문제인가?

• 스팬의 주소가 지표보다 길어 저장 비용이 몇 배로 든다
• 지표 쪽이 경로 틀을 쓰므로 스팬도 주소를 버리고 틀만 남겨야 한다
• 두 값의 형식이 달라 추적 백엔드가 스팬을 제대로 색인하지 못한다
• 이름도 값도 달라서 봉우리에서 트레이스로 건너갈 열쇠가 없다

오류는 전부 남기고 성공은 다섯 건에 하나만 남기는 표본 정책 아래에서 스팬으로 오류율을 세면?

• 실제보다 크게 부풀어 오른다 — 분모만 줄고 분자는 그대로이기 때문이다
• 실제보다 작게 나온다 — 성공한 요청이 훨씬 많이 남기 때문이다
• 실제와 같게 나온다 — 표본 추출은 비율을 바꾸지 않기 때문이다
• 계산 자체가 되지 않는다 — 표본에 상태 코드가 남지 않기 때문이다

표본 추출한 스팬으로 요청 수를 되돌리려면 무엇이 필요한가?

• 표본 추출기가 버린 스팬의 수를 SDK 지표에서 함께 읽어 온다
• 트레이스 아이디의 앞 몇 비트로 그 스팬이 남을 확률을 되계산한다
• 스팬마다 그 스팬이 남을 확률이 적혀 있어야 하고, 역수를 가중치로 더한다
• 표본 비율이 일정하면 남은 스팬 수에 비율을 곱하면 되므로 따로 필요한 것이 없다

표본 확률의 역수로 보정해도 되돌아오지 않는 것은?

• 경로와 상태 코드로 묶은 요청 수의 합계
• 표본에 한 건도 들어오지 않은 조합과 지연의 분위수
• 오류 수와 전체 수로 계산한 오류율
• 서비스 이름으로 묶은 서비스별 요청 수

지표에서 추적으로 건너가는 다리(구간마다 대표 trace_id 를 남기는 방식)의 한계는?

• 대표를 고르느라 스팬을 두 번 내보내야 해서 전송량이 두 배가 된다
• 대표의 trace_id 가 시간이 지나면 바뀌어 오래된 패널에서는 쓸 수 없다
• 추적 백엔드가 대표를 받아 주려면 지표와 같은 저장소를 써야 한다
• 구간마다 한 건뿐이라 보통의 요청으로는 건너갈 수 없고, 표본에서 빠진 요청은 대표가 되지 못한다

요청 식별자와 사용자 식별자를 지표 라벨에 넣지 않는 까닭은?

• 값의 가짓수가 그대로 계열 수를 늘려 저장과 질의가 무너지기 때문이다
• 지표 라벨은 문자열만 담을 수 있어 식별자 형식이 맞지 않기 때문이다
• 개인정보에 해당해 지표 저장소에 남기는 것이 금지되어 있기 때문이다
• 추적에 이미 있으므로 지표에 또 두면 두 값이 어긋날 위험이 있기 때문이다