Kubernetes 환경 OpenTelemetry Collector 로그 파이프라인의 내결함성 강화 전략 by 딥리서치

 

Kubernetes에서 OpenTelemetry Collector를 이용해 로그 데이터를 수집하고 ClickHouse로 내보낼 때, 각 단계(Receiver, Processor, Exporter)에서 장애가 발생해도 데이터 유실 없이 재처리할 수 있도록 설계해야 합니다. 아래에서는 수집(Receiver), 처리(Processor), 내보내기(Exporter) 각 컴포넌트별 장애 복구 전략과 설정 방법을 정리합니다. 또한 ClickHouse로 로그를 안정적으로 전송하기 위한 ClickHouse exporter 구성 및 모범 사례와, 필요한 경우 Sidecar, Persistent Volume, 외부 메시지 큐 연계 방안을 함께 다룹니다.

 

 

Receiver 단계 – 로그 수집의 신뢰성 확보

 

1. 파일 로그 수집(Filelog Receiver)의 상태 저장:

Kubernetes 환경에서 컨테이너 로그는 노드의 파일(예: /var/log/containers/...log)로 저장됩니다. OpenTelemetry의 filelog receiver를 사용해 이러한 로그를 읽는 경우, **현재 읽은 위치(offset)**를 디스크에 저장하여 Collector 재시작 후에도 이전에 읽던 지점부터 이어서 수집할 수 있습니다. 이를 위해 filelog 리시버 설정에 storage 옵션을 지정하고 file_storage 확장(파일 기반 저장소)을 사용합니다. 예를 들어:

extensions:
  file_storage:
    directory: /var/otelcol/data  # 오프셋 등의 상태를 저장할 경로 (빈디렉터리/퍼시스턴트 볼륨에 마운트)

receivers:
  filelog/mylogs:
    include: [/var/log/containers/*\.log]  # 수집할 로그 파일 경로 패턴
    start_at: beginning            # (필요시) 처음부터 또는 끝부터 읽기 설정
    storage: file_storage          # 상태를 저장할 storage 확장 지정
    include_file_path_resolved: true

service:
  pipelines:
    logs:
      receivers: [filelog/mylogs]
      ...      

위와 같이 설정하면 filelog 수집기는 **파일 경로와 오프셋 정보를 file_storage**를 통해 주기적으로 디스크에 기록합니다. Collector가 재시작되더라도 마지막으로 읽은 위치를 기억하여 같은 데이터를 중복 읽지 않으며(중복 수집 방지) , 중단 지점부터 로그 수집을 재개할 수 있습니다.

 

• Persistent Volume 마운트: file_storage가 데이터를 로컬 디스크에 기록하므로, Collector Pod에 EmptyDir 또는 PersistentVolume을 마운트하여 이 디렉토리가 Pod 재시작/재배포 시에도 유지되도록 하는 것이 좋습니다. EmptyDir의 경우 Pod가 재배포되면 사라지지만 컨테이너 충돌 후 재시작 시에는 유지되므로 일시적 장애 복구에는 도움이 됩니다. 완벽한 연속성을 원한다면 HostPath나 PVC 같은 노드 단위 영구 볼륨을 활용해 file_storage.directory를 마운트하여, DaemonSet으로 동작하는 수집 에이전트가 재시작되거나 업그레이드되어 새 Pod가 뜨더라도 이전 상태 파일을 이어서 사용할 수 있게 설계할 수 있습니다.
• 로그 로테이션 대응: Kubernetes 기본 kubelet 설정에서는 컨테이너 로그가 10MB 단위로 로테이션됩니다 . Collector나 에이전트가 일시 중단된 동안 로그 파일이 회전(rotated)되어 삭제되면 해당 기간 로그가 유실될 수 있습니다. 이를 방지하려면 로그 로테이션 정책을 완화하여 파일이 너무 빨리 교체되지 않도록 합니다 . 예를 들어 로그 파일 최대 크기와 보존 파일 수를 늘려서, Collector가 재가동되기 전까지 원본 로그 파일이 유지되도록 설정하는 것이 권장됩니다. Splunk의 OTel Collector 가이드라인에 따르면, Kubernetes의 기본 10MB 로테이션은 프로덕션 환경에는 너무 작으므로 보다 큰 크기나 긴 보존 기간으로 조정하는 것이 좋습니다 .
• 수집 지연 시 백프레셔(Backpressure): 로그 수집이 지연되거나 Exporter쪽 문제로 파이프라인이 막힐 경우, 리시버가 너무 앞서 나가서 데이터를 읽고 버리지 않도록 설계해야 합니다. 위의 filelog+storage 구성은 파일의 현재 읽은 위치를 기록하지만, 기본값으로는 Exporter쪽 큐가 가득 찰 때 새로운 로그 데이터를 **드롭(drop)**하기 때문에 여전히 유실 가능성이 있습니다 . 이를 개선하려면 수집 파이프라인에 백프레셔를 적용합니다. OTel Collector의 exporter queue 설정에서 sending_queue.block_on_overflow: true로 설정하면, Exporter 단계의 큐가 꽉 찼을 때 새로운 데이터 수집을 일시 중단하여 대기합니다. 이렇게 하면 리시버(filelog)가 로그 파일의 읽기를 멈추고 대기하므로, 로그 데이터는 원본 파일에 계속 쌓인 채 대기하며 드롭되지 않습니다. (파일은 후段에서 여전히 유지되고 있으므로 안전) 반면 이 모드에서는 막힐 경우 파이프라인이 정체될 수 있으므로, 큐 용량과 다운스트림 복구 시간을 충분히 고려해야 합니다.
• 기타 수집기 유형: 로그 수집은 filelog 외에도 Fluent Forward, Syslog, Journald, Kafka 등 다양한 리시버로 가능하며, 각 특성에 맞는 내결함성을 고려해야 합니다. 예를 들어 Kafka Receiver를 사용하는 경우 Kafka 자체가 로그를 버퍼링/저장하므로 Collector 장애 시에도 데이터가 Kafka에 남아 재처리 가능합니다. 이때 Kafka Consumer 오프셋 커밋을 적절히 관리하여, Exporter까지 완료된 후에만 오프셋을 진행하도록 해야 데이터 유실이 없습니다 (일반적으로 OTel의 Kafka receiver는 배치 처리 후 오프셋 커밋을 처리함으로써 이러한 내결함성을 지원합니다). Journald나 Fluentd/Fluent Bit forward 입력을 쓰는 경우에도, 입력 측 시스템이 자체 버퍼나 ack 메커니즘을 제공하므로 이를 활용합니다. 가능하다면 OTLP 프로토콜로 애플리케이션이 직접 Collector에 로그를 보내는 것보다, 파일 또는 메시지 큐를 중간 버퍼로 사용하는 방안이 신뢰성을 높여줍니다 . (예: 애플리케이션 stdout → 파일로그 + file_storage로 버퍼링)
• Collector 배포 토폴로지: 일반적으로 Kubernetes에서는 로그 수집기(Collector)를 DaemonSet으로 각 노드마다 1개씩 배포하여, 해당 노드의 모든 파드 로그를 수집합니다. DaemonSet으로 운영하면 Collector Pod 장애 시 kubelet이 자동 재시작하며, hostPath를 통해 노드 로그 디렉토리에 접근하고 오프셋 상태도 유지할 수 있습니다. 한편, 사이드카(Sidecar) 패턴도 가능합니다 – 애플리케이션 파드 내부에 Collector를 사이드카로 넣어 해당 파드의 로그만 수집하도록 하는 방법입니다. Sidecar 방식은 Fargate 같은 DaemonSet을 사용할 수 없는 환경에서 활용되며, 각 파드의 로그를 개별 수집하므로 격리도 높지만 오버헤드가 크고 파드 수가 많으면 비효율적입니다 . 사이드카를 쓸 경우 EmptyDir 같은 공유 볼륨을 애플리케이션 컨테이너와 마운트하여, 앱이 그 볼륨에 로그를 쓰고 Collector가 그 파일을 tail 하도록 구성하면 Collector 재시작 또는 일시 중단 시에도 해당 볼륨에 로그가 보존되어 다시 처리할 수 있습니다. (단, 파드 자체가 삭제되면 EmptyDir도 사라지므로, 정말 중요한 로그라면 외부 공유 스토리지에 로그를 쓰는 방식까지 고려해야 합니다.) 일반적으로 DaemonSet + Node 로그파일 수집 구성이 관리 용이성과 내결함성 측면에서 권장되며, 사이드카는 특수한 경우에만 사용됩니다.

 

 

Processor 단계 – 파이프라인 처리 중단 대비

 

Processor 단계에서는 로그를 변환하거나 배치 등 일시적으로 메모리에 보관하는 처리를 합니다. Processor 자체가 장애를 일으키는 경우(예: OOM이나 버그로 Crash) Collector 프로세스가 중단되므로, 이를 직접 복구하기보다는 Collector 재시작 후 데이터를 재처리하는 형태로 대비합니다. Processor 단계의 내결함성은 주로 과부하 방지와 메모리 관리를 통해 구현됩니다:

 

• 배치 처리(Batch Processor): 로그를 효율적으로 내보내기 위해 OTel Collector는 기본적으로 batch processor를 사용하여 일정량 또는 일정 시간 단위로 로그 레코드를 묶어 처리합니다. 배치 크기와 flush 주기를 조절하면 성능과 지연 시간을 튜닝할 수 있지만, 배치가 너무 크거나 flush 주기가 길면 Collector가 중단될 때 배치 내 미전송 로그가 메모리에 남아 유실될 가능성이 커집니다. ClickHouse에 로그를 넣는 경우, 너무 작은 배치는 ClickHouse에 과도한 소량 Insert를 일으켜 성능 문제를 일으킬 수 있고 너무 큰 배치는 지연이 증가합니다 . 권장 값은 약 5초 타임아웃 또는 5000건 정도로 알려져 있으며 , 실제 대규모 환경에서도 약 15,000건 배치를 사용하여 2분 내 데이터 가용성을 달성한 예가 있습니다 . Tip: ClickHouse Exporter의 batch: 설정으로 max_size와 timeout을 조정하고, ClickHouse 서버 측 비동기 Insert를 활성화하면 작은 배치도 ClickHouse가 내부적으로 모아서 처리하므로 안정성과 성능을 모두 높일 수 있습니다 .
• 메모리 제한(Memory Limiter Processor): 로그 량이 폭증하면 Collector가 OOM으로 죽을 수 있습니다. 이를 방지하기 위해 memory_limiter 프로세서를 사용하여 프로세스 메모리 사용량을 모니터링하고 일정 임계치 이상 시 신규 로그를 일시 드롭하거나 (soft limit 시) 또는 **GC를 강제 실행 (hard limit 시)**하여 버텨냅니다 . 메모리 제한은 데이터 유실을 일부 감수하더라도 Collector 프로세스 다운을 막기 위한 것이지만, persistent queue를 사용하면 드롭 대신 디스크로 대기시킬 수 있으므로 가능한 한 Exporter 단계의 영구 큐와 함께 쓰는 것이 좋습니다 (아래 Exporter 단계 참고). Memory Limiter의 soft limit이 발동하면 수집단계에서 데이터를 받지 않고 거부하므로 (일종의 backpressure), 로그 발신 측(파일이면 파일 적채, OTLP면 SDK 큐 등)에 로그가 일시적으로 쌓이게 되어 Collector를 보호합니다 . 메모리 한도는 시스템 메모리의 80% 수준을 soft, 90-95%를 hard로 두는 식으로 설정합니다.
• 필터/변환 프로세서의 오류 처리: 로그를 필터링하거나 변환하는 custom processor가 있을 경우, 가능하면 로직을 안정적으로 (에러 발생 시 기본 동작 유지 등) 구현하고, 오류 발생 시 해당 로그를 건너뛰거나 원본을 그대로 전달하도록 설계합니다. Collector 내장 프로세서들은 비교적 안정적이지만, 만약 특정 프로세서가 로그를 Drop하도록 잘못 설정되었다면 데이터 유실이 발생할 수 있으므로 구성 검증도 중요합니다. 내결함성을 위해서는 불필요한 드롭이나 샘플링을 피하고, 최대한 모든 로그가 최종 Exporter까지 흐르도록 설정합니다. (예: 프로덕션 로그 파이프라인에서는 샘플링을 하지 않는 것이 일반적입니다.)
• 상태 저장 Processor의 복구: 일부 프로세서는 상태를 가질 수 있습니다. 예를 들어 trace용 tail-sampling 프로세서는 일정 시간의 데이터를 모아둔 후 샘플링 결정하는데, 중간에 Collector가 재시작되면 그 모아둔 상태는 잃게 되어 해당 윈도우의 데이터가 처리 안 될 수 있습니다. 로그 파이프라인에서는 이러한 상태ful 프로세서는 드물지만, **집계(Aggregation)**나 지표 변환과 같이 상태를 쌓는 연산이 있다면 짧은 간격으로 flush하거나 또는 persistent storage를 활용해 상태를 저장하는 기능이 있는지 확인해야 합니다. 예컨대 groupbyattrs 같은 프로세서는 단순 그룹화만 하고 즉시 넘기므로 영향이 적습니다.
• Processor 장애 복구: 만약 Processor 단계에서 Collector 프로세스가 크래시 나면 (예: 메모리 부족으로), Kubernetes가 Collector Pod를 재시작합니다. 이때 이전에 수집한 로그 중 Exporter로 보내지 못한 것들은 기본적으로 메모리에서 사라지지만, 앞서 언급한 리시버의 파일 포인터와 익스포터의 영구 큐 덕분에 대부분 데이터를 재처리할 수 있게 됩니다. Filelog의 경우 이미 읽어들인 로그는 파일 오프셋이 진행됐기 때문에 기본 설정이라면 재시작 후 해당 부분을 다시 읽지 않아 유실 위험이 있습니다. 이를 해결하려면 exporter의 persistent queue가 반드시 켜져 있어야 합니다. Persistent Queue가 켜져 있으면, Crash 시점에 메모리에 있던 배치들은 모두 디스크에 기록되어 있으므로 재기동 후 이어 처리됩니다 . 따라서 Processor에서의 장애를 고려한 복구는 결국 Exporter 단계의 영구 큐와 Receiver의 재시작 위치 기억으로 달성됩니다.

 

요약하면, Processor 단계에서는 Collector가 과부하로 죽지 않도록 예방하고, 만약 장애가 발생하더라도 **이전 단계와 이후 단계의 보장(파일 로그 저장 및 persistent 큐)**을 통해 데이터를 잃지 않게 하는 데 초점을 맞춥니다.

 

 

Exporter 단계 – 재시도와 영구 큐를 통한 무손실 전송

 

Exporter는 최종적으로 데이터를 ClickHouse 등에 전송하는 역할로, 네트워크 장애나 수신처 불능 상태에서 가장 큰 영향을 받습니다. Exporter 단계의 내결함성 전략은 **전송 실패 시 재시도(Retry)**와 **큐잉(Buffering)**입니다:

 

• 자동 재시도 (Retry Mechanism): OpenTelemetry Collector의 모든 exporter는 exporterhelper 모듈을 통해 공통적인 재시도 로직을 지원합니다. retry_on_failure 설정을 활성화하면, export에 실패한 배치를 일정 백오프(backoff) 전략으로 재시도합니다 . 기본값으로 initial interval 5초, 최대 30초까지 배 증가 간격으로 시도하며 5분간 지속합니다 . 이 시간을 초과하면 해당 배치를 포기(drop)하는데, 절대로 데이터 유실을 원하지 않는다면 max_elapsed_time을 0으로 설정하여 무한 재시도로 둘 수 있습니다 . 다만, 무한 재시도 설정 시 장애가 장기화되면 큐가 가득 차는 문제가 있으므로 다음의 큐 설정과 함께 고려해야 합니다. 재시도 간격도 너무 짧으면 백엔드가 복구되기 전에 과부하가 될 수 있으므로 기본값을 따르거나 약간 늘리되, 지수 백오프를 사용해 점진적으로 늘어나는 것이 권장됩니다. 재시도 설정 예시:

exporters:
  clickhouse:
    endpoint: "http://clickhouse:8123"
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 0   # 0 = 무제한 재시도

이처럼 설정하면 장애 시 5초 후 재시도, 실패 시 7.5초 후 등 점진 지연하며 무기한 시도합니다.

 

• 큐잉 및 버퍼링 (In-memory Queue): Exporter는 기본적으로 메모리 내 고정 크기 큐를 사용해 비동기 전송을 처리합니다. OTel Collector의 기본 sending_queue.enabled 값은 true이며, 기본 용량은 1000개 배치입니다 . 이 큐에 배치가 쌓이고 백엔드로 보내면, ack를 받는 대로 큐에서 제거합니다. 만약 백엔드가 느리거나 응답이 없어 재시도로 남으면 계속 큐를 점유합니다. 큐가 가득 차면 기본 동작은 **새로운 배치를 거부(reject)**하여 상위 단계에서 드롭을 유발합니다 . 앞서 언급한 대로, sending_queue.block_on_overflow: true로 설정하면 거부 대신 상위 단계 처리를 블로킹하여 대기시킬 수 있습니다 . 블로킹은 데이터 유실 방지에는 좋지만, 과도하게 오래 지속되면 수집 파이프라인 전체가 멈추므로, 큐 크기를 충분히 크게 잡아두는 것이 안전합니다. 대규모 환경의 예로 OTel 기반 로그 게이트웨이에서 약 2시간치의 데이터를 메모리 큐에 보관하도록 설정한 사례도 있습니다 . 이 경우 큐가 가득 차더라도 새로운 데이터는 가장 앞의 오래된 데이터를 밀어내며(드롭) 입력을 수용함으로써 백프레셔를 걸지 않고, 2시간 내 백엔드 장애가 복구되면 데이터 유실 없이 처리하도록 한 것입니다 . 반대로 장애가 2시간을 넘어서면 일부 유실을 감수하는 전략입니다. 각 환경에 맞게 허용 가능한 지연 시간 또는 유실 허용 범위에 따라 큐 크기와 block 여부를 결정해야 합니다. 데이터 완전 보존이 목적이라면 block_on_overflow를 켜고, 가능하면 persistent queue를 사용하는 것이 바람직합니다.
• 영구 큐 (Persistent Queue) 활성화: Exporter 단계에서 가장 확실한 무손실 보장은 메모리 큐를 디스크 기반 영구 큐로 전환하는 것입니다. OTel Collector에서는 sending_queue.storage 옵션으로 영구 큐를 사용할 수 있으며, file_storage 등의 storage extension을 지정하면 in-memory 대신 해당 스토리지에 배치를 저장합니다 . 영구 큐 설정 시 Collector가 중단(crash 또는 재시작)되더라도 디스크에 저장된 큐 항목들이 유지되고, Collector 재기동 시 이어서 전송을 시도합니다 . 즉 “받았지만 아직 전송 못 한” 모든 로그가 디스크에 안전하게 저장되어 장애 시에도 유실되지 않습니다. 영구 큐의 크기는 기본적으로 1000배치 (in-memory와 동일)이며, sending_queue.queue_size로 조절 가능합니다 . 설정 방법 예:

extensions:
  file_storage/pq:
    directory: /var/otelcol/queue  # 영구 큐 데이터를 저장할 경로 (볼륨 마운트 필요)

exporters:
  clickhouse:
    endpoint: "http://clickhouse:8123"
    sending_queue:
      enabled: true
      storage: file_storage/pq   # persistent storage extension 지정
      queue_size: 5000           # 큐 배치 최대 5000 (필요에 따라 조절)
      block_on_overflow: true    # 큐 가득 찰 경우 블로킹 (드롭 방지)
    retry_on_failure:
      enabled: true
      max_elapsed_time: 0        # 무제한 재시도

위 설정에서는 file_storage 확장을 queue용도로 정의하고, ClickHouse exporter가 이를 사용하도록 지정했습니다. 영구 큐가 켜지면 모든 배치가 디스크에 기록되고 전송 후 지워지는 방식으로 동작합니다 . Collector 장애로 프로세스가 내려가더라도 디스크에 남은 배치들을 재시작 후 복구하여 처리하므로 데이터가 영구 보존됩니다 . (물론 디스크 자체의 영속성을 위해 해당 디렉토리는 EmptyDir 또는 HostPath/PVC로 보존되어야 함을 앞서 언급했습니다.)

 

영구 큐는 강력한 내결함성을 제공하지만, 고려할 점도 있습니다: 디스크 용량 모니터링이 필요합니다. 장애가 장시간 지속되거나 로그 유입량이 매우 높으면, 큐 파일이 계속 쌓여 디스크를 고갈시킬 수 있습니다. 따라서 queue_size로 최대 배치수를 제한하고, OTel Collector가 노출하는 큐 관련 메트릭 (예: otelcol_exporter_queue_size, otelcol_exporter_queue_capacity, otelcol_exporter_send_failed_log_records 등) 을 모니터링하여 장애 상황을 인지해야 합니다. 또한 persistent queue 사용 시 약간의 디스크 I/O 부하 및 Collector 시작 지연(재시작 시 누적된 큐 읽기) 등이 발생할 수 있으므로 성능에 민감한 환경에서는 큐 크기를 과도하게 크게 잡지 않는 것이 좋습니다.

 

• Exporter 구성의 다중화 및 고가용성: 한 개의 Collector에만 의존할 경우 그 인스턴스 장애 시 데이터를 해당 노드/파드에서 잠시라도 수집하지 못하는 공백이 생길 수 있습니다. 이를 보완하기 위해 Collector 자체의 HA 구성도 고려됩니다. 예를 들어 수집기는 Node당 1개씩이므로 대체가 어렵지만, 중앙 집계용 Collector(예: Agent→Gateway 모델에서 Gateway Collector)는 여러 개를 로드밸런싱으로 두어 하나가 다운되어도 다른 인스턴스가 수집을 이어받게 할 수 있습니다. OTLP나 FluentForward 같은 프로토콜은 LB 뒤에 여러 Collector replicas를 둘 수 있습니다. 다만 로그의 경우 중앙 수집을 위해 외부 큐를 사용하는 방안이 더 일반적입니다 (다음 섹션 참조).

 

정리하면 Exporter 단계에서는 재시도로 일시적 오류를 극복하고, 큐로 데이터를 보관하여 백엔드 복구 시까지 유실을 방지하며, 디스크 기반 영구 큐로 Collector 재시작/크래시에도 안전장치를 마련하는 것이 핵심 전략입니다 .

 

 

ClickHouse Exporter 장애 대응 및 내결함성 강화

 

ClickHouse를 로그 저장소로 사용하는 경우, ClickHouse Exporter (Opentelemetry Collector Contrib 모듈)를 사용하게 됩니다 . ClickHouse exporter 자체의 신뢰성을 높이기 위한 설정과 고려사항은 일반 exporter와 유사하지만, 대용량 로그를 고성능 DB에 넣는 특성을 감안한 추가 조치가 있습니다:

 

• Persistent Queue & Retry 활용: ClickHouse Exporter도 앞서 설명한 exporterhelper 기능을 그대로 따릅니다. 따라서 **retry_on_failure**를 활성화하고 **sending_queue.storage**로 persistent queue를 설정하는 것이 최우선입니다. 이를 통해 ClickHouse 서버가 일시적으로 다운되거나 네트워크가 단절되어도 로그가 손실되지 않고 Collector 측에 쌓였다가 전송을 재개할 수 있습니다 . 특히 ClickHouse처럼 자체적으로 데이터를 받아주는 버퍼가 없는 DB의 경우, 전적으로 수집 측에서 재시도와 버퍼링을 해야 합니다. OTel 설정 예시는 앞서 제시한 예와 동일하며, 대기열 크기(queue_size)는 환경에 맞게 충분히 크게 잡습니다. (예: 1000배치 이상) Collector 메모리도 queue 사용량에 따라 증가할 수 있으므로, memory_limiter와 함께 조율합니다.
• INSERT 방식 최적화: ClickHouse exporter는 로그 레코드를 HTTP API를 통해 INSERT합니다. 만약 로그 유입량이 높아 짧은 간격으로 작은 INSERT가 매우 자주 발생하면 ClickHouse에서는 Too many parts 에러가 발생하거나 성능이 저하될 수 있습니다 . 이를 방지하기 위해 Batch Processor 설정을 조정하여 어느 정도 적당한 크기의 배치를 모아서 보내는 것이 좋습니다. ClickHouse 공식 가이드는 배치 크기 5000건, 5초 타임아웃 정도를 예시로 들고 있습니다 . 또한 ClickHouse 서버 측에 Async Insert 기능을 켜두면, Collector가 보낸 INSERT들을 서버가 메모리에 모아두었다가 일괄 처리하여 디스크 파트를 효율적으로 관리합니다 . Collector에서는 batch flush 주기를 너무 길게 가져가지 않도록 (timeout 5초 등) 해서 데이터가 거의 실시간으로 유입되게 하되, ClickHouse에서 이를 비동기로 처리하도록 함으로써 수집 지연과 DB 부하의 균형을 맞출 수 있습니다 . 만약 Async Insert를 사용하지 않는다면 Collector 쪽에서 배치 크기를 크게 (예: 10k 이상) 잡아 DB 부하를 줄이도록 합니다.
• ClickHouse Cluster 구성: ClickHouse를 다중 노드로 구성한 경우, Exporter에서 단일 엔드포인트로 넣되 클러스터 샤드 간 분산삽입이 일어나게 할 수 있습니다. 예를 들어 Distributed 테이블을 가리키도록 exporter 설정을 하거나, LB를 통해 분산시킬 수 있습니다. 이러한 설정 자체는 Collector보다는 ClickHouse 측의 설정이지만, Export 실패 가능성을 줄이기 위해 ClickHouse 측도 HA를 구성하는 것이 중요합니다. Exporter는 기본적으로 하나의 endpoint(URL)만 설정되므로, 고가용 Load Balancer VIP 등을 사용하여 ClickHouse 노드 장애 시에도 접속이 가능하도록 합니다. (예: DNS로 여러 IP를 돌려주거나, ProxySQL 등 중간 계층 사용)
• 지연 모니터링 및 알림: ClickHouse exporter가 데이터를 못 보내고 쌓이는 상황을 빨리 인지하려면, Collector의 큐 길이, 재시도 횟수 및 ClickHouse 서버의 health를 모니터링해야 합니다. OTel Collector 내부 지표나 로그를 수집하여, 일정 시간 이상 재시도가 발생하면 경고를 띄우는 등 운영적인 대응도 필요합니다 . ClickHouse 측에도 삽입 지연이 길어지면 system.parts 증가 등의 신호가 있으므로 종합적으로 관찰합니다.
• Exporter 모듈 안정성: 현재 ClickHouse Exporter는 OpenTelemetry 프로젝트에서 베타(Beta) 단계로 알려져 있습니다 . 실험적인 기능일 수 있으므로 버전 업그레이드에 따른 변경을 주시하고, 충분한 테스트를 거쳐 사용하는 것이 좋습니다. 혹시 안정성 이슈가 발견된다면, 임시 방편으로 대안 경로를 마련할 수 있습니다. 예를 들어 OTel Collector에서 Kafka Exporter로 로그를 내보내고, 별도의 Consumer 애플리케이션이 Kafka에서 읽어 ClickHouse에 넣는 구조를 사용하면 문제가 생긴 exporter를 우회할 수 있습니다. 다만 구성 복잡도가 높아지므로, ClickHouse Exporter를 신뢰할 수 있을 정도로 테스트하고, 심각한 문제시 커뮤니티 이슈 등을 확인하여 패치 버전 업그레이드를 고려합니다.

 

 

모범 사례 및 확장된 장애 대비 패턴

 

마지막으로, 업계 커뮤니티나 기업에서 사용하는 로그 파이프라인 내결함성 모범 사례와 추가적인 고려사항을 정리합니다:

 

• Persistent Queue 적극 활용: 수집 파이프라인에서 디스크 버퍼링은 장애 복구의 핵심입니다. 가능하면 Receiver 단계(파일로그 등)와 Exporter 단계 모두에서 Persistent Storage를 활용하세요. 앞서 설명한 file_storage 확장을 Receiver와 Exporter에 모두 적용하면, Collector 재시작이나 일시 중단에도 데이터가 손실되지 않고 계속 처리될 수 있습니다 . 참고로 Splunk사에서는 Kubernetes 노드의 로그 파일 자체가 일종의 “persistent buffer” 역할을 하기 때문에 일반적인 경우 메모리 큐+재시도면 충분하고 영구 디스크 큐는 과하지 않게 사용할 것을 권장하지만 , 이는 로그 로테이션 등을 잘 관리한다는 전제 하에서입니다. 미션 크리티컬 환경이라면 과하다 싶을 정도로 이중, 삼중 버퍼링을 적용하는 편이 안전합니다. (예: 파일 + 영구큐 + 외부큐)
• 외부 메시지 시스템과 연계: 시스템 규모가 크고 완전한 무손실을 보장하려면, OpenTelemetry Collector 혼자만으로는 한계가 있을 수 있습니다. Kafka와 같은 외부 메시지 큐를 활용하면 내결함성을 크게 높일 수 있습니다. 일반적인 패턴은 **Collector(Agent)**가 로그를 받아 Kafka Exporter로 메시지를 큐에 넣고 , **중앙 Consumer (또는 Collector)**가 Kafka Receiver로 이를 읽어 ClickHouse로 넣는 것입니다. Kafka는 디스크 기반 로그 저장과 다중 소비, 브로커 클러스터링으로 고가용성을 지니므로, 한 번 Kafka에 들어간 로그는 지정한 보존기간 동안 유실될 걱정이 없습니다. Collector → Kafka 구간과 Kafka → ClickHouse 구간 모두 재시도/큐잉으로 구성하면 엔드투엔드로 강력한 장애 내성을 얻을 수 있습니다. (SigNoz와 같은 오픈소스도 유사한 구조를 사용하여, Collector가 수집한 데이터를 Kafka로 보내고 별도 서비스가 Kafka에서 ClickHouse로 적재합니다.) Kafka 외에도 Redis Streams, RabbitMQ, Pulsar 등을 중간 버퍼로 사용하는 것도 가능합니다. 다만 이런 추가 구성은 운영 복잡도가 증가하므로, 요구 조건(예: **“절대 로그 손실 불가”**와 같은)에 따라 도입을 판단합니다.
• Collector 이중화 및 스케일 아웃: DaemonSet의 각 에이전트는 1대뿐이므로 장애 시 재시작까지 수집 공백이 약간은 발생합니다. 이 공백을 메우려면 동일 노드에 중복 에이전트를 두는 식의 이중화는 현실적으로 어려운 만큼(동일 로그를 두 에이전트가 읽으면 중복 수집 문제 등 발생), 재시작 자동화와 신속화에 초점을 둡니다. Kubernetes의 Liveness Probe 등을 활용해 Collector가 응답하지 않을 경우 빠르게 재시작하고, CrashLoopBackOff 시 백오프간격도 너무 길지 않게 조정합니다. 또한 수평 확장을 통한 부하 분산으로 각 Collector의 부하를 낮춰 장애를 예방합니다. 수집량이 많은 경우 Pod 수를 늘리거나(노드별 여러 에이전트는 비추이므로 대신 노드를 더 추가), 중앙 Gateway를 여러 개 둘 수 있습니다. OTel Collector Operator의 autoscaling(HPA) 기능이나, 수동으로 Metric 기반 HPA를 설정해 CPU/Mem 사용률에 따라 Pod를 늘리는 것도 방법입니다 .
• Sidecar 활용 시 주의사항: 사이드카 패턴으로 Collector를 적용할 때는, 애플리케이션 컨테이너와 로그 경로를 공유하도록 해야 하며, 가능한 PersistentVolumeClaim을 마운트하여 pod 재생성 시에도 로그와 상태파일을 유지할 지 고려합니다. 그러나 일반적으로 개별 PVC를 모든 파드에 붙이는 것은 비현실적이므로, 짧은 수명 파드의 로그는 완벽히 수집하기 어려울 수 있음을 인정해야 합니다. 이럴 땐 애플리케이션이 종료 전에 로그를 flush하고, Collector 사이드카가 종료 시그널을 받고 남은 로그를 최대한 전송하도록 PreStop Hook 등을 쓸 수 있습니다. Sidecar Collector는 DaemonSet 대비 장애 영향 범위가 작지만, 반대로 말하면 각 파드별로 관리해야 하므로 운영상 복잡합니다. 따라서 가능하면 DaemonSet을 활용하고, 불가피한 경우(예: Fargate)는 Sidecar + PV 자료구조를 활용하는 정도로 가이드됩니다.
• 운영시 모니터링 및 로그: Collector 자신도 로그와 Metric을 내보낼 수 있습니다. otelcol 자체 로그에 Export 실패, 큐 드롭 발생 등의 경고가 남으므로 수집하여 경고 알람을 설정합니다. 혹은 Collector를 Prometheus 등으로 모니터링하여 otelcol_exporter_send_failed_* 메트릭이나 otelcol_exporter_queue_size 등의 변화에 알람을 걸어두면, 백엔드 장애나 Collector 문제를 조기에 발견할 수 있습니다 . 특히 영구 큐를 사용할 경우 디스크 사용률도 함께 모니터링하여 임계치 도달 전에 알리는 것이 중요합니다 .
• 구성 예시 및 검증: 실제 구성 시에는 공식 문서의 예제를 참고하여 적절히 수정합니다. ClickHouse 공식 문서에서도 OTel Collector를 이용한 로그 수집 예제를 제공하며, 여기에는 filelog receiver와 clickhouse exporter를 사용하는 YAML이 나와 있습니다 . 또한 Sumo Logic 등의 벤더 자료에서도 filelog + storage, batch, memory_limiter 등을 포함한 구성 샘플을 확인할 수 있습니다. 새로운 설정을 적용하기 전, 의도대로 동작하는지 테스트가 필수입니다. 예를 들어 의도적으로 ClickHouse를 내리는 상황을 만들어보고, Collector가 얼마나 오래 재시도를 지속하는지, 재기동 후 데이터를 모두 넣는지 등을 검증합니다. 소규모 환경에서는 persistent queue까지 쓰지 않더라도 큰 문제 없을 수 있으나, **프로덕션 환경에서는 “설마가 사람 잡는다”**는 마음으로 최악의 시나리오(네트워크 단절, DB 다운, Collector 크래시)를 가정한 Chaos 테스트도 권장합니다.
• 로그 유실 허용 범위 정의: 끝으로, 현실적으로 완전 무손실을 추구하면 시스템 복잡도가 크게 증가합니다. 경우에 따라 아주 짧은 다운타임 동안 발생한 극소수 로그의 유실은 비즈니스에 지장 없을 수 있습니다. 조직의 요구사항에 따라 RPO/RTO 관점에서 허용 가능한 데이터 손실/지연 범위를 정의하고, 그에 맞추어 위 전략들을 적절히 취사선택해야 합니다. 예를 들어 “최대 5분간의 로그는 유실될 수 있음”이 허용된다면 persistent queue 대신 5분 retry로 충분할 수 있고, “절대 유실 불가”라면 파일로그+persistent queue+외부MQ까지 다층 방어를 구축해야 할 것입니다.

 

以上의 전략들을 종합하면, Kubernetes 상에서 OpenTelemetry Collector를 활용한 로그 파이프라인은 다음과 같이 구성할 수 있습니다: 노드 로컬에서 파일로그 리시버로 로그 수집 → 메모리/디스크 배치를 통해 처리 및 완충 → ClickHouse로 내보내기 전 디스크에 안전하게 큐잉 → 전송 실패 시 무한 재시도 후 성공 시 삭제. 이를 통해 네트워크 단절이나 Collector 재시작, DB 장애 상황에서도 로그 데이터의 안전한 전달을 보장할 수 있습니다 .

 

참고 자료: OpenTelemetry 공식 문서 및 구성 가이드 , Splunk Observability 가이드 , OpenTelemetry Collector GitHub 및 블로그 자료 등이 이러한 모범 사례와 설정 방법을 자세히 다루고 있으므로, 실제 적용 시 함께 참고하면 도움이 됩니다.