LogStash vs Fluentd - 어떤 것을 선택해야 할까

출처: https://medium.com/techmanyu/logstash-vs-fluentd-which-one-is-better-adaaba45021b

 

이 글은 다음 글을 번역한 글입니다: Logstash vs Fluentd — Which one is better!

Logstash vs Fluentd — Which one is better !

 

LogStash와 Fluentd에 대해 알아보며 유사점과 차이점에 대해 알아보고 어떤 로그 수집기가 대상 프로젝트에 더 어울리는지 알아봅니다.

 

 

 

0. 앞선 글.

 

로그를 수집하고 Elastic stack로 전달하고자 할 때 우리는 일반적으로 ELK - Elastic, Logstash, Kibana를 듣게 됩니다. 이제 ELK는 Elastic stack와 동의어가 되었을 정도입니다. 하지만 기술적으로 그 어디에도 완벽한 솔루션은 존재하지 않습니다.

 

Fluentd는 Docker나 Kubernetes 환경과 같은 마이크로 서비스의 로깅에 대해 인기를 끌고 있습니다. 이는 Fluientd가 Treasure Data에 의해 구축되었고 CNCF의 일부이기 때문입니다. 따라서 Fluentd는 Kubernetes, Prometheus, OpenTracing과 같은 CNCF 호스팅 프로젝트들과 훨씬 더 어울립니다.

 

최근 프로젝트에 대해 이 두 로그 수집기에 대해 평가할 일이 있었고 두 분석기에 대한 장단점을 조사한 뒤 어떤 사례에 어떤 로그 분석기가 더 적합한지 결정할 수 있었습니다. 이 비교의 목적은 둘 중 어떤 로그 분석기가 더 우월한지 선택하는 것이 아니라 어떤 사용 사례에 어떤 로그 분석기가 더 적합한지 찾는 것입니다.

 

 

1. LogStash와 Fluentd의 비교.

 

A. 보증

Logstash는 인기 있는 ELK stack의 일부이며 Fluentd는 Treasure Data에 의해 구축되었고 CNCF의 일부입니다. 

Fluentd 역시 Eleastic에 대해 훌륭한 지원을 제공합니다. Kubernetis, OpenTascing, Prometheus와 같은 CNCF 호스팅 프로젝트에서는 Fluentd가 더 좋은 선택이 될 수 있습니다.

 

B. 코드 언어

Logstash는 호스트에 자바 런타임이 필요한 JRuby입니다. Fluentd는 자바 런타임이 필요하지 않은 CRuby입니다.

Fluentd는 자바 런타임이 필요하지 않다는 이점이 있습니다.

 

C. 이벤트 라우팅.

Logstash는 if-else 조건에 기반에 이벤트가 라우팅 됩니다. 예를 들자면 다음과 같습니다.

output { if [loglevel] == "ERROR" and [development] == "production" { { ... } }

 

Fluentd는 태그에 기반해 이벤트가 라우팅 됩니다. 예를 들자면 다음과 같습니다.

<match logtype.error> type ... </match>

 

이벤트에 태그를 지정하고 각 이벤트 유형에 대해 if-else를 사용하는 것이 더 쉽기 때문에 Fluentd가 더 나은 라우팅 접근 방식을 제공합니다. 만약 로그에 다른 종류의 타입이 많아진다면 Logstash는 관리하기가 쉽지 않을 것입니다.

 

D. 플러그인

Logstash는 200개 이상의 플러그인이 존재하며 Fluentd는 500개 이상의 플러그인이 존재합니다.

Logstash는 공식 git 저장소에 모든 플러그인을 가지고 있지만 Fluentd에는 아직 플러그인에 대한 중앙 git 저장소가 없습니다.

 

E. 성능

LogStash는 Fluentd보다 상대적으로 좀 더 많은 메모리를 사용합니다.

Fluentd가 약간 wrt 성능에 대해 약간 더 나은 평가를 받고 있습니다. 하지만 두 로그 수집기 모두 가벼운 수준이며 성능 측면에서 두 로그 수집기 모두 우수합니다.

 

F. 전송

Logstash는 메모리 상의 큐에 고정된 크기인 20개의 이벤트를 갖고 있으며 재시작 시 지속성을 위해 Redis 또는 Kafka와 같은 외부 큐에 의존합니다. Fluentd는 고도로 구성 가능한 버퍼링 시스템을 보유하고 있으며, 메모리상에 또는 디스크에 끝없는 배열로 구성될 수 있습니다.

OpenStack Summit 2015에서 이 강연에서 논의된 바와 같이, 둘 다 대부분의 사용 사례에서 잘 수행되고 10,000 개 이상의 이벤트를 문제없이 지속적으로 수행할 수 있습니다.

 

E. 엔터프라이즈급 지원

LogStash와 Fluentd 모두 지원합니다. 

LogStash가 공식적인 Elastic 스택의 일부이므로 LogStash의 지원이 더 낫습니다.

 

 

 

2. 사용 사례.

 

A. 로그 수집

Fluentd는 Docker에 Fluentd용 로깅 드라이버가 내장되어 있습니다. 즉, Fluentd에 로그를 푸시하기 위해 컨테이너에 추가 에이전트가 필요하지 않습니다. 로그는 STDOUT에서 Fluentd 서비스로 직접 전송되며 추가 로그 파일이나 영구 저장소가 필요하지 않습니다. 단지 docker-compose 파일에 다음과 같은 섹션을 추가해주면 됩니다.

logging: driver: "fluentd" options: fluentd-address: <fluentd IP>:<fluentd service port> tag: testservice.logs

 

Logstash의 경우 STDOUT의 애플리케이션 로그는 도커 로그에 기록되고 파일에 기록됩니다. 그런 다음 파일의 로그를 filebeat와 같은 플러그인을 통해 읽어서 Logstash로 보내야 합니다.

 

B. 로그 파싱.

Fluentd에는 json, regex, csv, syslog, apache, nginx 등과 같은 표준 내장 파서와 로그를 파싱 하는 grok과 같은 외부 파서가 있습니다.

Logstash에는 표준 형식 외에도 집계, geoip 등과 같은 필터링 및 구문 분석을 위한 더 많은 플러그인이 있습니다.

 

C. 메트릭 데이터 수집.

Fluentd는 시스템 / 컨테이너 측정 항목을 수집하는 즉시 사용할 수 있는 기능이 없습니다. 그러나 Prometheus exporter에서 메트릭을 스크랩 할 수 있습니다.
Logstash는 시스템 / 컨테이너 메트릭을 수집하고 이를 Logstash로 전달하는 즉시 사용 가능한 Metricbeat를 지원합니다. 또한 Logstash는 Prometheus exporter에서 메트릭을 스크랩 할 수도 있습니다.

 

D. 스크랩

Fluentd에는 메트릭, 상태 확인 등과 같이 http 엔드 포인트에서 데이터를 가져올 수있는 http_pull 플러그인이 있습니다.
Logstash에는 http 엔드 포인트에서 데이터를 가져올 수있는 Elastic에서 지원하는 http 플러그인이 있습니다.

 

 

 

3. 그러면 무엇을 이용해야 할까요?

 

위의 사용 사례를 살펴보면 Fluentd와 Logstash가 특정 요구 사항에 적합하다는 것이 분명합니다. 가장 좋은 점은 둘 다 동일한 환경에서 공존할 수 있으며 특정 사용 사례에 사용할 수 있다는 것입니다.

 

기존 VM의 모놀리틱 한 애플리케이션의 경우 로그, 메트릭, 상태 등의 수집을 위해 여러 에이전트를 지원하므로 LogStash가 확실한 선택처럼 보입니다. 

 

Docker 및 Kubernetes에서 호스팅 되는 마이크로 서비스의 경우에는 Fluentd가 기본 제공 로깅 드라이버와 원활한 통합을 고려할 때 훌륭한 선택으로 보입니다. json, nginx, grok 등과 같이 일반적으로 사용되는 모든 파서를 지원하기도 합니다.

 

ELK-EFK 하이브리드 구조에서는 아래와 같이 두 로그 수집기를 동시에 사용하여 지원할 수 있습니다. 

 

 

이 글이 혼란을 줄이고 더 나은 결정을 내리는 데 도움이되기를 바랍니다.