SynergyRCA: Kubernetes RCA with StateGraph and LLM

Summary

Simplifying Root Cause Analysis in Kubernetes with StateGraph and LLM에서 제안하는 system의 정확한 이름은 SynergyRCA다.

SynergyRCA는 LLM이 production Kubernetes cluster를 직접 탐색하게 하지 않는다. Kubernetes resource와 외부 system의 상태를 주기적으로 수집해 StateGraph로 만들고, resource 종류 사이의 관계를 MetaGraph로 요약한다. Incident가 발생하면 LLM은 이 graph에서 필요한 상태만 조회해 root cause report와 remediation command를 생성한다.

Kubernetes and external systems
            │
     Periodic snapshots
            │
       StateGraph
            │
       MetaGraph
            │
Incident → LLM-assisted graph query
            │
     Root cause report

핵심 아이디어는 다음과 같다.

Kubernetes RCA를 log message에 대한 자유로운 추측이 아니라, 관련 resource의 존재·상태·불일치를 graph에서 검증하는 문제로 바꾼다.

Why Kubernetes RCA Is Difficult

Kubernetes는 controller가 current state를 desired state에 맞추는 reconciliation 방식으로 동작한다. 장애는 종종 서로 다른 resource의 상태가 맞지 않을 때 발생한다.

Deployment desired replicas
        ↕
ReplicaSet current replicas
        ↕
Pod scheduling state
        ↕
PVC / Node / Image / Network state

하나의 error message만으로는 어느 resource를 조사해야 할지 명확하지 않을 수 있다.

cannot find volume "app-conf"

여기서 volume은 ConfigMap, Secret, PVC일 수 있다. PVC라면 다시 PV, StorageClass, CSI driver 또는 외부 NFS directory까지 확인해야 한다.

LLM에 error message만 입력하면 그럴듯한 일반론을 생성할 수 있지만, 실제 cluster의 resource name, namespace, timestamp와 상태를 모르면 root cause를 증명할 수 없다.

SynergyRCA는 이 문제를 graph-based retrieval로 해결한다.

StateGraph

StateGraph는 Kubernetes와 관련 external system에 존재하는 entity와 시간별 snapshot을 함께 저장한다.

Entity

Entity는 system 안에서 식별 가능한 object다.

Kubernetes native entity는 일반적으로 uid, name, namespace, kind처럼 여러 field로 식별된다. NFS directory는 server와 path의 조합으로 식별할 수 있다.

Snapshot and State

Snapshot은 특정 timestamp에 수집한 entity 상태다. Event resource가 아닌 snapshot은 논문에서 대문자 STATE vertex로 구분한다.

Pod entity
   ├── POD state at 10:00
   ├── POD state at 10:05
   └── POD state at 10:10

StateGraph는 다음 관계를 표현한다.

예를 들어 Pod snapshot에서 다음 관계를 추출할 수 있다.

Pod
  ├── ownerReference → StatefulSet
  ├── volume claim   → PVC
  ├── scheduled on   → Node
  ├── runs           → Container
  ├── pulls          → Image
  └── has address    → IP

각 edge에는 해당 관계가 유효했던 시간 범위와 원본 field 정보가 포함될 수 있다. 이를 이용하면 incident 발생 시점에 실제로 존재했던 관계를 조회할 수 있다.

Building the StateGraph

논문은 StateGraph를 다음 순서로 구성한다.

Collect snapshots
      │
Remove consecutive duplicates
      │
Extract entities
      │
Canonicalize identities
      │
Create vertices and edges
      │
Load into Neo4j

Collecting Snapshots

수집 대상은 Kubernetes API나 etcd에 한정되지 않는다.

• etcd의 Kubernetes resource
• Node의 container runtime
• NFS server와 mount directory
• Calico와 iptables 같은 network configuration
• Node와 registry의 image 정보

이 구성이 중요한 이유는 Kubernetes error의 실제 원인이 cluster 외부에 있을 수 있기 때문이다. FailedMount가 발생했을 때 PVC와 PV가 정상이어도 NFS server의 directory가 사라졌을 수 있다.

Removing Consecutive Duplicates

주기적으로 snapshot을 수집하면 상태가 변하지 않은 resource도 같은 data를 계속 생성한다. 이를 모두 별도의 STATE vertex로 저장하면 graph 크기가 불필요하게 증가한다.

SynergyRCA는 전체 기간에 존재하는 동일한 값을 무조건 하나로 합치는 것이 아니라, 시간상 연속되며 내용도 동일한 snapshot을 중복으로 판단한다. 연속 중복은 마지막 snapshot을 남기는 방식으로 정리하고, 각 snapshot이 유효했던 시간 범위를 함께 관리한다.

10:00 replicas = 3
10:05 replicas = 3
10:10 replicas = 3
10:15 replicas = 5

        ↓ consecutive deduplication

replicas = 3  → unchanged state with a valid time range
replicas = 5  → new state after the change

이렇게 하면 동일한 상태를 반복 저장하지 않으면서도 Deployment replica 변경처럼 실제로 발생한 state transition은 유지할 수 있다. 따라서 incident timestamp를 기준으로 당시 유효했던 state와 relationship을 조회할 수 있다.

Canonicalizing Entities

같은 resource가 name, UID 또는 다른 object 안의 reference 형태로 나타날 수 있다. SynergyRCA는 이 표현을 canonical form으로 정규화해 서로 같은 entity로 연결한다.

PVC name reference
        │
        └── (uid, name, namespace, kind)

이 과정이 빠지면 graph에 같은 resource를 나타내는 vertex가 여러 개 생겨 잘못된 path가 만들어질 수 있다.

MetaGraph

StateGraph가 실제 resource instance를 저장한다면 MetaGraph는 resource kind 사이의 구조를 저장한다.

StateGraph
  Pod-123 → PVC-456 → PV-789

MetaGraph
  Pod → PVC → PV

Object-oriented programming에 비유하면 StateGraph의 vertex는 object, MetaGraph의 vertex는 class에 가깝다.

Xiang et al., Simplifying Root Cause Analysis in Kubernetes with StateGraph and LLM, Figures 12-13.

MetaGraph는 문서에서 미리 만든 고정 schema가 아니다. 실제 StateGraph의 (source, edge, destination) 관계에서 kind와 edge type을 추출해 생성한다. 따라서 Custom Resource처럼 해당 cluster에만 존재하는 관계도 반영할 수 있다.

MetaGraph의 path를 metapath, StateGraph에 존재하는 실제 entity path를 statepath라고 부른다.

Metapath
  Job → Namespace → ResourceQuota

Statepath
  batch-job-1 → team-a → team-a-quota

RCA Workflow

SynergyRCA의 전체 흐름은 다음과 같다.

Xiang et al., Simplifying Root Cause Analysis in Kubernetes with StateGraph and LLM, Figure 1.

Incident
   │
Match source entity and timestamp
   │
Triage
   │
Find metapath in MetaGraph
   │
PathQueryGen
   │
Query statepath and STATE vertices
   │
StateChecker
   │
ReportGen
   │
ReportQualityChecker
   ├── Complete
   └── Retry with another destination kind

Matching Incident

Incident message, namespace, timestamp를 StateGraph와 대조해 error가 시작된 resource kind인 srcKind를 찾는다.

예를 들어 Job 생성 중 quota error가 발생했다면 시작점은 Job이 될 수 있다.

Triage

Triage module은 error message와 srcKind를 바탕으로 다음 항목을 예측한다.

srcKind
  = Incident가 시작된 resource kind

destKind
  = Root cause가 있을 가능성이 높은 resource kind

interKinds
  = 두 resource 사이에서 확인할 resource kinds

예를 들어 다음과 같이 판단할 수 있다.

srcKind:   Job
destKind:  ResourceQuota
interKind: Namespace

존재하지 않는 kind를 LLM이 만들어내지 않도록 실제 entity taxonomy를 prompt에 제공한다. 또한 cluster naming convention과 자주 발생하는 외부 원인 같은 expert guidance도 추가한다.

PathQueryGen

Driver는 MetaGraph에서 srcKind와 destKind를 연결하는 metapath를 찾는다. PathQueryGen은 이 metapath를 Neo4j에서 실행할 Cypher query로 변환한다.

Job → Namespace → ResourceQuota
          │
          └── Cypher query
                  │
                  └── job-1 → team-a → quota-a

LLM은 전체 graph를 자유롭게 탐색하는 것이 아니라 허용된 metapath를 실제 instance에 연결하는 query를 생성한다.

StateChecker

각 statepath에 포함된 entity의 incident 시점 STATE vertex를 가져온다. StateChecker는 이 JSON 상태에서 error와 관련된 field를 찾아 diagnostic summary를 생성한다.

예를 들어 ResourceQuota라면 requested, used, hard limit을 비교할 수 있다.

requested CPU
      +
current used CPU
      >
quota hard limit

ReportGen and Quality Check

ReportGen은 여러 diagnostic summary를 합쳐 다음 결과를 만든다.

• Root cause conclusion
• Evidence summary
• Resource name과 namespace
• Remediation command

ReportQualityChecker는 conclusion이 error message를 충분히 설명하는지 평가한다. 설명이 부족하면 이전에 시도하지 않은 destKind를 선택하도록 Triage로 되돌린다. 한 incident에서 최대 세 번까지 report 생성을 시도한다.

Reconciliation as an RCA Rule

SynergyRCA는 Kubernetes의 state reconciliation을 세 가지 검사로 단순화한다.

Existence

필요한 state나 external entity가 실제로 존재하는가?

Pod references PVC
  → Does the PVC exist?

Correctness

해당 state의 값이 허용 범위 안에 있는가?

ResourceQuota
  → Is the requested resource within the hard limit?

Consistency

연결된 entity의 상태가 서로 일치하는가?

Pod expects a bound PVC
  ↔ PVC status is Bound

이 세 가지 규칙은 LLM이 Kubernetes 전체를 알고 있어야 한다는 요구를 줄이고, retrieved state가 error를 실제로 설명하는지 확인하는 기준을 제공한다.

Evaluation

참고한 논문의 연구진은 GPT-4o, Azure OpenAI Assistants API와 Neo4j를 사용해 SynergyRCA를 구현했다. Graph 구축에는 PySpark와 GraphFrames를 사용했다.

평가는 서로 다른 두 production Kubernetes cluster에서 수행됐다.

연속 중복 snapshot을 제거한 뒤의 data 크기이며, incident owner와 senior Kubernetes administrator가 ground truth와 결과 평가에 참여했다.

논문에서 precision은 “최대 세 번의 trial 안에 ground truth를 합리적으로 설명하는 report를 생성한 example의 비율”로 정의된다.

평균 분석 시간은 attempt당 dataset 1에서 약 131초, dataset 2에서 약 119초였다. 논문이 말하는 “약 2분”은 이 attempt 평균에 해당한다.

이 결과를 해석할 때는 다음 조건을 함께 봐야 한다.

• 두 dataset은 동일한 error type 구성을 사용하지 않는다.
• 하나의 example에서 최대 세 번 report 생성을 시도할 수 있다.
• Precision은 다른 RCA 논문의 single-label accuracy와 정의가 다르다.
• LLM module별 평가는 전문가의 report 판단을 포함한다.

Limitations

Snapshot Consistency

가장 큰 한계는 빠르게 변하는 resource를 일정 주기로 수집한다는 점이다. 논문 구현은 예시로 5분 간격 snapshot을 설명한다.

10:00 PVC Pending
10:02 Incident occurs
10:05 PVC Bound

10:05 snapshot만 조회하면 incident 당시 UnboundPVC 상태를 놓칠 수 있다. 실제로 FailedScheduling-UnboundPVC와 일부 quota 관련 case에서 낮은 precision이 나타났다.

Complex Aggregation

모든 root cause를 하나의 statepath 검사로 해결할 수 있는 것은 아니다. NodeNotAvailable처럼 모든 Node의 taint, capacity, affinity 조건을 집계해야 하는 문제는 더 복잡한 query와 tool이 필요하다.

Data Collection Cost

StateGraph는 etcd뿐 아니라 runtime, storage, network와 image repository의 snapshot을 수집해야 한다. 운영 cluster에서 polling interval을 줄이면 최신성은 좋아지지만 수집 부하와 graph 크기가 증가한다.

Remediation Safety

논문은 remediation command도 생성하지만, report가 정확하다는 것과 command가 production에서 안전하다는 것은 다른 문제다. 실제 적용에서는 command 실행 전에 namespace, resource version, blast radius와 rollback 가능성을 별도로 검증해야 한다.

LATS-RCA and SynergyRCA

두 방법은 모두 LLM을 RCA에 사용하지만 해결하려는 문제와 evidence 구조가 다르다.

Different Search Spaces

LATS-RCA의 search space는 diagnostic hypothesis다.

Database issue?
Upstream timeout?
Resource exhaustion?
Deployment regression?

SynergyRCA의 search space는 resource relationship과 statepath다.

Pod → PVC → PV → NFS
Job → Namespace → ResourceQuota
Pod → Node → Image

Different Ways to Control Hallucination

LATS-RCA는 reflection score와 cross-modal correlation으로 근거가 약한 reasoning path의 우선순위를 낮춘다.

SynergyRCA는 실제 entity taxonomy, MetaGraph path와 STATE vertex로 LLM이 사용할 수 있는 resource와 evidence 범위를 제한한다.

LATS-RCA
  → Competing hypotheses are scored

SynergyRCA
  → Allowed entities and paths are grounded in the graph

Results Are Not Directly Comparable

LATS-RCA의 LO2 91.3% accuracy와 SynergyRCA의 0.88·0.92 precision을 숫자만으로 비교하면 안 된다.

• Dataset과 target system이 다르다.
• LATS-RCA는 single-label exact match accuracy를 사용한다.
• SynergyRCA는 최대 세 번의 시도 안에 report가 ground truth를 설명했는지 평가한다.
• LATS-RCA production 결과는 실제 incident 37건, SynergyRCA는 반복되는 Kubernetes error example을 포함한다.

따라서 “어느 쪽이 더 정확한가”보다 다음 기준으로 선택해야 한다.

Logs and metrics contain the decisive evidence
  → LATS-style hypothesis exploration

Kubernetes resource state mismatch is central
  → SynergyRCA-style graph retrieval

Combining Both Ideas

두 구조는 상호 배타적이지 않다. 실제 Kubernetes platform에서는 StateGraph가 후보 resource와 state evidence를 제공하고, tree-search agent가 여러 원인을 비교하도록 결합할 수 있다.

Incident
   │
StateGraph retrieves related resources
   │
Candidate root cause paths
   │
Tree search compares logs, metrics, and states
   │
Human-reviewed diagnosis

이 경우 StateGraph는 탐색 범위를 줄이고, tree search는 하나의 metapath가 충분하지 않을 때 대안 가설을 유지하는 역할을 한다. 다만 graph freshness, token cost와 tool execution safety를 동시에 관리해야 한다.

Key Takeaways

• StateGraph는 실제 entity와 시간별 state를, MetaGraph는 resource kind 사이의 관계를 표현한다.
• Triage는 srcKind, destKind, interKinds를 고르고 PathQueryGen이 이를 Cypher query로 변환한다.
• StateChecker는 존재, correctness, consistency 관점에서 retrieved state를 검사한다.
• 두 production dataset에서 논문이 정의한 precision은 0.88과 0.92였고 attempt당 평균 시간은 약 2분이었다.
• 빠르게 변하는 resource의 snapshot inconsistency는 핵심 한계다.
• LATS-RCA는 hypothesis tree를, SynergyRCA는 resource state graph를 중심으로 한다.
• 두 논문의 수치는 metric과 dataset이 달라 직접적인 성능 비교에 사용할 수 없다.

Review Questions

1. StateGraph와 MetaGraph는 각각 어떤 정보를 저장하는가?
2. Metapath와 statepath의 차이는 무엇인가?
3. Triage module이 destKind와 interKinds를 구분하는 이유는 무엇인가?
4. Snapshot interval이 짧아지면 정확성과 운영 비용은 어떻게 달라지는가?
5. LATS-RCA와 SynergyRCA의 search space는 어떻게 다른가?

References

• Simplifying Root Cause Analysis in Kubernetes with StateGraph and LLM
• LATS-RCA: Language Agent Tree Search for Root Cause Analysis in Microservices
• Exploring LLM-based Agents for Root Cause Analysis
• Neo4j Cypher Manual