옵저버빌리티 백엔드 스택 선택 (SigNoz vs Grafana LGTM)
상태
승인 — Grafana LGTM 단독 채택 확정. PoC 비교(STK-OBS-11) 측정에서 Grafana가 비용/운영 면에서 우위로 확인됐고, SigNoz 스택은 제거했다(STK-OBS-13: docker-compose.signoz.yml·observability/signoz/·collector의 otlp/signoz exporter 삭제, 런타임 컨테이너·볼륨 정리로 ~3.6GB 회수). (벤더 중립 OTel이라 추후 SigNoz 재도입이 필요하면 Collector exporter만 추가하면 됨)
후보군
| 방안 | 설명 |
|---|---|
| Grafana LGTM | OTel Collector → Tempo(trace)·Prometheus(metric)·Loki(log) → Grafana 단일 UI. 컴포넌트 조합형 OSS |
| SigNoz | OTel-native 단일 앱(ClickHouse 백엔드). trace·metric·log를 한 앱 UI에서 연결 |
| Elastic APM(ELK) | Elasticsearch + Kibana + APM Server. 로컬 메모리 부담 가장 큼 |
결정
Grafana LGTM 채택 권고. 동일 텔레메트리(중앙 OTel Collector fan-out)를 양 스택에 동시 유입시켜 측정한 결과는 다음과 같다.
| 평가 축 | SigNoz | Grafana LGTM | 우위 |
|---|---|---|---|
| 로컬 메모리(측정, docker stats) | ~3.6GB (clickhouse 2.3GB + zookeeper 0.8GB + collector 0.44GB + signoz 0.05GB) | ~0.42GB (grafana 0.19 + loki 0.10 + prometheus 0.09 + tempo 0.04) | Grafana (8.5x 경량) |
| 운영 복잡도 | clickhouse+zookeeper+migrator+opamp. opamp config push 불안정 → 정적 config 직접 구동 우회 필요(STK-OBS-04 발견) | 4개 경량 컨테이너, 무이슈 기동 | Grafana |
| 단일 UI 경험(trace→log→metric) | 단일 앱에서 자연 연결 (APM UX 우수) | Tempo·Prometheus·Loki 3 데이터소스를 Grafana가 통합, trace↔log는 링크 설정 필요 | SigNoz |
| 분산 trace 연결 품질 | 동일 (OTLP·W3C) — 4서비스+Kafka consume 단일 trace 확인 | 동일 | 동률 |
| Spring/Python OTel 계측 호환성 | 동일 (벤더 중립 OTel, 백엔드 무관) | 동일 | 동률 |
| 인프라 exporter 커버리지(mysql/kafka/redis) | Collector prometheus receiver 경유 수집 | Prometheus 네이티브 scrape | 동률(Grafana 약간 단순) |
| 대시보드·생태계 성숙도 | 작음(APM 특화) | 압도적(대시보드·커뮤니티) | Grafana |
| dev Grafana Loki 연속성 | 별개 스택 | dev에서 이미 Grafana Loki 사용 → 연속성 | Grafana |
결정 이유
- 로컬 리소스: 개인/로컬 docker 환경에서 SigNoz ~3.6GB는 과대 footprint. Grafana ~0.42GB로 8.5배 경량.
- 운영 단순성: SigNoz는 ClickHouse·Zookeeper·migrator·opamp 의존이 무겁고, 로컬에서 opamp config push가 불안정해 정적 config 우회가 필요했다(실제 PoC 난항). Grafana 스택은 4개 경량 컨테이너로 무이슈 기동.
- 생태계·연속성: Grafana 대시보드 생태계가 압도적이고, dev 환경에서 이미 Grafana Loki를 쓰고 있어 연속성이 높다.
- SigNoz의 단일 UI(trace↔log↔metric 자연 연결) UX는 분명한 강점이나, 로컬/개인 프로젝트 규모에선 위 비용을 상쇄하지 못한다.
- 벤더 중립 OTel 계측이라 추후 규모가 커져 SigNoz의 통합 UX가 필요해지면 Collector exporter만 바꿔 서비스 코드 변경 없이 재전환 가능하다.
결정(2026-06-21): 당분간 양 스택 병행 운영한다. Grafana는 경량 상시 운영, SigNoz는 단일 UI(APM) UX를 함께 활용·비교하기 위해 유지. 추후 단일 스택으로 정리할 경우 권고는 Grafana(메모리 8.5배 경량)이며, SigNoz 정리 시
docker compose -f docker-compose.signoz.yml down -v로 ~3.6GB 회수.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| Elastic APM(ELK) | 로컬 docker에서 Elasticsearch 메모리 부담(2GB+)이 가장 크고, OTLP 변환 레이어 추가 필요. 후보에서 제외하고 SigNoz·Grafana 2종만 PoC |
| 둘 다 운영 유지 | 로컬 단일 머신에 두 스택 상시 운영은 리소스 낭비. PoC 후 1개로 정리 |
트레이드 오프
- (득) 벤더 중립 계측(OTel)이라 어느 쪽을 골라도 서비스 코드 변경 없이 백엔드만 교체 가능.
- (실) PoC 기간 동안 두 스택을 동시 운영하는 로컬 리소스 비용 발생.