트래픽이 적은 서비스에서 드문 장애를 놓치지 않게 하는 트레이스 샘플링 전략은 무엇인가?

열린 질문

공개된 샘플링 조언은 대개 트래픽 규모가 크다는 것을 전제합니다: 작은 비율만 남기고, 오류와 느린 요청을 놓치지 않도록 테일에서 샘플링하고, 나머지는 큰 수의 법칙에 맡기라는 식입니다. OpenTelemetry의 샘플링 페이지 자체도 데이터 발생량이 매우 적은 경우(초당 수십 건 이하의 작은 트레이스)를 아예 샘플링하지 말아야 할 이유 중 하나로 들면서, 거기서 설명을 멈춥니다. 작은 서비스는 초당 요청이 몇 건 정도이고 대부분 정상이며, 정말 중요한 이벤트는 드뭅니다. 하루에 타임아웃 한 번, 일주일에 잘못된 페이로드 한 번 정도입니다. 고정된 헤드 샘플링 비율은 이런 이벤트 대부분을 걸러 내 버립니다. 이 정도 규모라면 전부 보존하는 것도 흔히 감당할 만하지만, 그러면 보존 기간이 비용을 좌우하는 지렛대가 되고, 테일 샘플링에는 트레이스 전체를 버퍼링하는 컬렉터가 필요합니다.

트래픽이 적은 서비스의 운영자들은 실제로 무엇을 해 왔고, 그 비용은 얼마였을까요? 후보로는 짧은 기간 동안은 모든 트레이스를, 긴 기간 동안은 오류나 느린 트레이스만 보존하는 방식, 헬스체크와 크롤러에는 예외를 두고 나머지는 100%로 헤드 샘플링하는 방식, 상태·지연 시간·특정 속성에 대한 규칙을 둔 테일 샘플링, 그리고 트래픽이 줄어들면 비율을 높이는 동적 샘플링 등이 있습니다. 이 중 어떤 방식을 팀들이 계속 유지했고 어떤 방식을 포기했는지, 그리고 장애 리뷰에서 필요한 트레이스가 샘플링으로 이미 사라졌다는 사실을 얼마나 자주 발견했는지는 아직 알려져 있지 않습니다.

유용한 답변에 담겨야 할 것

서비스의 요청 비율과 트레이스당 서비스 수, 샘플링 메커니즘과 그 규칙, 트레이스 종류별 보존 기간, 명시된 단위로 표시한 스토리지와 컬렉터 비용, 트레이스가 남아 있었던 장애와 없었던 장애의 사례, 그리고 그 설정이 트래픽이나 팀의 변화를 견뎌 냈는지 여부. 공급자의 기본값이라면 그렇다고 밝혀야 하고, 일화는 단일 사례임을 명시해야 합니다.