クイズ: 三つの信号とメトリクス設計

장애 조사에서 세 신호를 보는 순서로 권장되는 것은?

• 메트릭 → 트레이스 → 로그
• 로그 → 메트릭 → 트레이스
• 트레이스 → 메트릭 → 로그
• 셋은 대체재이므로 순서가 없다

Summary 타입을 서비스 수준 지표로 쓸 수 없는 이유는?

• 파드 재시작 때 카운터 리셋을 스스로 보정하지 못해서
• 버킷 경계를 바꿀 수 없어서
• 저장 용량을 너무 많이 써서
• 인스턴스 안에서 이미 백분위를 계산해 내보내므로 여러 인스턴스를 합칠 방법이 없어서

스크레이프 간격 15초, 초당 요청 500건인 서비스에서 지연 시간을 게이지로 저장하면?

• 평균은 정확하지만 분위수만 부정확해진다
• 7,500건 중 1건의 값만 저장되고 나머지는 복원되지 않는다
• 저장은 다 되지만 조회가 느려진다
• 카운터 리셋 때만 값이 유실된다

rate(sum(http_requests_total)[5m:]) 처럼 sum 을 먼저 하고 rate 를 걸면 생기는 문제는?

• 파드 재시작이 리셋으로 인식되지 않아 배포 직후마다 트래픽이 줄어든 것처럼 보인다
• 쿼리가 문법 오류로 실패한다
• 결과 단위가 초당이 아니라 분당으로 바뀌어 버린다
• 라벨이 전부 사라진다

histogram_quantile 에서 by (le) 를 빠뜨리면?

• 쿼리가 즉시 에러를 낸다
• 에러 없이 틀린 숫자를 반환해 대시보드에 몇 달씩 남는다
• 항상 0 이 나온다
• 마지막 버킷 값이 그대로 나온다

http_request_duration_seconds_bucket 에 route 120 × method 5 × le 11 × instance 40 이면 시계열은 몇 개인가?

• 6,600
• 26,400
• 264,000
• 312,000