Spring 로그 모니터링 시스템: ELK → Grafana Loki Stack 전환기
1. 들어가며
척척학사 BE 서버의 로그 모니터링을 위해 그동안 ELK(Elasticsearch + Logstash + Kibana) 스택을 사용해왔다.
하지만 다음과 같은 고민이 생기기 시작했다:
- ELK 구성 요소가 너무 많다
- 리소스를 과하게 잡아먹는다
- 로그 분석만 목적인데 유지비용이 너무 크다
(현재는 무료 플랜이지만 추후 유료화 고려)
그래서 가볍고 효율적인 대안인 Grafana Loki Stack을 도입했다.
2. 왜 ELK를 벗어나고 싶었나?
ELK는 분명 강력했지만, 현실적인 한계가 존재했다:
- 리소스 소모: Elasticsearch만 해도 메모리 2~4GB는 기본
- 설정 복잡성: Logstash나 Filebeat 설정이 번거로움
- 운영 부담: 인덱스 관리, 롤오버 설정 등 신경 쓸 게 많음
- 작은 서버엔 과도함: 단일 EC2 Spring 서버 기준으로는 과한 스택
3. 대안으로 선택한 Grafana Loki Stack
Grafana Loki Stack은 로그 모니터링에 최적화된 경량 스택이다. 구성은 단순하다:
[Spring Boot] → [Promtail] → [Loki] → [Grafana]- Promtail: 로그 수집기 (Filebeat 역할)
- Loki: 로그 저장소 (Elasticsearch 대체)
- Grafana: 시각화 및 알림 기능 (Kibana 대체)
4. 기술 선택의 핵심 기준
| 비교 항목 | ELK Stack | Grafana Loki Stack |
|---|---|---|
| 리소스 사용량 | 높음 ❌ | 낮음 ✅ |
| 설정 및 배포 난이도 | 복잡 ❌ | 간단 ✅ |
| 비용 효율성 | 낮음 ❌ | 높음 ✅ |
| 로그 분석 목적 | 충분 ✅ | 충분 ✅ |
| 운영 편의성 | 낮음 ❌ | 높음 ✅ |
우리 팀의 상황(단일 서버, 로그 중심 모니터링, 예산 민감)엔 Loki가 딱이었다.
5. 적용 과정 요약
✅ Spring Boot 로그 포맷 설정
logging:
pattern:
console: '{"timestamp":"%d{yyyy-MM-dd HH:mm:ss}","level":"%p","message":"%m"}'✅ Promtail 설정 예시
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /tmp/positions.yaml
clients:
- url: http://loki:3100/loki/api/v1/push
scrape_configs:
- job_name: spring
static_configs:
- targets:
- localhost
labels:
job: spring
__path__: /app/logs/*.log
pipeline_stages:
- json:
expressions:
timestamp: '@timestamp'
level: level
thread: thread_name
logger: logger_name
message: message6. Grafana 쿼리 & 대시보드 구성
| 패널 이름 | 설명 | 쿼리 예시 |
|---|---|---|
| 전체 로그 수 | 시간에 따른 로그 발생량 트렌드 확인 | count_over_time({job="spring"}[1m]) |
| 에러 로그 수 | 에러 레벨 로그만 시간별 개수로 확인 | `count_over_time({job="spring"} |
| 에러 로그 상세 보기 | 최근 에러 로그 리스트 확인 (로그 테이블) | `{job="spring"} |
| 에러 로그 비율 (%) | 전체 로그 중 에러 로그 비율 | `rate({job="spring"} |
✅ Y축: logs/sec 또는 %
✅ Panel 유형: Time series, Logs, Stat 등 적절히 선택
7. 자동 복구를 위한 설정
✅ 1. 대시보드 JSON 저장 위치
~/monitoring/grafana/provisioning/dashboards/loki-dashboard.json~/monitoring/grafana/provisioning/dashboards/spring-log-dashboard.json
✅ 2. Dashboard provisioning 설정
# ~/monitoring/grafana/provisioning/dashboards/dashboards.yaml
apiVersion: 1
providers:
- name: default
orgId: 1
folder: Loki
type: file
updateIntervalSeconds: 10
options:
path: /var/lib/grafana/dashboards✅ 3. Grafana 환경변수 설정
environment:
- GF_SECURITY_ADMIN_USER=admin
- GF_SECURITY_ADMIN_PASSWORD=admin
- GF_DASHBOARDS_DEFAULT_HOME_DASHBOARD_PATH=/var/lib/grafana/dashboards/spring-log-dashboard.json✅ 4. Docker Compose volume 추가
grafana:
volumes:
- ../grafana/provisioning:/etc/grafana/provisioning
- ../grafana/dashboards:/var/lib/grafana/dashboards8. 전환 후 느낀 점
- ✅ 서버 부담이 확 줄었다
- ✅ 설정이 직관적이라 유지보수도 쉬워졌다
- ✅ 필터링 쿼리가 간단해서 분석 속도도 빨라졌다
이제는 Spring 로그 기반으로 에러 알림, 사용자 요청 추적, 성능 저하 분석을 가볍게 처리할 수 있게 됐다.
9. 마무리
ELK는 여전히 강력한 도구이지만, 단일 Spring 서버에서 로그 중심 분석이 목적이라면
Grafana Loki Stack이 더 합리적인 선택일 수 있다.
이번 전환은 단순한 기술 변경이 아니라,
척척학사의 운영 환경에 맞는 현실적인 선택이었다.
기술을 선택할 땐 유행보다 현실을 먼저 보자!
^~^