문제기존에는 EC2 환경에서 ELK 스택을 사용해 로그를 수집하고 있었다.하지만 개인 프로젝트와 홈 서버 성격의 서비스까지 포함되면서 다음 문제가 발생했다.ELK는 메모리 사용량이 너무 큼라즈베리파이의 RAM 용량은 4~8GB이지만 ELK를 가볍게 띄워도 3~4GB가 소요됨라즈베리파이의 디스크 IO 성능 제한 지금 환경에서 ELK는 기능은 충분하지만, 너무 무거우므로 “가벼운 로그 수집 시스템”이 필요하다.서비스별 로그 흐름 파악장애 발생 시 빠른 원인 추적저사양 환경에서도 안정적으로 동작운영 부담이 적을 것 Loki + Grafana + Promtail 조합기존 로그 시스템과 달리 로그 본문을 인덱싱 하지 않고 로그에 붙은 라벨(Label)만 인덱싱하는 구조메모리 사용량이 낮고디스크 IO 부담이 ..

지난 글에서 Raspberry Pi + Elasticsearch + Kibana 환경을 기반으로 로그 분석 환경을 구축한 이유와 설치 과정을 다뤘다.이번 글에서는 스프링 애플리케이션에서 발생하는 로그를 Kibana가 이해할 수 있는 JSON 형식으로 변환하고, 모든 요청 로그에 TraceId를 자동 포함시키는 방법을 정리해보려 한다. 로그를 “정형화”해야 하는 이유 Spring Boot의 기본 로그는 다음과 같은 단순 문자열(Log Line) 형태이다:2025-11-21 13:11:02 INFO OrderService - 주문 생성 완료 user=100, order=50021 이러한 기본 방식에는 여러 문제점이 존재1. 검색의 어려움2. 에러 원친 추적 어려움3. MSA 같은 다중 서버 환경에 비효..

로그를 시각화하고 중앙에서 모니터링하려는 목적에서 Elasticsearch, Kibana을 사용한 로그 수집 및 시각화 시스템을 구축하려고 한다. 이를 위해, Spring 서버에서 생성된 로그를 통일화하여 ELK 시스템에 전송하는 두 가지 방법을 고려하였다. 방법 1: Spring → Logstash TCP 직결 Spring 애플리케이션에서 생성된 로그를 Logback을 사용하여 직접 TCP를 통해 Logstash로 전송하고, Logstash는 해당 로그를 받아 Elasticsearch에 삽입하는 방식구성:Spring에서 생성된 로그는 logback.xml 또는 logback-spring.xml에서 설정된대로 TCP를 통해 Logstash에 전달Logstash는 TCP로 받은 로그를 처리하고, 이를 J..

AWS EC2에 배포된 Spring Boot 서버에서는 사용자의 행동, API 요청 흐름, 에러 발생 지점 등을 모두 로그(Log) 로 기록한다.이 로그는 단순한 문자열이 아니라, 서비스 운영에서문제 파악 → 원인 분석 → 병목 추적 → 장애 대응 → 성능 개선까지 모든 과정에 필수적인 핵심 데이터다. 문제는, 이렇게 발생하는 로그가 시간이 지날수록 서버 내부에서만 누적되고, 파일로만 남아있으면:특정 사용자 요청 흐름을 찾기 어렵고동일한 traceId를 기준으로 묶어서 보기 힘들고에러 발생 전후의 로그를 빠르게 조회하기 어렵고서버가 늘어나면 로그를 서버마다 직접 들어가서 확인해야 하고장애가 발생해도 빠르게 원인을 찾기 힘들다 이런 문제를 해결하기 위해 AWS에서 생성되는 Spring Boot 로그를 ..