Fluentd 설치 및 실행

설치 및 실행

• docker 나 kubernetes 에서 사용하는 방법도 있지만 테스트용이므로 rpm 패키지를 이용한
  설치를 해보겠습니다.
• Redhat 계열 사용자 기준으로 설치 명령은 다음과 같습니다. 아래에 OS 종류별 설치버전에 대한
  정보가 있으니 확인하고 맞는 버전을 설치하면 됩니다.

# td-agent 4
$ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh | sh

# td-agent 3
$ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh

설치버전 참고

td-agent 실행

• fluentd의 실행파일은 td-agent 라는 이름의 바이너리 파일입니다. 사용하는 설정파일의 위치는
  /etc/td-agent 경로에 있으며 실행방법은 다음과 같습니다.

$ td-agent -c [설정파일]
$ td-agent -c /etc/td-agent/td-agent.conf

• 이런식으로 로그가 보이면 정상적으로 실행된것입니다. 아래에서 설명할 stdout 으로 출력시 로그를 확인할수 있습니다.

conf 파일 설정, 테스트

• fluentd 설정파일은 top-bottom 형식으로 관리됩니다. filter는 아래에서 설명하겠지만 일반적인 로그의 처리순서는 source => filter => match 이므로 각 섹션의 정의 순서도 같아야 합니다.

• Logstash 처럼 fluentd 도 설정파일에 따라 source, match 들을 구성할수 있습니다.

• 여기부터 설명하는 설정파일은 /etc/td-agent 경로에 in_http.conf 파일을 만들어서 진행합니다.

source

http input을 사용하는 간단한 예제입니다. 8888 포트로부터 오는 request를 수신하도록 설정했습니다.

<source>
  @type http
  port 8888
  bind 0.0.0.0
</source>

match

• source 에서 데이터가 들어오면 출력을 정의할 Matching rule을 정의합니다.
• 아래 예제에선 test.cycle 이라는 태그를 가진 http request가 input 으로 들어올때 stdout 이라는 output plugin 을 사용하였습니다.

<match test.cycle>
  @type stdout
</match>

in_http.conf

<source>
  @type http
  port 8888
  bind 0.0.0.0
</source>

<match test.cycle>
  @type stdout
</match>

테스트

$ curl -i -X POST -d 'json={"action":"login","user":2}' http://localhost:8888/test.cycle
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: Keep-Alive
Content-Length: 0

2021-07-08 13:39:43.919733335 +0900 test.cycle: {"action":"login","user":2}

이벤트 구조

fluentd 의 이벤트는 세가지로 구성되었습니다.

tag

• 이벤트가 발생한 지점을 나타내며 메시지 라우팅에 사용됩니다.

time

• 이벤트가 발생한 시간을 나타내며 나노초 단위로 표시됩니다.

record

• JSON 형태의 로그 오브젝트입니다.

이벤트 처리

• 로그의 형태는 모두 일정하지 않으니 로그데이터를 처리하는 기능이 필요합니다. 이번 예제에서는
  Filters, Labels 에 대해 설명해보겠습니다.

Filters

• Filter는 이벤트를 통과시키거나 차단할수 있습니다.
• 아래 설정 파일에서도 알수있듯이 Filter는 이벤트가 match 섹션 이전에 거쳐가야 하는 단계입니다.
• type rule에 의하여 이벤트를 검사하고 이번 예제는 logout action에 대해서는 이벤트를 차단하고 logins 에 대해서만 처리합니다.
• filter 설정 내부에 grep를 사용하여 이벤트로 들어온 JSON 형식의 로그에서 key : action인 데이터가 logout 이라면 제외하는것입니다.

in_http.conf

<source>
  @type http
  port 8888
  bind 0.0.0.0
</source>

<filter test.cycle>
  @type grep
  <exclude>
    key action
    pattern ^logout$
  </exclude>
</filter>

<match test.cycle>
  @type stdout
</match>

action : login test

$ curl -i -X POST -d 'json={"action":"login","user":2}' http://localhost:8888/test.cycle
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: Keep-Alive
Content-Length: 0

2021-07-08 13:46:40.735012664 +0900 test.cycle: {"action":"login","user":2}

action : logout test

$ curl -i -X POST -d 'json={"action":"logout","user":2}' http://localhost:8888/test.cycle
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: Keep-Alive
Content-Length: 0

• action 키값을 logout 으로 했을때 출력이 되지않는다면 정상입니다.

Labels

• Label은 source 에서 받은 데이터를 특정 Label 에 대한 섹션으로 이벤트를 전달하는 기능입니다.
• 위에서 fluentd 설정 규칙은 top-bottom 이라고 하였는데 Label이 정의되있다면 이 규칙을 무시할수있습니다.

in_http.conf

<source>
  @type http
  bind 0.0.0.0
  port 8888
  @label @STAGING
</source>

<filter test.cycle>
  @type grep
  <exclude>
    key action
    pattern ^login$
  </exclude>
</filter>

<label @STAGING>
  <filter test.cycle>
    @type grep
    <exclude>
      key action
      pattern ^logout$
    </exclude>
  </filter>

  <match test.cycle>
    @type stdout
  </match>
</label>

• 위 설정파일을 보면 source => filter => label 섹션의 순서로 되있습니다. 순서로만 보면 source 에서 들어온 데이터는 filter 섹션으로 가야하지만 source 섹션에서 @label @STAGING 으로 Label을 지정했기 때문에 @STAGING 으로 지정되있는 Label 섹션으로 이벤트가 전달됩니다.

참고

• https://ksr930.tistory.com/141