IT

[옵저버빌리티] OpenTelemetry(OTel) Collector 완벽 가이드: Metricbeat 286KB 최적화부터 Wazuh·APM·RUM·Heartbeat 대체 비교까지

PONERponix 2026. 11. 12. 00:59

1. 문제 상황: OTel 메트릭 1건이 286KB? Metricbeat와 왜 이렇게 다를까?

호스트 리소스 모니터링을 위해 OpenTelemetry Collector를 구성하고 Kafka로 데이터를 쐈을 때, 메시지 1건의 크기가 무려 286KB에 달해 당황하는 경우가 많습니다. 단건당 0.5KB~2KB에 불과한 Metricbeat와 비교하면 100배가 넘는 수치입니다. 이 현상의 원인과 최적화, 그리고 Observability 아키텍처 관점에서의 도구 비교를 총정리합니다.

2. 286KB 폭증의 3대 원인과 다운사이징 최적화

원인 분석:

  1. processes / process 스크래퍼: OS에서 실행 중인 모든 개별 프로세스의 CPU, 메모리, I/O 지표를 전수 수집하여 수천 개의 데이터 포인트가 발생함.
  2. send_batch_size: 1024: 데이터 포인트 1,024개가 찰 때까지 모아서 하나의 OTLP 요청으로 묶어 발송함.
  3. OTLP JSON 인코딩: 라벨과 메타데이터가 텍스트로 중복 포함되어 페이로드 덩치가 비대해짐.

최적화된 collector.yaml 설정 (2~5KB 다운사이징):

receivers:
  hostmetrics:
    collection_interval: 60s
    scrapers:
      cpu:
      memory:
      disk:
      filesystem:
        exclude_mount_points:
          mount_points: ["/dev.*", "/proc.*", "/sys.*"]
          match_type: regexp
      network:
      load:
      # [핵심 1] 비대한 process/processes 스크래퍼 제거

processors:
  batch:
    timeout: 5s
    # [핵심 2] 한 메시지에 담기는 배치 크기를 줄여 Kafka 레코드 단건 크기 축소
    send_batch_size: 50
    send_batch_max_size: 100

exporters:
  kafka:
    brokers: ["1.234.25.136:13100"]
    metrics:
      topic: "metrics"
      # [핵심 3] otlp_proto 사용 시 바이너리 압축으로 직렬화 크기 70% 이상 절감
      encoding: otlp_json

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      processors: [batch]
      exporters: [kafka]

3. Wazuh vs OpenTelemetry: 대체 가능한가?

결론: 대체 불가능하며, 상호 보완적인 도구입니다.

비교 항목 OpenTelemetry (OTel) Wazuh Agent
핵심 도메인 Observability (성능, 메트릭, 트레이싱) Security / XDR / SIEM (보안 침해, 규정 준수)
특화 기능 APM, 분산 트레이싱, 리소스 수집, RUM FIM (파일 무결성 검사), SCA 취약점 진단, Active Response(IP 차단)
로그 분석 질문 "시스템 성능이 정상이고 장애가 없는가?" "악성코드나 비인가 침입이 발생하지 않았는가?"

4. APM, RUM, Heartbeat(Uptime)의 OTel 일원화

  • APM Agent 대체: Java/Python/Node.js는 소스 코드 수정 없이 -javaagent:opentelemetry-javaagent.jar 옵션만으로 자동 계측(Auto-Instrumentation)이 가능하며, Datadog/Pinpoint 종속성을 완전히 탈피합니다.
  • RUM (Real User Monitoring): 프론트엔드 웹페이지 헤더에 OTel JS SDK를 삽입하면 브라우저 Core Web Vitals 및 AJAX 호출이 서버 백엔드 트레이스와 W3C traceparent로 자동 연결되어 진정한 End-to-End 추적이 완성됩니다.
  • Elastic Heartbeat 대체: OTel Contrib의 httpcheckreceiver, pingreceiver, tcpportreceiver를 사용하면 별도의 Uptime 에이전트 없이 OTel Collector 단일 프로세스로 서비스 생존 및 SSL 인증서 만료 감시를 일원화할 수 있습니다.