[ERP 구축기 #04] APM이 없어서 직접 만든 Grafana 모니터링 환경

💣 기존 ERP에는 모니터링 환경이 없었다

기존 ERP 시스템을 운영하면서 확인해보니 애플리케이션의 상태를 통합적으로 확인할 수 있는 APM(Application Performance Monitoring) 환경이 별도로 구축되어 있지 않았다.

 

시스템에 장애가 발생하거나 특정 API의 응답이 느려지더라도 어느 구간에서 문제가 발생했는지 빠르게 확인하기 어려운 구조였다.

신규 PQ 시스템을 구축하면서 단순히 서비스를 개발하는 것에서 끝내지 않고, 운영 단계에서 발생하는 문제까지 빠르게 추적할 수 있는 모니터링 환경을 함께 구축하기로 했다.

 

상용 APM을 도입하는 방법도 있지만 비용 부담이 있기 때문에 우선 Self-host 방식으로 운영할 수 있는 오픈소스 솔루션을 검토했다.

 

그로부터 시일이 꽤 지나서 무료로 사용할 수 있는 APM이 무엇이 있나 확인을 해보았고

grafana외 여러 제품군이 있다는걸 알게 되었다

 

📎 오픈소스 APM 비교

신규 시스템에 적용할 모니터링 솔루션은 다음 조건을 중심으로 검토했다.

• Self-host 방식으로 무료 운영이 가능한가
• Spring Boot와 연동하기 쉬운가
• API 요청에 대한 Trace 추적이 가능한가
• SQL 및 DB 성능 문제를 추적할 수 있는가
• 로그와 메트릭을 함께 확인할 수 있는가
• 운영에 필요한 Dashboard를 자유롭게 구성할 수 있는가

제품	무료 Self-host	Spring Boot	SQL 추적	UI 편의성추천
SigNoz	✅	✅ 매우 좋음	✅	⭐⭐⭐⭐⭐	1순위
Uptrace	✅	✅	✅	⭐⭐⭐⭐	2순위
Grafana + Tempo	✅	✅	✅	⭐⭐⭐	기존 Grafana 활용
Apache SkyWalking	✅	✅ 매우 좋음	✅	⭐⭐⭐	Java 중심
Jaeger	✅	✅	✅	⭐⭐	Trace 전용에 가까움

 

 

Docker를 활용해 비교할 APM들을 직접 구축하고 현재 개발 중인 Spring Boot 서비스와 연동해보면서 생각이 조금 달라졌다.

Grafana는 기존에 사용해본 경험이 있었고, Dashboard를 업무 및 운영 환경에 맞게 자유롭게 구성할 수 있다는 점이 가장 큰 장점이었다.

 

또한 Prometheus, Loki, Tempo 등을 조합하면 Metrics, Logs, Traces를 하나의 Grafana 화면에서 연결하여 확인할 수 있기 때문에 최종적으로 Grafana Stack을 사용하기로 결정했다.

 

구성요소	역할
Grafana	Metrics / Logs / Traces 통합 시각화
Prometheus	Spring Boot 및 시스템 Metrics 수집
Loki	Spring Boot 애플리케이션 로그 저장 및 조회
Tempo	Trace ID 기반 API 요청 흐름 추적
Grafana Alloy	애플리케이션 로그 수집 및 Loki 전달
Node Exporter	물리 서버 CPU, Memory, Disk 등 수집
Redis Exporter	Redis Metrics 수집
Postgres Exporter	PostgreSQL Metrics 수집

 

 

🚀 Grafana 모니터링을 위한 아키텍쳐

Grafana 로그수집 아키텍쳐

 

 

단순히 CPU와 Memory 현황 그래프를 보는 것보다 실제 장애가 발생했을 때 원인을 빠르게 찾을 수 있는 구조를 만드는 것을 중요하게 생각했다.

 

Dashboard에서 오류가 발생한 API를 확인하면 Trace ID를 클릭하여 Tempo로 이동하고, 해당 요청이 Controller → Service → Repository 등 어떤 경로로 처리되었는지 확인할 수 있도록 구성했다.

 

추가적인 애플리케이션 로그가 필요한 경우 URI를 통해 Loki로 이동하여 해당 요청과 관련된 상세 로그를 확인할 수 있도록 Dashboard 간 링크도 연결했다.

Grafana에서 대시보드에 있는 traceId 기반으로 빠르게 조회할수 있도록 연계한 플로우

 

 

(Prometheus) Metrics — CPU, Memory, API 응답시간, JVM, DB Connection 등 시스템의 상태를 수치로 확인
(Loki) Logs — 애플리케이션에서 발생한 오류와 실행 기록 확인
(Tempo) Traces — 하나의 API 요청이 애플리케이션 내부에서 어떻게 처리되었는지 추적

 

 

Tempo로 분산 Trace 데이터를 저장하고 Trace ID를 기준으로 API 요청의 처리 흐름과 각 Span의 수행시간을 추적하고

OpenTelemetry를 통해 DB 호출 Span을 수집하여 API 처리 로직중 redis 조회, DB쿼리, API 연계등 실행 시간 차지하는 비중도 확인할 수 있도록 구성했고

실제 실행된 쿼리도 확인할 수 있도록 postProcessAfterInitialization 을 활용하여 실행된 완성 쿼리를 tempo에서 수집되게 구성했다

 

 

 

📗 처음에는 서버의 CPU나 Memory 사용량을 확인하는 정도의 모니터링을 생각했다.

하지만 실제로 구축해보니 운영에서 더 중요한 것은 장애가 발생했을 때 원인을 얼마나 빠르게 찾을 수 있는가였다.

 

Metrics만으로는 시스템에 문제가 있다는 사실은 알 수 있지만 정확한 원인을 찾기는 어렵다. 여기에 Logs와 Traces를 연결하면서 특정 API에서 오류가 발생했을 때 요청 흐름과 관련 로그까지 빠르게 추적할 수 있는 환경을 만들 수 있었다.

앞으로 PQ 시스템을 k3s 환경으로 만들면서 컨테이너와 Pod 상태까지 함께 모니터링하고, CI/CD 및 무중단 배포 환경도 단계적으로 구축할 예정이다.