[Fluent Bit] #1 Fluent Bit란? (feat. Fluentd 동생)

정리배경

---

입사 후 담당하게 된 두번째 프로젝트가 팀에서 사용하는 로깅 (Logging) 파이프라인을 재구성하는 것이었다. 사내에서 사용하는 로깅 시스템이 있었지만 아래 이유 때문에 재구성의 필요성이 느껴졌다.

• 에러 메세지를 확인하는데 있어서 UI 상의 불편함 → ElasticSearch에 적재함으로써 검색의 용이성 확보
• 제한된 로그 메세지 형식으로만 로그를 적재할 수 있는 불편함 → json 형태의 메세지를 자유롭게 주고받을 수 있는 kafka를 중간 매개체로 사용

만약에 팀 차원에서 로깅 시스템을 직접 개발한다면, 이런 문제점을 개선할 수 있다고 판단하여 개발을 시작했고 그 가운데 사용한 기술 스텍은 아래와 같다.

• Fluent Bit
• Fluentd
• Kafka
• ElasticSearch

각 기술에 대해 컨테이너 기반 사용 방법을 중심으로 정리할 계획이다. 개발을 할 때는 컨테이너를 사용하지 않았는데, 추후에 이 기술들을 사용하게 된다면 컨테이너를 사용할 것 같아서 방향을 이렇게 정했다.

Fluent Bit란 무엇인가

---

Fluent Bit is a Fast and Lightweight Logs and Metrics Processor and Forwarder for Linux, OSX, Windows and BSD family operating systems. 

fluent bit는 CNCF 산하의 프로젝트로 fluentd 이후에 개발된 오픈 소스, 다중 플랫폼의 로그 처리기이다. 데이터의 크기가 증가하고 데이터가 발생하는 소스의 다양성도 증가하고 있는 가운데 이런 복잡한 데이터를 얼마나 신뢰도 있게, 가볍게 처리하는게 중요한 문제로 떠오르고 있다. fluent bit는 이런 배경 하에 개발되었으며 구체적인 features는 아래와 같다.

• High Performance
• Data Parsing
  • 비구조적인 메세지를 파서를 이용해서 json 등의 형태로 변환한다
• Reliability and Data Integrity
• Networking
• Pluggable Architecture and Extensibility
  • 80개 이상의 사용 가능한 플러그인
  • filter 기능
• Monitoring
• Stream Processing

개발 배경

---

원래는 Treasure Data의 팀에서 fluentd를 개발했는데 embedded linux와 같은 제한된 환경에서 더 가벼운 로그 프로세서가 필요해졌다. 이런 배경에서 fluent bit가 개발되었다.

Fluentd vs Fluent Bit

---

fluentd와 fluent bit 사이에 큰 차이점은 없다. 다만, fluent bit가 좀 더 특수한 상황에서 가볍게 사용되기 위한 목적으로 fluentd을 기반으로 해서 만들어졌다는 점이다. 차이점을 살펴보자.

	Fluentd	Fluent Bit
scope	containers / servers	embedded linux / containers / servers
language	c & ruby	c
memory	~40mb	~650kb
performance	high performance	high performance
dependencies	certain number of gems	zero dependencies
plugins	more than 1000 plugins available	around 70 plugins available
license	apache license v2.0	apache license v2.0

둘다 가벼운 툴이긴 한데, fluent bit가 훨씬 가벼운 것을 알 수 있다. 또한 C로만 개발이 되어서 dependencies가 아예 없다는 점이다. 의존성이 없으므로 다른 라이브러리를 깔 필요가 없고, 따라서 더욱 가벼운 것 같다.

개념

---

1) Event or Record

fluent bit에 의애허 유입되는 모든 종류의 데이터를 event 또는 record라고 부른다. 예를 들어 아래 예시 로그에서는 총 4개의 독립적인 이벤트가 있다.

Jan 18 12:52:16 flb systemd[2222]: Starting GNOME Terminal Server
Jan 18 12:52:16 flb dbus-daemon[2243]: [session uid=1000 pid=2243] Successfully activated service 'org.gnome.Terminal'
Jan 18 12:52:16 flb systemd[2222]: Started GNOME Terminal Server.
Jan 18 12:52:16 flb gsd-media-keys[2640]: # watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)

2) Filtering

가끔 이벤트의 내용을 변경하거나 대체, 받지 않을 때도 있는데, 이를 Filtering이라고 부른다. 보통 특정 정보를 추가하거나, 이벤트의 특정 부분을 따로 떼어서 전송하거나, 특정 조건을 충족하는 이벤트를 유입하지 않는 용도로 사용된다.

3) Tag

fluent bit로 유입되는 모든 데이터는 tag를 할당받는다. 이 태그는 나중에 어떤 필터 또는 output phase를 통과할지 결정하는데 있어서 Router에 의해 사용된다. 모든 태깅된 record는 matching rule이 있어야 한다.

4) Timestamp

이벤트가 언제 생성되었는지에 대한 '시간'을 나타낸다. 형식은 SECONDS.NANOSECONDS이다.

5) Match

fluent bit는 하나, 또는 여러 개의 도착점으로 이벤트를 처리하고 전송하는데 태그가 미리 지정된 룰에 맞는다면 해당 이벤트가 선택된다.

6) Structured Message

이벤트는 구조화된 메세지이거나 비구조화된 메세지이다. 구조화된 메세지는 key-values 형태를 가진다.

7) Buffering

fluent bit가 데이터를 처리할 때, 데이터를 전송하기 전에 로그를 memory (heap)에 저장한다. buffering은 이와 같이 레코드를 어딘가에 저장해두는 능력을 의미한다. 메모리에 buffering하는 것은 가장 빠른 메커니즘이긴한데, backpressure, data safety와 같은 특수한 상황에 대처하는 전략이 필요하기도 하다.

fluent bit는 buffering 메커니즘으로 memory 뿐만 아니라 file system이라는, 혼합 솔루션을 제공한다. 이를 통해 안전하고 높은 성능으로 데이터를 처리할 수 있다.

8) Data Pipeline

• Input
• Parser
  • raw string을 구조화된 메세지로 바꾸는 역할
  • 이전: 192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395
  • 이후: {"host": "192.168.2.20" ... }
• Filter
  • 로그가 최종 도착지에 도달하기 이전에 변경 사항을 적용한다.
• Buffer
  • 데이터를 저장하기 위해 통일되고 일관된 메커니즘을 제공한다.
  • in-memory 또는 file-system 모드를 이용한다.
• Router
  • 데이터를 여러 도착지로 안내하는, core feature이다.
  • INPUT에서 Tag로 데이터 소스에 대한 이름을 지었으면, OUTPUT에서 Match을 통해 해당 데이터 소스를 받는다.

[INPUT]
    Name cpu
    Tag  my_cpu

[INPUT]
    Name mem
    Tag  my_mem

[OUTPUT]
    Name   es
    Match  my_cpu

[OUTPUT]
    Name   stdout
    Match  my_mem

Reference

• https://docs.fluentbit.io/manual/