ErrorMonitor 라이브러리는 Java 애플리케이션에서 발생하는 예외를 실시간으로 감지하고, 상세 정보를 수집하여 외부 시스템으로 전송하는 모니터링 도구입니다. Java Agent 기술과 Bytecode Instrumentation (바이트코드 조작)을 활용하여, 기존 애플리케이션 코드의 수정을 최소화하면서 강력한 에러 리포팅 기능을 제공하는 것이 특징입니다.
특히, 예외 발생 시점의 정보뿐만 아니라, 해당 예외로 인해 실행되지 못한 향후 호출될 메서드를 예측하는 독창적인 기능을 포함하고 있어, 개발자가 잠재적인 문제를 파악하고 디버깅하는 데 큰 도움을 줄 수 있습니다.
ErrorMonitor는 크게 '초기화 및 변환' 단계와 '실행 및 리포팅' 단계로 나누어 동작합니다.
- 초기화 및 변환 (Application Startup Phase)
- Agent 로딩: JVM이 시작될 때
javaagent옵션을 통해ErrorMonitorAgent가 로드됩니다. - Transformer 등록: Agent는
ErrorMonitorTransformer를 JVM에 등록합니다. 이 Transformer는 클래스가 로딩될 때마다 바이트코드를 검사하고 수정할 수 있는 권한을 가집니다. - 바이트코드 조작:
ErrorMonitorTransformer는 로딩되는 클래스의 메서드 중@ErrorMonitor어노테이션이 붙은 메서드를 찾습니다. 어노테이션이 발견되면, ByteBuddy 라이브러리를 사용해 해당 메서드의 종료 지점(onExit)에ErrorMonitorAdvice코드를 삽입합니다. 이 과정은 메서드 전체를try-catch블록으로 감싸는 것과 유사한 효과를 냅니다.
- Agent 로딩: JVM이 시작될 때
- 실행 및 리포팅 (Runtime & Reporting Phase)
- 예외 감지:
@ErrorMonitor가 적용된 메서드 실행 중 예외가 발생하면, 삽입된ErrorMonitorAdvice코드가 이를 감지합니다. - 비동기 처리: 감지된 예외는
ErrorReporter로 전달됩니다.ErrorReporter는 별도의 스레드 풀을 사용하여 예외 정보를 비동기적으로 처리하므로, 원래 애플리케이션의 흐름을 방해하지 않습니다. - 정보 수집: 예외의 스택 트레이스에서 클래스명, 메서드명, 발생 라인, 에러 메시지 등의 핵심 정보를 추출합니다.
- 미래 호출 분석:
BytecodeFutureCallAnalyzer가 예외가 발생한 지점의 바이트코드를 분석하여, 이후에 호출될 예정이었던 메서드 목록(future calls)을 예측합니다. - JSON 생성 및 전송: 수집된 모든 정보(기본 오류 정보 + 미래 호출 목록)는
ErrorLog객체로 캡슐화된 후, JSON 형태로 직렬화되어 외부 서버로 전송되거나 콘솔에 출력됩니다.
- 예외 감지:
2) 실행 시: 예외 감지 & 비차단(Async) 리포팅
이 라이브러리를 도입함으로써 얻을 수 있는 기대 효과는 다음과 같습니다.
- 코드 비침투성 (Non-Invasive): 개발자는 오류를 추적하고 싶은 메서드에
@ErrorMonitor어노테이션 하나만 추가하면 됩니다. 반복적인try-catch-log블록을 작성할 필요가 없어 비즈니스 로직의 가독성과 순수성을 유지할 수 있습니다. - 애플리케이션 성능 및 안정성 보장: 오류 리포팅 과정이 별도의 스레드에서 비동기적으로 처리되므로, 모니터링으로 인한 애플리케이션의 성능 저하를 최소화합니다. 또한, 리포터 자체에서 오류가 발생하더라도 애플리케이션의 본래 흐름에 영향을 주지 않도록 설계되었습니다.
- 사전 예방적 디버깅: 오류 발생으로 인해 실행되지 못한 '미래 호출' 정보를 제공함으로써, 단순한 오류 해결을 넘어 "이 오류 때문에 어떤 기능이 수행되지 못했는가?" 에 대한 통찰력을 얻을 수 있습니다. 이를 통해 잠재적인 2차 장애를 예방하고, 사용자 경험 저하를 최소화할 수 있습니다.
- 통합 용이성: 오류 리포트가 체계적인 JSON 형식으로 제공되므로, Elasticsearch, Splunk와 같은 외부 로그 분석 시스템이나 자체적인 대시보드와의 연동이 매우 용이합니다.
- 최적화된 성능: 클래스 로딩 시, 실제 바이트코드를 조작하기 전에 어노테이션 존재 여부를 먼저 빠르게 확인하는 최적화 로직이 포함되어 있어, 모니터링 대상이 아닌 클래스에서는 거의 부하를 유발하지 않습니다.