클러스터마다 다른 임계값과 운영 카탈로그를 분리하기

코드에 들어 있던 운영 기준을 밖으로 꺼내기

초기 RCA Rule은 코드 안에 Collector 선택, 임계값과 권장 조치가 함께 들어 있었다. 기능을 빠르게 검증할 때는 단순했지만 운영 환경이 늘어나자 문제가 생겼다.

• DiskPressure에서 어떤 Collector를 요청할지 바꾸려면 코드를 수정해야 했다.
• 특정 Detector를 canary 기간에만 끄기 어려웠다.
• 같은 디스크 사용률도 클러스터 성격에 따라 정상 기준이 달랐다.
• 권장 조치 문구와 정책을 변경할 때 애플리케이션 릴리스가 필요했다.
• 운영 변경이 코드 리뷰와 섞여 Audit 경계가 흐려졌다.

그래서 분석 코드는 신호를 계산하는 역할에 집중하고, 운영 기준은 Operational Catalog와 Cluster Threshold Override로 분리했다.

Operational Catalog의 세 영역

Catalog는 크게 Collector, Action, Rule을 관리한다.

Collector Catalog

Collector의 의미, 활성화 여부와 필요한 permission mode를 정의한다. Alert별 Collector 조합도 Catalog에서 선택한다.

DiskPressure
  → node
  → disk
  → inode
  → kernel
  → systemd

모든 Collector를 항상 실행하면 수집 시간이 길어지고 권한 범위도 커진다. 장애 증상에 필요한 근거부터 요청하되 추가 Evidence가 필요하면 다음 수집을 만들도록 했다.

Action Catalog

Signal에 어떤 확인 작업과 안내를 연결할지 정의한다. 가장 중요한 계약은 plan.executable=false다. Catalog가 외부 파일로 분리돼도 host mutation을 실행하는 우회 경로가 생기면 안 된다.

Rule Catalog

Detector별 enablement를 관리한다. 특정 canary에서 disk-pressure Rule을 잠시 끌 수 있지만, 변경 내용은 검증과 승인 절차를 거친다.

잘못된 Catalog는 부팅 단계에서 막기

외부 JSON은 필요한 key만 넣고 기본 Catalog와 병합할 수 있다. 대신 다음 계약을 위반하면 애플리케이션을 시작하지 않는다.

• schema version이 맞는지
• 존재하지 않는 Collector를 참조하는지
• Action policy가 빠졌는지
• 필수 수동 조사 Action이 있는지
• 실행 가능한 Action plan이 포함됐는지

운영 설정 오류를 조용히 무시하면 일부 Rule만 빠진 상태로 Report가 생성될 수 있다. 잘못된 설정으로 동작하는 것보다 시작 단계에서 명확히 실패하는 편이 안전하다고 판단했다.

Platform Info API와 Web Console Settings에서는 현재 Catalog source, version, checksum과 Collector·Action·Rule 개수를 읽기 전용으로 보여준다. “어떤 설정으로 이 Report가 만들어졌는가”를 운영자가 확인할 수 있다.

Preview와 승인 Draft

Override를 바로 적용하지 않고 먼저 preview한다. JSON Pointer 기준 diff, 현재 값과 제안 값, 검증 결과를 반환하고 Audit event를 남긴다.

검증을 통과한 내용은 다음 상태를 갖는 Draft로 저장한다.

draft → approved | rejected | discarded

승인됐다고 현재 Platform 설정이 즉시 바뀌지는 않는다. Handoff 내용이나 GitOps PR을 통해 외부 변경관리 절차로 전달한다. 분석 플랫폼이 자기 Rule을 API 호출 하나로 바꾸는 구조를 피했다.

클러스터별 Threshold Override

Catalog와 별도로 클러스터마다 임계값을 덮어쓸 수 있게 했다.

{
  "thresholds": {
    "disk.warning.percent": 93,
    "disk.critical.percent": 95
  },
  "reason": "staging storage pool has a higher normal baseline"
}

알 수 없는 key, 범위를 벗어난 percent, warning보다 낮은 critical 값은 저장하지 않는다. 실제 분석에서는 다음처럼 effective threshold를 계산한다.

application default + cluster override

사용된 값은 Report의 derived signal에 함께 기록한다. 같은 95%가 어느 클러스터에서는 critical이고 다른 곳에서는 정상 범위일 수 있기 때문이다.

이 구조를 선택한 이유

운영 기준을 코드에서 분리하면 유연해지지만 잘못 사용하면 더 위험하다. 그래서 단순한 외부 설정 파일이 아니라 다음 경계를 함께 만들었다.

• schema와 fail-fast 검증
• checksum과 source 가시성
• preview와 diff
• 역할 기반 저장·승인
• Audit 기록
• 자동 적용 금지

설정을 바꿀 수 있는 기능보다, 누가 어떤 이유로 어떤 기준을 바꿨는지 설명할 수 있는 구조가 더 중요했다.

프로젝트 저장소: Kubernetes Cluster Infra RCA Platform