ELK - Filebeat 란? (실시간 로그 수집)

2019. 3. 20. 23:29Search-Engine/Elasticsearch&Solr

ELK - Filebeat 란?



https://coding-start.tistory.com/187

조금 더 다듬어서 Filebeat 정리하였습니다.


    <실시간 로그 수집을 위한 프로세스 구성>


만약 많은 애플리케이션이 분산되어 있고, 각 애플리케이션이 로그 파일들을 생성한다고 생각해보자. 만약 해당 로그 파일을 하나의 서버에 일일이 ssh 터미널을 이용하여 로그 파일을 수집하는 것이 합리적인 행동일까? 만약 엄청난 규모의 서비스이고 분산되어 있는 서비스의 애플리케이션이 수백개라고 생각하면 ssh를 이용하는 방법은 생각하기도 싫은 방법일 것이다. 이런 상황에서 Filebeat는 로그와 혹은 파일을 경량화된 방식으로 전달하고 중앙 집중화하여 작업을 보다 간편하게 만들어 주는 역할을 한다. 


다시한번 Elastic 공식 홈페이지에서 소개하는 Filebeat를 설명하자면, Filebeat는 로그 데이터를 전달하고 중앙화하기 위한 경량의 Producer이다. 서버에 에이전트로 설치되는 Filebeat는 지정한 로그 파일 또는 위치를 모니터링하고 로그 이벤트를 수집한 다음 인덱싱을 위해 Elasticsearch 또는 Logstash로 전달한다.




Filebeat의 작동 방식은 어떻게 될까?

Filebeat를 시작하면 설정에서 지정한 로그데이터를 바라보는 하나이상의 inputs을 가진다. 지정한 로그 파일에서 이벤트(데이터발생)가 발생할 때마다 Filebeat는 데이터 수확기(harvester)를 시작한다. 하나의 로그 파일을 바라보는 각 havester는 새 로그 데이터를 읽고 libbeat에 보낸다. 그리고 libbeat는 이벤트를 집계하고 집계된 데이터를 Filebeat 설정에 구성된 출력으로 데이터를 보낸다.






Filebeat 시작하기

▶︎▶︎▶︎Filebeat Download


파일비트를 다운로드 받았다면 압축을 풀고, filebeat.yml 파일을 열어 설정파일을 살펴본다.


1
2
3
4
5
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/*.log
cs


위의 설정은 수집할 로그파일의 경로를 설정한다. 즉, /var/log/*.log의 파일을 수집대상으로 정해놓는 것이다.


1
2
3
4
5
6
7
cloud.id: "staging:dXMtZWFzdC0xLmF3cy5mb3VuZC5pbyRjZWM2ZjI2MWE3NGJmMjRjZTMzYmI4ODExYjg0Mjk0ZiRjNmMyY2E2ZDA0MjI0OWFmMGNjN2Q3YTllOTYyNTc0Mw=="
 
output.elasticsearch:
  hosts: ["myEShost:9200"]
 
setup.kibana:
  host: "mykibanahost:5601"
cs


출력을 Elasticsearch로 지정하여 수집한 로그데이터를 엘라스틱서치에 저장할 수 있다. 물론 중간에 Logstash 등을 거쳐 데이터를 추가적인 처리를 한 후에 엘라스틱서치에 데이터를 저장할 수도 있다.


1
2
3
#----------------------------- Logstash output --------------------------------
output.logstash:
  hosts: ["127.0.0.1:5044"]
cs


자세한 설정은 Elastic 공식 페이지를 이용하시길 바랍니다.




Filebeat는 파일의 상태를 어떻게 유지하나?

편집하다

Filebeat는 각 파일의 상태를 유지하며 레지스트리 파일의 상태를 디스크로 자주 플러시한다. 상태는 수확기(havester)가 읽었던 마지막 오프셋을 기억하고 모든 로그 라인이 전송되는지 확인하는 데 사용된다. Elasticsearch 또는 Logstash와 같은 출력에 도달 할 수 없는 경우 Filebeat은 마지막으로 보낸 행을 추적하고 출력이 다시 사용 가능 해지면 파일을 계속 읽는다. Filebeat가 실행되는 동안 상태 정보도 각 입력에 대해 메모리에 보관된다. Filebeat가 다시 시작되면 레지스트리 파일의 데이터가 상태를 다시 작성하는 데 사용되며 Filebeat은 마지막으로 알려진 위치에서 각 수확기를 계속 사용한다 또한 Filebeat는 적어도 한번 이상 구성된 데이터를 지정한 출력으로 전달함을 보장한다.




Filebeat와 Kafka를 이용한 간단한 로그수집


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#=========================== Filebeat prospectors =============================
#filebeat로 어떤 파일을 보낼지를 선택하는 부분이다. /Users/yun-yeoseong/kafka_directory/kafka/logs/server.log 파일을 보내기 위한 설정
kafka.home: /Users/yun-yeoseong/kafka_directory/kafka
filebeat.prospectors:
  - input_type: log
    paths:
      -${kafka.home}/logs/server.log*
    multiline.pattern: '^\['
    multiline.negate: true
    multiline.match: after
    fields.pipeline: kafka-logs #파이브라인 아이디
 
#============================= Filebeat modules ===============================
 
filebeat.config.modules:
  # Glob pattern for configuration loading
  path: ${path.config}/modules.d/*.yml
 
  # Set to true to enable config reloading
  reload.enabled: false
 
  # Period on which files under path should be checked for changes
  #reload.period: 10s
 
#==================== Elasticsearch template setting ==========================
 
setup.template.settings:
  index.number_of_shards: 3
  #index.codec: best_compression
  #_source.enabled: false
 
#==================== Kafka output ==========================
#kafka의 프로듀서의 역할을 설정하는 부분이다.
output.kafka: 
  hosts: ["localhost:9092","localhost:9093","localhost:9094","localhost:9095"]
  topic: 'kafka-log'
  partition.round_robin: 
    reachable_only: false
 
  required_acks: 1
  compression: gzip
  max_message_bytes: 1000000
cs


위는 카프카를 output으로 하는 설정이다. 간단하게 설정에 대해 설명하면 filebeat.prospectors는 Filebeat의 input을 정의하는 것이다. '-' 구분으로 여러개의 input을 정의할 수 있다. input_type: log 설정은 로그 파일의 모든 행을 읽는 설정이다. paths는 읽어올 파일의 경로이다. '-'구분으로 여러개의 경로를 지정할 수 있다. multiline 설정은 로그 데이터처럼 여러 개행된 데이터를 처리할때 사용하는 어떠한 규칙이라고 보면된다. 자세한 사항은 Elastic 공식 페이지를 확인하면 될듯하다. output.kafka 설정은 출력을 정의한다. hosts는 Kafka 클러스터 노드들을 배열로 나열한 것이고, 여기서 파일비트는 카프카 입장에서는 하나의 프로듀서이므로 pub할 topic을 설정한다. 나머지 설정들은 kafka의 producer 설정이므로 생략한다. 그리고 파일비트에서 카프카는 위처럼 호스트를 나열하면 내부적으로 로드밸런싱을 해주므로 하나의 브로커에만 데이터 요청이 가질 않는다.

이번 예제에서는 파일비트가 데이터를 정말로 수집하는 지를 보기 위해서 kafka가 기본으로 제공하는 console consumer를 이용할 것이다.
우선은 위의 설정에 작성된 토픽을 생성해준다.

kafka는 3대를 클러스터링한 환경이다. 만약 kafka 클러스터링 방법을 모른다면 밑의 링크에서 참조하고 와도 될듯싶다.
▶︎▶︎▶︎kafka cluster


> ./kafka-topic.sh --zookeeper localhost:2181,localhost:2182,localhost:2181/kafka-broker(자신이 설정한 디렉토리입력) --topic Kafka-log --partitions 3 --replication-factor 2 --create.  -> 토픽생성

>./filebeat -e -c filebeat.yml -d "publish"  -> 위에서 작성한 설정파일에 기준한 파일비트 실행

>./kafka-console-consumer.sh --bootstrap-server localhost:9092,localhost:9093,localhost:9094 --topic kafka-log --from-beginning ->컨슈머실행

카프카의 클러스터중 하나를 다운시켰다 실행시키는 등의 로그가 출력되는 작업을 수행한 후에 컨슈머에 들어오는 데이터를 확인해보자.


왼쪽이 컨슈머, 오른쪽은 파일비트의 로그이다. 파일비트에서 수집한 카프카의 로그가 카프카로 보내지고 컨슈머가 해당 브로커에서 데이터를 가져오는 것을 볼 수 있다.