스프링의 로깅 처리

김수호·2024년 11월 21일

>로깅을 해야하는데 어떻게 로깅처리를 하면 좋을까?

배경

애플 로그인을 구현할 때 로그를 보면서 수정이 필요한 상황이었다.
로깅처리가 하나도 안되어있어서 당장의 sout으로 로깅을 보는 수준의 상황.
이번에 제대로 로깅을 추가해보자.

스프링에서의 로깅 프레임워크 선택

1. 스프링에서 로깅을 처리하기 위한 자료 조사.

스프링에서는 logback이나 log4j2를 사용한다.

2. logback vs log4j2 무엇이 더 좋을까?

성능을 봤을땐 당연 log4j2가 좋다.

성능 관련 지표이며 logback의 위치를 보았을때 굉장히 낮은 위치에 속하는걸 볼 수 있다.

3. 그럼에도 logback을 선택한 이유

그럼 무조건 logback보단 log4j2가 좋은거 아니냐? 라는 말을 할수 있다.
틀린말은 아니다.
그럼에도 logback을 선택하였다.
이유는 : elk가 싫었고, fluentd를 선택하고 싶었기 때문이다.
그렇다면 구글에 한번 logback fluentd와 log4j2 fleuntd를 검색해보길 바란다.
그렇다면 logback을 활용한 fluentd예제와 이슈 정리 등 굉장한 많은 자료들이 반겨줄 것이다.

위와같은 이유로 나는 fluentd를 선택하기 위해서 logback을 선택하였다.

로그 수집,처리 도구 선택

1.로그 수집 관련 자료조사

fluentd와 logstash,datadog, Sentry 등등 있었다.

2. 다양한 도구 중에서 무엇을 사용하는게 좋을까?

아마 다들 ELK EFK는 많이 들어봤을 것이다. 그 만큼 대표적이라고 볼 수 있다.
그럼 ELK의 L은 로그스태시 인데 F는 무엇인가? fluentd이다.
그럼 소거법으로 지워서 ELK와 EFK에 대해서 비교를 해보자.

ELK vs EFK

난 여기서 우리 환경에 대해서 한번 생각해보기로 했다.
스타트업의 환경에서 많은 ec2를 사용하지 않으며 비용최적화 상태에서 진행해야한다.
최대한 스택을 뺄수있다면 오히려 빼는게 이득인 상황이다.
그럼에도 확장성은 보유하고 싶다.

이 상황의 최적의 솔루션은 ELK도 EFK도 아닌 fluentd다.
이유는 fluentd의 경우 혼자서도 사용이 가능하다.
실제로 fleuntd + s3로 설계하는 케이스도 있다.
그렇다면 최소화 시킬 수 있는 환경이라면
키바나랑 엘라스틱서치를 설치하지 않아도 되는 fluentd가 조금 더 최적화 된 상황이라고 생각하였고
fleuntd를 골랐다.