测验：属性、事件与链接

실패한 요청의 스팬에 속성을 더할 때 기준으로 삼을 질문은?

• 백엔드에서 색인 비용이 가장 싼 값은 무엇인가
• 자동 계측이 이미 넣어 준 값과 겹치지 않는 값은 무엇인가
• 이 서비스가 가진 변수 중 이름이 가장 짧은 것은 무엇인가
• 이 스팬만 들고 같은 실패를 다시 내려면 무엇이 더 있어야 하나

인증 토큰을 스팬에 남기는 방법으로 가장 알맞은 것은?

• 길이만 정수로 남긴다
• 앞 네 글자만 잘라 그대로 남긴다
• 원문을 남기되 스팬 상태를 ERROR 로 둔다
• 이벤트 속성에 넣으면 속성이 아니므로 원문으로 남겨도 된다

재시도에 대해 속성과 이벤트를 어떻게 나누는 것이 맞나?

• 재시도는 전부 이벤트로만 남기고 속성은 쓰지 않는다
• 재시도는 전부 속성으로만 남기고 이벤트는 쓰지 않는다
• 횟수는 속성으로, 각 시도가 언제 왜 실패했는지는 이벤트로 남긴다
• 첫 시도만 속성으로 남기고 나머지는 로그로 보낸다

다른 트레이스와의 관계를 shop.parent_trace_id 같은 속성 문자열로 적어 두면 무엇을 잃는가?

• 그 속성이 금지 열쇠로 분류되어 백엔드가 스팬을 버린다
• 도구가 두 트레이스를 이어 주지 못해 사람이 눈으로 찾아 열어야 한다
• 속성 값이 문자열이라 타입 검사를 통과하지 못한다
• 관계를 적은 쪽의 스팬 길이가 대기 시간만큼 늘어난다

속성 열쇠 하나의 고유값이 수천 가지가 되는 가장 흔한 원인은?

• 열쇠 이름에 점을 너무 많이 썼다
• 정수 값을 문자열로 넣었다
• 이벤트에 속성을 붙였다
• 예외 메시지처럼 식별자가 박힌 문장을 범주형 열쇠에 넣었다

팀 규약을 문서가 아니라 기계가 읽는 파일로 적고 검사기를 붙이는 이유는?

• 새 핸들러를 계측할 때 같은 기준이 자동으로 적용되고 어긋난 곳이 바로 드러나기 때문
• 규약 파일이 있으면 SDK 가 금지된 속성을 알아서 지워 주기 때문
• 규약 파일이 백엔드의 색인 설정을 대신하기 때문
• 문서로 적으면 속성 이름이 semconv 와 충돌하기 때문