TIL 2024-01-31 로깅에 대한 고민을하다 알게된 글~~

 

그냥 두서없이 메모하면서 쓴 글이라, 읽기 힘드실 겁니다...

 

@Around("@annotation(piglin.swapswap.global.annotation.SwapLog)")
    public Object swapLog(ProceedingJoinPoint joinPoint) throws Throwable {

        HttpServletRequest req = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();

        log.info("start transaction");
        log.info("\nMethod - {} | Method Argument - {}\nIP - {} | Browser - {}\n▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ Cookie ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼\n{} \n▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲",joinPoint.getSignature().getName(), joinPoint.getArgs(), getRemoteAddr(req), getBrowser(req),
                getCookie(req));

        Object result = null;
        try {
            result = joinPoint.proceed();
            log.info("success transaction");
        } catch (Throwable e) {
            log.error("failed transaction", e);
        }
        return result;

    }

 

현재 저렇게 AOP 로깅을 만들었는데, 메소드 이름, 매개변수, 아이피, 브라우저, 쿠키로 사용자를 판별한다.

 

트랜잭션이 성공했는지 안 했는지를 보기위해 start transaction을 넣어주고 transaction 끝났다면 끝났다고 말해주게 해주려고 했는데 계속 위화감이 들었다.

 

왜 위화감이 들었을까?

점마는 진짜 transaction이 시작했고 끝났다는 걸 알리는게 아니기 때문이다 그냥 메서드 시작하고 끝나는 걸 알리는거임

트랜잭션 안 붙은 메서드에서도 붙일 수 있음

 

TraceId / MDC

MSA로 분산되어 있는 서버라고 한다면 트랜잭션을 추적하는 셀리움(라이브러리), 일단은 모놀릭이여서 쓰레드 넘버를 기본적으로 찍어줘야함 (쓰레드 ID를 찍어주는 이유는 시작부터 요청마다의 쓰레드를 구분하기 위함), 이게 분산 되었을 때, 모놀릭 → MSA 로 갔을 때 쓰레드 ID를 공통화

쓰레드 ID를 MDC 로그백을 사용한다면 MDC를 지원해줌 로그를 모니터링 한다고 했을 때 섞임

로그를 한 요청에 여러개가 찍힐 텐데,

MDC 를 사용해서 요청마다의 정보를 찍어두는 것이 좋음 trace라고 부르기도 함

trace id, request id 등을 찍는 이유가 멀티쓰레드 환경이기 때문에 저 로그 순서가 보장이 안됨 추적 아이디가 꼭 필요하다 UUID로 해도 되고(라이브러리 사용) → RequestId 로 사용

 

// 어느 환경에서 어느 레벨로 찍을 것인지 정하면 좋음

로그백 파일도 여러가지로 나눠서 관리할 수도 있음 실무에서는 그렇게 사용

xml은 임포트 기능이 있음

 

 

분산로그 트레이싱

zipkin

spring cloud sleth

 

시스템간의 호출 → 분산환경 간 추적을 위해서 나옴

예를 들어 MSA 환경에서 회원 서버 → 알림 서버로 보내면 쓰레드 ID가 달라지는데 이걸 해결 해줌

 

DB 트랜잭션 로깅

보통 db에서 트랜잭션 로그를 지원해줌

트랜잭션 fail log를 할지 rollback 로그를 할지

crash rollback

db 이중화 m, s m 쪽에만 트랜잭션 가져오고 s 에서는 get하는 방식(트랜잭션 x)

m쪽에서 로그를 쌓아놓고 보통은 crash rollback 에러를 쌓아두다가 한달에 한번 정도 백에다가 알려줌(좀 많이 쌓이는 부분이 문제가 많은 거니까)

 

번외.

옛날엔 서버를 펫처럼 씀 하드 늘려주고 포트 늘려주고 트래픽 관리해주고

도커가 나오고나서는 가축처럼 씀 ㅋㅋㅋㅋㅋㅋ (어? 너 죽었어? 다른 애 키울게)

그래서 로그의 의미가 퇴화되는 듯함

그래서 조금 느려도 안전한 코드가 각광받는 현상이 생김.

 

도커에서 띄우는데 로그를 어떻게 저장할까요

도커 저장 → ec2 하드 디스크에 저장 → 도커 껐다키면 하드 디스크 초기화 → 볼륨 마운트로 ec2에 저장하지 않는 이상 휘발성임. → 로그를 디텍팅하는 파일비트, 엘라스틱 서치로 다른 로그 서버에 쌓아둠→ 다른 ec2를 또 열어서 로그만 주구장창 쌓는 것 → 엘라스틱 서치 스택이라고 부름 → 파일 비트 엘라스틱 서치 키바나 등등 시각화 잘 돼있고 서치엔진도 잘 돼있음