クイズ：保存・発火・配信の境界

PrometheusRule 생성은 성공했지만 /api/v1/rules에 그룹이 없습니다. 먼저 확인할 조합은?

• 규칙 네임스페이스 선택과 규칙 라벨 선택
• Alertmanager 수신자의 재전송 주기만
• 웹훅 수신 서버의 요청 본문 크기만
• 알림 메시지의 표시 언어와 글자 수

ServiceMonitor의 endpoints.port에 넣어야 하는 값은 무엇인가요?

• 컨테이너 포트의 정수 값을 문자열로 변환한 값
• 선택한 Service에 선언된 포트의 이름
• Pod 이름 뒤에 컨테이너 포트를 붙인 값
• Service의 ClusterIP에 프로토콜을 붙인 값

메트릭 target은 up인데 발급 요청은 503입니다. 가장 정확한 해석은?

• up이면 업무 실패는 클라이언트 측 문제다
• 503이므로 exporter 프로세스는 반드시 종료됐다
• 수집 경로와 업무 의존성 상태는 서로 다르다
• up이므로 규칙 선택과 통지 전달도 완료됐다

Prometheus는 firing인데 Alertmanager API에는 알림이 없습니다. 어느 경계를 조사하나요?

• 사용자에게 보이는 알림 제목과 번역
• 이미 통과한 규칙의 YAML 들여쓰기만
• 수신 웹훅의 send_resolved 옵션만
• Prometheus의 Alertmanager 연결·발견·접근

Alertmanager가 알림을 받았지만 기본 sink receiver에는 전송 대상이 없습니다. 결과는?

• 수신해도 실제 웹훅 통지는 없을 수 있다
• 기본 웹훅으로 자동 전송된 것으로 본다
• Prometheus의 규칙이 자동으로 삭제된다
• 수신한 알림은 즉시 업무 성공으로 바뀐다

웹훅 그룹에 옛 파드의 resolved와 새 파드의 firing이 함께 왔습니다. 무엇을 해야 하나요?

• resolved가 하나 있으니 새 파드도 복구로 판정
• 개별 알림 상태와 현재 대상 라벨을 대조
• 그룹이 도착했으니 모든 파드를 정상으로 판정
• 알림 이름만 같으면 시간과 파드를 생략

구성 변경 직후 조회가 비어 있고 컨트롤러는 계속 실행 중입니다. 올바른 다음 행동은?

• 조회가 비었으니 즉시 환경 전체를 다시 설치
• 임의의 정상 JSON을 저장해 검사를 먼저 통과
• 설정과 반영 로그를 확인하며 같은 환경을 재관측
• for 값을 0으로 만들면 모든 전달 문제가 해결

관측 API 호출 실패 뒤 빈 객체를 diagnose에 넣었습니다. 합당한 반환은?

• inactive — 경보가 없으니 정상 상태
• recovered — 관측할 장애가 사라진 상태
• notified — 전송한 뒤 비워진 것으로 추정
• unknown — 필요한 관측 근거가 없는 상태