Quiz: Observability

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

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

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

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

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

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

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

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

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

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

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

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

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

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