#filebeats

동기?

지금 회사에서는 어플리케이션 로그를 확인하려면, 서버에 들어가서 vi로 로그 파일을 열어서 확인해야한다. 개발 장비나, 백오피스는 인스턴스 하나로 서비스되고 있어서 비교적 로그 확인이 쉽..다. 그러나 상용 서비스는 서버도 여러 대, 인스턴스도 여러개로 운영되고 있어서 로그를 확인하기가 쉽다고 할 수 없다. 그리고 보통 로그를 확인하는 경우는, 에러가 발생하고 있거나 장애 원인에 대해 확인하기 위한 다소 급박한 상황이다 ^^ 여러 장비, 여러 서비스의 로그를 한곳에서 확인할 수 있는 대시보드를 만들고 싶었다. 

대부분의 스타트업에서 로그 모니터링 시스템으로 ELK를 사용한다. ELK로 대충 어떻게 구성한다라는 것은 여기저기서 주워들어서 알고 있었지만 직접 구성해본적은 이번이 처음이라 디테일한 부분에서 난관이 있었다. 

 작업한 내용들을 정리하려고 한다.

Elastic Stack

ELK라고 부르는 (E elasticsearch L logstash K kibana) 와  서버에 쌓이는 로그를 전송해줄 Filebeat 까지를 Elastic stack 으로 본다. 그리고 여기저기 서버에서 로그가 많이 몰릴것을 예상해서, 중간 버퍼로 Kafka를 사용한다.

(일반적인) 구성

Filebeat

로그 데이터를 전달하고 중앙화하기 위한 경량의 Producer.

서버에 에이전트로 설치되는 Filebeat는 지정한 로그 파일 또는 위치를 모니터링하고 로그 이벤트를 수집한 다음 인덱싱을 위해 Elasticsearch 또는 Logstash로 전달한다.

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

Kafka

로그 모니터링 시스템에서, 생산자는 filebeat

로그 모니터링 시스템에서 소비자는 logstash 

Kafka에 대한 포스트

https://leeilly.tumblr.com/post/189185876586/kafka-%EC%B9%B4%ED%94%84%EC%B9%B4

Elasticsearch

데이터를 저장하고 분석하는 엔진 역할을 수행하는 핵심 모듈

Kibana