Log Collectors

마지막 업데이트: 2026년 2월 23일

Kubernetes 환경에서 로그를 수집하는 다양한 도구들이 있습니다. 이 문서에서는 FluentBit, Promtail, Grafana Alloy, OpenTelemetry Collector를 심층적으로 비교하고, 각 도구의 설정 방법과 최적화 전략을 설명합니다.

목차


개요

로그 수집기 역할

spinner

핵심 기능

기능
설명

수집 (Input)

다양한 소스에서 로그 읽기

파싱 (Parsing)

로그 형식 해석 및 구조화

필터링 (Filtering)

불필요한 로그 제거

변환 (Transform)

필드 추가/수정/삭제

버퍼링 (Buffering)

일시적 저장으로 안정성 확보

출력 (Output)

목적지로 로그 전송


FluentBit

개요

FluentBit은 CNCF 프로젝트로, C로 작성된 경량 로그 프로세서입니다. Fluentd의 경량 버전으로 시작했지만, 현재는 독립적인 프로젝트로 발전했습니다.

항목

언어

C

메모리

~10MB

성능

초당 수십만 이벤트

플러그인

100+ 내장

라이선스

Apache 2.0

CNCF

Graduated

아키텍처

spinner

전체 설정 예시

파서 설정

Lua 스크립트 예시

DaemonSet 배포


Promtail

개요

Promtail은 Grafana Labs에서 개발한 Loki 전용 로그 수집 에이전트입니다. Loki와 함께 사용하도록 최적화되어 있습니다.

항목

언어

Go

메모리

~50MB

목적지

Loki 전용

K8s 통합

네이티브

라이선스

AGPL-3.0

개발사

Grafana Labs

아키텍처

spinner

전체 설정 예시

파이프라인 스테이지 상세

DaemonSet 배포


Grafana Alloy

개요

Grafana Alloy는 Grafana Agent의 후속 프로젝트로, OpenTelemetry Collector 배포판을 기반으로 합니다. River 설정 언어를 사용하여 더 유연한 구성이 가능합니다.

항목

언어

Go

기반

OTEL Collector

설정

River (HCL 유사)

목적지

다중 (Loki 최적화)

라이선스

Apache 2.0

개발사

Grafana Labs

River 설정

Promtail에서 마이그레이션


OpenTelemetry Collector

개요

OpenTelemetry Collector는 벤더 중립적인 텔레메트리 데이터 수집, 처리, 내보내기 파이프라인입니다.

항목

언어

Go

목적지

다중

신호

Logs, Metrics, Traces

라이선스

Apache 2.0

CNCF

Incubating

OTLP Proto 인코딩의 성능 우위:

OpenTelemetry Collector는 OTLP(OpenTelemetry Protocol) Proto 인코딩을 사용합니다. JSON 대비 필드명을 숫자 태그로 치환하여 40-60%의 전송 용량을 절감합니다.

지표
Filebeat/Fluentd (JSON)
OTel Collector (OTLP Proto)
개선

메시지 인코딩

JSON (필드명 포함)

Proto (숫자 태그)

40-60% 용량 절감

배치 전송

1,000건 = 1,000 메시지

1,000건 ≈ 7 메시지 (150건/배치)

143배 메시지 수 감소

처리량

16.5 MB/s

300 MB/s

18배 향상

Core당 처리량

150건/초 (Fluentd)

4,000건/초

26배 향상

실사례: 카카오페이증권 Pallas v2 프로젝트에서 Filebeat/Fluentd → OTel Collector 전환 시 동일 하드웨어로 18배 처리량 향상을 달성했습니다.

아키텍처

spinner

전체 설정 예시

Routing Connector

OTel Collector의 Routing Connector를 사용하면 로그 타입별로 서로 다른 파이프라인으로 분기할 수 있습니다. 이를 통해 로그 종류에 따라 다른 처리 로직과 목적지를 설정할 수 있습니다.

Kafka 토픽 통합: Routing Connector를 사용하면 기존의 로그 타입별 Kafka 토픽 분리 방식을 단일 토픽 + Collector 내 라우팅으로 대체할 수 있어, Kafka 토픽 관리 부담이 줄어듭니다.

로그 레벨별 Pool 분리 (대규모 환경)

일 TB 이상의 로그를 처리하는 환경에서는 모든 로그를 동일한 우선순위로 처리하면 장애 시 핵심 로그 수집이 지연될 수 있습니다. OTel Collector Pool을 로그 레벨별로 분리하여 SLA를 차등 적용합니다.

Pool
용도
SLA
스케일링 전략

Fast

핵심 이벤트, ERROR/FATAL

2분 이내 수집

우선순위 높음, 항상 여유 리소스 확보

Common

일반 운영 로그 (INFO/WARN)

15분 이내 수집

기본 오토스케일링

Debug

디버깅용 (DEBUG/TRACE)

최선 노력 (Best-effort)

피크 시 축소 가능

구성 예시:

운영 팁: Fast Pool은 장애 상황에서도 항상 가용해야 하므로, PriorityClass를 system-cluster-critical 수준으로 설정하고 전용 노드 그룹에 배치하는 것을 권장합니다.


비교 및 선택 가이드

기능 비교표

기능
FluentBit
Promtail
Grafana Alloy
OTEL Collector

메모리 사용량

~10-50MB

~50-100MB

~50-100MB

~50-100MB

CPU 사용량

낮음

중간

중간

중간

설정 언어

INI

YAML

River (HCL)

YAML

Kubernetes 통합

우수

우수

우수

우수

멀티라인 처리

우수

우수

우수

양호

JSON 파싱

우수

우수

우수

우수

Lua 스크립팅

지원

미지원

미지원

미지원

WASM 플러그인

지원

미지원

미지원

미지원

Loki 지원

우수

네이티브

네이티브

양호

OpenSearch 지원

네이티브

미지원

미지원

양호

CloudWatch 지원

네이티브

미지원

미지원

양호

메트릭 수집

지원

제한적

우수

우수

트레이스 수집

미지원

미지원

우수

네이티브

OTLP Proto 지원

미지원

미지원

지원

네이티브

Core당 처리량

~3,000건/초

~500건/초

~2,000건/초

~4,000건/초

버퍼링

메모리/파일

메모리

메모리

메모리

사용 사례별 권장

의사결정 플로우

spinner

퀴즈

이 장에서 배운 내용을 테스트하려면 로그 수집기 퀴즈를 풀어보세요.

마지막 업데이트