Quiz: scrape budgets and information loss

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

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

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

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

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

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

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

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

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

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

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

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