1 개요
- 버퍼링 및 스토리지
Fluent Bit의 최종 목표는 로그를 수집, 구문분석, 필터링하고 중앙 위치로 전달하는 것입니다. 이 워크플로우에는 여러 단계가 있으며 중요한 부분 중 하나는 버퍼링 기능입니다 . 버퍼링은 배송 준비가 될 때까지 처리된 데이터를 임시 위치에 배치하는 메커니즘입니다.
기본적으로 Fluent Bit는 데이터를 처리할 때 메모리를 레코드를 저장하기 위한 기본 및 임시 장소로 사용하지만, 집계 및 데이터 안전 기능을 제공하기 위해 파일 시스템 기반의 영구 버퍼링 메커니즘을 갖는 것이 이상적인 특정 시나리오가 있습니다.
올바른 설정을 선택하는 것은 중요하며 서비스 동작은 백프레셔 세팅에 따라 조절될 수 있습니다. 설정을 시작하기 전에 청크, 메모리, 파일시스템, 백프레셔 사이의 관계를 이해했는지 확인하겠습니다.
2 청크, 메모리, 파일시스템, 백프레셔
적절한 설정을 위해서는 청크, 버퍼링, 백프레셔 개념을 이해하는 것이 중요합니다. 이러한 개념의 의미를 요약해 보겠습니다.
2.1 청크
입력 플러그인(소스)이 레코드를 내보내면 엔진은 해당 레코드를 청크로 그룹화합니다. 청크 크기는 일반적으로 약 2MB입니다. 설정에 따라 엔진은 이 청크를 배치할 위치를 결정하며, 기본값은 모든 청크가 메모리에만 생성되는 것입니다.
2.2 복구할 수 없는 청크
fluent-bit가 청크를 복구 불가능으로 표시하는 경우는 다음 두 가지 시나리오입니다.
- Fluent Bit가 청크에서 잘못된 레이아웃을 발견한 경우. 잘못된 레이아웃은 예상 형식을 따르지 않는 청크입니다 (청크의 정의)
- Fluent Bit가 잘못되었거나 유효하지 않은 청크 헤더 크기를 발견한 경우
두 시나리오 모두에서 Fluent-Bit은 오류 메시지를 기록한 다음 복구할 수 없는 청크를 삭제합니다.
2.3 버퍼링과 메모리
위에서 언급했듯이 엔진에서 생성된 청크는 메모리에 배치되지만 이는 설정가능합니다.
메모리가 입력 플러그인에 대해 설정된 유일한 메커니즘인 경우 메모리는 가능한 한 많은 데이터를 거기(메모리)에 저장합니다. 이는 시스템 오버헤드가 가장 적은 가장 빠른 메커니즘이지만 느린 네트워크나 응답하지 않는 원격 서비스로 인해 서비스가 레코드를 충분히 빠르게 전달할 수 없는 경우, 전달할 수 있는 것보다 더 많은 데이터를 축적하므로 Fluent Bit 메모리 사용량은 증가합니다.
백프레셔가 있는 고부하 환경에서는 메모리 사용량이 높아질 위험이 있으며 커널(OOM Killer)에 의해 종료(kill)될 가능성이 있습니다. 이 백프레셔 시나리오에 대한 회피방법(workaround)은 입력 플러그인이 등록할 수 있는 레코드의 메모리 양을 제한하는 것입니다. 이러한 설정 속성이 mem_buf_limit입니다. 플러그인이 mem_buf_limit보다 많은 항목을 큐에 추가한 경우 해당 데이터가 적절하게 전달되거나 플러시될 때까지 더 많은 항목을 수집할 수 없습니다. 이 시나리오에서는 문제의 입력 플러그인이 일시중지되었습니다. 입력이 일시중지되면 재개될 때까지 레코드가 수집되지 않습니다. TCP나 tail과 같은 일부 입력의 경우 입력을 일시중지하면 거의 확실하게 로그 손실이 발생합니다. tail 입력의 경우 Fluent Bit는 읽고 있는 현재 파일에 현재 오프셋을 저장하고 입력이 재개되면 백업을 선택할 수 있습니다.
Fluent Bit 로그 출력에서 다음과 같은 메시지를 찾습니다.
[input] tail.1 paused (mem buf overlimit)
[input] tail.1 resume (mem buf overlimit)
mem_buf_limit 회피방법은 특정 시나리오 및 환경에 적합하고 서비스의 메모리 사용량을 제어하는 데 도움이 되지만, 일시중지된 동안 파일이 회전되면 새 레코드를 등록할 수 없으므로 해당 데이터가 손실될 수 있습니다. 이는 모든 입력 소스 플러그인에서 발생할 수 있습니다. mem_buf_limit의 목표는 메모리 조절과 서비스의 생존입니다.
완전한 데이터 안전을 보장하려면 파일 시스템 버퍼링을 사용하십시오.
다음은 입력 정의의 예입니다.
[INPUT]
Name tcp
Listen 0.0.0.0
Port 5170
Format none
Tag tcp-logs
Mem_Buf_Limit 50MB
이 입력이 로그 버퍼링에 50MB가 넘는 메모리를 사용하는 경우, Fluent Bit 로그에 다음과 같은 경고가 표시됩니다.
[input] tcp.1 paused (mem buf overlimit)
Mem_Buf_Limit는 storage.type가 기본값인 memory으로 설정된 경우에만 적용됩니다. 아래 섹션에서는 storage.type filesystem을 활성화할 때 적용되는 제한사항을 설명합니다.
2.4 구조를 위한 파일 시스템 버퍼링
파일 시스템 버퍼링을 활성화하면 백프레셔 및 전반적인 메모리 조절에 도움이 됩니다.
그 이면에는 메모리와 파일시스템 버퍼링 메커니즘은 상호 배타적이지 않습니다. 실제로 입력 플러그인(소스)에 대해 파일 시스템 버퍼링을 활성화하면 성능과 데이터 안전성이라는 두 가지 장점을 얻을 수 있습니다.
파일시스템 버퍼링이 활성화되면 엔진의 동작이 달라집니다. 을 통해) 디스크에 복사본을 매핑합니다 . 새로 생성된 청크는 (1) 메모리에서 활성화되고 (2) 디스크에 백업되며 (3) up"청크 내용이 메모리에 있음"을 의미하도록 호출됩니다.
파일 시스템 버퍼링 메커니즘은 높은 메모리 사용량과 역압을 어떻게 처리합니까? Fluent Bit는 메모리에 있는 청크 수를 제어합니다 up.
기본적으로 엔진은 메모리에 총 128개의 청크(모든 청크 고려)를 가질 수 있도록 허용하며 up, 이 값은 서비스 속성에 의해 제어됩니다 storage.max_chunks_up. 전달 준비가 완료된 활성 청크 up와 아직 기록을 수신 중인 청크입니다. 다른 나머지 청크는 상태에 있습니다 down. 이는 해당 청크가 파일 시스템에만 있고 up전달될 준비가 되지 않는 한 메모리에 있지 않음을 의미합니다. 청크는 2MB보다 훨씬 크지 않으므로 기본값 storage.max_chunks_up128을 사용하면 각 입력은 대략 256MB의 메모리로 제한됩니다.
입력 플러그인이 storage.type다음과 같이 활성화된 경우 임계값 filesystem에 도달하면 storage.max_chunks_up플러그인이 일시 중지되는 대신 모든 새 데이터가 down파일 시스템에 있는 청크로 이동됩니다. 이를 통해 서비스의 메모리 사용량을 제어할 수 있으며 서비스에서 데이터가 손실되지 않는다는 보장도 제공됩니다. 기본적으로 제한은 storage.max_chunks_up최선의 방식으로 적용됩니다. Fluent Bit는 다음과 같은 청크에만 새 데이터를 추가할 수 있습니다 up. 제한에 도달하면 청크가 임시로 up메모리에 저장되어 새 데이터를 수집한 다음 down나중에 상태로 전환됩니다. 일반적으로 Fluent Bit는 총 up청크 수를 storage.max_chunks_up.
활성화된 경우 storage.pause_on_chunks_overlimit(기본값은 꺼짐), 를 초과하면 입력 플러그인이 일시 중지됩니다 storage.max_chunks_up. 따라서 이 옵션을 사용하면 storage.max_chunks_up입력에 대한 하드 제한이 됩니다. 입력이 일시 중지되면 재개될 때까지 레코드가 수집되지 않습니다. TCP 및 tail과 같은 일부 입력의 경우 입력을 일시 중지하면 거의 확실하게 로그 손실이 발생합니다. 테일 입력의 경우 Fluent Bit는 읽고 있는 현재 파일에 현재 오프셋을 저장하고 입력이 재개되면 백업을 선택할 수 있습니다.
Fluent Bit 로그 출력에서 다음과 같은 메시지를 찾아볼 수 있습니다.
[input] tail.1 paused (storage buf overlimit
[input] tail.1 resume (storage buf overlimit
2.5 청크에 대한 파일시스템 공간 제한
Fluent Bit는 논리적 큐 개념을 구현합니다. 태그를 기반으로 청크를 여러 대상으로 라우팅할 수 있습니다. 따라서 우리는 청크가 생성된 위치와 이동해야 하는 위치에 대한 내부 참조를 유지합니다.
청크에 대한 여러 대상이 있는 경우 대상 중 하나가 다른 대상보다 느릴 수 있거나 하나가 역압을 생성하지만 전부는 아닌 경우를 찾는 것이 일반적입니다. 이 시나리오에서 논리적으로 큐에 추가되는 파일 시스템 청크의 양을 어떻게 제한합니까?
Fluent Bit v1.6부터 storage.total_limit_size특정 논리적 출력 대상에 대해 파일 시스템에 존재할 수 있는 청크의 총 크기(바이트)를 제한하는 출력 플러그인에 대한 새로운 구성 속성을 도입했습니다. 대상 중 하나가 구성된 에 도달하면 storage.total_limit_size해당 논리적 출력 대상에 대한 큐에서 가장 오래된 청크가 삭제되어 새 데이터를 위한 공간을 확보합니다.
3 설정
스토리지 계층 설정은 다음 세 가지 영역으로 이루어집니다.
- 서비스 섹션
- 입력 섹션
- 출력 섹션
알려진 서비스 섹션은 스토리지 계층에 대한 전역 환경을 설정하고, 입력 섹션은 사용할 버퍼링 메커니즘을 정의하며, 출력은 논리적 파일 시스템 큐에 대한 제한을 정의합니다.
3.1 서비스 섹션 설정
서비스 섹션은 기본 설정 파일에 정의된 섹션을 참조합니다.
| 키 | 설명 | 기본값 |
|---|---|---|
| storage.path | 스트림과 데이터 청크를 저장할 파일 시스템의 선택적 위치를 설정합니다. 이 매개변수가 설정되지 않으면 입력 플러그인은 메모리 내 버퍼링만 사용할 수 있습니다. | |
| storage.sync | 데이터를 파일 시스템에 저장하는 데 사용되는 동기화 모드를 구성합니다. Normal 또는 full 값을 사용할 수 있습니다 . 전체를 사용하면 파일 시스템 버퍼의 안정성이 향상되고 Fluent Bit가 충돌하더라도 데이터가 파일 시스템에 동기화되도록 보장됩니다. Linux에서 full은 MAP_SYNC 옵션 에 해당합니다. | normal |
| storage.checksum | 파일시스템에서 데이터를 쓰고 읽을 때 데이터 무결성 검사를 활성화합니다. 스토리지 계층은 CRC32 알고리즘을 사용합니다. | Off |
| storage.max_chunks_up | 입력 플러그인이 filesystem저장소 유형을 활성화한 경우 이 속성은 메모리에 있을 수 있는 최대 청크 수를 설정합니다 up. 활성화할 때 메모리 사용량을 제어하는 데 사용하는 설정입니다 storage.type filesystem. | 128 |
| storage.backlog.mem_limit | storage.path가 설정된 경우 Fluent Bit는 전달되지 않았지만 여전히 스토리지 계층에 있는 데이터 청크를 찾습니다. 이를 백로그 데이터라고 합니다. 백로그 청크는 이전 Fluent Bit 실행에서 남은 파일 시스템 청크입니다. 다시 시작할 때 Fluent Bit가 선택하는 종료 전에 보낼 수 없는 청크입니다. Fluent Bit는 입력에 대한 storage.backlog.mem_limit모든 청크의 현재 메모리 사용량과 비교하여 값을 확인합니다 . 청크가 현재 제한보다 적은 메모리를 소비하는 up경우 백로그 청크를 메모리로 가져와 출력으로 전송할 수 있습니다. | 5M |
| storage.metrics | http_server기본 섹션에서 옵션이 활성화된 경우 [SERVICE]이 옵션은 스토리지 계층의 내부 메트릭을 사용할 수 있는 새 엔드포인트를 등록합니다. 모니터링 섹션을 참조하세요. | off |
| storage.delete_irrecoverable_chunks | 활성화되면 런타임 중에 삭제되고, 설정된 저장 경로 디렉터리에 있는 다른 복구할 수 없는 청크는 Fluent-Bit이 시작될 때 삭제됩니다. | off |
서비스 섹션은 다음과 같이 생겼습니다.
[SERVICE]
flush 1
log_Level info
storage.path /var/log/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
해당 구성은 데이터 경로가 /var/log/flb-storage/인 선택적 버퍼링 메커니즘을 설정하며, 백로그 데이터를 처리할 때 체크섬을 실행하지 않고 최대 5MB의 메모리를 사용하여 일반 동기화 모드를 사용합니다.
3.2 입력 섹션 설정
선택적으로 모든 입력 플러그인은 스토리지 기본설정을 설정할 수 있습니다. 다음 표에서는 사용가능한 옵션을 설명합니다.
| 키 | 설명 | 기본값 |
|---|---|---|
| storage.type | 사용할 버퍼링 메커니즘을 지정합니다. memory(메모리) 또는 filesystem(파일시스템)일 수 있습니다. | memory |
| storage.pause_on_chunks_overlimit | storage.max_chunks_up 값에 도달 하면 입력 플러그인을 일시중지(새 데이터 수집 중지)해야 하는지 여부를 지정합니다. | off |
다음 예시에서는 파일시스템 버퍼링 기능과 두 개의 입력 플러그인(첫 번째는 파일시스템 기반, 두 번째는 메모리 전용)을 제공하는 서비스를 설정합니다.
[SERVICE]
flush 1
log_Level info
storage.path /var/log/flb-storage/
storage.sync normal
storage.checksum off
storage.max_chunks_up 128
storage.backlog.mem_limit 5M
[INPUT]
name cpu
storage.type filesystem
[INPUT]
name mem
storage.type memory
3.3 출력 섹션 설정
특정 청크가 파일시스템 storage.type 기반인 경우, 출력 플러그인에 대한 논리적 큐의 크기를 조절할 수 있습니다. 다음 표에서는 사용가능한 옵션을 설명합니다.
| 키 | 설명 | 기본값 |
|---|---|---|
| storage.total_limit_size | 현재 출력 논리적 대상에 대한 파일 시스템의 청크 버퍼링을 위한 최대 디스크 공간 크기(바이트)를 제한합니다. |
다음 예시에서는 파일시스템에 CPU 사용량 샘플이 포함된 레코드를 생성한 후 논리적 큐(버퍼링)을 5M로 제한하는 Google Stackdriver 서비스에 전달합니다.
[SERVICE]
flush 1
log_Level info
storage.path /var/log/flb-storage/
storage.sync normal
storage.checksum off
storage.max_chunks_up 128
storage.backlog.mem_limit 5M
[INPUT]
name cpu
storage.type filesystem
[OUTPUT]
name stackdriver
match *
storage.total_limit_size 5M
어떤 이유로 Fluent Bit가 네트워크 문제로 인해 오프라인 상태가 되면 CPU 샘플을 계속 버퍼링하지만 최신 데이터는 최대 5MB만 유지합니다.
4 참고
-
{{comment.page_title}} ―{{comment.name}}