[End-Gamers] 실전 AI 학습용 로그를 만들어보자 - Loki·Prometheus·Grafana 스택 구축기

"테스트 로그는 어디서 구하지..?"

 

 

AI 장애 분석 도구를 만들다가 제일 먼저 막힌 게 이거였다.

실제 운영 로그는 당연히 못 쓰고, 손으로 만들자니 패턴이 너무 단조로워서 AI가 제대로 학습이 안 된다.

 

loghub같은 유익한 사이트도 있지만, 내가 원했던 제니퍼 로그나 KB 스타일의 로그가 아니었기 때문에
학습용 로그를 계속해서 생성할 로그 생성기가 필요했다.

https://github.com/logpai/loghub

GitHub - logpai/loghub: A large collection of system log datasets for AI-driven log analytics [ISSRE'23]

 

결과적으로 1초에 N건씩 4종류의 금융 로그를 실시간으로 쏘고,

Loki·Prometheus·Grafana로 모니터링하는 스택까지 구축했다.

 

---

1. 두 저장소가 이루는 파이프라인

프로젝트는 두 레포지토리가 연결된 구조다.

log-autogenerator                  incident-autopsy
────────────────────────           ─────────────────────────────
시나리오별 로그 생성 (4종)            →→→   output/ 폴더 직접 읽기
                                    →→→   incident API (REST)
                                    →→→   Loki (GUID 기반 조회)
                                                ↓
                                       AI 분석 → 보고서 생성

log-autogenerator가 실제 금융 시스템처럼 동작하는 로그를 만들고, incident-autopsy가 가져다가 분석한다.

Loki·Prometheus·Grafana는 그 흐름을 실시간으로 보여주는 모니터링 스택이다.

 

---

2. 핵심 설계 - GUID 공유

실제 금융 시스템에서 트랜잭션 하나는 여러 시스템에 동시에 흔적을 남긴다.

이걸 재현하지 않으면 AI가 "멀티소스 로그에서 같은 장애를 찾는" 연습을 할 수 없다.

 

실제 샘플 데이터를 뜯어보니 핵심 힌트가 있었다. Jennifer APM 로그와 KB Framework 앱로그가 동일한 33자 GUID를 공유하고 있었다.

Jennifer APM:  GUID : AA0VW3YT2GJAGZ1Y8KXPQMNE7RFTU0C
Framework 앱:  [AA0VW3YT2GJAGZ1Y8KXPQMNE7RFTU0C][E][AbsSqlHandler] SQLException

 

 

생성하는 소스는 4종이다.

소스	상관 ID
Jennifer APM Transaction	GUID 33자 (AA0...)
KB Framework 앱로그	GUID 33자 (Jennifer와 동일)
Spring Boot REST + Hibernate	UUID v4 (별도)
Spring Boot Log4j	TXN-NNNNNNN (별도)

앞의 두 소스가 같은 GUID를 쓰기 때문에, incident-autopsy가 GUID 하나만 알면 연관된 로그 전부를 찾아낼 수 있다.

 

---

3. 시나리오 설계

장애 패턴을 그냥 랜덤으로 만들면 의미가 없다.

그래서 실제 금융 시스템에서 자주 나오는 패턴 4종을 정의했다.

시나리오	상황	응답 시간
sql_exception	SQL 컬럼 사이즈 초과 / 제약 위반	900~1500ms
payment_timeout	결제 게이트웨이 응답 없음	3000~10050ms
null_pointer	사용자 프로필 LEFT JOIN 결과 없음 → NPE	200~500ms
normal	정상 완료 3종	50~400ms

에러 타입마다 스택트레이스 내용이 다르다.

 

sql_exception이면 ORA-01401, DataIntegrityViolationException이 나오고,

null_pointer면 NullPointerException이 나온다. 같은 패턴만 반복하면 AI가 외워버리기 때문에 다양성이 중요했다.

 

 

연속 모드로 실행하면 한국 금융권 기준 시간대별 피크 패턴도 적용된다.

python generator.py --continuous --rate 2 --error-rate 0.05 --peak-pattern

오전 10시, 오후 15시에 트래픽이 최대 2배까지 올라가는 사인파 모델이다. 실제 시스템과 비슷한 트래픽 패턴을 재현하려고 넣었다.

---

4. Loki를 선택한 이유

파일로만 쌓으면 GUID 검색이 불편하다. 그리고 실시간으로 에러율을 보면서 "내가 원하는 패턴으로 로그가 나오고 있나" 확인하고 싶었다.

모니터링 스택을 붙이기로 하면서 Loki와 Elasticsearch를 비교했다.

항목	Loki	Elasticsearch
메모리	~256MB	~2GB+
본문 인덱싱	레이블만	전체 단어
라이선스	AGPL	SSPL (2021~)

개발 환경에서 Elasticsearch를 띄우면 다른 걸 실행할 여유가 없다.

그리고 우리 케이스에서 전문 인덱싱이 필요한 게 아니었다.

 

레이블로 범위를 좁힌 다음 GUID를 본문에서 grep하면 충분했다.

이러한 이유로 Loki를 사용하기로 결정했다.

 

---

5. 카디널리티 - 레이블 설계에서 가장 고민한 부분

레이블을 잘못 설계하면 스트림이 폭발하고 오히려 더 느려진다.

 

Loki는 레이블 조합마다 별도 스트림을 만든다. 레이블 값의 종류가 많아질수록 스트림 수가 곱셈으로 늘어난다. 스트림이 10,000개를 넘으면 인덱스가 비대해져서 검색이 오히려 느려진다.

 

가장 고민한 게 GUID였다. GUID가 레이블이면 검색이 제일 빠르지만, 값이 수만 개다.

GUID가 레이블일 때:
source(4) × has_error(2) × error_type(4) × guid(수만) = 수십만 스트림 ❌

 

결국 GUID는 본문에 남기고 나머지만 레이블로 쓰기로 했다.

source(4) × has_error(2) × error_type(4) × tx_code(20) = 640 스트림 ✅

GUID는 레이블로 조회하는 대신, 먼저 source와 error_type으로 범위를 좁힌 다음 본문에서 grep 한다.

속도 차이는 크지 않았다.

 

---

6. 트러블슈팅

1. Grafana 한글 깨짐

Grafana 대시보드를 코드로 만들기 위해 PowerShell 스크립트로 JSON 파일을 생성했다.
근데 패널 이름 "에러 건수", "응답 시간" 같은 한글이 전부 ???? 같은 문자로 깨져서 나왔다.

 

원인은 BOM이었다. BOM(Byte Order Mark)은 파일 맨 앞에 몰래 붙는 3바이트짜리 마커인데, "이 파일은 UTF-8이에요"라고 알려주는 역할을 한다.

근데 Grafana API는 BOM을 인식 못 하고 파일 내용이 깨진 것처럼 읽는다.

PowerShell은 파일을 저장할 때 자동으로 BOM을 붙이는 게 기본 동작이라 이게 문제가 됐다.

 

따라서 Python으로 파일 생성 방식을 바꿨다.

with open("dashboard.json", "w", encoding="utf-8") as f:
    json.dump(data, f, ensure_ascii=False)

Python의 open(encoding="utf-8")은 BOM 없이 저장한다.

ensure_ascii=False는 한글을 에러처럼 이스케이프하지 말고 그냥 "에러"로 저장하라는 뜻이다.

이 두 가지가 합쳐지니까 Grafana가 한글을 제대로 읽게 되었다.

 

 

2. Stat 패널이 숫자 하나 대신 선 15개로 쪼개지는 버그

에러 총 건수를 큼직한 숫자 하나로 보여주는 stat 패널을 만들었다.
근데 숫자 하나 대신 15개 선이 겹쳐서 꽤나 보기 불편한 그래프가 나왔다.

 

원인은 Loki가 로그 파일마다 별도 시리즈를 만들기 때문이다.

로그 파일이 15개면 에러 건수도 파일별로 15개 숫자가 따로 계산된다.

Grafana는 이걸 합산하지 않고 그냥 15개 선으로 다 그려버린다.

 

sum()으로 감싸면 15개를 하나로 더해준다.

# 전: 파일마다 따로 → 15개 선
count_over_time({job="incident-autopsy"} |= "ERROR" [1m])

# 후: 전부 합산 → 숫자 하나
sum(count_over_time({job="incident-autopsy"} |= "ERROR" [1m]))

 

3. Dashboard UID 충돌

Grafana는 대시보드를 UID로 식별한다.

UID가 같으면 "같은 대시보드를 업데이트하는 것"으로 보고, UID가 다르면 "새 대시보드를 만드는 것"으로 본다.

 

버전 업그레이드를 하면서 UID를 dashboard-v1에서 dashboard-v2로 바꿨다. 그랬더니 Grafana 내부 DB에는 v1짜리 대시보드가 남아있는데, 파일에서는 v2가 들어오니까 충돌이 났다. 프로비저닝 자체가 실패하면서 대시보드가 아예 안 뜨는 상황이 됐다.

 

UID를 다시 v1으로 되돌리니까 Grafana가 기존 레코드를 업데이트하는 방식으로 처리하면서 정상적으로 뜯다.

* 교훈: UID는 한 번 정하면 함부로 바꾸면 안 된다.

 

 

4. Docker 컨테이너에서 host 서비스 접근 불가

Prometheus는 Docker 컨테이너 안에서 돌고, 메트릭을 수집하려는 log-autogenerator는 host(내 컴퓨터)에서 직접 돌고 있었다.
localhost:9000으로 접근을 시도했는데 연결이 안 됐다.

 

원인은 Docker 네트워크 격리다. 컨테이너 안에서 localhost는 내 컴퓨터가 아니라 컨테이너 자기 자신을 가리킨다. 컨테이너 입장에서 host(내 컴퓨터)는 외부 서버와 마찬가지라 주소를 따로 알아야 한다.

extra_hosts:
  - "host.docker.internal:host-gateway"

host-gateway는 Docker가 자동으로 host IP를 할당해주는 특수 키워드다. 이 설정을 추가하면 컨테이너 안에서 host.docker.internal이라는 이름으로 host에 접근할 수 있다. Windows Docker Desktop과 EC2 Ubuntu 환경 둘 다 이 설정 하나로 해결됐다.

 

---

7. 최종 결과

python generator.py --continuous --rate 2 --error-rate 0.05 --peak-pattern

총 인시던트:  1,479건
에러 건수:    17건
에러율:       1.22%
소스 4종 수집: jennifer-apm / framework-applog / log4j / modern-rest ✅
피크 배수:    1.75 (오후 피크타임)

Grafana에서 피크 배수가 올라갈수록 에러 건수도 같이 올라가는 걸 실시간으로 확인할 수 있었다.

실제 금융 시스템의 피크타임 패턴을 학습한 결과, 비슷하게 동작했다.

 

---

8. 실무에 붙이려면

현재 구조는 시뮬레이터 기준으로 tx_code가 20개다.

실제 금융 시스템의 거래코드는 수천 개 수준이라 그대로 레이블로 쓰면 스트림이 폭발한다.

채널(10) × 업무(20) × 트랜잭션(~500) = 수천 종
→ source(4) × has_error(2) × error_type(4) × tx_code(3,000) = 96,000 스트림 ❌

실무 환경이라면 tx_code를 업무 대분류(계좌, 결제, 대출 등 ~10종)로 묶거나,

PostgreSQL에 별도 인덱스 DB를 병행해서 GUID를 빠르게 찾는 구조로 가야 한다.

 

테스트 데이터가 현실적이어야 AI 분석도 현실적이다.
단순한 더미 데이터로 학습한 AI는 실제 로그 앞에서 무너진다.

 

 

End-Gamers | incident-autopsy | log-autogenerator