クイズ: サンプリングと運用

헤드 샘플링 1% 인 환경에서 시간당 5건 발생하는 오류를 조사하려 합니다. 보존되는 오류 트레이스는?

• 시간당 5건 전부 (오류는 항상 보존된다)
• 시간당 약 0.5건
• 샘플링과 무관하게 오류는 별도 경로로 저장된다
• 시간당 약 0.05건 — 1건을 보려면 평균 20시간 대기

테일 샘플링을 도입해도 줄어들지 않는 비용은?

• 백엔드에 쌓이는 저장 비용
• 백엔드의 인덱싱 비용
• 에이전트에서 컬렉터까지의 네트워크 전송량
• 백엔드 조회에 드는 쿼리 비용

DaemonSet 으로 배포한 컬렉터에서 tail_sampling 을 쓰면 안 되는 이유는?

• DaemonSet 은 메모리 제한이 낮기 때문
• DaemonSet 은 프로세서를 지원하지 않기 때문
• 한 트레이스의 스팬이 여러 노드의 에이전트로 흩어져 각자 일부만 보고 판정하기 때문
• 노드 수만큼 중복 저장되기 때문

게이트웨이 컬렉터를 3대로 늘리면서 앞에 일반 라운드로빈 로드밸런서를 두었습니다. 예상되는 증상은?

• 같은 트레이스의 스팬이 여러 인스턴스로 흩어져 트레이스가 무작위로 잘린다
• 부하가 균등해져 메모리 사용량이 줄어든다
• decision_wait 이 3배로 늘어난다
• 샘플링 정책이 3번씩 중복 적용된다

피크 트래픽 10,000 trace/s, decision_wait 30s 인 환경에서 num_traces 를 50,000 으로 두었습니다. 결과는?

• 메모리를 아껴 안정적으로 동작한다
• 상한을 넘은 오래된 트레이스가 강제로 판정되어 불완전한 결과가 저장된다
• decision_wait 이 자동으로 줄어든다
• 초과분은 디스크로 스필된다

tail_sampling 정책에서 헬스체크 라우트를 제외하려 합니다. 올바른 방법은?

• 정책을 아예 만들지 않는다
• string_attribute 정책에 invert_match 를 켜서 해당 라우트가 아닌 것만 남긴다
• probabilistic 정책의 비율을 0 으로 둔다
• filter 프로세서를 tail_sampling 뒤에 둔다