RULE ENGINE
관측된 상황을 분석하고
근거 있는 해결방안을 제시한다
고객사 Zabbix 연동 모듈의 메트릭과 로그 수집기의 로그를 공통 형식으로 받아 지속 평가합니다. 이상 징후로 Incident를 만들고, 원인 후보와 해결방안을 규칙으로 점수화합니다. 필요하면 Ansible Playbook을 선택해 고객사 실행 모듈에 조치를 요청합니다.
CUSTOMER HANDOFF → SHARED IMPLEMENTATION BASELINE
상황을 만들고,
규칙으로 해석하고 조치한다
고객이 전달한 문서와 샘플 코드, 구두 협의, 기존 AZeT 연동 코드를 함께 검토해 신규 룰엔진과 시뮬레이터의 공통 기준을 정리했습니다. 요구사항이 완성되지 않은 상태를 전제로, 대표 시나리오부터 고객과 공유하며 점진적으로 확장합니다.
01
EXECUTIVE SUMMARY
두 모듈이 맡는 역할
관측된 상황을 분석하고
SIMULATOR
운영 장애의 시간 흐름을
메트릭과 로그로 재현한다
실제 Zabbix를 호출하지 않고 Zabbix 연동 모듈의 출력 역할을 모사합니다. 동시에 고객사 로그 수집기의 출력도 모사합니다. 룰엔진은 출처가 Simulator라는 이유로 다른 계산을 하지 않으며, 운영 데이터와 완전히 같은 계약으로 처리합니다.
핵심 문장
시뮬레이터가 상황을 만들면, 룰엔진이 이를 분석·예측하고 해결방안과 안전한 조치를 결정합니다.
확정시뮬레이터는 테스트 성공을 위한 별도 우회로가 아니다.
정답 비교 기능은 내부 회귀검증에만 선택적으로 사용하며 제품의 중심 역할은 실제와 유사한 상황 생성입니다.
02
CONFIRMED PRINCIPLES
지금까지 함께 확정한 원칙
신규 개발
기존 AZeT 안의 룰엔진·시뮬레이션 기능은 구현 기반으로 사용하지 않고 새 모듈로 설계합니다.
AI 미사용
LLM, 생성형 AI, 외부 AI API, ML 모델 훈련 없이 명시적인 비즈니스 룰로 계산합니다.
메트릭 중심
고객이 직접 언급한 입력은 Zabbix가 수집한 메트릭이며, 이벤트는 필수 중심 모델로 가정하지 않습니다.
로그도 직접 활용
일반 인프라·애플리케이션 로그를 원인 분석의 증거로 사용합니다. 고객사가 수집기를 만든다고 가정합니다.
출처 중립
동일한 메트릭과 로그라면 운영 수집기와 시뮬레이터의 룰 평가 결과가 같아야 합니다.
시뮬레이터 독립
실제 Zabbix를 경유하지 않고 Zabbix 메트릭 출력과 로그 수집기 출력을 직접 모사합니다.
실행 경계 분리
우리는 Playbook을 선택하고 고객사 Ansible 실행 모듈을 호출합니다. Ansible 구동 자체는 고객사 책임입니다.
점진적 개발
완성되지 않은 도메인 설계를 한 번에 고정하지 않고 시나리오 단위로 구현·시연·피드백합니다.
03
CURRENT AZET FACT CHECK
기존 코드에서 확인한 연동 현황
✓ 이미 있는 것
- Zabbix DB polling과 표준 envelope 처리
- RabbitMQ 메트릭 수신 경로
- ClickHouse 메트릭 시계열 저장
- CPU·Memory·Disk 현황 대시보드 API/UI
- Zabbix 비수치 history/problem의 로그 저장 경로
△ 아직 없는 것
- 파일 tail, journald, syslog 수집기
- 컨테이너·Kubernetes 범용 로그 수집기
- 고객사 로그 수집기와의 확정 계약
- 로그 증거를 실제 RCA에서 평가하는 완성 구현
- 신규 룰엔진·시뮬레이터의 공통 수집 API
! 주의할 점
- 기존 Zabbix numeric 경로는 itemId를 실제 Zabbix DB에서 조회
- 시뮬레이터가 임의 itemId를 만들면 매핑 실패 가능
- 기존 stream consumer는 설정상 기본 비활성일 수 있음
- 기존 로그 테이블은 범용 수집기 존재의 증거가 아님
- 기존 RCA의 PASSIVE_LOG 평가는 보류 상태
설계 결론: 시뮬레이터가 가짜 Zabbix 원시 itemId를 만들거나 ClickHouse에 직접 쓰게 하지 않습니다. 운영 연동과 시뮬레이터가 함께 사용할 표준 Telemetry Ingestion 경계를 만들고 그 뒤에서 저장·룰 평가를 동일하게 수행합니다.
04
TARGET ARCHITECTURE
운영과 시뮬레이션이 만나는 지점
불변 조건
sourceType은 감사·화면 표시·데이터 정리·환경 격리에는 사용하지만 RCA 점수와 조치 선택에는 사용하지 않습니다.05
TELEMETRY CONTRACTS
우리가 선제적으로 정하는 입력 계약
고객사 구현이 나중에 달라지면 Adapter에서 변환합니다. 룰엔진의 내부 계약은 안정적으로 유지하는 것이 목표입니다.
METRIC · azet.metric.v1
표준 메트릭 예시
{
"messageId": "m-20260816-0001",
"customerId": "cust-001",
"environmentId": "dev-sim",
"assetId": "host-web-01",
"serviceId": "checkout-api",
"metricCode": "os.disk.usage",
"value": 91.7,
"unit": "percent",
"observedAt": "2026-08-16T14:31:00+09:00",
"source": { "sourceType": "SIMULATOR", "sourceId": "sim-01" },
"tags": { "mount": "/data", "region": "kr-central" }
}LOG · azet.log.v1
표준 로그 예시
{
"messageId": "l-20260816-0042",
"customerId": "cust-001",
"environmentId": "dev-sim",
"assetId": "host-web-01",
"serviceId": "checkout-api",
"hostName": "web-01",
"logType": "APPLICATION",
"severity": "ERROR",
"observedAt": "2026-08-16T14:31:08+09:00",
"message": "write failed: no space left on device",
"logger": "com.example.FileWriter",
"traceId": "trace-a91",
"source": { "sourceType": "SIMULATOR", "sourceId": "sim-01" },
"tags": { "mount": "/data" }
}식별
customerId + environmentId + assetId를 기본 상관관계 키로 사용하고, 서비스 문제는 serviceId를 추가합니다. hostName·IP·Pod 이름은 참고값입니다.
로그 분류
OS, APPLICATION, CONTAINER, KUBERNETES, DATABASE, MIDDLEWARE, NETWORK, SECURITY, CICD, SYSTEM, OTHER
심각도
TRACE, DEBUG, INFO, WARN, ERROR, FATAL, UNKNOWN으로 정규화합니다.
전송 제한
로그 batch 최대 500건·5MB, message 최대 64KB, tags 최대 32개를 초기 기본값으로 둡니다.
신뢰성
messageId로 멱등 처리하고, 시간대가 포함된 ISO 8601을 사용합니다. 지연 데이터는 버리지 않고 late arrival로 표시합니다.
보호
토큰·암호·쿠키·인증 헤더 등 비밀정보를 수집기 또는 Ingestion 경계에서 마스킹합니다. 미매핑 자산은 격리 큐로 보냅니다.
전송 방식: 계약은 HTTP/RabbitMQ와 독립적으로 정의합니다. 초기 운영은 기존 AZeT 흐름과 맞춰 RabbitMQ를 우선 검토하며, 로그에는 별도 topic·queue·DLQ를 두는 방안을 권장합니다.
06
INCIDENT LIFECYCLE
언제 분석을 시작하고 언제 끝내는가
임계치
CPU·Memory·Disk·Network 등 메트릭이 룰 임계치를 초과
추세
아직 임계치 전이라도 증가율과 지속시간상 장애가 예상됨
로그 패턴
오류 패턴이 발견되거나 지정 시간창 안에 반복 횟수 초과
선택 입력
Zabbix Problem·Alarm이 제공되면 추가 시작 조건과 증거로 사용
OPEN이상 감지
→ANALYZING증거 수집·RCA
→ACTION_PROPOSED해결방안 제시
→ACTION_REQUESTED실행 모듈 호출
→MONITORING사후 관찰
→RESOLVED · CLOSED복구 확인·종료
ACTION_REJECTED 승인 거절ACTION_FAILED 실행 실패REOPENED 관찰 중 재발
예측의 정의
AI 예측이 아니라 임계치·증가율·지속시간·반복 패턴·상태 전이 룰로 가까운 시점의 장애 가능성을 계산합니다.
디스크 82% + 시간당 6% 증가 → 약 2시간 안에 95% 도달 가능메모리 사용량 지속 증가 + 회수 없음 → 고갈 위험10분간 오류 로그 빈도 4배 증가 → 서비스 장애 전조07
RULE ENGINE
판단 결과는 설명 가능해야 한다
ROOT CAUSE SCORE
어떤 원인이 가장 그럴듯한가?
20% 사전 가능성 + 35% 증거 일치 + 15% 시간 상관
10% 의존관계 + 10% 변경 상관 + 10% 과거 유사도 − 반증
10% 의존관계 + 10% 변경 상관 + 10% 과거 유사도 − 반증
ACTION SCORE
어떤 조치가 가장 적합한가?
25% 원인 제거 적합도 + 20% 과거 성공률 + 20% 안전성
15% 복구 속도 + 10% 검증 신뢰도 − 10% 업무 영향
15% 복구 속도 + 10% 검증 신뢰도 − 10% 업무 영향
EXAMPLE
DISK_CAPACITY_RISK
같은 디스크 문제라도 관측 증거에 따라 원인과 조치가 달라집니다.
애플리케이션 로그 폭증파일 증가 + write 실패 패턴0.86
임시파일 누적/tmp 증가 + 오래된 파일 수0.73
백업파일 누적backup 경로 + 배치 시간 상관0.42
설명 가능한 결과2시간 내 디스크 포화 가능성이 높고, 애플리케이션 로그 폭증이 가장 유력근거 4건 → log diagnostics 제안 → 정책 허용 시 cleanup Playbook 요청 → 사용률 75% 이하와 write 오류 중단을 사후 검증
감지 상황예상 영향원인 Top N점수·판단 근거추가 확인 항목권장 해결방안선택 Playbook자동 실행 여부사후 검증 조건
R1조회·진단자동 실행 가능
R2저위험·복구 가능정책에 따라 자동
R3서비스 영향 가능사람 승인 필수
R4삭제·재부팅·대규모 변경자동 실행 금지
08
SIMULATOR
한 점의 값이 아니라 상황의 흐름을 만든다
Metric timeline
정상 기준선 → 점진적 악화 → 위험 구간 → 장애 → 조치 후 회복을 시계열로 생성합니다.
Correlated logs
메트릭 변화와 맞물리는 OS·애플리케이션·K8s·CI/CD 로그를 정확한 시각과 자산 ID로 생성합니다.
Optional alarm
필요한 시나리오에서는 Zabbix Problem/Alarm 형식의 선택 신호도 모사할 수 있습니다. 필수 입구는 아닙니다.
Context & recovery
고객·환경·자산·서비스, 변경 이력, 의존관계, 수집 누락과 조치 후 정상화까지 표현합니다.
T+00정상disk 62%
T+20악화 시작시간당 +6%
T+45오류 동반write warning
T+60Incidentdisk 91%
T+70조치 결과 모사disk 72%
T+85안정오류 중단
OPTIONAL INTERNAL REGRESSION
정답지는 제품 입력이 아니다
시나리오 작성자는 기대 원인·허용 조치·금지 조치·복구 기준을 내부 검증 정보로 둘 수 있습니다. 이 값은 룰엔진에 전달하지 않으며 고객 시연에서는 상황 생성과 분석 흐름이 중심입니다.
- Root Cause Top1 / Top3
- Forbidden action 차단
- R3 승인 라우팅
- R4 자동실행 0건
- 사후 복구 판정
- 회귀 차이 보고
고객 자료와의 차이: v2.3 문서는 Oracle과 자동 검증을 강조하지만, 현재 합의에서는 시뮬레이터의 주 역할을 운영 상황 생성으로 재정의합니다. 기존 샘플의 단순한 임계치 120% 값과 한 줄 로그보다 현실적인 시간 흐름을 구현해야 합니다.
09
FIRST THREE SCENARIOS
고객과 먼저 공유할 대표 시나리오
디스크 포화
사용량 점진 증가 → 쓰기 실패 로그 → 헬스 체크 실패 → 원인 판정 → 정리 조치 → 복구 확인
- 주요 메트릭
- os.disk.usage, disk free bytes, file growth
- 주요 로그
- no space left, log rotation failure, health check failure
- 후보 Playbook
- disk-diagnostics, safe-log-cleanup
- 복구 기준
- 사용률 75% 이하, 쓰기 오류 중단
메모리 고갈
메모리 지속 증가 → GC/회수 실패 → OOM 또는 헬스 체크 실패 → 진단·승인 조치
- 주요 메트릭
- os.memory.usage, swap, JVM heap
- 주요 로그
- OutOfMemoryError, OOMKilled, health timeout
- 후보 Playbook
- memory-diagnostics, service-restart
- 복구 기준
- 사용률 안정, health 정상, OOM 재발 없음
CPU 급증
CPU 상승 → 응답 지연 → 오류율 증가 → 문제 프로세스 식별 → 진단 또는 제한 조치
- 주요 메트릭
- os.cpu.usage, load average, response time
- 주요 로그
- request timeout, thread pool exhausted
- 후보 Playbook
- cpu-process-diagnostics, process-control
- 복구 기준
- CPU·응답시간 정상화, 오류율 감소
첫 세로 슬라이스 권장: S-01 디스크 포화를 먼저 끝까지 구현합니다. Metric/Log 계약, Incident, RCA, Playbook 요청, 사후검증, Simulator 시간축을 한 번에 검증할 수 있습니다.
10
ANSIBLE PLAYBOOK BOUNDARY
선택과 실행의 책임을 나눈다
OUR MODULERule Engine원인·안전등급에 맞는 Playbook 선택
→OUR MODULEExecution Request대상·파라미터·승인·중복키 구성
→CUSTOMER MODULEAnsible RunnerPlaybook 실제 구동과 상태 반환
→OUR MODULEPost-check메트릭·로그로 실제 복구 판단
REQUEST EXAMPLE
{
"requestId": "act-00019",
"incidentId": "inc-00481",
"playbookId": "safe-log-cleanup",
"target": { "assetId": "host-web-01" },
"parameters": { "path": "/var/log/app", "olderThanDays": 7 },
"reason": "disk capacity risk; log growth is top cause",
"riskClass": "R2",
"approval": { "required": false },
"idempotencyKey": "inc-00481:safe-log-cleanup:v1"
}RESPONSE STATES
고객 모듈이 돌려줄 최소 상태
ACCEPTEDRUNNINGSUCCEEDEDFAILEDREJECTEDTIMED_OUT
실행 성공은 Incident 해결과 같지 않습니다. 룰엔진은 Playbook 완료 후 별도의 관찰 시간 동안 메트릭과 로그가 복구 기준을 만족하는지 확인합니다.
11
SCOPE & DECISION LOG
확정·가정·추후 협의 항목
✓ 확정
- 신규 룰엔진과 시뮬레이터 개발
- 메트릭·로그 기반 지속 평가
- Simulator는 Zabbix와 로그 수집기 역할 모사
- Simulator origin에 따른 룰 분기 없음
- 규칙 기반 예측·RCA·Action 선정
- Playbook 선택과 고객 실행 모듈 호출까지 담당
- R3 승인 필수, R4 자동실행 금지
- LLM·AI API 미사용
△ 현재 작업 가정
- 고객사가 범용 로그 수집기를 구현
- 우리가 v1 로그·메트릭 계약을 먼저 제시
- 변경 시 Adapter로 고객 계약 수용
- RabbitMQ를 우선 전송 후보로 검토
- 기존 AZeT ClickHouse 저장 구조 활용 가능
- Zabbix Problem/Alarm은 선택 입력
? 구현 중 고객과 확정
- 고객사 Ansible API의 실제 payload·인증
- 고객별 metric threshold와 시간창
- 운영 자동 실행 허용 범위
- 자산·서비스·토폴로지 원천 시스템
- 메시지 보존기간과 재처리 정책
- 처리량·지연·정확도 합격선
범위 밖고객사 Zabbix 연동 모듈 개발고객사 로그 수집기 개발Ansible 직접 구동 엔진LLM·생성형 AI실제 운영망 장애 주입기존 룰엔진 코드 재사용
고객 자료를 해석하는 기준
| 자료 표현 | 이번 구현 기준 |
|---|---|
| “AI prediction” | 임계치·추세·상태 전이·반복 패턴을 사용한 결정론적 예측 |
| “Feedback Learning” | 성공률 통계와 제한된 bias 또는 룰 변경 제안. 자동 ML 학습 아님 |
| “Self-Evolving” | 변경 제안 → 사람 승인 → 회귀검증 → Release Gate의 통제형 운영 |
| “Digital Twin / fault injection” | 실제 장비 장애 주입이 아니라 메트릭·로그·맥락의 합성 |
| 221 events / 884 causes | 완성 범위가 아닌 Seed 카탈로그. 대표 시나리오부터 검증 후 확장 |
| Phase 3 validation | 합성 데이터 검증 결과이며 실제 운영 정확도의 증명으로 사용하지 않음 |
12
INCREMENTAL DELIVERY
시나리오 중심의 점진적 개발안
계약과 골격
Metric/Log v1, Asset 식별, Incident 상태, 룰 정의 포맷, Simulator 시나리오 포맷을 고정합니다.
산출물Schema · API · 저장 경계S-01 세로 슬라이스
디스크 포화 상황을 생성하고 감지·예측·RCA·Playbook 요청·복구 확인까지 연결합니다.
산출물고객 시연 가능한 첫 흐름안전과 운영 연동
승인, R1~R4, 멱등성, 실패·timeout, 고객 Ansible 모듈과의 Adapter를 보강합니다.
산출물안전한 조치 WorkflowS-02·S-03 확장
메모리 고갈과 CPU 급증으로 로그 상관관계·서비스 영향·다른 조치 유형을 검증합니다.
산출물재사용 가능한 룰·시나리오 패턴고객 피드백 반복
시연 결과에 따라 임계치·증거·조치·계약을 버전 관리하고 회귀검증합니다.
산출물승인된 고객별 Rule Pack구현 Iteration과 고객 확인 Gate
| Iteration | 핵심 결과 | 고객 확인 Gate |
|---|---|---|
| 0 · 기준선 | 독립 모듈 경계 ADR, Metric/Log/Incident/Playbook/Scenario 계약, 두 서비스 골격, 연동 Stub | G0 · 구조와 실제 payload·식별자 확인 |
| 1 · S-01 데이터 | 디스크 정상→악화→복구 시계열과 상관 로그, 공통 Ingestion | G1 · 데이터 현실성 확인 |
| 2 · Detect/RCA | Incident 자동 생성, Evidence, 원인 3종과 설명 가능한 점수 | G2 · 원인·임계치·시간창 확인 |
| 3 · Action | R1~R4, Playbook 요청, 결과 수신, 사후검증 | G3 · Ansible API와 실행정책 확인 |
| 4 · 확장 | 메모리 고갈·CPU 급증, 승인·차단, 시나리오 제어 | G4 · 추가 시나리오 우선순위 |
| 5 · 안정화 | DLQ·재처리·격리·보안·관측성·Rule/Scenario 버전 관리 | G5 · 운영 합격선과 E2E 승인 |
첫 구현 PR
독립 모듈 Architecture ADR + Metric·Log·Scenario Schema + 두 서비스 health 골격 + S-01 fixture만 포함합니다. 기존 내부 eventaction 경계와의 관계, 계약, 재현 가능한 입력을 먼저 고정한 뒤 판단 로직을 연결합니다.
CUSTOMER DOCUMENT SEED
221대표 이벤트
884원인 후보
3,536증거 규칙
119조치 명세
주요 검토 자료 — Master Implementation Guide, Customer-Adaptive RCA v2.2, RealOps Ansible Action Guide v2.1, Simulation Lab v2.3, Phase 2 Architecture, Phase 3 Self-Evolving Operation Guide, APM/DPM 확장 자료 및 기존 AZeT monitoring-connector·dashboard·ClickHouse 코드.
13
CONTINUOUS CODEX EXECUTION
새 세션에서도 빠뜨리지 않고 이어가는 구조
개발 계획을 37개의 순차 태스크로 분해했습니다. 각 태스크는 앞선 대화를 요구하지 않고, 자신의 명세만으로 구현·검증·기록할 수 있습니다.
37전체 Task·Gate
31구현 Task
6고객 승인 Gate
0현재 DONE
T000다음 태스크
1 실행 프로토콜
- 항상 같은 순서로 계획·결정·상태를 읽음
- 의존성이 끝난 가장 앞의 READY 선택
- 한 번에 IN_PROGRESS는 하나만 허용
- 허용 경로 밖 변경은 Blocker로 기록
2 독립 태스크 명세
- 고유 ID와 선행 태스크
- 필수 입력 문서와 Allowed scope
- 정확한 산출물과 범위 밖 항목
- 실행할 테스트 명령과 완료 조건
3 진행상황 정본
- PROJECT_STATUS가 현재 상태의 단일 정본
- SESSION_LOG에 변경·명령·결과·다음 작업 기록
- Decision Log에 장기 결정 누적
- Evidence 없이는 DONE 처리 금지
TODO의존성 대기
→READY착수 가능
→IN_PROGRESS한 번에 1개
→REVIEW검증·승인
→DONEEvidence 완료
태스크 연속 구간
| 구간 | Task ID | 완성되는 결과 |
|---|---|---|
| Iteration 0 | T000~T050 → G000 | ADR, 8개 계약, 서비스 골격과 연동 Stub |
| Iteration 1 | T100~T140 → G100 | S-01 Metric·Log 시간축과 공통 수집·저장 |
| Iteration 2 | T200~T240 → G200 | Detector, Incident, Evidence, 설명 가능한 RCA |
| Iteration 3 | T300~T340 → G300 | Action, Safety, Playbook 요청, Post-check |
| Iteration 4 | T400~T430 → G400 | S-02·S-03, 승인·차단, Simulator 제어 |
| Iteration 5 | T500~T550 → G500 | 신뢰성·보안·운영·회귀·성능·고객 E2E |
세션 종료 조건
구현 코드만 남기지 않습니다. 상태·세션 로그·검증 Evidence·다음 READY 태스크를 같은 변경에 기록해야 한 태스크가 완료됩니다.
LIVE DEVELOPMENT CHECKLIST
태스크별 개발 계획과 점검 현황
아래 내용은 실행 계획과 진행상황 정본에서 자동 생성됩니다. 태스크를 펼치면 독립 개발에 필요한 범위, 산출물, 검증 명령과 완료 조건을 확인할 수 있습니다.
0 / 37 DONE0%
상태 기준일 2026-08-16
READY·진행·검토·완료·차단 여부와 선행 태스크를 확인합니다.
산출물과 Acceptance command 결과가 완료 조건을 충족하는지 봅니다.
DONE은 완료 시각과 Evidence가 있어야 하며 Gate는 고객 확인 후 닫습니다.
개발 계획 데이터를 불러오는 중입니다.