메트릭은 당겨야 할까, 밀어야 할까: Pull과 Push 수집 방식 비교

메트릭을 모으는 방법은 크게 두 방향으로 설명할 수 있습니다.

Pull: 수집기가 대상에 접속해 메트릭을 가져온다.
Push: 대상이나 에이전트가 수집기로 메트릭을 보낸다.

Prometheus의 /metrics scrape는 Pull을 대표합니다. 애플리케이션이나 exporter가 메트릭 엔드포인트를 열어두면 Prometheus가 주기적으로 접속합니다. OpenTelemetry SDK가 OTLP로 Collector에 메트릭을 내보내는 구성은 Push를 대표합니다. 여기서 Pull은 대상이 수동적으로 노출한다는 뜻이지, 수집까지 수동이라는 뜻은 아닙니다. 실제 연결과 수집은 Prometheus가 능동적으로 수행합니다.

설명만 보면 Push가 더 현대적으로 느껴질 수 있습니다. 서비스가 생길 때 알아서 데이터를 보내고, 중앙 Collector를 수평 확장하면 될 것처럼 보입니다. 반대로 Kubernetes에서는 ServiceMonitor 하나로 Pod를 발견하는 Prometheus 구성이 훨씬 단순할 때도 많습니다.

그래서 “어느 쪽이 더 최신인가”만으로 선택하면 중요한 운영 차이를 놓치기 쉽습니다.

이 글에서는 두 방식을 다음 기준으로 비교합니다.

개발자와 플랫폼 운영자의 편의성
수집 대상과 데이터 양이 늘어날 때의 확장 방식
수집기나 백엔드가 멈췄을 때의 실패 처리
Kubernetes와 클라우드 네이티브 환경에서의 구성
Prometheus와 OpenTelemetry가 함께 쓰이는 최근 흐름

먼저 결론부터 말하면 Pull과 Push의 가장 큰 차이는 화살표 방향이 아닙니다.

수집 실패를 누가 발견하는가?
누가 재시도하고 버퍼링하는가?
사라진 대상을 누가 판단하는가?

이 책임이 어느 쪽에 놓이는지가 핵심입니다.

촘촘하게 모이는 직조와 바깥으로 펼쳐지는 자수 선이 한 화면에서 만나는 섬유 작품 — 메트릭을 당기거나 미는 두 방향은 서로 다른 운영 책임을 한 시스템 안에서 엮습니다.

비교 전에 세 층을 나누자

Prometheus와 OTLP를 바로 비교하면 서로 다른 층의 개념이 섞입니다. 메트릭 시스템은 적어도 다음 세 층으로 나눠보는 편이 좋습니다.

계측: 애플리케이션이 무엇을 측정하는가
수집: 누가 연결을 시작하고 데이터를 옮기는가
저장: 어느 백엔드가 시계열을 보관하고 질의하는가

Prometheus client library를 쓴다고 반드시 로컬 Prometheus에만 저장해야 하는 것은 아닙니다. Prometheus는 대상을 scrape한 뒤 Remote Write로 장기 저장 백엔드에 보낼 수 있습니다.

OpenTelemetry SDK도 반드시 특정 벤더의 백엔드로 직접 보내야 하는 것은 아닙니다. OTLP로 Collector에 보낸 뒤 Prometheus Remote Write로 변환하거나, Prometheus-compatible 백엔드로 내보낼 수 있습니다.

현재 Prometheus는 OTLP/HTTP metrics receiver도 제공합니다. 반대로 OpenTelemetry Collector에는 Prometheus receiver가 있어 기존 /metrics 엔드포인트를 scrape할 수 있습니다. 어느 제품을 저장소로 쓰는지와 어느 방향으로 수집하는지는 별개의 선택입니다.

따라서 실제 선택은 다음처럼 묻는 편이 정확합니다.

이 수집 경계에서는 Pull과 Push 중 무엇이 더 적합한가?

한눈에 비교하기

기준	Pull: Prometheus scrape	Push: OTLP export
연결 시작	수집기가 대상에 연결	SDK 또는 Agent가 수신기에 연결
개발 시작	`/metrics` 엔드포인트와 scrape 설정	SDK·Agent와 OTLP 엔드포인트 설정
중앙 통제	주기, 타임아웃, 대상, 샘플 한도를 수집기에서 관리	Collector에서 배치, 필터링, 라우팅, 재시도 정책 관리
대상 발견과 식별	서비스 디스커버리의 대상·레이블을 사용	고정 수신 주소와 resource attribute를 사용
실패 감지	scrape 성공 여부와 `up` 시계열을 자동 생성	exporter 오류와 데이터 부재를 별도로 관찰
백엔드 장애	대상에 거의 영향을 주지 않음	큐, 재시도, 폐기, 역압력 정책 필요
짧은 작업	scrape 전에 종료될 수 있음	종료 전 flush할 수 있지만 전달 보장은 별도 설계 필요
네트워크	수집기에서 대상으로 접근 가능해야 함	일반적으로 워크로드의 outbound 연결만 필요
여러 신호	metrics 중심	metrics, traces, logs를 공통 경로로 전송 가능
수평 확장	대상 sharding과 수집기 복제	수신기와 gateway 확장, writer 식별자 관리
원본 확인	엔드포인트를 직접 열어보기 쉬움	전송 파이프라인 단계별 점검 필요

이 표에서 어느 한 열이 항상 우월하지는 않습니다. 애플리케이션 개발자에게 편한 방식과 플랫폼 팀이 운영하기 편한 방식도 다를 수 있습니다.

Prometheus가 왼쪽으로 scrape 요청을 보내고 오른쪽으로 메트릭 응답을 받는 Pull과 애플리케이션이 오른쪽 Collector로 OTLP 배치를 보내는 Push 비교도 — Pull은 요청과 메트릭 응답이 반대 방향으로 움직이고, Push는 송신 측이 메트릭 배치를 수신기로 보냅니다. 이 차이가 discovery, 전달, 실패 처리 책임의 위치를 바꿉니다.

Pull은 수집 책임을 중앙에 둔다

Pull 구성에서 애플리케이션의 역할은 비교적 단순합니다.

요청이 오면 현재 메트릭 값을 노출한다.

언제 가져갈지, 얼마나 자주 가져갈지, 실패했을 때 언제 다시 시도할지는 Prometheus가 결정합니다. 애플리케이션은 최종 저장소 주소나 인증 정보를 알 필요가 없습니다. 대신 scrape 요청을 제때 처리할 수 있어야 하며, 메트릭을 노출하는 과정에서 무거운 계산이나 외부 호출을 수행하면 scrape 자체가 새로운 부하가 될 수 있습니다.

대표 구성은 다음과 같습니다.

Application / Exporter
        ↑ scrape
Prometheus
        ↓ optional remote write
Long-term Storage

Prometheus는 scrape할 때 job과 instance 레이블을 붙이고, up, scrape_duration_seconds, scrape_samples_scraped 같은 시계열을 자동으로 만듭니다. 여기서 up=0은 비즈니스 기능 전체가 죽었다는 뜻이 아니라 Prometheus가 해당 엔드포인트를 성공적으로 scrape하지 못했다는 뜻입니다. 그래도 “메트릭을 가져올 수 있는가”를 별도 계측 없이 확인할 수 있다는 장점은 큽니다.

원본을 확인하기도 쉽습니다.

curl -s http://application:8080/metrics

대시보드가 비어 있을 때 엔드포인트, 서비스 디스커버리, relabeling, 저장 순서로 범위를 좁힐 수 있습니다.

Pull의 편의성은 중앙 설정에서 나온다

수집 주기를 15초에서 30초로 바꾸거나 특정 레이블을 제거해야 할 때 애플리케이션을 다시 배포하지 않고 Prometheus 설정을 바꿀 수 있습니다. 수집 대상의 샘플 수나 응답 크기가 갑자기 늘어날 때도 수집기 쪽에서 제한을 둘 수 있습니다.

이 구조는 조직 내 서비스가 많을수록 편리합니다. 각 서비스가 서로 다른 백엔드 인증 정보, 큐 정책, 재시도 설정을 들고 있지 않아도 됩니다.

반면 Prometheus가 대상에 접근할 수 있어야 합니다. 망이 분리됐거나 NAT 뒤에 있는 대상, 외부 고객 환경에 설치된 agent, 매우 짧게 실행되는 작업은 중앙 scrape가 어색할 수 있습니다.

또한 Prometheus가 멈춘 동안 대상이 과거 샘플을 보관해주는 것은 아닙니다. scrape하지 못한 시점의 gauge 값이나 짧은 변화는 일반적으로 나중에 되가져올 수 없습니다. 다만 프로세스가 계속 살아 있고 누적 counter가 reset되지 않았다면, 장애 중 증가한 총량은 다음 scrape 값에 반영되어 rate 계산에 일부 남을 수 있습니다. 애플리케이션이 수집기 장애의 영향을 받지 않는 대신, 샘플 해상도와 일시적인 상태 변화는 잃을 수 있다는 뜻입니다.

Push는 전송 책임을 송신 측으로 옮긴다

Push 구성에서는 애플리케이션 SDK나 가까운 Agent가 주기적으로 메트릭 배치를 만들고 OTLP 수신기로 전송합니다.

가장 단순한 구성은 다음과 같습니다.

Application SDK
        ↓ OTLP
Observability Backend

개발 환경에서는 간단하지만, 서비스가 최종 백엔드 엔드포인트와 인증 방식에 직접 결합합니다. 운영 환경에서는 보통 Collector를 사이에 둡니다.

Application SDK
        ↓ OTLP
Local Agent / Sidecar Collector
        ↓ OTLP
Gateway Collector
        ↓
One or More Backends

애플리케이션은 가까운 Collector에 빠르게 넘기고, Collector가 배치, 재시도, 필터링, resource attribute 보강과 백엔드 라우팅을 맡습니다.

예를 들어 애플리케이션은 환경변수만으로 OTLP/HTTP 엔드포인트를 지정할 수 있습니다.

export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-agent:4318
export OTEL_SERVICE_NAME=checkout-api
export OTEL_RESOURCE_ATTRIBUTES=deployment.environment.name=production

Collector는 OTLP를 받아 다음 Collector나 백엔드로 전달합니다.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 15
  batch: {}

exporters:
  otlphttp/backend:
    endpoint: https://telemetry.example.com

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/backend]

실제 운영에서는 TLS, 인증 헤더, 큐 크기와 재시도 정책을 함께 정해야 합니다. 아래 예시는 파이프라인 형태만 보여주므로, 그대로 인터넷에 노출할 수 있는 보안 구성은 아닙니다.

Push의 편의성은 고정된 진입점에서 나온다

Push에서는 수집기가 모든 Pod 주소를 찾아다닐 필요가 없습니다. 새 Pod가 뜨면 같은 Collector service로 보내면 됩니다. 외부 백엔드가 바뀌어도 애플리케이션이 아니라 Collector 설정만 바꿀 수 있습니다.

특히 trace와 log도 OpenTelemetry로 다룬다면 하나의 SDK 구성과 Collector 파이프라인을 공유할 수 있습니다. 애플리케이션 계측 표준화라는 관점에서는 큰 장점입니다.

대상 discovery가 사라지는 대신 식별 책임은 송신 데이터로 이동합니다. service.name, service.instance.id와 Kubernetes resource attribute가 부정확하면 서로 다른 Pod의 시계열이 합쳐지거나, 재시작한 인스턴스가 같은 writer처럼 보일 수 있습니다. 고정된 수신 주소만 준비하면 끝나는 것은 아닙니다.

하지만 데이터 전송에 실패했을 때의 책임이 생깁니다.

얼마나 오래 재시도할 것인가
메모리 큐가 가득 차면 무엇을 버릴 것인가
디스크 큐가 필요한가
애플리케이션 종료 때 flush를 얼마나 기다릴 것인가
Collector 장애가 애플리케이션 자원 사용량에 영향을 주지 않는가

무한히 안전한 큐는 없습니다. 백엔드 장애가 충분히 길어지면 결국 데이터를 버리거나 디스크를 계속 사용하거나 송신 측을 느리게 해야 합니다. OTLP exporter는 일시 오류를 재시도할 수 있지만, 실제로 얼마나 버퍼링하는지는 SDK와 Collector 구성에 달려 있습니다. 따라서 Push는 장애 구간을 일부 흡수할 수 있지만, 자동으로 무손실을 보장하는 방식은 아닙니다.

확장성은 fan-out과 fan-in의 차이다

Pull은 수집기가 많은 대상으로 연결하는 fan-out 구조입니다.

Prometheus 1개
→ 수백 또는 수천 대상
→ 대상마다 주기적인 scrape

대상이 늘면 서비스 디스커버리, 동시 연결, scrape 응답 크기, 활성 시계열 수가 함께 늘어납니다. 단일 Prometheus의 용량을 넘으면 대상을 여러 shard에 나눕니다. 고가용성을 위해 같은 대상을 두 Prometheus가 각각 scrape하는 구성도 흔합니다. 이 경우 저장되는 두 시계열을 전체 질의 계층에서 구분하거나 중복 제거할 기준도 필요합니다.

이 방식은 각 대상이 독립적이라는 장점이 있습니다. 한 exporter가 느려도 타임아웃 범위 안에서 해당 대상 문제로 격리하기 쉽습니다. 반면 shard가 나뉘면 전체 질의와 rule 평가를 위해 Thanos 같은 질의 계층이나 중앙 Remote Write 백엔드가 필요할 수 있습니다.

Push는 많은 송신자가 적은 수의 수신기로 모이는 fan-in 구조입니다.

수백 또는 수천 송신자
→ Collector gateway pool
→ 백엔드

수신기를 load balancer 뒤에서 수평 확장하기 쉬워 보이지만 메트릭에는 고유한 주의점이 있습니다. 같은 시계열을 여러 writer가 동시에 보내면 중복, reset 해석 오류, out-of-order sample이 생길 수 있습니다. service.instance.id 같은 resource identity와 metric stream의 single-writer 경계를 안정적으로 유지해야 합니다.

Collector가 상태를 가진 processor를 사용한다면 아무 gateway로 보내도 되는지 따져야 합니다. 수평 확장은 Pod 수만 늘리는 문제가 아니라 시계열 식별자와 처리 상태를 어디에 둘지 정하는 문제입니다.

Kubernetes에서는 둘 다 클라우드 네이티브하다

Push가 Pull보다 무조건 Kubernetes 친화적이라는 설명은 정확하지 않습니다. 두 방식 모두 Kubernetes의 다른 특성과 잘 맞습니다.

Pull과 Kubernetes 서비스 디스커버리

Prometheus Operator를 사용하면 ServiceMonitor나 PodMonitor로 수집 대상을 선언할 수 있습니다. 아래 ServiceMonitor의 selector는 Pod가 아니라 app: checkout-api 레이블을 가진 Service를 선택하며, 그 Service가 가리키는 Pod 엔드포인트가 실제 scrape 대상이 됩니다.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: checkout-api
  labels:
    team: commerce
spec:
  selector:
    matchLabels:
      app: checkout-api
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

새 Pod가 생기거나 사라질 때 Kubernetes 레이블과 서비스 디스커버리가 대상 목록에 반영됩니다. 애플리케이션 Pod에는 백엔드 주소나 인증 정보가 필요하지 않습니다.

이 방식은 다음 대상에 특히 잘 맞습니다.

장기 실행되는 Deployment와 StatefulSet
node exporter, kube-state-metrics 같은 인프라 exporter
Kafka, Redis, PostgreSQL처럼 exporter 생태계가 성숙한 시스템
엔드포인트 도달 가능성과 수집 상태를 함께 보고 싶은 대상

Push와 Kubernetes Agent/Gateway

애플리케이션이 OTLP를 보내는 경로는 DaemonSet Agent와 Deployment Gateway 구성에 잘 맞습니다.

각 Node: DaemonSet Collector
각 Cluster: Gateway Collector Deployment
각 Region: 중앙 ingest 또는 장기 저장 백엔드

DaemonSet Collector는 같은 node의 애플리케이션이 보내는 telemetry를 받고 host·kubelet·container 관련 데이터를 보강할 수 있습니다. 필요하면 kubeletstats나 Prometheus receiver를 통해 데이터를 직접 Pull하기도 합니다. 즉 Collector를 도입한다고 모든 수집 경로가 Push로 바뀌는 것은 아닙니다. Gateway는 인증, 필터링, 라우팅 같은 공통 정책을 맡습니다.

이 방식은 다음 상황에서 유리합니다.

애플리케이션 metric, trace, log를 함께 수집할 때
auto-instrumentation을 플랫폼 표준으로 적용할 때
워크로드에서 외부로 나가는 연결만 허용할 때
여러 cluster나 고객 환경에서 고정된 ingest 엔드포인트로 보낼 때
백엔드를 바꾸거나 여러 백엔드로 분기할 가능성이 클 때

대신 Collector도 모니터링해야 하는 운영 대상이 됩니다. CPU와 memory, 큐 사용량, 거부·유실된 telemetry, export 실패와 백엔드 latency를 확인해야 합니다.

짧게 실행되는 작업은 Push가 항상 답일까

짧은 배치 작업과 serverless 워크로드는 Pull의 약점이 잘 드러나는 영역입니다. 15초마다 scrape하는데 작업이 3초 만에 끝나면 Prometheus가 한 번도 보지 못할 수 있습니다.

Push는 종료 전에 마지막 배치를 flush할 수 있으므로 더 자연스럽습니다. 하지만 process가 강제 종료되거나 네트워크가 끊기면 마지막 데이터가 전달되지 않을 수 있습니다. 종료 hook 하나로 전달 보장이 생기는 것은 아닙니다. 업무적으로 반드시 남아야 하는 실행 결과라면 메트릭 전송과 별개로 durable job state나 event 기록도 필요합니다.

Prometheus Pushgateway도 이 문제와 관련해 자주 언급되지만, 일반 서비스의 Push 수집기로 보면 안 됩니다. Pushgateway는 scrape하기 어려운 제한된 서비스 단위 배치 작업의 결과를 보존하는 예외적인 도구에 가깝습니다. instance별 데이터의 생명주기를 직접 정리하지 않으면 종료된 작업의 시계열이 계속 남을 수 있고, 원래 대상을 직접 scrape할 때 얻던 up 신호도 잃게 됩니다.

최근 흐름은 Push가 Pull을 없애는 것이 아니다

애플리케이션 계측에서는 OpenTelemetry와 OTLP의 적용 범위가 넓어지고 있습니다. metric만이 아니라 trace와 log에 같은 resource identity와 전송 경로를 적용할 수 있고, 백엔드에 종속되지 않은 계측 API를 사용할 수 있기 때문입니다.

그렇다고 Prometheus scrape가 과거 방식이 된 것은 아닙니다. Kubernetes와 인프라 영역에는 이미 많은 /metrics 엔드포인트, exporter, ServiceMonitor, alert rule이 존재합니다. 대상 발견과 scrape 성공 여부를 중앙에서 관리하는 모델도 여전히 실용적입니다.

두 생태계는 오히려 서로의 수집 방식을 받아들이고 있습니다.

OpenTelemetry Collector의 Prometheus receiver는 기존 엔드포인트를 scrape합니다.
OpenTelemetry Operator의 Target Allocator는 Prometheus target을 Collector 사이에 분배할 수 있습니다.
Prometheus는 OTLP/HTTP metrics receiver를 활성화해 OTLP Push를 직접 받을 수 있습니다. 이 receiver는 기본적으로 비활성화되어 있으며, 인증 없이 외부에 노출하지 않도록 별도 보안 경계를 두어야 합니다.
Collector는 OTLP metrics를 Prometheus Remote Write로 내보낼 수 있습니다.

그래서 실제 플랫폼에서는 exporter를 Pull하고 애플리케이션 telemetry를 OTLP로 Push한 뒤 같은 메트릭 백엔드와 운영 문맥으로 연결하는 혼합 구성이 자연스럽습니다.

Kubernetes의 Pull 경로는 Prometheus가 인프라에 scrape 요청을 보내고 메트릭 응답을 받은 뒤 백엔드로 전달하며 Push 경로는 애플리케이션 Pod가 OTLP 배치를 Collector와 같은 백엔드로 보내는 구성도 — Pull과 Push는 조직 전체의 단일 선택이 아닙니다. 대상과 네트워크 경계에 맞게 나누고 같은 저장·질의 계층에서 연결할 수 있습니다.

Pull과 Push는 조직 전체에서 하나만 골라야 하는 전역 설정이 아닙니다. 수집 대상과 네트워크 경계마다 선택할 수 있습니다. “인프라는 Pull, 애플리케이션은 Push”도 유용한 출발점일 뿐 절대 규칙은 아닙니다.

상황별 선택 기준

Pull을 먼저 검토할 상황:

안정적으로 실행되는 서비스나 인프라 대상이다.
이미 검증된 Prometheus exporter가 있다.
엔드포인트 도달 가능성과 scrape 실패를 직접 감지하고 싶다.
수집 주기, 타임아웃과 레이블 정책을 중앙에서 통제하고 싶다.
애플리케이션에 백엔드 주소, 인증 정보, 재시도 큐를 넣고 싶지 않다.

Push를 먼저 검토할 상황:

워크로드가 짧게 실행되거나 중앙에서 접근할 수 없는 네트워크에 있다.
중앙 수집기에서 대상으로 접근하기 어렵고 outbound만 허용된다.
metric, trace, log를 같은 계측 체계로 보내고 싶다.
Collector에서 필터링, 보강, 라우팅과 백엔드 전환을 관리하고 싶다.
export 큐와 재시도를 운영할 준비가 되어 있다.

혼합 구성을 검토할 상황:

Kubernetes와 인프라는 Prometheus 생태계를 이미 사용하고 있다.
새 애플리케이션은 OpenTelemetry로 표준화하려 한다.
기존 exporter를 다시 계측하지 않고 OTLP 파이프라인과 연결하고 싶다.
하나의 백엔드 또는 운영 화면에서 두 경로를 함께 조회해야 한다.

운영 전에 확인할 체크리스트

[ ] 누가 수집 연결을 시작하는가
[ ] 대상 또는 송신자 식별자는 재시작 후에도 올바르게 구분되는가
[ ] 수집기나 백엔드가 멈추면 어디에 얼마나 버퍼링되는가
[ ] 큐가 가득 차면 어떤 데이터가 버려지는가
[ ] 데이터가 오지 않을 때 대상 장애와 수집 경로 장애를 구분할 수 있는가
[ ] 중복 writer와 중복 scrape를 막거나 의도적으로 처리했는가
[ ] 수집 주기와 export 주기가 실제 탐지 목표에 맞는가
[ ] 인증 정보와 TLS 책임이 어느 계층에 있는가
[ ] Collector와 Prometheus 자체를 별도로 모니터링하는가
[ ] 장기 저장과 전체 질의는 어느 계층이 담당하는가

메트릭 수집 방식은 엔드포인트 모양을 고르는 문제가 아닙니다. 운영 실패의 책임을 어디에 둘지 정하는 아키텍처 선택입니다.

Pull은 대상을 단순하게 만들고 중앙 수집기가 발견과 실패 감지를 책임집니다. Push는 네트워크 경계를 넘고 여러 telemetry 신호를 통합하기 쉽지만 송신 측과 Collector가 전송 신뢰성을 책임져야 합니다.

메트릭은 수집 자체보다 어떤 운영 대상으로부터 온 신호인지 식별하고, 대시보드와 알림에서 같은 문맥으로 해석하는 일이 중요합니다. Konduo는 Prometheus-compatible metric source와 리소스 플러그인을 연결해 Redis, Kafka, PostgreSQL 같은 대상의 메트릭을 같은 운영 문맥에서 읽도록 설계되어 있습니다.

최신 구성은 한 방향을 고집하기보다 경계를 나눕니다.

인프라와 exporter에는 Pull,
애플리케이션 telemetry에는 Push,
운영 화면에서는 다시 하나의 문맥으로 연결한다.

참고 자료

함께 읽기 좋은 글

JVM 메트릭만으로는 컨테이너를 설명할 수 없다 - 애플리케이션 내부와 실행 환경의 메트릭을 어떤 경계에서 수집할지 살펴봅니다.
Kafka Client Metrics는 관측의 빈틈을 메울 수 있을까 - 클라이언트가 원격으로 메트릭을 보내는 구조와 운영상 한계를 다룹니다.
Konduo Community를 Docker Compose로 10분 안에 시작하기 - Prometheus scrape와 remote write receiver가 함께 쓰이는 실제 구성을 보여줍니다.