잘생긴 로그 수집기, Fluentd 플루언트디

Fluentd 로고

읽는법 : 플루언디 (t는 묵음) 혹은 플루언트디 로 읽히는 것 같다.

 

File, Syslog 등등 아주아주 다양한 형식의 로그를 필터를 거쳐 한 군데로 모아주는 역할을 한다.

Graylog, ELK 처럼 시각화하거나 분석해주는 기능은 없다.

그래서 주로 그런 친구들과 붙어서 사용한다.

 

회사에서 로그 파일들을 모아 디비에 저장하는 프로그램을 찾았는데 아주 적합하다.

 

개인적으로 아주 호감인 것은 문법이 굉장히 직관적이다.

XML 과 비슷하게 생겼고, 보자마자 바로 이해할 만하다.

 

 

 

 

네네 이런 구조랍니다~

이런 형식의 인풋 아웃풋과 아주 다양한 파일형태를 수용한다.

Fluentd 에서 타 서버의 Fluentd로 연동이 되는 모습

 

 

conf 파일을 보자. 문법이 아주 직관적이다.

<source>
  @type tail
  path /logdata/access/*.com.log,/logdata/access/*.net.log,/logdata/access/*.kr.log
  exclude_path ["/logdata/access/*.gz", "/logdata/access/*.zip" ]
  pos_file /var/log/td-agent/nginx-access.log.pos
  tag nginx.raw
  refresh_interval 1s
</source>

<source>
  @type http
  port 9880
  bind 0.0.0.0
  body_size_limit 32m
  keepalive_timeout 10s
</source>
 
<filter nginx.raw>
  @type record_modifier
  remove_keys date, time, encoding, length
  <record>
    host "#{Socket.gethostname}"
  </record>
  <replace>
    key agent
    expression /^$/
    replace -
  </replace>
</filter>
 
<match mypatternA.*>
  @type file
  path /var/log/fluent/myapp
  compress gzip
  <buffer>
    timekey 1d
    timekey_use_utc true
    timekey_wait 10m
  </buffer>
</match>

코드 출처 : sketchofcreed.tistory.com/entry/fluentd-%EC%84%B8%ED%8C%85-%EB%B0%8F-%EC%9A%B4%EC%9A%A9 + 공식문서

 

전체적인 흐름: 

   1. source 가 input 을 담당하고,

   2. filter / parser 등이 받아온 인풋에 대한 처리,

   3. match 가 "매치 됐을 때 무얼 할까?" 라는 output을 담당한다.

 

1. <source> = input

@ tail, @ http, @ forward 등 인풋 플러그인으로 시작한다. 각 인풋 플러그인마다 하위속성이 다르다.   대표적인 3가지를 소개한다. (물론 3개 뿐 아니라 더 있다.) @tail 은 리눅스 명령어 tail 과 같은 의미로, 하위 속성인 path 에 지정된 파일의 마지막 부분을 지속적으로 읽어온다.     = 로컬호스트의 파일 마지막부분 읽어오기 @http 는 curl 명령어 같이 http 요청으로 로그를 받는 플러그인이다. port와 bind 속성이 매우 직관적이다. @forward 는 보통 -   [ 실제 로그가 찍히는 서비스 서버 ] 에 설치된 [ fluentd A ] 에서 로그를 보내고,   [ 로그 수집하는 서버 ] 에 설치된 [ fluentd B ] 에서 로그를 수집할 때   [ 로그 수집하는 서버의 fluentd B ] 에서 사용하는 태그이다. 이런 작동을 포워딩(한글로 굳이 꼽자면 주선하다?)이라고 부르기도 해서 forward라고 이름지어진 듯 하다.

 

 

NOTE :
   INPUT 공통적으로 핵심적인 속성은 tag 속성이다. 
   tag는 이름이다. tag로 source를 구분해서 처리한다.

   예를 들어,
   A.log 에서 오는 모든 소스를 tagA 라고 하면,
   tagA에 적용될 필터를 <filter tagA> 로 지정하고,
   tagA가 어디로 빠질지 아웃풋도 <match tagA> 로 지정한다.

   Grouping이 필요할 때는 "." 으로 묶을 수 있다.

   예를 들어,
   A.log 에서 오는 모든 소스를 filelog.tagA
   B.log 에서 오는 모든 소스를 filelog.tagB 로 지정한다.
   그러면 <parser filelog.*> 를 통해 filelog 로 묶인 모든 인풋을 파싱할 수 있다.

 

 

 

2. <filter>, <parser>, <formatter> 등 처리

옵션 플러그인이기 때문에 간략하게 짚고 넘어가겠다.

<filter foo.bar>
  @type grep
  regexp1 message cool
</filter>

보자마자 바로 알 수 있지 않는가?

리눅스 명령어 grep 과 같은 역할이다.

 

3. <match> = output

유일한 아웃풋 플러그인이다.

<formatter>를 통해 형식을 지정해서 결과물을 출력할 수 있다.

아웃풋 플러그인만 5조 5억개~ 는 아니고 18개이다.

공식 페이지 예제에서 다룬 file 태그를 보면,

path로 경로 지정을 해주고, gzip 으로 압축 저장을 한다. buffer 태그는 말그대로 지속적으로 들어오는 출력을 임시 저장할 버퍼이다. buffer 태그는 한 플러그인에 한번만 설정할 수 있다.

 

이렇게 fluentd 가 로그셔틀을 하면, mongo, kafka, elasticsearch 같은 친구들에게 상납한다.

 

연예인들이 작은 얼굴에 오밀조밀 눈코입이 선명하게 박혀있는 모습과 같이,

기능들도 다 보면 알짜배기에 딱 필요한 기능들만 있으며, 문법까지 깔끔하게 잘생겼다.

C와 Ruby 기반이기 때문에 매우 가볍고 빠르기까지 하다.

 

이런 멋진 Fluentd, 안쓰면 바봉.