옵저버빌리티 백엔드 스택 선택 (SigNoz vs Grafana LGTM)
상태
제안 — PoC 비교(STK-OBS-11) 후 최종 확정. 본 ADR은 비교 축과 절차를 고정하고, 결과 측정값으로 ## 결정을 채운다.
후보군
| 방안 | 설명 |
|---|
| 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. 로컬 메모리 부담 가장 큼 |
결정
PoC 후 확정 (미정). 두 스택을 동일 텔레메트리로 띄워 아래 평가 축으로 측정한다.
| 평가 축 | SigNoz | Grafana LGTM |
|---|
| 단일 UI 경험(trace→log→metric 연결) | (측정) | (측정) |
| 분산 trace 연결 품질 | (측정) | (측정) |
| Spring/Python OTel 계측 호환성 | (측정) | (측정) |
| 인프라 exporter 커버리지(mysql/kafka/redis) | (측정) | (측정) |
| 로컬 리소스(메모리) | (측정) | (측정) |
| 대시보드·생태계 성숙도 | (측정) | (측정) |
| dev Grafana Loki 연속성 | (측정) | (측정) |
결정 이유
검토 대안
| 방안 | 기각 이유 |
|---|
| Elastic APM(ELK) | 로컬 docker에서 Elasticsearch 메모리 부담(2GB+)이 가장 크고, OTLP 변환 레이어 추가 필요. 후보에서 제외하고 SigNoz·Grafana 2종만 PoC |
| 둘 다 운영 유지 | 로컬 단일 머신에 두 스택 상시 운영은 리소스 낭비. PoC 후 1개로 정리 |
트레이드 오프
- (득) 벤더 중립 계측(OTel)이라 어느 쪽을 골라도 서비스 코드 변경 없이 백엔드만 교체 가능.
- (실) PoC 기간 동안 두 스택을 동시 운영하는 로컬 리소스 비용 발생.