cloudwithbass

[Fluent Bit] About Fluent Bit, Concept of Fluent Bit 본문

Monitoring & Logging

[Fluent Bit] About Fluent Bit, Concept of Fluent Bit

여영클 2024. 11. 19. 22:30
  • Fluent Bit의 공식 문서에서 ABOUT, CONCEPTS 섹션의 내용을 번역한 글입니다.
  • Fluent Bit의 개념을 빠르게 알 수 있도록 제가 생각하는 핵심 사항들을 요약해서 작성했습니다.
  • 따라서 Fluent의 역사, 라이센스 등 기술적 개념과 연관성이 적은 항목은 생략했습니다. 이러한 자세한 내용들은 공식 문서를 참고바랍니다.

 

목차

    ABOUT

     

    1. What is Fluent Bit?

    Fluent Bit는 제한된 시스템부터 복잡한 클라우드 인프라까지, 광범위한 환경에서 원격 측정 데이터를 처리하고 수집하는 어려움을 효율적으로 처리하기 위해 설계된 오픈 소스 원격 측정(telemetry) 에이전트입니다.

     

    Fluent Bit는 로깅 계층을 최적화하고 메트릭과 추적 처리 과정을 추가하여 여러분의 인프라에 대한 관측 가능성 전략을 향상시킵니다.

     

    Fluent Bit는 벤더 중립적 접근을 지원하므로, Prometheus나 OpenTelemerty 같은 다른 생태계와 매끄럽게 통합할 수 있습니다.

     

    Fluent Bit는 최상의 성능을 지속시키고 리소스 사용량을 적게 유지하면서 다양한 데이터 소스와 형식을 효율적으로 관리할 수 있습니다.

     

    Introduction to fluentbit

    2. Fluentd & Fluent Bit

    특히 시스템이 광범위한 경우, 원격 측정 데이터 처리는 복잡할 수 있습니다. 이것이 Fluent가 만들어진 이유입니다.

    Fluentd는 단순한 도구가 아니라, Fluent Bit와 같은 하위 프로젝트와 다양한 언어를 위한 SDK를 포함하도록 하는 생태계속에서 성장했습니다.

     

    이 문서에서 우리는 Fluentd와 Fluent Bit 오픈 소스 프로젝트 사이의 관계를 설명합니다.

     

    공통점

    • Apache License v2.0에 따라 라이센스되었습니다. (Licensed under the terms of Apach License v2.0.)
    • 매일 수백만 번 배포됩니다.
    • 산업에서 넓게 채택됩니다: AWS, Microsoft, Google Cloud, 그리고 다른 수백가지 메이저 회사들에게 신뢰받습니다.

     

    그 프로젝트들(Fluentd, Fluent Bit)은 많은 유사성이 있습니다: Fluent Bit는, Fluentd 아키텍처와 일반적 디자인의 best idea를 바탕으로 설계되고 구축되었습니다. 둘 중 무엇을 선택할 지는 최종 사용자의 요구에 달렸습니다.

     

    Attribute Fluentd Fluent Bit
    Scope 컨테이너 / 서버 임베디드 리눅스 / 컨테이너 / 서버
    Language C & Ruby C
    *Memory 60 MB 이상 대략 1MB
    Performance 중간 성능 고성능
    Dependencies **다른 gem들에 의존한 Ruby Gem 플러그인이 요구되는 경우가 아니면 의존성 없음
    Plugins 1,000개 이상의 외부 플러그인 100개 이상의 내장 플러그인
    License Apache License v2.0 Apache License v2.0

     

    * 각 도구가 사용하는 메모리 사용량을 뜻합니다.

    ** 원문은 Built as a Ruby Gem, depends on other gems입니다. Ruby Gem은 Ruby 언어에서 사용하는 라이브러리나 애플리케이션을 패키지화한 형식을 의미합니다.

     

    종합적으로, Fluent Bit는 Fluentd보다 플러그인이 적지만 메모리를 적게 사용하며 성능이 높고, 의존성이 없습니다.

     

    Fluentd와 Fluent Bit는 모두 수집기나 Forwarder로 작동할 수 있으며, 서로를 보완하거나 단독으로만 사용할 수 있습니다.

     

    최근 클라우드 제공업체는 성능과 경쟁력을 위해 Fluentd에서 Fluent Bit로 전환했습니다.  Fluent Bit은 이제 차세대 솔루션으로 간주됩니다.

     

    참고: Fluentd는 퍼포먼스 이슈로 인해 2023년 10월에 AWS에서 Fluentd 지원이 중단되었습니다.

     

    CONCEPTS

    1. Key Concepts

    Fluent Bit가 어떻게 작동하는지 이해하기 위해 핵심 개념들을 배웁니다.

    이 문서를 읽으면 다음 주제를 이해하는 데 도움이 됩니다:

    • Event or Record
    • Filtering
    • Tag
    • Timestamp
    • Match
    • Structured Message

     

    Event or Record

    Fluent Bit가 검색한 로그나 메트릭에 속한 모든 데이터는, Event 또는 Record로 간주됩니다.

     

    예를 들어 다음과 같은 Syslog 파일이 있습니다.

    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)

    이 파일은 네 개의 독립된 Event를 나타내는 네 개의 라인이 포함되어 있습니다.

     

    Event는 다음 항목들로 구성됩니다:

    • 타임 스탬프
    • key-value 메타데이터 (v2.1.0 이상)
    • 페이로드 (전송되는 데이터 자체)

    Event Format

    Fluent Bit 와이어 프로토콜은 Fluent Bit가 사용하는 내부 통신 형식입니다.

    위 Syslog 예시와 같은 이벤트를 아래와 같은 2차원 배열로 나타냅니다. 

    [[TIMESTAMP, METADATA], MESSAGE]

     

     

    Filtering

    여러분은 Event의 내용을 수정해야 할 수가 있습니다. 

    이벤트를 변경, 추가, 삭제하는 과정을 Filtering이라고 합니다.

     

    다음과 같은 경우 Filtering을 사용합니다. 

    • IP 주소와 같은 구체적인 정보를 추가하기
    • 이벤트 내용의 특정 부분을 선택하기
    • 특정 패턴과 일치하는 이벤트 삭제하기

     

    Tag

    Fluent Bit에서 수집한 모든 이벤트에는 Tag가 할당됩니다.

    이 태그는 라우터가 이후 단계에서 어떤 필터나 Output 단계를 거쳐야할지 결정하는 데 사용됩니다.

    대부분의 태그는 구성될 때 수동으로 할당됩니다.

    만약 태그가 특정되지 않으면, Fluent Bit는 해당 이벤트가 생성된 Input 플러그인 인스턴스의 이름을 할당합니다.

    플러그인에 대한 내용은 '3. Data Pipeline' 섹션에서 설명합니다.

     

    태그가 있는 Record는 반드시 일치 규칙(Matching rule)이 있어야 합니다. Tag와 Matches에 대한 더 자세한 사항은 Routing 문서를 참고하세요.

     

     

    TimeStamp

    Timestamp는 이벤트가 생성된 시간을 나타냅니다. 모든 이벤트는 관련 TimeStamp를 포함합니다.

    모든 이벤트는 타임 스탬프를 갖으며, 이 타임스탬프 input plugin에 의해 설정되거나 데이터 파싱 과정에서 발견됩니다.

     

    타임 스탬프는 다음 형식의 소수가 있는 정수(numeric fractional integer)입니다:

    SECONDS.NANOSECONDS

     

    SECONDS는 Unix epoch 이후로 경과된 초의 숫자입니다.

    참고: Unix epoch는 1970년 1월 1일 00:00:00 UTC를 기준으로 합니다.

    NANOSECONDS는 10억분의 1(1 나노초)를 나타냅니다.

     

    MATCH

    Fluent Bit는 수집되고 처리된 이벤트들을 하나 이상의 목적지로 라우팅할 수 있게 합니다

    MATCH는 Tag가 정의된 규칙과 일치하는 이벤트를 선택하기 위한 규칙을 나타냅니다.

    Routing 문서를 참고하세요.

     

    Structured messages

    소스 이벤트는 구조적일 수 있습니다.

    Structure는 이벤트 메시지 내에서 key와 value의 집합을 정의합니다. 이건 데이터를 빠르게 수정하기 위함입니다.

     

    다음 두 메시지를 예시로 들겠습니다

     

    No structured message

    "Project Fluent Bit created on 1398289291"

     

    With a structured message

    {"project": "Fluent Bit", "created": 1398289291}

     

    성능적인 이유로, Fluent Bit는 MessagePack이라고 불리는, 이진 직렬화된 데이터 방식을 사용합니다.

     

    2. Buffering

    Fluent Bit가 데이터를 처리할 때, 시스템 메모리를 주 or 임시 저장소로 사용하여 레코드 로그가 전달되기 전, 이들을 저장합니다.

     

    Buffering은 기록들을 저장하고, 들어오는 데이터를 지속적으로 저장하는 기능입니다. 메모리에서 버퍼링은 가장 빠른 메커니즘이지만, backpressure, 데이터 보안을 처리하거나 메모리 소모량을 줄일 특별한 전략이 있습니다.

     

     

    Fluent Bit의 버퍼링 전략은 네드워크 장애나 지연은 backpressure와 일반적인 전송 실패 관련 문제를 해결하도록 설계되었습니다.

     

    Fluent Bit는 두 메커니즘을 제공합니다.

    • 메모리에서 사용되는 주 버퍼링 메커니즘
    • (선택 사항) 파일 시스템을 이용한 보조 버퍼링 메커니즘

    이 하이브리드 솔루션을 사용하면 여러분은 어떤 사례라도 안전하게 수용하고, 데이터 처리 시간 동안 고성능을 유지할 수 있습니다.

     

    이러한 메커니즘들은 상호 배타적이지 않습니다. 데이터 처리되고 전달된 준비가 될 때엔 항상 메모리에 존재합니다. 반면 큐에 있는 다른 데이터는 처리될 준비가 되고 메모리로 이동할 때까지 파일 시스템에 존재해도 됩니다. 

     

    버퍼링 구성에 대한 더 자세한 내용은 Buffering & Storage 문서를 참고해주세요.

     

    3. Data Pipeline

    https://docs.fluentbit.io/manual/concepts/data-pipeline/input

     

    이 섹션에선 Input부터 Output까지 차례로 설명합니다.

     

    Input

    Fluent Bit는 다양한 소스로부터 데이터를 수집하는 input 플러그인을 제공합니다.

    몇몇 플러그인은 로그 파일들로부터 데이터를 수집하며, OS로부터 데이터를 수집하는 플러그인도 있습니다.

    다양한 요구들에 적합한 플러그인들이 존재합니다.

     

    input 플러그인이 로드될 때, 내부 인스턴스가 생성됩니다. 각각의 인스턴스는 자기만의 독립적인 구성을 갖습니다.

    구성 키를 property라고도 합니다.

     

    모든 input 플러그인은 사용 방법과 어떤 property를 사용할 수 있는지에 대한 정보가 포함된 공식 문서가 있습니다.

    더 자세한 내용은 Input Plugins 문서를 참고하세요.

     

     

    Parser

    구조화되지 않은 메시지나 raw string 형태의 메시지를 처리하는 것은 어렵습니다. 그래서 구조화시키는 것은 데이터를 더욱 사용성있게 합니다. 데이터가 수집될 때 input 플러그인을 사용해서 데이터 구조를 설정하세요.

     

    Parser는 비구조화된 데이터를 구조화된 데이터로 변경합니다. 예를 들어, 다음 Apache 로그를 보겠습니다.

    192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395

     

    이 로그는 형식이 없는 raw string 형태의 메시지입니다. 이 메시지를 구조화하는 것은 나중에 데이터를 처리하기 쉽도록 만듭니다. 만약 regular expression parser를 사용하면, 이 로그는 다음과 같이 변경됩니다.

    {
  "host":    "192.168.2.20",
  "user":    "-",
  "method":  "GET",
  "path":    "/cgi-bin/try/",
  "code":    "200",
  "size":    "3395",
  "referer": "",
  "agent":   ""
 }

     

    Parser는 완전히 구성 가능하며, 독립적이고 선택적으로 각 input 플러그인에 의해 처리됩니다.

    더 자세한 사항은 Parsers 문서를 참고하세요.

     

    Filter

    프로덕션 환경에서 여러분은 수집하는 데이터를 완전히 제어할 필요가 있습니다. Filtering은 데이터를 목적지로 전송하기 전에, 데이터를 변경할 수 있게 합니다.

     

    Filtering은 플러그인을 통해 시행됩니다. 각 사용가능한 필터는 여러분의 로그를 일치, 제외, 강화할 수 있습니다.

     

    Fluent Bit는 많은 피러를 지원합니다. 필터링의 일반적인 사용 사례는 Kubernetes deployment입니다.

    모든 Pod 로그는 그것과 연관된 적절한 메타데이터가 필요합니다.

     

    Input 플러그인처럼 필터는 자신만의 독립적인 구성을 갖는 인스턴스 context에서 실행됩니다.

    구성 키를 property라고도 합니다.

     

    더욱 자세한 내용은 Filters 문서를 참고하세요.

     

    Buffer

    Buffer 단계의 목표는 in-memory 모델 또는 file system-based 모드를 사용하여 통합적이고 지속적인 데이터 저장 메커니즘을 제공하는 것입니다.

     

    Buffer 단계는 변경할 수 없는 상태의 데이터를 포함합니다. 이건 필터가 적용될 수 없다는 의미입니다.

     

    버퍼된 데이터는 raw text가 아닌, Fluent Bit 내부의 이진 표현을 사용합니다.

     

    Fluent Bit는 데이터 손실을 피하기 위해 백업 시스템 용도로 사용되는 file system 메커니즘을 제공합니다.

     

    Router

    Routing은 필터링된 데이터를 하나 이상의 목적지로 전송할 수 있게 해주는 핵심 특성입니다.

    라우터는 Tag와 Matching 규칙의 개념에 의존합니다.

     

    데이터가 Input 플러그인에 의해 생성될 때 Tag가 붙습니다. Tag는 사람이 읽을 수 있는 지표이며, 데이터 출처가 어디인지 식별하는 데 도움을 줍니다. Tag는 보통 자동으로 생성됩니다.

     

    데이터를 어디로 라우팅할 지 정의하기 위해, Output 구성에 Match 규칙을 설정합니다.

     

    아래의 예시는CPU 메트릭을 Elasticsearch DB로, 메모리 메트릭을 표준 output interface로 라우팅합니다.

    [INPUT]
    Name cpu
    Tag  my_cpu

[INPUT]
    Name mem
    Tag  my_mem

[OUTPUT]
    Name   es
    Match  my_cpu

[OUTPUT]
    Name   stdout
    Match  my_mem

     

    Routing은 Input Tag와 Output Match 규칙을 읽습니다. 데이터가 일치하지 않은 Tag를 갖고 있는 경우, 이 데이터는 삭제됩니다.

     

    다음 예시처럼 와일드 카드를 사용할 수 있습니다.

    [INPUT]
    Name cpu
    Tag  my_cpu

[INPUT]
    Name mem
    Tag  my_mem

[OUTPUT]
    Name   stdout
    Match  my_*

     

     

    다음 예시처럼 Regex(정규 표현식)를 지원합니다.

    [INPUT]
    Name temperature_sensor
    Tag  temp_sensor_A

[INPUT]
    Name humidity_sensor
    Tag  humid_sensor_B

[OUTPUT]
    Name         stdout
    Match_regex  .*_sensor_[AB]

     

    정규 표현식인 '.*_sensor_[AB]'는 '_sensor_A' 또는 '_sensor_B'로 끝나는 태그와 매칭합니다.

    이 접근법은 더욱 유연하고 강력하게 데이터를 처리할 수 있도록 합니다.

     

    Output

    Output 인터페이스는 데이터의 목적지를 정의합니다. 흔히 사용되는 목적지는 원격 서비스나 로컬 파일 시스템, 또는 다른 표준 인터페이스입니다.

    Output은 플러그인에 의해 시행됩니다.

     

    Ouput 플러그인이 로드될 때, 내부 인스턴스가 생성됩니다.  각각의 인스턴스는 자기만의 독립적인 구성을 갖습니다.

    구성 키를 property라고도 합니다.

     

    모든 Output 플러그인은 사용 방법과 어떤 property를 사용할 수 있는지에 대한 정보가 포함된 공식 문서가 있습니다.

     

    더 자세한 내용은 Output Plugins 문서를 참고하세요.