-
Notifications
You must be signed in to change notification settings - Fork 8
로깅과 Logback에 대해 알아보아요.
정보를 제공하는 일련의 기록인 로그(log)를 생성하도록 시스템을 작성하는 활동
즉, 우리 애플리케이션의 정보를 알 수 있는 기록을 남기는 것이라고 생각할 수 있습니다.
어느 날 제가 몸이 아파서 팀 회의를 참가하지 못했다고 해봅시다. 몸이 괜찮아진 몰리는 전날 회의에 정해진 사항을 확인하기 위해 회의록을 학인합니다.
그런데, 우리의 서기 켬미가 그날 따라 회의록을 작성하지 못했네요. 몰리는 회의록이 없기 때문에 팀의 진행 사항이 어떻게 흘러갔는데 확인할 수 없습니다.
우리 애플리케이션이 다운되거나 문제가 발생했을 때 이를 파악할 수 있는 정보가 필요합니다.
갑자기 어느날 서버가 죽었는데 아무런 정보도 확인할 수 없다면, 백엔드 개발자들은 문제 파악을 할 수 없습니다. 문제를 해결했다고 해도, 문제가 무엇인지도 모르는 상태이니 정말 해결한 건지 확신할 수도 없구요.
따라서 효과적인 시스템 파악 및 디버깅을 위해 자세한 로깅이 필요합니다.
로그는 레벨이 존재합니다. 쉽게 말하면 기록에 등급을 정할 수 있다는 것이죠.
System.out.println과 같은 출력문은 모든 메시지가 출력되지만 로그는 환경에 따라 높은 등급만 보거나, 낮은 등급까지 확인하는 등 조정할 수 있습니다. 운영 환경별 로깅 레벨 수준이 달라야 하는 이유
로깅 프레임워크는 애플리케이션에서 발생하는 로그를 생성해주는 도구입니다.
로깅 프레임워크를 통해 우리는 로그 기록(생성), 로그 레벨 관리, 로그 형식 및 출력 대상 지정 할 수 있습니다.
SLF4J에 대해 알아봅시다. SLF4J는 자바에서 다양한 로깅 프레임워크에 대한 Facade, 즉 추상화 계층을 제공하는 인터페이스입니다.
이게 뭔말이야? 저는 "JPA가 자바 ORM에 대한 명세(인터페이스)인 것처럼 SLF4J도 자바 logging system에 대한 인터페이스다" 라고 이해했습니다.
Spring Boot Starter 라이브러리를 사용하면 기본으로 ‘ spring-boot-starter-logging ‘가 포함되고 여기에 SLF4J도 포함되어 있습니다.
따라서 우리는 SLF4J의 구현체인 로그 프레임워크 중 하나를 선택하여 사용하면 됩니다.
Logback은 우리가 로그를 효과적으로 관리하기 위해 사용할 수 있는 로깅 프레임워크 중 하나입니다. 예상하셨듯 SLF4J의 구현체입니다. 우리 서비스에서는 Logback 을 사용해서 로깅을 했습니다.
Logback을 사용한 이유는 SLF4J과 함께 Spring Booter Start가 기본적으로 Logback을 포함하고 있기 때문입니다. 고려한 로깅 프레임워크
Logback은 xml 또는 yml 파일로 작성할 수 있습니다.
xml이 더 자세히 커스텀하고 관리하기에 좋아서 xml을 사용했습니다.
먼저 logback-spring.xml을 통해 logback을 어떻게 사용할 건지 작성해줍니다.
Logback은 Logger, Appender 그리고 Layout의 세 가지 주요 클래스를 기반으로 설정할 수 있습니다.
# 예시
<configuration>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="CONSOLE" />
</root>
</configuration>
- Logger: 로깅을 수행 ➡️ 로그 "기록(생성)"
- Appender: 로그 이벤트의 출력 대상을 정의 ➡️ "어디에" 저장 또는 출력할 것인지
- Layout: 로그 메시지의 형식을 지정 ➡️ 로그가 "어떻게 생겼는지"
- 백엔드 코드 컨벤션
- 백엔드 기술 스택 및 선정 이유
- 각종 인스턴스 설정 파일 및 구성 위치 가이드
- ERD (24.09.27)
- 백엔드 CI CD 동작 프로세스
- 로컬 DB 환경 설정
- 백엔드 로깅 전략
- 백엔드 로그 모니터링 구성도
- 스프링 메트릭 모니터링 구성도
- Flyway 로 스키마 관리
- 코드잽 서버 구성도
- Git Submodule 사용 메뉴얼
- 프론트엔드 코드 컨벤션
- 프론트엔드 기술 스택 및 선정 이유
- 프론트엔드 서비스 타겟 환경 및 브라우저 지원 범위 선정
- 프론트엔드 모니터링 및 디버깅 환경 구축
- 프론트엔드 테스트 목록
- 프론트엔드 라이브러리 기술 검토
- 프론트엔드 개발서버, 운영서버 빌드 및 배포 환경 구분
- 목표했던 타겟 환경과 디바이스에서 서비스 핵심 기능 동작 확인
- 프론트엔드 접근성 개선 보고서
- EC2 로그 확인 방법
- VSCode를 통한 EC2 인스턴스 SSH 연결 방법
- 터미널을 통한 EC2 인스턴스 SSH 연결 방법
- NGINX 설정 파일 접근 및 적용 방법
- DB 접속 및 백업 방법
- [QA] 배포 전 체크리스트
- CI 파이프라인 구축
- CD 파이프라인 구축
- 백엔드 CI CD 트러블슈팅
- Lombok Annotation Processor 의존성을 추가한 이유
- 2차 스프린트 기준 ERD
- DTO 검증하기
- ProblemDetail
- Fork된 레포지토리 PR에서 CI Secrets 접근 문제 해결
- AWS CloudWatch 모니터링
- 스프링 메트릭 모니터링 구축 방법
- 로깅과 Logback에 대해 알아보아요.
- 백엔드 CD 파이프라인 Ver.2
- 요청, 응답 로그에 correlationId 를 추가하자!
- 3차 스프린트 기준 ERD
- 더미데이터 생성하고 실행하기
- 쿼리 성능 개선 결과
- 테이블별 인덱스 설정 목록
- 사용자 증가 시 발생할 수 있는 문제 상황과 개선 방안
- k6를 사용한 서버 부하 테스트
- 6차 스프린트 기준 ERD
- Query Performance Improvement Results
- 테스트 전략 및 CI 설정
- CI CD 구조
- 배포 전, 로컬에서 로그인 기능 포함 테스트해보는 법
- stylelint 적용기
- 내 작업 브랜치 중간에 Merge된 동료의 작업물을 넣고 싶다면 pull vs rebase
- [TS] Webpack config
- [TS] Webpack 환경에서 MSW v2 이슈
- [TS] webpack에서 react‐router‐dom 적용 안됨
- 2024.07.28 새 기획 회의
- 2024.07.26 2차 데모데이 후 회의
- 2024.07.11 백엔드 논의 좀 할게요
- 2024.07.11 백엔드 ERD 회의
- 2024.07.09 깃 브랜치 전략, PR 템플릿 회의
- 2024.07.03 주제 선정 회의
- 2023.07.03 팀빌딩데이 킥오프 회의
- 2023.08.07 3차 스프린트 중간회고