뭐요

[Spring] Sentry 도입기 (feat. 로그 관리) 본문

Spring

[Spring] Sentry 도입기 (feat. 로그 관리)

욕심만 많은 사람 2023. 8. 19. 13:48

로그 관리 도구 부재의 문제점

좋지못한 가독성

에러 디버깅 등 로그를 확인할 필요성이 생긴다면 직접 터미널을 통해 ssh 접속해서 서버에 접근했습니다. 터미널에서 로그를 확인하다 보니 무수히 쌓여있는 로그를 읽을 때 분간이 가지 않아서 읽기가 힘듭니다.

클라이언트와 API 연동의 어려움

서버에서 개발한 API를 연동하기 위해 클라이언트가 API를 테스트 하면서 문제가 발생할 수 있습니다. 때때로 (물론 우리 소프티어 부트캠프 AOS, FE 님들은 잘해주시지만 ^,^) 다음과 같이 말하곤 합니다.

“이거 안되는데요?”

그러면 API를 호출했을 때 어떤 parameter를 넣었는지, 로그를 확인하기 위해 언제 호출했는지 등 반문 해야합니다. 심지어 로그만 확인한다면 원인을 쉽게 알 수 있는 경우도 빈번히 있었습니다. 이러한 과정이 번거로워서 API 호출 정보를 쉽게 알 수 있으면 좋겠다, 클라이언트도 쉽게 로그를 확인할 수 있으면 좋겠다고 생각했습니다.

번거로움

로그를 확인하기 위해서 매번 ssh 접속하는 것은 굉장히 번거로운 일입니다. 번거롭다 보니까 에러 로그 확인을 하지 않고 디버깅을 하게 됐고, 오히려 문제점을 파악하는 데에 시간이 오래걸렸습니다.

로컬에서는 잘되는데요?

왜인지 로컬에서는 문제없이 잘 되지만, 운영 서버에서는 동작하지 않는 경우가 빈번히 발생했습니다. 그런 경우에 로컬 환경에서는 테스트할 수 없기 때문에 운영 서버의 로그 확인이 필수적입니다. 그치만 말했듯이 “번거로움” 이슈가 존재합니다.

 

Micrometer란?

Java의 어플리케이션 성능 모니터링을 위한 다양한 시스템과 통합될 수 있는 메트릭 파사드입니다. 즉, 애플리케이션에서 생성된 메트릭을 다양한 모니터링 시스템으로 전송할 수 있도록 하는 라이브러리입니다.

Metric (메트릭)
시스템의 성능, 작동 상태, 사용률 등에 대한 측정 지표
ex) CPU 사용률, 메모리 사용량, HTTP 통신 응답 시간

Facade (파사드)
설계 패턴 중 하나로, 복잡한 서브시스템에 대한 단순화된 인터페이스를 제공하는 역할 수행
따라서, Micrometer가 제공하는 인터페이스를 통해 다양한 모니터링 툴에 통일된 방식으로 메트릭을 제공할 수 있음

 

Monitoring Tool 선택하기

Micrometer가 제공하는 표준 측정 방식에 맞춰 구현되어있는 다양한 모니터링 툴이 존재합니다. 공식 문서에 따르면 아래 사진과 같이 Micrometer를 구현하는 다양한 모니터링 툴이 있음을 알 수 있습니다.

대표적으로 많이 사용되는 성능 모니터링 툴로는 아래 4가지가 있습니다.

ELK

Prometheus

Sentry

 

Sentry 적용하기

가격 정보

Sentry 가격 정보

  • Developer : 1개 계정 사용, 30일 데이터 보존, 오류 5,000개 제한, 트랜잭션 10,000개 제한
  • Team, Business : 무제한 계정 사용, 90일 데이터 보존, 오류 50,000개 제한, 트랜잭션 100,000개 제한
  • Enterprise : 맞춤형 비용

 

Spring Boot 적용

1. 적용할 Platform 선택

Sentry로 모니터링을 할 플랫폼을 선택합니다.

본 프로젝트에서는 Spring Boot를 사용하므로 선택 후 Configure SDK 를 누릅니다.

 

 

2. 의존성 추가

사용 중인 Build Tool과 Spring Boot 버전을 고려하여 의존성을 추가합니다. (지금 보니까 Gradle이 아니라 Graddle이라고 적혀있네요 오타인가 봅니다..!)

본 프로젝트에는 Gradle과 Spring Boot 2를 사용해서 다음처럼 추가했습니다.

dependencies {
    implementation 'io.sentry:sentry-spring-boot-starter:6.27.0' // Sentry
}

 

 

3. Sentry 설정 등록

application 파일에 DSN을 설정합니다.

기본적인 세팅을 마치고 프로젝트 설정에 들어가면 본인에게 할당된 DSN을 확인할 수 있습니다.

sentry:
  dsn: {본인에게 할당된 DSN}
  traces-sample-rate: 1.0 # 전송할 트랜잭션의 양 1.0 = 100% 
  logging:
    minimum-event-level: info # 최소 이벤트 로그 레벨
    minimum-breadcrumb-level: info # 최소 브래드크럼 레벨
What is breadcrumb?
 * 에러가 발생하기 전에 어떤 작업들이 있었는지의 컨텍스트를 제공

 

 

4. Logback 추가

slf4j의 구현체인 Logback 프레임워크를 사용하려 Sentry로 로그를 전송할 거라면 Logback 의존성을 추가해줍니다.

Logback을 이용할지, 직접 @AOP로 커스텀하여 사용할지 선택할 수 있습니다. 일단 Logback을 적용하고 좀 더 고도화 할 필요성을 느낀다면 그 때 바꾸기로 결정했습니다.

 

 

5. 테스트

본 프로젝트에는 Controller에서 발생하는 예외를 GlobalExceptionHandler 객체를 생성하여 한 번에 관리해줍니다.

위 문서를 참고하여 일부러 예외를 발생시켜 테스트해보겠습니다.

 

 

Sentry Issue 관리
코드를 수정하기에 앞서서, 로컬에 모든 세팅을 완료하고 서버를 실행하니까 issue에 다음과 같이 기록되었습니다.
시각화가 잘 되어 확실히 로그를 관리하기가 매우 편하겠지만 무분별하게 issue가 생기지 않도록 log level을 조절해야 함을 느꼈습니다. 일단 API 호출을 통해 테스트 하고 마저 설정해보겠습니다!@
@RestControllerAdvice
@Slf4j
public class GlobalExceptionHandler {
        ...

    @ExceptionHandler(BusinessException.class)
    public ResponseEntity<ErrorResponseDto> handleBusinessException(BusinessException e) {
        log.warn("BusinessException : {}", e.getMessage());
        final ErrorResponseDto response = ErrorResponseDto.of(e.getResultCode());
        return new ResponseEntity<>(response, HttpStatus.valueOf(response.getStatusCode()));
    }
}

기존의 코드는 비즈니스 로직 상의 예외가 발생한다면 warn level의 로그를 콘솔에 찍어주었습니다. 이제 Sentry에서 확인 할 수 있도록 코드를 수정하면 다음과 같습니다.

@ExceptionHandler(BusinessException.class)
public ResponseEntity<ErrorResponseDto> handleBusinessException(BusinessException e) {
    // log.warn("BusinessException : {}", e.getMessage());
    Sentry.captureException(e);
    final ErrorResponseDto response = ErrorResponseDto.of(e.getResultCode());
    return new ResponseEntity<>(response, HttpStatus.valueOf(response.getStatusCode()));
}

이후에 Swagger에서 테스트용 API를 호출해보았습니다.

존재하지 않는 옵션Id를 query string에 실어서 호출했고 Sentry에 다음과 같이 issue가 발행되었습니다.

 

 

stack trace, breadcrumbs, os information, query string 및 header 등 API 호출 기본 정보를 읽기 편한 format으로 보여주는 것을 볼 수 있습니다.

보기좋게 시각화 해주는 것도 큰 장점이지만, 각 issue 별로 팀원을 assign 할 수 있다는 점이 큰 특징인 것 같습니다. 실시간으로 에러를 모니터링 하는 것이 중요한 서비스에서 장애 발생 시 팀원과 협업할 때 굉장히 유용할 것 같습니다 👨🏻‍🏫

 

 

6. 기타 설정

  • 테스트 하고나니 TimeZone이 GMT 기준으로 설정되어 있었습니다. Seoul의 시간과 맞추도록 변경합시다.

  • server-name 설정 ⇒ 현재는 1대의 server만 운영하기 때문에 실효성은 없지만 추후 server를 증설하는 경우 어떤 server에서 발생한 에러인지 파악하기 쉽습니다.

sentry:
  dsn: {}
  servername: ca_art

 

  • 그 외 설정정보는 Sentry 공식문서에서 확인 가능합니다.

 

(Slack Notification 연동 참고 이미지)

 

 

적용 후기

위와 같은 과정을 거쳐서 Sentry를 성공적으로 적용했습니다.

며칠 사용해보니 Sentry를 학습하고 적용하는 데에 사용한 리소스를 상회할만큼 편리함을 느꼈습니다. 구체적으로는 다음과 같은 편리함을 몸소 느꼈습니다.

  1. 운영서버에서 장애가 발생하면 Slack으로 알림이 옵니다. Slack 메세지에서 바로 로그를 확인할 수 있고, 더 구체적으로 확인할 필요성이 있을 때 메세지에 걸려있는 링크만 누르면 곧장 원인을 파악할 수 있었습니다. 꽤나 편리합니다.
  2. 각각의 API가 호출된 시각이 기록됩니다. 이 레코드는 그래프로 나타내어 지는데, 실제 서버를 운영하는 경우에 트래픽을 파악할 때 굉장히 유용하겠다고 느꼈습니다.
  3. Sentry에는 특정 조건을 만족하는 경우에 별도로 알림을 받을 수 있는 기능이 있습니다. API를 호출했을 때 Transaction이 n초 이상 걸리는 경우 알림을 받도록 했는데, 병목 지점을 트래킹하는데 굉장히 유용합니다.

이런 모니터링 툴을 APM이라고 부른다는 것을 알게 됐습니다. APM을 사용하여 로그를 관리하는 이유를 몸소 느낀 시간이 됐습니다. 올해가 가기 전에 앱을 배포해서 서비스를 운영해보고 싶어, 소프티어 부트캠프와 별도로 진행중인 사이드 프로젝트가 있습니다..! 해당 프로젝트에도 APM 도구를 사용해서 로그 관리 및 성능 모니터링을 관리하려고 합니다. 끝~~

'Spring' 카테고리의 다른 글

스프링에서 OpenAI API 성능 개선기  (0) 2023.09.03
공식문서에서 권장하는 REST API의 URI 설계 가이드  (0) 2023.05.21
스프링 : 테스트 코드 작성 가이드  (0) 2023.05.16
스프링 : @Transactional의 기본 적용 범위  (0) 2023.05.05
스프링 Exception Handler 적용 (@ExceptionHandler, @ControllerAdvice)  (1) 2023.04.16
'Spring' Related Articles more