✏️ [Spring Boot] 로그 잃고 외양간 고치기

[psychology50]

내용 (한줄 요약)

그냥 Spring에서 로그 파일 생성 설정 방법이라 읽어보지 않으셔도 무방한데, 여러분들은 어떤 기준으로 언제, 어디서 로그를 남기는지 논의해보고 싶습니당.

예상 독자

로그 관리의 필요성을 느끼는 스프링 개발자

블로그 링크

https://jaeseo0519.tistory.com/441

[youngsu5582]

다만, 혼자서 API 개발부터, 프로젝트 관리에 온갖 회의는 물론이고, 개인적으로도 영어, OS, JVM 공부까지 하다가, 또 틈만 나면 Spring 프레임워크 소스 코드 분석하는데 로그 관리에 투자할 시간이 없었을 뿐.

몸이 혹시 멀티 스레드로 돌아가나요...?
너무 멋있네요 🥲

<springProfile name="prod">
    <root level="info">
        <appender-ref ref="CONSOLE"/>
    </root>

해당 부분에서 prod 를 CONSOLE 로 하는 이유가 있나요?
생각하는 부분으론 상시 prod 를 모니터링 하는게 아닐거 같은데 CONSOLE 로 하는게 궁금합니당
( 추가로, 서버가 죽으면 날라가지 않나요? )

---

내용에 대한 얘기로

저희는 프로젝트에서 프론트와 소통이 용이한 부분에 로그를 찍었던 거 같아요.
예를 들어, 참가 신청을 했는데 잘 됐는지 등
( 그냥 GET 빼고 다 찍은거 같기도 하구요 ㅋㅋㄱㄱㅋㄲ )

추가로, AOP 를 통해 Request Response 도 찍을려고 했는데
무차별 공격때문에 어마어마하게 로그가 쌓여서 포기했습니다.

저도 이 로그의 기준점에 대해서 고민을 했었는데
결국 고객 CS 응대를 할 때 필요한 정보들을 남긴다고 하더라구요.

제 결제가 안되었는데요?
서드파티 잘못인지, 우리 잘못인지, 고객 잘못인지 가리기 위해 필요

에러가 발생하면 그냥 슬랙이나 디코 웹훅으로 날리는것도 방법일 거 같긴 해요.
아니면, 데이터들 팀원에게 공유하기 위해

@Profile("prod")
@Component
class InteractionEventListener(
    private val interactionNotificationChannel: NotificationChannel
) {

    @Async
    @EventListener
    fun onNewMember(newMemberEvent: NewMemberEvent) = interactionNotificationChannel.notify(
        Notification(
            "회원가입",
            "새로운 사용자 ${newMemberEvent.username}이 회원가입 했습니다"
        )
    )

이렇게 슬랙으로 간단하게 공유하는 경우도 있더라구요.

결론은 주어진 도구 활용하는게 최고인듯 싶슴다 ㅋㅋㄱㅋㄱㄲ

오늘도 글 잘 보고 갑니다~

[psychology50]

해당 부분에서 prod 를 CONSOLE 로 하는 이유가 있나요? 생각하는 부분으론 상시 prod 를 모니터링 하는게 아닐거 같은데 CONSOLE 로 하는게 궁금합니당 ( 추가로, 서버가 죽으면 날라가지 않나요? )

이 내용은 단순히 예시라서 그렇습니다 허허.
실제로 프로덕트에 반영한 로그는 info 레벨은 console로 출력하고, debug 레벨은 file에 기록하도록 설정해두었어요.

다만, 이 부분은 각 팀에서 알아서 잘 이야기해서 결정할 문제기 때문에, 제 서비스의 디테일한 설정은 포함하지 않았습니다!

저희는 프로젝트에서 프론트와 소통이 용이한 부분에 로그를 찍었던 거 같아요. 예를 들어, 참가 신청을 했는데 잘 됐는지 등 ( 그냥 GET 빼고 다 찍은거 같기도 하구요 ㅋㅋㄱㄱㅋㄲ )

전 GET 요청도 모두 포함했는데, 해당 요청은 제외하는 것도 좋은 생각인 거 같아요!
이건 생각을 못 해봤네요.

추가로, AOP 를 통해 Request Response 도 찍을려고 했는데 무차별 공격때문에 어마어마하게 로그가 쌓여서 포기했습니다.

개인적인 생각인데, 이 부분은 트래픽 처리율 제한 장치로 제한하면 좋을 거 같다는 생각이 들어요.
그러면 무차별 공격을 수행하는 로그는 proxy 레벨에서 남기고, 서버의 로그도 유지할 수 있을 거 같다는 생각이 듭니다.

저도 이 로그의 기준점에 대해서 고민을 했었는데 결국 고객 CS 응대를 할 때 필요한 정보들을 남긴다고 하더라구요.

제 결제가 안되었는데요?
서드파티 잘못인지, 우리 잘못인지, 고객 잘못인지 가리기 위해 필요

안 그래도 최근에 저희 팀원 중 한 분이 어떤 서비스와 트러블이 생겨서, 로그 정보를 받은 적이 있는데
사용자 행동을 하나하나 다 로그로 남기고 있더라구요.

그런데 이게 API 서버 로그라기 보다는, Google Analytics 같은 분석 도구로 수집한 데이터들 같아서
서버에서 이런 목적으로 남기는 게 유의미한가? 라는 생각이 잠시 들었었어요 ㅋㅋ

생각해보니 잘잘못을 확실히 가리기 위해선 모두 기록하는 게 안전할 거 같네요. ㅎㅎ

에러가 발생하면 그냥 슬랙이나 디코 웹훅으로 날리는것도 방법일 거 같긴 해요. 아니면, 데이터들 팀원에게 공유하기 위해

생각해보니 전역 예외 핸들러 부분에서 이벤트 발행 하나만 추가해줘도
제품 코드에 침투하는 영향도 줄이고, 빠른 에러를 확인할 수 있다는 점에서 매력적인 거 같아요.

그런데 제 서비스에 반영하면 하루종일 에러 코드 알림이 디코로 날아올까 살짝 두려워지는..ㅎㅎ ^^

[youngsu5582]

그러면 무차별 공격을 수행하는 로그는 proxy 레벨에서 남기고, 서버의 로그도 유지할 수 있을 거 같다는 생각이 듭니다.

앞단에 nginx 나 ALB 에 waf 만 활성화 하면 됐는데 시간이 부족하더라구요.
그리고, 실제 요청마다 로그를 다 남기기엔 너무 길기도 하고, 불필요해서 안남겼습니다.
이것도 POST 만은 로그 찍어도 괜찮았을거 같긴 하네용.

그런데 이게 API 서버 로그라기 보다는, Google Analytics 같은 분석 도구로 수집한 데이터들 같아서
서버에서 이런 목적으로 남기는 게 유의미한가? 라는 생각이 잠시 들었었어요 ㅋㅋ

Google Analytics 는 약간 DAU 나 정보성을 얻기 위한 요소로 자주 사용된다는 거 같더라구요.
결국 프론트는 믿지 않는게 좋은거 같더라구요 ㅋㄱㅋㄱㄲ.

그런데 제 서비스에 반영하면 하루종일 에러 코드 알림이 디코로 날아올까 살짝 두려워지는..ㅎㅎ ^^

저도 그래서 log.error 는 Exception.class 로 ( 예상하지 못한 에러 ) 잡히는 요소만 했는데 생각보다 효과를 톡톡히 봤습니다.
( 어떤 사용자가 3G 환경인지 모르겠는데 중복 데이터 3번 들어가서 매칭이 11명이 되는일이 있었습니다 ㅋㄱㅋㄱㄲ )