바이너리 로그 전송 시스템 모니터링 & 로그 수집기 (2025)

0한눈에

• 대상: 고객사 on-premise Updater 모듈 → 중앙 모니터링 서버 로그 전송 경로.
• 핵심 산출물: 표준 포맷 오류 로그 "로그 수집기" 기획·설계.
• 부수 개선: 데이터 타입 용어 표준화(other→main, filecomp→source), API 버저닝 도입.

1왜 필요했나

중앙에서 고객사 on-premise로 동기화하는 Updater 모듈에서 오류가 발생해도, 오류가 고객사 환경 안에서만 발생하기 때문에 내부에서 즉시 인지하기 어려웠다. 그 결과 장애 대응이 지연됐다. → 고객사 환경에 대한 가시성을 확보해 사전 인지·신속 대응이 가능한 구조가 필요했다.

2설계 흐름

1. 고객사 Updater 모듈에서 동기화 중 오류 발생
2. 로그 수집기가 오류 로그를 정해진 포맷으로 변환
3. 중앙 모니터링 서버로 표준 포맷 로그 전송·집계
4. 잠재 문제 사전 인지 → 선제적 장애 대응

3명확성·확장성 개선

• 데이터 타입 용어 표준화: 모호한 명칭을 의미 기반으로 정리 — other → main, filecomp → source.
• API 버저닝 도입: 인터페이스 변경 시에도 하위 호환을 유지하도록 버전 체계 적용.

4온보딩 포인트

• 고객사 on-premise 환경은 기본적으로 내부에서 보이지 않는다 → 가시성 확보는 항상 로그를 중앙으로 끌어오는 것에서 시작.
• 로그는 표준 포맷으로 정규화해야 집계·모니터링이 가능하다.
• 외부로 노출되는 인터페이스는 API 버저닝으로 변경 안전성을 확보한다.

5공개(포트폴리오)와의 차이

공개 버전(human/portfolio/items/binlog-shipping-log-collector.html)은 내부 모듈명을 일반화·내부 식별자·고객사명을 제거하고, 동기화 모듈 오류 인지라는 문제·접근·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용으로 내부 용어를 그대로 유지한다.

🔄 바이너리 로그 동기화 시리즈 ② — ① 스크램블링 · ② 모니터링·로그 수집기 · ③ 암호화 전환 · ④ 모니터링 v2