26Y19c2

실시간 1단계 핵심은 배치를 돌리던 Polars 엔진의 고차원 SRE 수식을 Prometheus가 실시간으로 이해할 수 있는 PromQL(Prometheus Query Language)로 번역하여, Kubernetes 환경의 PrometheusRule Custom Resource(CRD)로 선언형 등록을 진행하는 것입니다.

모니터링 스택(kube-prometheus-stack 등)이 이 규칙을 실시간으로 감시하다가, 임계치를 돌파하는 순간 2단계와 3단계(JIT LLM RCA)를 깨울 수 있도록 Webhook 알람을 던지게 만듭니다.

생산 환경에 바로 적용할 수 있는 구체적인 등록 명세와 방법입니다.

---

📄 1. 어떤 내용을 등록해야 하나? (PrometheusRule YAML 명세)

우리가 앞서 정의한 4대 SRE 유도 특징량을 cAdvisor 및 Cilium 익스포터 기반의 실시간 벡터 연산으로 재구성한 YAML 파일입니다.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: lakehouse-sre-realtime-rules
  namespace: monitoring
  labels:
    role: alert-rules
    release: prometheus-stack # 사내 Prometheus Operator가 긁어갈 수 있는 Label 매칭
spec:
  groups:
  - name: lakehouse-sre-behavioral-anomaly
    rules:

    # 1. 분산 노드 간 Data Skew 변동계수 폭발 탐지
    - alert: LakehouseDataSkewExplosion
      expr: |
        (
          stddev by (workload_type) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))
          /
          avg by (workload_type) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))
        ) > 0.4
      for: 3m
      labels:
        severity: critical
        tier: infrastructure
      annotations:
        summary: "High Distributed Load Skew Detected in {{ $labels.workload_type }}"
        description: "특정 워크로드 노드 간 CPU 부하 변동계수가 0.4를 초과했습니다. 데이터 셔플 키 또는 버킷 불균형이 강하게 의심됩니다."

    # 2. 메모리 OOM 시한폭탄 근접도 탐지
    - alert: MemoryOomProximityCrisis
      expr: |
        (
          sum by (namespace, pod, container, workload_type) (container_memory_working_set_bytes{container!=""})
          /
          sum by (namespace, pod, container, workload_type) (container_spec_memory_limit_bytes{container!=""} > 0)
        ) > 0.95
      for: 1m
      labels:
        severity: critical
        tier: compute
      annotations:
        summary: "Container Memory OOM Proximity reached {{ $value | humanizePercentage }}"
        description: "{{ $labels.pod }} [{{ $labels.container }}] 가 한계값(Limit)의 95%에 도달하여 OOM Killer 사살 직전 상태입니다."

    # 3. CPU 스로틀링 포화 밀도 감지
    - alert: CpuThrottleDensitySaturation
      expr: |
        (
          rate(container_cpu_cfs_throttled_seconds_total{container!=""}[5m])
          /
          rate(container_cpu_usage_seconds_total{container!=""}[5m])
        ) > 0.3
      for: 5m
      labels:
        severity: warning
        tier: compute
      annotations:
        summary: "Severe CPU Throttling Density on {{ $labels.workload_type }}"
        description: "사용 연산량 대비 CFS 스로틀링 밀도가 30%를 돌파하여 파이프라인의 전체 타임라인 지연이 발생 중입니다."

    # 4. Cilium eBPF 커널 레이어 패킷 드롭 스파이크 감지
    - alert: CiliumEbpfPacketDropSpike
      expr: sum by (workload_type) (increase(cilium_drop_count_total[1m])) > 50
      for: 1m
      labels:
        severity: critical
        tier: network
      annotations:
        summary: "Cilium CNI eBPF Packet Drop Spike Detected"
        description: "최근 1분간 커널 단에서의 패킷 드롭이 50건을 돌파했습니다. Network Policy 포화 또는 eBPF Map 한계 도달 정황이 있습니다."

🧮 핵심 PromQL 매커니즘 해부

• Data Skewness 변동계수($CV$) 구현: PromQL은 통계 함수인 stddev와 avg를 그룹별로 제공합니다. 이를 분기하여 수식화하면 배치에서 구현했던 수학적 변동계수 연산이 실시간 슬라이딩 윈도우로 완벽히 재현됩니다.

$CV = \frac{\sigma \text{ (표준편차)}}{\mu \text{ (평균)}}$

• OOM 근접도 구현: cAdvisor의 container_memory_working_set_bytes는 커널이 메모리가 부족할 때 가장 먼저 참조하는 실효 지표입니다. 이를 limit선으로 다이렉트로 나누어 0.95(95%)를 넘는지 실시간 감시합니다.

---

⚙️ 2. 어떻게 등록하고 연동해야 하나? (방법 및 아키텍처 결착)

위 내용을 등록하고, 장애 발생 시 온디맨드 LLM 에이전트까지 데이터 파이프라인을 연결하는 전체 가동 절차입니다.

1단계: 규칙 반영 (GitOps 또는 Kubectl)

작성한 YAML 파일을 현재 플랫폼 클러스터의 Prometheus Operator가 감시하는 경로에 배포합니다.

kubectl apply -f lakehouse-sre-realtime-rules.yaml

Prometheus 서버가 구성 파일을 자동으로 핫 리로드(Hot-reload)하며 매 15~30초 주기로 해당 PromQL을 실시간 연산하기 시작합니다.

2단계: Alertmanager 알림 채널을 2단계/3단계 연동 웹훅으로 라우팅

임계치가 넘어가서 경보(Alert)가 발령되면, 이 이벤트를 JIT 융합 파이프라인 수신기(Webhook Receiver)로 쏘아 보내야 합니다. alertmanager.yaml 설정에 다음 수신 경로를 등록합니다.

route:
  group_by: ['alertname', 'cluster', 'workload_type', 'namespace']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'jit-llm-rca-webhook'  # ◀ SRE 전용 수신기 지정

receivers:
- name: 'jit-llm-rca-webhook'
  webhook_configs:
  - url: 'http://sre-jit-agent.monitoring.svc.cluster.local:8080/alert-webhook' # 2단계 캡처러 수신 주소
    send_resolved: false

---

🔄 이후 이어지는 실시간 오케스트레이션 스냅샷

이렇게 1단계를 등록해 두면, 예컨대 StarRocks 노드 균열로 LakehouseDataSkewExplosion 경보가 터지는 순간 Alertmanager가 10초 만에 sre-jit-agent 웹훅을 때립니다.

그러면 대기하던 에이전트가 호출 시점 앞뒤 15분간의 Thanos 메트릭과 Keycloak/Cilium 로그 백로그 20줄을 딱 한 손에 쥐고(2단계), 사내 LLM에게 "얘 지금 분산 버킷 깨졌으니까 조치 플레이북 4번 사출해"라는 정밀 RCA 지스크를 슬랙으로 즉시 사출(3단계)하게 됩니다.

이것이 시스템 리소스를 낭비하지 않으면서 프로덕션 환경을 방어하는 가장 이상적인 실시간 AI-SRE 통합 메커니즘입니다.