사전 Fluent Bit
구현체

Fluent Bit

gabury1고친 사람 github-actions[bot]

Fluent Bit 은 서버 여기저기서 생기는 기록을 대신 모아 보관할 곳까지 실어 나릅니다. 나르는 동안 필요 없는 줄을 걸러 내고 모양을 다듬습니다. 프로그램은 기록을 뱉어 두기만 하고 어디로 보낼지는 신경 쓰지 않습니다. 서버마다 한 벌씩 띄워 두고 씁니다.

쉽고 빠른 이해

Fluent Bit 은 로그를 모아 보내 주는 심부름꾼 프로그램입니다. 웹 서버가 남긴 접속 기록을 읽어다 검색 엔진에 넣어 두는 일이 그런 심부름입니다.

이 심부름꾼이 없으면 프로그램마다 로그를 어디로 보낼지 스스로 알아야 합니다. 보낼 곳이 바뀌면 프로그램을 모두 고쳐야 하고, 보낼 곳이 멈추면 프로그램까지 같이 붙잡힙니다.

어떻게 도나:

  1. 로그 파일과 컨테이너의 출력에서 새로 생긴 줄을 읽어 들입니다
  2. 글자 덩어리인 한 줄을 항목으로 쪼개고 볼 필요 없는 줄을 버립니다
  3. 검색 엔진이나 저장소로 내보냅니다
  4. 받는 쪽이 못 받으면 쌓아 두었다가 다시 보냅니다

대가가 있습니다. 프로그램과 저장소 사이에 하나가 더 끼므로 로그가 도착하기까지 시간이 더 걸립니다. 쌓아 둔 것을 미처 못 보내고 죽으면 그만큼 사라집니다. 품이 드는 가공은 맡기지 못하므로 그런 처리는 뒤에 다른 물건을 세워야 합니다.

상세

Fluent Bit 은 로그와 메트릭을 모아 다른 곳으로 보내는 수집 프로그램입니다. 내려받아 서버에 띄워 두면 정해 준 데서 데이터를 읽어다 정해 준 데로 내보냅니다. 애플리케이션과 저장소 사이에 서서 그 둘을 잇는 물건입니다.

이 절은 먼저 애플리케이션이 로그를 직접 보내지 않는 까닭을 봅니다. 그다음 데이터가 지나가는 세 단계, 갈래를 나누는 이름표, 받는 쪽이 밀릴 때 버티는 장치를 차례로 봅니다. 끝으로 이 물건을 어디에 띄워 두는지와 가벼움을 얻으려고 내려놓은 것을 봅니다.

애플리케이션이 로그를 직접 보내지 않는 까닭

웹 서버 열 대가 접속 기록을 남긴다고 해 봅시다. 각 서버가 검색 엔진으로 직접 보내게 하면 저장소의 주소와 접속 열쇠, 실패했을 때 다시 보내는 절차가 프로그램마다 들어갑니다. 저장소를 다른 것으로 바꾸는 날 열 군데를 모두 고쳐야 합니다.

받는 쪽이 밀릴 때도 곤란해집니다. 검색 엔진이 잠깐 버벅이면 기록을 보내던 프로그램이 응답을 기다리며 붙잡힙니다. 기록을 남기는 곁일이 본래 하던 일을 방해합니다.

그래서 사이에 프로그램을 하나 끼웁니다. 애플리케이션은 표준 출력이나 로그 파일에 적기만 합니다. 그것을 읽어다 어디로 보낼지는 Fluent Bit 이 맡습니다. 보낼 곳이 바뀌어도 이 한 벌만 고치면 됩니다.

지나가는 세 단계 — 입력·필터·출력

Fluent Bit 을 지나는 데이터는 정해진 단계를 차례로 밟습니다. 입력이 데이터를 읽어 들이고, 필터가 그것을 다듬고, 출력이 바깥으로 내보냅니다. 단계마다 무엇을 쓸지는 따로 고릅니다.

입력은 어디서 읽을지를 정합니다. 파일 끝에 붙어 새로 적히는 줄을 따라 읽거나, 컨테이너 런타임이 모아 둔 표준 출력을 받거나, 운영체제가 남기는 syslog 를 받습니다.

필터는 읽어 들인 한 줄을 쓸 만한 모양으로 바꿉니다. 글자 덩어리인 한 줄을 시각과 로그 레벨과 메시지 같은 항목으로 쪼개는 일을 파싱이라고 합니다. 쪼갠 데이터에 기계 이름이나 컨테이너 이름을 덧붙이고, 볼 필요가 없는 줄은 여기서 버립니다.

출력은 어디로 보낼지를 정합니다. 검색 엔진, 객체 저장소, 메시지 큐, 클라우드 업체가 파는 로그 서비스가 모두 받는 쪽이 됩니다.

flowchart TD
    subgraph 만드는 쪽
        A["컨테이너 표준 출력"]
        B["로그 파일"]
        C["시스템 로그"]
    end
    subgraph FB["Fluent Bit"]
        I["입력 · 읽어 들인다"] --> F["필터 · 다듬는다"] --> O["출력 · 내보낸다"]
    end
    subgraph 받는 쪽
        D["검색 엔진"]
        E["객체 저장소"]
        G["메시지 큐"]
    end
    A --> I
    B --> I
    C --> I
    O --> D
    O --> E
    O --> G

그림의 왼쪽 셋은 서로 다른 데서 오지만 입력을 지나면 같은 모양이 됩니다. 그래서 필터와 출력은 한 가지 모양만 다루면 되고, 새 입력이 늘어도 뒤 단계를 고칠 일이 없습니다.

데이터에 붙는 이름표

읽어 들인 데이터에는 이름표가 하나씩 붙습니다. 어느 입력에서 들어왔는지를 가리키는 짧은 문자열입니다. 필터와 출력은 이 이름표를 보고 자기가 다룰 것만 골라냅니다.

이름표가 있어서 한 벌이 여러 갈래를 동시에 다룹니다. 웹 서버 기록은 검색 엔진으로 보내고 결제 기록은 객체 저장소로 보내는 식으로 갈래마다 목적지가 달라집니다. 같은 데이터를 두 곳으로 함께 보내는 것도 됩니다.

밀리는 데이터를 버티는 장치

보내는 속도보다 받는 속도가 처지면 아직 못 보낸 데이터가 쌓입니다. Fluent Bit 은 그것을 버퍼에 담아 둡니다. 저장소가 잠깐 끊겨도 그동안 읽은 것을 들고 있다가 다시 붙으면 이어서 보냅니다.

버퍼에는 한도가 있습니다. 한도에 닿으면 새로 읽어 들이는 속도를 스스로 늦춥니다. 처리가 밀린 뒤 단계가 앞 단계를 붙잡아 세우는 이 동작을 백프레셔라고 합니다. 그래도 넘치면 뒤에 오는 것을 버립니다.

버퍼를 메모리에 두면 손이 덜 가고, 디스크에 두면 프로세스가 죽어도 남습니다. 둘 중 무엇을 쓸지는 잃어도 되는 양으로 정합니다. 끊겼다 다시 붙을 때는 재시도를 하므로 같은 줄이 두 번 도착할 수 있고, 받는 쪽이 그것을 견뎌야 합니다.

띄워 두는 위치

Fluent Bit 은 로그를 만드는 쪽 가까이에 둡니다. 기계마다 한 벌씩 띄워 그 기계의 모든 로그를 맡기는 방식이 흔합니다. 컨테이너 하나 옆에 붙여 그 컨테이너만 맡기기도 합니다. Kubernetes 에서는 앞의 것을 데몬셋으로, 뒤의 것을 사이드카 컨테이너로 띄웁니다.

앞단이 많아지면 중간에 모아 주는 계층을 하나 더 둡니다. 기계마다 뜬 것들이 그 계층으로 보내고, 그 계층이 한데 묶어 저장소로 보냅니다. 저장소에 붙는 연결 수가 줄고, 저장소를 바꿀 때 고칠 데도 그 계층 하나로 줄어듭니다.

flowchart TD
    subgraph 서버1["서버 1"]
        P1["애플리케이션"] --> A1["Fluent Bit"]
    end
    subgraph 서버2["서버 2"]
        P2["애플리케이션"] --> A2["Fluent Bit"]
    end
    A1 --> AG["모아 주는 계층"]
    A2 --> AG
    AG --> S["저장소"]

그림처럼 수백 대에 한 벌씩 뜨는 물건이라 한 벌이 먹는 몫이 작아야 합니다. 남의 기계에 얹혀 도는 처지이므로 애플리케이션이 쓸 메모리와 프로세서를 축내면 안 됩니다. 이 요구가 이 물건의 생김새를 거의 다 정했습니다.

가벼움을 얻으려고 내려놓은 것

Fluent Bit 은 C 로 쓰였고 실행 파일 하나로 돕니다. 프로그램을 돌리려고 미리 깔아 두어야 하는 런타임이 없고, 띄우는 데 걸리는 시간도 짧습니다. 그 대신 내려놓은 것이 있습니다.

내려놓은 것 무엇이 곤란해지나
붙일 수 있는 것의 가짓수 받아 오고 내보낼 수 있는 곳이 Fluentd 보다 적습니다. 없는 것은 직접 만들거나 뒤에 다른 물건을 세워야 합니다
품이 드는 가공 여러 줄을 묶어 셈하거나 다른 데이터와 맞춰 보는 일은 못 합니다. 그런 처리는 저장소나 뒤쪽 처리기가 맡습니다
확실한 전달 버퍼에 담긴 것을 미처 못 보내고 죽으면 사라집니다. 디스크 버퍼로 줄일 수는 있어도 없애지는 못합니다
긴 보관 데이터를 들고 있지 않습니다. 지나가게만 하므로 지난 기록을 찾아보려면 저장소가 따로 있어야 합니다

그래서 Fluent Bit 은 저장소나 분석 도구를 대신하지 않습니다. 모으고 다듬어 넘기는 구간만 맡습니다.

Fluentd 와의 관계

Fluent Bit 과 Fluentd 는 같은 집안에서 나온 형제입니다. 하는 일이 같고, 입력과 필터와 출력으로 짜인 구조도 같습니다. 이름표로 갈래를 나누는 방식까지 같습니다.

가른 것은 무게입니다. Fluentd 는 받아 오고 내보낼 수 있는 곳이 훨씬 많고 그만큼 먹는 몫도 큽니다. Fluent Bit 은 Fluentd 보다 가볍고, 대신 다룰 수 있는 것이 적습니다.

둘을 같이 쓰기도 합니다. 기계마다 Fluent Bit 을 띄워 모으게 하고, 모아 주는 계층에 Fluentd 를 세워 품이 드는 가공을 맡기는 짜임입니다.

관련 항목

Fluent Bit 이 실어 나르는 관측 신호

로그 · 메트릭 · 트레이스 · 텔레메트리 · 관측성 · OpenTelemetry

Fluent Bit 이 데이터를 읽어 들이는 입력원

표준 출력 · 표준 에러 · 로그 파일 · syslog · journald · 컨테이너 런타임 · 파일 디스크립터

Fluent Bit 이 데이터를 내보내는 저장소

Elasticsearch · OpenSearch · Loki · Kafka · Amazon S3 · CloudWatch · Cloud Logging · Prometheus

Fluent Bit 이 데이터를 다듬는 처리 단계

파싱 · 정규 표현식 · JSON · 구조화 로그 · 타임스탬프 · 로그 레벨 · 샘플링 · 라우팅

Fluent Bit 이 몰리는 데이터를 버티는 장치

버퍼 · 백프레셔 · 재시도 · 메시지 큐 · 디스크 · 메모리

Fluent Bit 을 띄우는 배포 단위

데몬셋 · 사이드카 컨테이너 · Kubernetes · 노드 수준 로깅 에이전트 · 에지 디바이스

Fluent Bit 과 같은 역할을 두고 겨루는 수집기

Fluentd · Logstash · Vector · Filebeat · OpenTelemetry Collector · rsyslog

Fluent Bit 이 속하는 상위 분류

데이터 파이프라인 · 로그 수집기 · 인프라 · CNCF · 객체 저장소

다른 이름: 플루언트비트