퀴즈: 관측성

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

1. 메시를 깔았는데 분산 트레이스가 한 홉짜리로만 보입니다. 가장 유력한 원인은?

   1. 수집기 주소가 틀려 하위 서비스가 만든 스팬만 전송에 실패하고 있어서
   2. 사이드카가 첫 홉에서만 스팬을 만들고 그 뒤 홉에서는 만들지 않아서
   3. 애플리케이션이 인바운드 요청의 트레이스 헤더를 아웃바운드 요청에 복사하지 않아서
   4. 샘플링 비율이 1% 라 뒤따르는 홉이 대부분 걸러지고 있어서

2. `istio_requests_total` 의 `reporter` 라벨을 필터링하지 않으면 생기는 문제는?

   1. 같은 요청이 보낸 쪽과 받은 쪽 양쪽에서 기록되어 요청 수가 두 배로 보인다
   2. reporter 를 지정하지 않은 메트릭은 아예 수집되지 않는다
   3. 보낸 쪽과 받은 쪽의 버킷 경계가 달라 지연 히스토그램이 어긋난다
   4. 요청이 mTLS 로 왔는지 평문으로 왔는지 구분할 수 없게 된다

3. STRICT mTLS 전환의 완료 기준을 메트릭으로 정의한다면 가장 적절한 것은?

   1. 액세스 로그의 `response_flags` 가 일정 기간 전부 `-` 로만 찍히는 것
   2. `istio_requests_total` 의 총합이 전환 전후로 변하지 않고 유지되는 것
   3. 전환 전후로 p99 지연이 통계적으로 유의한 차이를 보이지 않는 것
   4. `connection_security_policy` 가 `none` 인 요청이 일정 기간 0건인 것

4. Mixer 가 제거되고 Telemetry API v2 로 바뀌면서 얻은 가장 큰 이점은?

   1. 프로메테우스 같은 수집 시스템 없이도 대시보드를 볼 수 있게 됐다
   2. 액세스 로그가 프록시 안에서 자동으로 압축되어 저장량이 줄었다
   3. 요청마다 별도 서비스를 호출하지 않아 지연과 장애 지점이 사라졌다
   4. 메트릭 이름과 라벨 체계가 업계 표준 규격으로 통일됐다

5. 액세스 로그의 응답 플래그가 `UF` 인 503 을 조사할 때 먼저 볼 것은?

   1. 설정한 재시도 횟수를 모두 소진하고도 성공하지 못했는지
   2. 연결 풀의 최대 대기 요청 수가 너무 작게 잡혀 있는지
   3. VirtualService 에 맞는 라우트가 없어 매칭에 실패했는지
   4. 한쪽만 STRICT 인 mTLS 설정 불일치나 포트/프로토콜 미스매치

6. 메시 메트릭만으로는 알 수 없는 것은?

   1. 어떤 서비스가 어떤 서비스를 호출했는지
   2. 주문이 실제로 저장됐는지 같은 도메인 결과
   3. 요청 지연이 p50 과 p99 에서 어떻게 분포하는지
   4. 서비스별 요청 성공률과 5xx 응답 비율

7. 커스텀 태그로 요청 경로 전체나 사용자 ID 를 메트릭 라벨에 넣으면?

   1. 값의 종류가 많아지면 샘플링 비율이 자동으로 낮아진다
   2. 요청을 개별로 구분할 수 있어 대시보드가 더 정확해진다
   3. 프록시가 종류가 많은 라벨을 자동으로 해시해 묶어 준다
   4. 라벨 값의 종류만큼 시계열이 늘어 카디널리티가 폭발한다