퀴즈: 카디널리티 폭발

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

1. 라벨이 method(5) × status(8) × endpoint(40) 일 때 시계열 개수는?

   1. 라벨 값 종류를 더한 53개
   2. 모든 라벨 값 조합인 1,600개
   3. method와 status만 곱한 320개
   4. 라벨 이름 수만 센 3개

2. 다음 중 메트릭 라벨로 가장 위험한 것은?

   1. 요청마다 달라지는 trace_id
   2. 값 종류가 제한된 HTTP method
   3. 값 종류가 제한된 status_code
   4. 배포 환경을 나타내는 environment

3. `endpoint="/api/orders/8f3a91"` 형태로 라벨을 만들면?

   1. 조회가 정확해진다
   2. 주문 개수만큼 시계열이 늘어 폭발한다
   3. 저장 공간이 절약된다
   4. 알림이 정확해진다

4. '이 사용자의 요청이 왜 느렸는지' 를 알아야 한다. 어떤 신호를 써야 하는가?

   1. 메트릭에 user_id 라벨 추가
   2. 메트릭 보존 기간 연장
   3. 로그와 트레이스 — 높은 카디널리티는 이쪽의 몫이다
   4. 대시보드 추가

5. 카디널리티 폭발이 이미 일어났을 때 애플리케이션 배포 없이 즉시 쓸 수 있는 조치는?

   1. 시계열의 보존 기간을 더 늘려 잡는다
   2. 무거운 대시보드를 지운다
   3. 울리는 알림 규칙을 끈다
   4. 수집 단계의 relabel 로 문제 라벨이나 메트릭을 떨어뜨린다

6. 에러를 라벨로 남길 때 올바른 형태는?

   1. `error="db_timeout"` 처럼 분류된 값
   2. `error="connection to 10.0.3.17:5432 timed out"`
   3. `error=` 에 스택트레이스
   4. `error=` 에 타임스탬프 포함