퀴즈: 수집 예산과 정보 손실

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 업무 HTTP는 200인데 up=0이며 최근 오류가 sample limit 초과입니다. 적용 한도는 8, relabel 뒤 샘플은 13개입니다. 맞는 설명은?

   1. 해당 스크레이프 전체가 실패했으며 업무 장애 여부는 별도로 확인한다.
   2. 앞의 8개는 정상 수집되고 나머지 5개만 다음 수집으로 미뤄진다.
   3. 업무 프로세스가 반드시 종료됐으므로 먼저 재시작해야 한다.
   4. 한도는 조회 결과 개수에만 적용되므로 수집 실패와 관계없다.

2. 한도를 16으로 높이자 up=1, 현재 요청 시계열 12개가 됐습니다. 이 관측이 증명하는 범위는?

   1. 사용자 라벨의 증가가 영구적으로 제한되어 계측 문제가 해결됐다.
   2. 이 응답은 새 한도 안에 들어왔지만 라벨 조합 수는 그대로다.
   3. 질의 결과가 자동 집계되어 TSDB에는 한 시계열만 저장됐다.
   4. 수집 한도가 메모리 상한을 대체하므로 별도 자원 측정이 불필요하다.

3. 사용자별 값 1~12의 구별 라벨을 labeldrop으로 제거했습니다. 이번 실제 실험에서 up=1인데 합계는 1입니다. 타당한 판단은?

   1. up=1이므로 원 합계 78도 정확하게 보존됐다고 보고한다.
   2. labeldrop은 sum과 같으므로 결과 1을 합계 78로 해석한다.
   3. 고유 주소가 충돌했으며 라벨 삭제를 집계로 간주하면 안 된다.
   4. 전체 합계가 1인 것은 요청 처리량이 정확히 초당 1건이라는 뜻이다.

4. 요청 지표 family를 제외하자 up=1이지만 요청 질의는 빈 벡터입니다. 가장 적절한 보고는?

   1. 표본이 없다는 것과 값 0이 같으므로 요청 0건이라고 기록한다.
   2. up이 정상이라 모든 업무 지표가 보존됐다고 기록한다.
   3. 표본을 다시 만들기 위해 대시보드에서 모든 빈 값을 0으로 바꾼다.
   4. 필터로 필요한 신호가 사라졌는지 확인하고 0과 결손을 구별한다.

5. 소스에서 route별 합계 78을 한 counter로 노출했습니다. 샘플은 2개이고 한도 8에서 정상입니다. 올바른 한계는?

   1. 요청 합계를 유지했지만 사용자별 세부 질문에는 이 지표만으로 답할 수 없다.
   2. 현재 시계열이 줄었으므로 이전 사용자별 샘플도 즉시 삭제됐다.
   3. 모든 서비스에서 sample_limit=8이 최적이라는 사실을 검증했다.
   4. 현재 합계 78을 그대로 78 requests/second로 표시할 수 있다.

6. 개선 후 현재 count는 1인데, 과거 평가 시각의 쿼리는 count=12와 sum=78입니다. 무엇을 확인한 것인가?

   1. 현재 sum 질의가 과거 시계열을 물리적으로 하나로 합쳤다.
   2. 현재 계측 변경 뒤에도 그 과거 시점의 샘플을 조회할 수 있다.
   3. series API의 모든 라벨이 현재 활성 표본이라는 뜻이다.
   4. 과거 정보를 지우려면 사용자 ID 라벨을 대시보드에서 숨기면 된다.