저장된 규칙이 실행되는 규칙이 되기까지

한 줄 요약

PrometheusRule을 만들었다는 것은 규칙을 Kubernetes에 저장했다는 뜻입니다.
그 규칙이 선택되고, Prometheus에 로드되고, 실제 시계열에 평가되는지는 각각 확인해야 합니다.

왜 이게 필요했나

가상의 발급 플랫폼 팀은 장애 알림 규칙을 추가했습니다. 터미널에는 created가 찍혔고
코드 리뷰에서도 식이 맞다고 확인했습니다. 며칠 뒤 발급 API가 503을 내는데도 호출이
오지 않았습니다. 규칙 이름을 검색하면 Kubernetes에서는 보이지만 Prometheus의 rules
API에는 없었습니다. 팀은 '알림 식을 더 민감하게 바꾸자'고 했지만, 읽지도 않는 식의
임계값을 바꾸는 것은 이번 실패를 고치지 못합니다.

문제는 서로 다른 두 성공을 같은 것으로 부른 데 있습니다. API 서버는 객체의 저장을
담당하고, Operator는 자신이 관리하는 Prometheus에 넣을 객체를 골라 구성을 만듭니다.
애플리케이션 팀이 규칙을 저장할 권한을 가졌더라도 모든 Prometheus가 그 규칙을 읽는
설계라면 여러 팀의 규칙이 무분별하게 섞입니다. 선택 범위는 불편한 장벽이 아니라
소유권과 운영 범위를 표현하는 장치입니다.

어떻게 동작하나

| 관측 대상 | 확인하는 질문 | 아직 증명하지 못하는 것 |
| --- | --- | --- |
| Kubernetes의 PrometheusRule | 규칙 객체가 저장돼 있는가 | Operator 선택·실제 평가 |
| Namespace와 규칙의 라벨 | 지정된 선택 범위에 들어오는가 | 구성이 실제 프로세스에 반영됐는가 |
| Prometheus rules API | 실행 중인 인스턴스에 그룹이 로드됐는가 | 조건 충족·알림 전달 |
| targets API | 어떤 주소를 어떤 결과로 수집하는가 | 그 업무가 성공하고 있는가 |

선택은 두 번 좁힙니다. 먼저 ruleNamespaceSelector가 규칙을 찾을 네임스페이스를
고릅니다. 그 범위에서 ruleSelector가 PrometheusRule의 라벨을 검사합니다.
기본값과 비어 있는 선택자의 의미는 필드마다 다를 수 있으므로, '아무것도 안 썼으니
모두 선택하겠지'라고 추측하지 않습니다. 정확한 동작은
[Operator 규칙 선택 안내](https://prometheus-operator.dev/docs/developer/alerting/)에서 확인합니다.

예를 들어 monitoring=yes 네임스페이스 중 owner=payments 규칙만 읽는 인스턴스가
있다고 합시다. 규칙에 owner=payments를 넣었어도 네임스페이스가 범위 밖이면 읽지
않습니다. 네임스페이스만 고쳤는데 규칙이 owner=orders라면 여전히 읽지 않습니다.
둘을 한꺼번에 전체 선택으로 바꾸면 당장 보일 수는 있지만, 다른 팀의 규칙까지 읽어
중복 알림이나 비용 증가를 만들 수 있습니다. 필요한 한 조건만 고치고 다시 관측합니다.

메트릭 수집도 별도 선택 경로입니다. ServiceMonitor가 Service의 라벨과 포트 이름을
통해 수집 대상을 찾고, Prometheus는 ServiceMonitor의 네임스페이스와 라벨을 선택합니다.
포트 숫자를 문자열로 적는 것과 Service의 포트 이름을 쓰는 것은 같지 않습니다.
권한 부족도 라벨 불일치처럼 대상이 안 보이는 증상으로 나타날 수 있으므로,
[공식 문제 해결 순서](https://prometheus-operator.dev/docs/platform/troubleshooting/)에 따라
선택된 객체, 생성된 구성, 서비스와 발견 권한을 차례로 확인합니다.

현장에서 만나는 모습

이 단원의 준비 실험에서는 대상 메트릭이 up인데 규칙 그룹이 비어 있었습니다.
네임스페이스 라벨만 고친 뒤 75초 동안 보아도 규칙은 나타나지 않았습니다. 규칙 라벨을
맞추자 약 80초 뒤 로드됐습니다. 이는 한 번의 관측값이지 대기 시간을 고정하라는
권장이 아닙니다. API 변경, 구성 파일 투영, 재로딩과 평가가 다른 시점에 일어나므로
터미널의 configured를 마지막 증거로 삼지 말라는 사례입니다.

실패 응답의 모양도 중요합니다. 처음 만든 exporter는 올바른 지표 본문을 내보냈지만
Content-Type이 비어 있어 Prometheus 3의 scrape가 실패했습니다. 대상을 찾는 데는
성공했고 내용을 읽는 데 실패한 것입니다. 라벨을 다시 바꿔도 이 문제는 해결되지
않습니다. target의 lastError를 읽고 생산자의 HTTP 헤더를 고쳤습니다. 이 차이는
[Prometheus 3 변경 안내](https://prometheus.io/docs/prometheus/latest/migration/)와 대조할 수 있습니다.

수집 성공인 up은 애플리케이션이 메트릭을 반환했다는 관측입니다. 발급 기능의 외부
의존성이 고장 나도 exporter 프로세스는 계속 정상 응답할 수 있습니다. 반대로 지표가
없다는 것은 업무가 반드시 실패했다는 뜻이 아닙니다. 업무 상태와 관측 상태를 따로
기록하고, 둘 중 하나를 모르면 그 빈칸을 그대로 남겨야 합니다.

다음 레슨에서 할 것

다음 읽기에서는 규칙을 로드한 뒤에도 통지가 도착하지 않는 경계를 살펴봅니다.
그 뒤 실습에서 준비된 규칙의 식은 바꾸지 않고 네임스페이스·규칙 라벨을 각각 고칩니다. 저장된 객체와
실제 rules·targets API를 함께 봅니다. 한 경계를 고친 뒤 무엇이 바뀌고 무엇이 그대로인지
기록하세요. 실습은 개인 VM의 실제 k3s를 사용하며 운영 클러스터에 적용하는 절차가 아닙니다.