fluent bit 트러블 슈팅

이번 게시글에서는 fluent bit의 에러로그와 해결방법에 대해 정리합니다.

 

1. fluent bit이란 

수집기의 한 종류로 다양한 input과 output을 지원하는 솔루션입니다.

쿠버네티스 로그수집기로 사용한다면 

도커 컨테이너가 제공하는 /var/log/containers 아래의 로그파일을 읽어 외부로 보낸는데 사용되는 솔루션입니다.
구축방법과 아키텍쳐는 아래 게시글을 참고해주세요

[devops] fluent bit 으로 k8s(eks)로그 관리하기(bluent-bit 사용법, EFK)

 

 

2. fluent bit 동작원리 및 에러로그 분석

fluent bit을 로그수집기로 사용하게 되면 /var/log/containers 아래의 로그파일을 읽어와서 지정된 output으로 http request를 보냅니다.
별다른 이슈가 없다면 cpu와 memory 위주로 사용하게 되며  cpu memory가 부족할것 같다면 fluent bit 데몬셋의 cpu, memory limit을 조절해줄 수 있습니다.(노드의 리소스가 넉넉하다면)

 

그러나 cpu, memory limit을 넉넉하게 해놨는데도 아래와 같은 로그가 떨어지는 경우가 발생합니다.
(아래 로그는 fluent bit의 output이 kinesis firehose 로 지정되어 있는 상황이지만 에러의 원인과 조치방법만 알고있다면 output의 종류 는 크게 문제가 되지 않습니다.)

[2022/07/21 05:44:21] [error] [output:kinesis_firehose:kinesis_firehose.11] Failed to send log records to XX
[2022/07/21 05:44:21] [error] [output:kinesis_firehose:kinesis_firehose.11] Failed to send log records
[2022/07/21 05:44:21] [error] [output:kinesis_firehose:kinesis_firehose.11] Failed to send records
[2022/07/21 05:44:21] [ warn] [engine] failed to flush chunk '1-1658382261.194783957.flb', retry in 6 seconds: task_id=3, input=tail.11 > output=kinesis_firehose.11 (out_id=11)
[2022/07/21 05:44:27] [ info] [engine] flush chunk '1-1658382261.194783957.flb' succeeded at retry 1: task_id=3,
input=tail.11 > output=kinesis_firehose.11 (out_id=11)

 

fluent bit은 output으로 http request를 보냈을때 output 서버의 특정 문제(일반적으로 limit을 초과하는경우가 많습니다)로 데이터 전송에 실패하게되면 먼저 전송에 실패했다고 에러로그를 찍습니다. 

([error] [output:kinesis_firehose:kinesis_firehose.11] Failed to send log records to XX)

 

실패했다고 해당 데이터가 유실된건 아닙니다. fluent bit은 실패한 케이스는 retry를 하도록 개발되어있습니다.

실패하게 되면 chunk파일을 만들어 디스크에 저장한 후 새로운 스레드를 만들어 retry를 하게 됩니다.

 

3. 대처방법

해당문제는 주로 fluent bit의 output으로 지정된 서버의 limit이 너무 작아 request가 timeout에 걸리가 되고 fluent bit이 retry를 하게 되는 경우에 발생하며 가장 위험합니다.

limit이 초과하게 된 상황에서 계속해서 output이 발생하게 되면 retry 정보를 chunk 파일로 저장하게 되므로 디스크의 남은 용량이 점점 줄어들게 되며 retry를 위한 스레드도 계속해서 생성되므로 메모리도 폭발하고 retry request가 쌓이다보니 엄청난 네트워크 요청이 쌓이게 되고 최악의 경우 클러스터 전체에 무리를 주는 결과까지 초래할 수 있습니다.

기존 chunk파일을 무시하고자 하는 마음에 pod을 재시작하게 되더라도 fluent bit은 chunk파일이 있다면 retry를 위한 스레드를 생성하게 되므로 해결되지 않습니다.

 

이럴경우 해당 노드에 접근해 강제로 chunk파일을 삭제해주면(필요시 백업) fluent bit은 정상적으로 돌아오며 output 서버의 limit을 증대시켜주면 fluent bit은 정상적으로 동작하게 됩니다.

output으로 kinesis 등의 버퍼역활을 할수 있는 솔루션을 사용하거나, kafka등을 구축하여 해결할 수 있습니다.

또한 네트워크 비용과 속도에 문제가 발생한다면 fluent bit filter의 use_kubelet옵션과
daemonset의 hostNetwork, dnsPolicy 등의 옵션을 검토해 불필요한 네트워크 비용을 줄이고(불필요한 IGW를 타지 않도록) 속도를 개선할 수 있습니다.