인프라 메트릭 수집 방식 선택 (exporter + scrape)
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| 전용 exporter + Prometheus scrape | mysqld-exporter·kafka-exporter·redis-exporter가 /metrics 노출, Prometheus·Collector가 scrape |
| Collector receiver 직접 수집 | Collector의 mysql/redis receiver로 직접 폴링 |
| 앱 코드에서 인프라 메트릭 노출 | 애플리케이션이 인프라 상태를 측정해 메트릭화 |
결정
인프라 3종은 표준 exporter + Prometheus scrape로 수집한다. Collector의 prometheus receiver가 같은 exporter를 scrape해 SigNoz로도 전달한다.
결정 이유
- mysqld/kafka/redis exporter는 사실상 표준이며 메트릭 커버리지가 넓다(커넥션·consumer lag·메모리 등).
- exporter는 인프라와 독립 컨테이너라 앱·인프라 코드를 건드리지 않는다.
- 한 exporter를 Prometheus(Grafana 측)와 Collector(SigNoz 측)가 동시에 scrape → 두 스택 동일 인프라 메트릭 확보.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| Collector receiver 직접 수집 | receiver 종류·성숙도가 exporter보다 제한적, 커버리지 부족 |
| 앱 코드에서 노출 | 인프라 관심사를 앱에 침투시킴, 책임 분리 위반 |
트레이드 오프
- (득) 표준·넓은 커버리지, 인프라/앱 비침투, 두 스택 공통 수집.
- (실) exporter 컨테이너 3개 추가로 compose 구성·포트 관리 증가.