Elasticsearch 입문 25편 — Logstash·Beats·Fluentd·Vector (외부 수집기 비교)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 25편이에요. 23편에서 Bulk API, 24편에서 Ingest Pipeline 으로 ES 안쪽 의 수집 경로를 봤다면 — 이번 25편은 ES 로 들어오기 전 단계 의 외부 수집기들이에요. 즉, 어디서 로그·메트릭을 긁어다가 어떻게 가공해서 ES 에 던지느냐 자리.

ES 앞단의 외부 수집기

23편에서 봤듯 ES 자체도 Bulk API 로 직접 데이터를 받을 수 있어요. 문제는 현실의 로그·메트릭이 ES 친화 JSON 으로 깔끔하게 오지 않는다 는 거예요. nginx access log 는 한 줄짜리 텍스트고, syslog 는 RFC 5424 포맷이고, CPU·메모리 메트릭은 OS API 를 호출해야 나오고, Kubernetes Pod 로그는 노드 파일 시스템에 흩어져 있어요.

이 수집·파싱·가공·전송 자리를 채우는 도구들이 외부 수집기 (collector / shipper / ETL) 예요. 이 자리에 사실상 표준이 된 도구가 다섯 갈래로 정리돼요 — Logstash · Beats · Fluentd · Fluent Bit · Vector. 이번 글은 이 다섯을 한 줄에 비교하는 자리예요.

세 가지 축으로 갈라 보면 — 첫째 언어 / 메모리 부담 (JVM 무거움 vs Go·Rust 경량), 둘째 역할 두께 (단순 shipping vs 무거운 ETL), 셋째 생태계 (Elastic 진영 vs CNCF 진영 vs 신규 Rust). 이 세 축으로 나머지 본문을 따라가면 흐름이 잡혀요.

Logstash — JVM 기반 무거운 ETL

Logstash 는 ELK 스택 의 첫 글자 L 자리예요. 2009년 Jordan Sissel 이 만들었고 2013년 Elastic 사가 인수했어요. JRuby (JVM 위에서 도는 Ruby) 로 짠 데이터 처리 파이프라인 엔진 이에요. 한 줄로 — 대용량 로그를 다양한 곳에서 받아, 풍부한 필터로 가공해, 다양한 곳으로 보내는 도구.

핵심 구조는 input · filter · output 3단계예요. input 에서 파일·TCP·HTTP·Kafka·Beats·JDBC 등 50+ 소스에서 데이터를 받아요. filter 에서 grok (정규식 파싱)·mutate (필드 추가·삭제·변환)·date (날짜 파싱)·geoip (IP → 지리 정보)·ruby (커스텀 코드) 등으로 가공해요. output 에서 ES·S3·Kafka·파일 등 50+ 대상으로 보내요.

설정 파일이 DSL (Domain Specific Language) 처럼 생겼어요. 예를 들면 — input { file { path => "/var/log/nginx/access.log" } } 같은 형태. nginx 로그를 grok 으로 파싱해서 ES 에 보내는 가장 흔한 패턴이 이런 식이에요.

# logstash.conf 예시 — nginx access log → ES
input {
  file {
    path => "/var/log/nginx/access.log"
    start_position => "beginning"
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
  geoip {
    source => "clientip"
  }
  mutate {
    convert => { "response" => "integer" }
    convert => { "bytes" => "integer" }
  }
}

output {
  elasticsearch {
    hosts => ["http://es01:9200"]
    index => "nginx-access-%{+YYYY.MM.dd}"
  }
}

장점은 기능의 두께 예요. grok 패턴이 200+ 개 미리 정의돼 있고, 어떤 이상한 포맷도 정규식으로 파싱이 가능해요. 단점은 JVM 부담 이에요. 기본 힙 1GB, CPU 4코어 정도가 시작점이고, 노드 한 대를 거의 다 잡아먹어요. 그래서 각 서버마다 띄우기엔 너무 무거워서 — 보통 중앙 집중형 수집 노드 1~5대만 띄우고, 각 서버는 가벼운 Beats 로 Logstash 에 보내는 2단 구조 가 표준이에요.

작성 시점(2026-05) 기준 최신은 Logstash 8.x 이고, ES 8.x 와 버전이 보통 일치해요. 라이선스는 ES 와 같은 SSPL + Elastic License 또는 AGPL 옵션이에요.

Filebeat · Metricbeat — 경량 shipper

Beats 는 Elastic 사가 Logstash 가 너무 무겁다 는 피드백을 받아 2015년에 만든 경량 데이터 shipper 모음 이에요. Go 로 짜서 메모리 10~50MB · CPU 거의 0% 수준에서 돌아요. 각 서버에 한 개씩 가볍게 띄우는 agent 자리.

가장 많이 쓰는 두 가지가 Filebeat 와 Metricbeat 예요. Filebeat 는 로그 파일 한 줄씩 읽어서 보내는 단순 도구예요. nginx·tomcat·MySQL 로그 같은 파일을 tail 처럼 읽어 ES 또는 Logstash 에 던져요. 내부에 registry 라는 작은 파일을 두고 어디까지 읽었는지 기록해서, 프로세스 재시작해도 중복·누락 X.

Metricbeat 는 OS·미들웨어 메트릭을 수집 하는 도구예요. CPU·메모리·디스크 · 네트워크 같은 OS 지표와, MySQL·PostgreSQL·Redis·nginx·Docker·Kubernetes 같은 미들웨어 지표를 모듈 단위로 받아 ES 에 시계열로 박아요.

설정은 YAML 한 파일이에요. 모듈 단위로 enable 만 하면 끝이라 학습 비용이 Logstash 의 1/10 수준.

# filebeat.yml 예시
filebeat.inputs:
- type: log
  paths:
    - /var/log/nginx/access.log
  fields:
    log_type: nginx-access

processors:
  - add_host_metadata: {}
  - add_kubernetes_metadata: {}

output.elasticsearch:
  hosts: ["http://es01:9200"]
  index: "filebeat-%{+yyyy.MM.dd}"

setup.kibana:
  host: "http://kibana:5601"

핵심 패턴 두 가지를 외워 두면 좋아요. (1) Beats → ES 직접 — 단순 로그·작은 규모면 Filebeat 가 grok 대신 ingest pipeline (24편) 으로 ES 에서 파싱. (2) Beats → Logstash → ES — 복잡한 파싱·여러 source 합치기·backpressure 완충 이 필요하면 중간에 Logstash 를 둬요. Beats 가 각 서버에서 가볍게 긁어 Logstash 로 모아 → Logstash 가 중앙에서 무겁게 가공 → ES 로.

작성 시점(2026-05) 기준 최신은 Beats 8.x (ES·Logstash 와 동일 버전).

다른 Beats — Heartbeat·Auditbeat·Packetbeat·Functionbeat

Filebeat·Metricbeat 외에도 특수 자리 의 Beats 가 몇 개 더 있어요. 한 줄씩만.

• Heartbeat — uptime monitoring 자리. HTTP·TCP·ICMP 로 원격 서비스가 살아있는지 주기적으로 체크해 ES 에 박아요. 외부에서 보는 monitoring (서비스가 사용자에게 보이는 관점).
• Auditbeat — Linux audit framework 와 파일 무결성 모니터링 (FIM, File Integrity Monitoring) 자리. 시스템 콜·로그인·파일 변경 감지. 보안·컴플라이언스 요건.
• Packetbeat — 네트워크 패킷 분석 자리. HTTP·DNS·MySQL·MongoDB 등 프로토콜 단위 트래픽 을 캡처해 느린 쿼리·이상 패턴 을 ES 로 보내요. APM 의 전신.
• Functionbeat — 서버리스 환경 (AWS Lambda·Cloudflare Workers) 에서 도는 Beats. CloudWatch Logs·Kinesis·SQS 같은 클라우드 소스에서 데이터를 받아 ES 로.
• Winlogbeat — Windows Event Log 전용. Windows 서버 운영팀의 표준 도구.

이 중 Heartbeat · Packetbeat 는 33편(Kibana·ELK) 의 Observability 자리에서 다시 나와요.

Fluentd & Fluent Bit — CNCF, Kubernetes 표준

Fluentd 는 2011년 일본 Treasure Data 사가 만든 오픈소스 로그 수집기 예요. 2019년 CNCF (Cloud Native Computing Foundation) 에 Graduated 단계로 졸업하면서 — Kubernetes 환경의 사실상 표준 로그 수집기 자리가 굳어졌어요. Ruby + C 로 짰고, 메모리 부담은 Logstash 보다 가볍고 Beats 보다 무거워요 (40~100MB 수준).

핵심 강점은 plugin 생태계 예요. 800+ 개의 input·output·filter plugin 이 RubyGems 로 풀려 있어요. input · filter · output 3단계 구조는 Logstash 와 비슷하지만, 설정 문법이 XML 비슷한 형태 예요.

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx-access.log.pos
  tag nginx.access
  <parse>
    @type nginx
  </parse>
</source>

<match nginx.access>
  @type elasticsearch
  host es01
  port 9200
  logstash_format true
  logstash_prefix nginx-access
</match>

Fluent Bit 는 Fluentd 의 경량판 이에요. C 로 다시 짜서 메모리 1~5MB · CPU 거의 0% 수준이에요. Fluentd = Logstash 자리, Fluent Bit = Filebeat 자리 로 한 줄 매핑하면 머릿속에 잘 박혀요. 2020년 이후 Fluent Bit 도 CNCF Graduated 단계로 졸업.

EFK 스택 이라는 단어가 자주 등장하는데, Elasticsearch + Fluentd (or Fluent Bit) + Kibana 의 조합이에요. ELK 의 L 자리에 Fluentd 가 들어간 구조고, Kubernetes 환경 에서 표준 패턴이에요. Kubernetes 의 모든 Pod 로그가 노드의 /var/log/containers/ 에 모이는 구조 라서, 각 노드에 Fluent Bit DaemonSet 한 개씩 띄워 ES 로 보내는 게 거의 모든 K8s 클러스터의 1st pick.

ELK 와 EFK 의 선택 기준은 간단해요. Elastic 진영 (Elastic Cloud · Beats agent · APM) 을 통째로 쓰면 ELK, Kubernetes 네이티브 (CNCF 만 모아 쓰는 자리, 멀티 클러스터, 멀티 벤더) 면 EFK.

Vector — Rust 기반 신규 (Datadog)

Vector 는 2019년 Timber.io (현재 Datadog 산하) 가 만든 Rust 로 짠 통합 옵저버빌리티 데이터 파이프라인 이에요. 2021년 Datadog 인수 이후 빠르게 성장해서, 작성 시점(2026-05) 기준 Logstash·Fluentd 의 차세대 대안 으로 평가받아요.

핵심 차별점 세 가지가 있어요. (1) Rust 의 성능 — Logstash 대비 10배, Fluentd 대비 3배 빠르다는 벤치마크 (Datadog 자체 측정 기준). (2) 통합 처리 — 로그·메트릭·트레이스 세 가지 텔레메트리를 한 도구로 처리 (Logstash·Beats 처럼 도구 분리 X). (3) VRL — Vector Remap Language 라는 도메인 특화 언어로 grok 보다 빠르고 명확한 데이터 변환.

설정은 TOML 또는 YAML 한 파일이에요. source · transform · sink 3단계 (= input · filter · output).

# vector.toml 예시
[sources.nginx_logs]
type = "file"
include = ["/var/log/nginx/access.log"]

[transforms.parse_nginx]
type = "remap"
inputs = ["nginx_logs"]
source = '''
. = parse_nginx_log!(.message, "combined")
.timestamp = parse_timestamp!(.timestamp, format: "%d/%b/%Y:%T %z")
'''

[sinks.es_out]
type = "elasticsearch"
inputs = ["parse_nginx"]
endpoints = ["http://es01:9200"]
bulk.index = "nginx-access-%Y.%m.%d"

장점은 성능 + 메모리 효율 + 단일 바이너리 예요. Go 의 Beats 보다도 빠르고, JVM 의존도 X 라서 컨테이너 이미지가 10~20MB 수준. 단점은 생태계가 아직 작아서 — Logstash 200+ filter 나 Fluentd 800+ plugin 만큼은 아니에요. 신규 프로젝트라면 1st 후보로 검토할 만하고, 기존 ELK·EFK 가 잘 도는 환경이면 굳이 갈아엎을 필요는 X.

선택 가이드 — 한눈 비교표

다섯 도구를 한 표에 압축하면 이렇게 정리돼요.

선택 기준 한 줄 가이드 — 가벼운 shipping 만 필요 하면 Filebeat 또는 Fluent Bit, 복잡한 ETL 이 필요 하면 Logstash 또는 Vector, Kubernetes 표준 EFK 환경 이면 Fluent Bit + Fluentd, Elastic 진영 통합 환경 이면 Beats + Logstash.

자주 만나는 사고

사고 1 — Logstash JVM 메모리 OOM

원인 — 기본 힙 1GB 로 시작했는데 nginx access log 처럼 초당 수만 건 이 한꺼번에 들어오면 grok·json 파싱 후 내부 큐 가 가득 차서 Java OutOfMemoryError 로 죽어요.

해결 — jvm.options 에서 힙 2~4GB 로 올리고 (-Xms2g -Xmx2g), pipeline.workers 와 pipeline.batch.size 를 CPU 코어 수에 맞게 튜닝해요. 그래도 부족하면 persistent queue 를 켜서 디스크 기반 버퍼로 전환.

사고 2 — Beat backpressure

원인 — Filebeat 가 ES 또는 Logstash 에 데이터를 던지는데, downstream 이 느려져서 받지 못하면 Filebeat 가 registry 의 읽은 위치 를 갱신하지 못한 채 내부 큐가 가득 차서 새 로그를 읽지 못해요. 결과적으로 로그가 노드 디스크에 쌓이다가 disk full 사고로 번져요.

해결 — Filebeat 의 queue.mem.events 를 늘리고, output.elasticsearch.bulk_max_size 를 키워 전송 효율을 올려요. 더 근본적으로는 ES 또는 Logstash 의 처리 용량 을 올려야 해요. Logstash 의 persistent queue 가 이 backpressure 완충 자리의 표준 솔루션이에요.

사고 3 — grok 정규식 폭주

원인 — Logstash 의 grok filter 가 너무 복잡한 정규식 을 만나면 catastrophic backtracking 으로 CPU 100% · 처리 멈춤 사고가 나요. 특히 임의의 사용자 입력 을 파싱하는 자리에서 자주 발생.

해결 — match 옵션에 timeout_millis 를 설정해 5초 넘어가면 포기 하게 박아요. 정규식 자체는 greedy .* 를 피하고 anchored ^...$ 또는 non-greedy .*? 를 써서 backtracking 가능성 을 차단. 가능하면 grok 대신 dissect (단순 분리자 기반 파싱) 를 쓰는 게 안전.

사고 4 — Fluentd buffer overflow

원인 — Fluentd 의 output buffer 가 ES 장애 중에 디스크에 쌓이다가 디스크 가득 으로 프로세스 정지 사고. 특히 Kubernetes DaemonSet 에서 EBS 볼륨 크기가 작으면 자주 발생.

해결 — <buffer> 블록에서 total_limit_size 를 디스크 크기의 50% 이하로 박고, overflow_action 을 drop_oldest_chunk 로 설정해서 오래된 청크부터 버리는 정책을 두는 게 표준. 동시에 디스크 사용량 알람 을 별도로 띄워 둬요.

사고 5 — Vector config 오류로 silent drop

원인 — Vector 의 VRL 변환 코드에 예외 처리가 빠지면 일부 이벤트가 조용히 drop 돼요. 예를 들어 parse_json!(.message) 가 실패하면 그 이벤트는 내부 에러 처리기 로 빠지고, 별도 sink 가 없으면 그대로 사라져요.

해결 — VRL 의 ! (실패 시 panic) 대신 ? (실패 시 null 반환) 를 써서 예외 허용 하고, processing_errors 를 별도 sink (예 — S3 dead letter) 로 보내는 패턴을 표준화. Vector 의 internal metrics 를 ES 또는 Prometheus 로 보내 drop count 를 항상 모니터링.

사고 6 — Kubernetes Pod 로그 누락

원인 — Fluent Bit DaemonSet 가 노드의 /var/log/containers/*.log 를 tail 하는데, Pod 가 재시작되면서 로그 파일이 rotate 되면 마지막 몇 줄 이 누락되는 자리.

해결 — Fluent Bit 의 [INPUT] tail 에서 Refresh_Interval 5, Rotate_Wait 30 옵션을 박아 rotation 후 30초간 더 읽도록 설정. DB 옵션으로 SQLite 기반 읽은 위치 저장 을 켜면 Fluent Bit 재시작에도 누락 X.

사고 7 — 타임스탬프 두 자리 사고

원인 — 로그 원본의 생성 시간 (예 — nginx 의 $time_local) 과 ES 의 색인 시간 (@timestamp 기본값) 이 다르면 — Kibana 에서 시계열로 봤을 때 5분 늦게 들어온 로그가 5분 늦은 시간에 찍혀서 사고 시간대 분석이 어그러져요.

해결 — Logstash 의 date filter, Filebeat 의 processors , Fluentd 의 <parse> 블록에서 원본 timestamp 를 @timestamp 로 강제 덮어쓰기 가 표준 패턴. 시간대(timezone) 도 명시적으로 박아야 UTC vs KST 9시간 차이 사고가 안 나요.

운영 권장 패턴

수집기 1차 선택은 2단 구조 또는 1단 구조 결정부터예요. 1단 구조 는 Filebeat · Fluent Bit · Vector → ES 직접 으로 간단하지만, 가공 기능이 약하고 backpressure 완충 이 어려워요. 2단 구조 는 Beats · Fluent Bit → Logstash · Fluentd · Vector → ES 로, 중앙 ETL 노드에서 무거운 가공·버퍼링을 담당해요. 초당 1만 건 이상 · 복잡한 파싱 · 멀티 source 라면 2단 구조가 정답.

각 노드의 수집기는 항상 메모리·CPU 한도 를 박아 둡니다. systemd 의 MemoryLimit 이나 Kubernetes 의 resources.limits 로 수집기가 노드 자원을 다 잡아먹는 사고를 예방. 특히 Logstash·Fluentd 같은 VM 기반 수집기 는 예측 불가능한 GC 가 가끔 CPU 100% 를 잡아먹어요.

수집기 자체의 운영 monitoring 을 빠뜨리지 말아요. Logstash 는 _node/stats API, Beats 는 monitoring output, Fluentd 는 monitor_agent plugin, Vector 는 internal metrics endpoint — 다 자체 monitoring 인터페이스가 있어요. 이걸 Prometheus 또는 Stack Monitoring (Elastic 의 self-monitoring 기능, 30편) 으로 항상 모니터링해야 수집기 자체의 사고 가 조기 발견돼요.

데이터 retention 은 수집기 단이 아닌 ES 단의 ILM (Index Lifecycle Management, 6편) 에서 정합니다. 수집기에서 데이터 보존을 거는 패턴은 복구 어려움 · 정책 분산 으로 사고가 잦아요. 수집기는 지나가는 통로 자리, 저장·삭제는 ES 자리.

시험 직전 한 번 더 — 압축 노트

• 외부 수집기 = ES 앞단의 수집·파싱·가공·전송 자리.
• Logstash = JVM 기반 무거운 ETL. input·filter·output 3단계. grok 200+. 중앙 집중형.
• Filebeat = Go 경량 로그 shipper. 메모리 10~30MB. registry 로 읽은 위치 기록.
• Metricbeat = Go 경량 메트릭 수집. OS·미들웨어 모듈 단위. 시계열로 ES 박음.
• 다른 Beats = Heartbeat (uptime) · Auditbeat (FIM) · Packetbeat (네트워크) · Functionbeat (서버리스) · Winlogbeat (Windows).
• Fluentd = CNCF Graduated. Ruby+C. plugin 800+. Kubernetes 표준.
• Fluent Bit = Fluentd 경량판. C. 메모리 1~5MB. K8s DaemonSet 1st pick.
• EFK 스택 = ELK 의 L 자리에 Fluentd. Kubernetes 표준.
• Vector = Datadog 산하. Rust. 성능 10×. VRL 데이터 변환 언어.
• 사고 7대 — Logstash OOM · Beat backpressure · grok 폭주 · Fluentd buffer overflow · Vector silent drop · K8s 로그 누락 · 타임스탬프 두 자리.
• 1단 구조 = 수집기 → ES 직접 (간단). 2단 구조 = Beats → Logstash → ES (대용량·복잡 파싱).
• 수집기는 지나가는 통로, retention 은 ES 의 ILM 자리.
• 작성 시점(2026-05) — Logstash·Beats 8.x, Fluentd 1.16+, Fluent Bit 3.x, Vector 0.40+.

시리즈 다른 편

• 이전 글 = 24편 Ingest Pipeline — Processor·Painless·Pipeline 구성
• 다음 글 = 26편 Cluster Operations — Node Role·Master 선출·Allocation·Health
• 6편 = Index Lifecycle Management — Rollover·Hot-Warm-Cold·Frozen·Delete
• 8편 = Mapping Deep — Static·Dynamic·Multi-field·Runtime
• 23편 = Bulk API — Batch 색인·Backpressure·Retry 전략
• 24편 = Ingest Pipeline — Processor·Painless·Pipeline 구성
• 30편 = Monitoring — Stack Monitoring·_cluster/health·slow log
• 33편 = Kibana·ELK — Discover·Visualize·Dashboard·Observability
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — ES 앞단의 외부 수집기 = Logstash (무거운 ETL) · Beats (Elastic 경량 shipper) · Fluentd/Fluent Bit (CNCF·K8s 표준) · Vector (Rust 신규) 다섯 갈래. 가벼운 shipping 은 Filebeat·Fluent Bit, 무거운 ETL 은 Logstash·Vector, K8s 환경은 Fluent Bit + Fluentd 가 1st pick.