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에서 검증하는 문제로 바꾼다.

My Take: StateGraph Is the Durable Part

내가 이 연구에서 가장 중요하게 생각하는 부분은 LLM workflow보다 장애 시점의 resource 상태와 관계를 다시 조회할 수 있는 temporal evidence layer다.

LLM은 Triage, query 생성과 report 작성 module에서 교체할 수 있다. 반면 entity identity가 잘못 연결됐거나 incident 당시 state를 보존하지 못했다면 어떤 모델을 사용해도 올바른 root cause를 증명하기 어렵다.

Better reasoning
  cannot recover
Missing or incorrectly linked state

따라서 SynergyRCA의 실질적인 기반은 다음 세 가지라고 해석한다.

• 같은 entity를 여러 source에서 하나로 연결하는 canonical identity
• snapshot과 relationship이 유효했던 시간을 나타내는 valid-time
• 결론이 어느 source field에서 나왔는지 추적할 수 있는 provenance

연속 중복 snapshot 제거도 단순한 저장 공간 최적화로만 볼 수 없다. 변하지 않은 상태를 하나의 유효 기간으로 표현하면 “장애가 발생했을 때 어떤 값이 적용되고 있었는가”를 조회할 수 있는 시간 모델이 된다.

이 관점에서는 LLM보다 graph 구축과 freshness가 먼저다. Graph가 부정확하면 grounded report처럼 보이는 잘못된 결론이 만들어질 수 있기 때문이다.

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 가능성을 별도로 검증해야 한다.

How I Would Design It

실제 Kubernetes platform에 적용한다면 collection, evidence, reasoning과 decision을 분리한다.

Collection plane
  → Snapshot, Watch, Event, Audit and external collectors

Evidence plane
  → Canonical identity, valid-time, provenance and graph

Reasoning plane
  → Read-only path query, state check and hypothesis ranking

Decision plane
  → Engineer review, remediation approval and rollback

주기적 snapshot은 전체 상태를 복원하는 baseline으로 유지하되, 짧게 발생하고 사라지는 변화는 Watch, Event와 Audit data로 보완한다. 이 신호들이 항상 완전한 상태를 제공하는 것은 아니므로, event stream만으로 graph를 구성하기보다 snapshot 사이의 변화 후보를 찾는 evidence로 사용한다.

각 graph vertex와 edge에는 가능한 경우 다음 정보를 함께 저장한다.

• 수집 source와 원본 object reference
• observation time과 valid-time
• canonical identity를 만든 field
• 수집 실패 또는 freshness 상태

LLM은 전체 Neo4j에 자유로운 query를 실행하지 않고 MetaGraph에서 허용된 path와 read-only query template 안에서 동작하게 한다. 결론에는 resource name, namespace, incident timestamp와 사용한 STATE vertex를 연결하고, evidence가 없는 부분은 추론과 사실을 구분해 표시한다.

Remediation command는 report와 별도 artifact로 다룬다. 생성된 command가 있어도 RBAC 권한, 대상 resource version, 예상 blast radius와 rollback 방법을 확인하기 전에는 실행하지 않는다.

What I Would Validate

검증의 초점은 LLM이 자연스러운 report를 만드는지가 아니라 graph가 장애 당시 사실을 보존하고 올바른 evidence path를 반환하는지에 둔다.

비교 실험에서는 다음 값을 함께 측정한다.

• Incident 시점의 state reconstruction 정확도
• 올바른 root cause entity가 top-k path에 포함되는 비율
• 잘못 연결된 entity와 stale evidence 비율
• Graph 구축·갱신 비용과 query latency
• Engineer가 report를 검증하는 데 걸린 시간
• Remediation 제안 중 실제로 안전하다고 승인된 비율

특히 연속 중복 제거가 state transition을 없애지 않는지 별도로 확인해야 한다. 저장량 감소율보다 incident 전후의 변경 순서와 valid-time이 유지되는지가 더 중요한 acceptance criterion이다.

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는 핵심 한계다.
• SynergyRCA의 지속적인 가치는 LLM module보다 identity, valid-time과 provenance를 갖춘 evidence graph에 있다.
• 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