ADR-002 메트릭 수집 = Prometheus 직접 scrape, trace·log만 Collector

• 상태: 채택
• 날짜: 2026-07-03
• 근거: PRD FR-1, FR-3, FR-4 / TDD “Possible Solutions — 메트릭 수집 경로”

맥락

FR-3은 “단일 Collector가 trace→Tempo·metric→Prometheus·log→Loki 라우팅”을 명시하고, 동시에 FR-1은 “/actuator/prometheus 엔드포인트 재사용”을, FR-4는 “Prometheus가 exporter 메트릭을 수집”을 명시한다. 앱·exporter 메트릭을 Collector로 밀지, Prometheus가 직접 당길지 결정이 필요하다.

결정

• 메트릭 주 경로 = Prometheus 직접 scrape: 앱 /actuator/prometheus·exporter 3종 /metrics·Collector self :8888·Prometheus self를 Prometheus가 pull한다.
• trace·log = OTel Collector: 앱이 OTLP로 Collector에 발신 → Collector가 trace→Tempo·log→Loki 라우팅.
• Collector→Prometheus remote_write 경로는 열어둠: Collector가 OTLP로 받은 소량 메트릭·exemplar를 prometheusremotewrite로 넘겨 FR-3 문구를 충족하되, 주 메트릭 경로는 아니다.

근거

1. FR-1 정합 — /actuator/prometheus 재사용은 scrape 모델이 전제. Collector로 push하면 엔드포인트 재사용이 아니라 새 경로가 된다.
2. 장애 격리 — 메트릭(scrape)과 trace(push)를 분리하면 Collector 다운 시에도 메트릭 수집이 계속된다(User Scenario 4의 self-scrape 감지 전제 충족). 단일 경로는 Collector가 메트릭까지 SPOF가 된다.
3. exporter는 본래 scrape 모델 — mysqld/redis/kafka exporter는 /metrics pull이 표준. Collector 경유는 불필요한 홉.

대안 (미채택)

• 모든 텔레메트리를 Collector 단일 경로(OTLP push→remote_write): 아키텍처는 단순하나 Collector SPOF·FR-1 위반. 미채택(단, remote_write 보조 경로만 유지).

영향

• prometheus.yml에 scrape 잡 6종(app·mysqld·redis·kafka·collector·self). env는 relabel로 부여(인프라 exporter) 또는 앱 태그(app) 사용.
• Collector config는 trace/log receiver→exporter + remote_write exporter만.
• ⑦(다중 인스턴스)는 app scrape 잡의 타깃 목록을 확장하면 됨(구조 제공).