Beats - 기본

Sungjin·2022년 12월 15일

ELK Stack

목록 보기

4/4

아파치 HTTPD 서버 관리는 아주 잘 알고 있지만 엔진엑스에 대해서는 아직 낯설다면 로그에서 어떤 내용을 찾아서 어떻게 해석해야 할지 막막할 것이다. 아니면 윈도우 서버는 잘 다루지만 현재 리눅스 서버를 학습 중이라면 리눅스 서버의 정상 동작을 잘 파악하기 위한 메트릭을 알아내기 위해 제법 시간을 들여야한다. 이 모든 사항을 설정으로 정의해서 소프트웨어가 알아서 파악하게 만드는 방법은 없을까? 이게 바로 비츠와 비츠 모듈이 하는 일이다.

비츠는 가볍고 사용하기 쉬운 데이터 수집기다. 고프로그래밍 언어로 작성된 경량 프로그램이기 때문에 로그 수집을 원하는 시스템에 큰 부담을 주지 않으며 로그스태시, 엘라스틱서치와 연계해 다양한 시스템의 이벤트를 수집할 수 있게 도와준다. 비츠는 오픈소스 라이선스를 따르며 립비트라는 프레임워크를 제공하므로 사용자들이 직접 필요한 각 비트를 구현할 수 있다.

비츠는 수집한 데이터를 엘라스틱으로 실어 나르기 위해 최전방에 위치한 소프트웨어로서, 엘라스틱에서 공식적으로 지원하는 파일비트(로그 파일 수집), 메트릭비트(메트릭 수집), 패킷비트(네트워크 데이터 수집), 윈로그비트(윈도우 이벤트 로그 수집), 오딧비트(감사데이터 수집), 하트비트(가동시간 모니터링 데이터 수집, 펑션비트(서버리스 데이터 수집) 외에도 공동체에서 만든 카프카비트(카프카 토픽 데이터 수집), 엔진엑스비트(엔진엑스 상태 수집), MySQL비트 등 상당히 많은 비트가 존재한다. 이와 더불어 비츠는 온프레미스와 가상 머신뿐만 아니라 컨테이너와 쿠버네티스 환경에서도 사용이 가능하므로 전체 인프라스트럭처의 관측성을 높이기 위한 토대로도 볼 수 있다.

비츠는 설정이 간편하고 별도의 데이터 가공을 위한 프로그래밍 작업이 필요하지 않으므로 일단 원하는 비트를 확보했다면 빠르게 데이터 수집을 시작할 수 있으며, 특정 비트 내에서 모듈을 추가하는 방식으로 필요한 기능을 확장할 수 있다.

🌈 비츠 소개

비츠는 가벼운 프로그램을 지향하기 때문에 하나의 목적만을 수행한다. 그래서 비츠는 목적별로 많이 나누어져 있고, 다양한 비츠들이 존재한다. 데이터 수집을 하는 역할만 보면 로그스태시와 유사해 보일 수도 있으나 차이가 있다. 로그스태시는 다양한 플러그인을 포함해 범용성이 높은 만큼 무겁게 움직이는 반면, 비츠는 범용성을 포기하고 특정 목적만 수행하도록 가볍게 구성되어 애플리케이션 성능에 영향을 미치지 않고 동작할 수 있다.

간단한 수집이 목적이라면 비츠를 사용하는 것이 성능 상 더 적합하다.

🌈 파일비트

💡 파일비트 아키텍처

서버나 시스템을 운영하다 보면 수많은 로그들이 파일 형태로 발생한다. 파일비트는 이런 로그 파일을 쉽게 수집하도록 도와주며 궁극적으로 엘라스틱과 키바나를 이용해 로그를 추적하고 통계를 만들어 활용할 수 있게 도와준다.

파일비트는 다음과 같이 크게 세 가지 주요 구성요소로 이뤄져 있다.

구성요소	설명
입력	설정 파일에서 하베스터에 대한 입력 소스를 정한다. 파일비트는 하나 혹은 여러 개의 입력을 가질 수 있다.
하베스터	입력에 명시된 파일을 직접 수집하는 주체다. 파일은 하나의 하베스터를 가지며, 하베스터는 파일을 한 줄씩 읽고 내보내는 역할을 한다. 또한 파일을 열고 닫는 역할도 한다. 하베스터가 실행되는 동안에는 파일 디스크럽터가 열려 있다.
스풀러	하베스터가 수집한 이벤트를 엘라스틱서치나 로그스태시 같은 장소로 전달한다.

파일비트는 기본적으로 파일에 적재되는 로그들을 가져오는 역할을 한다. 입력에서 대상 경로를 모니터링하다가 새로운 파일이 발견되면 하베스터를 생성해서 해당 데이터를 읽어 들인다.

💡 파일비트 실행
파일비트를 실행해보자. 원하는 로그파일을 수집하기 위해 설정 파일을 수정해야 한다. filebeat.yml 이라는 설정파일이 있다. 설정 파일에서 설정 가능한 모든 파라미터는 온라인 문서에서 확인 가능하다. 파일비트 설정 파일 작성 방식이 로그스태시와 비슷해 보이지만 플러그인을 통해 입력/필터/출력을 설정하는 로그스태시와 달리 파일비트는 복잡한 설정이 없다.

filebeat.yml을 다음과 같이 수정해보자.

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /Users/admin/logs/test.log

output.elasticsearch:
  hosts:  ["localhost:9200"]

setup.kibana:
  host: "localhost:5601"

인풋은 파일비트가 가져오는 입력이고, 아웃풋은 내보내는 출력이다.

인풋으로 설정하는 타입은 다음과 같다.

인풋 타입	설명
log	가장 기본이 되는 타입으로, 파일시스템의 지정한 경로에서 로그 파일을 읽어 들인다.
container	도커 같은 컨테이너의 로그를 수집하기 위한 입력으로, 파일을 읽어 들인다는 점에서 log 와 비슷하다.
s3	log 타입과 유사하나, 아마존 웹 서비스의 S3 버킷에 위치한 파일을 읽어들인다.
kafka	다른 타입과는 다르게 파일을 읽어 들이는 대신 카프카의 토픽을 읽어 들인다.

인풋은 타입에 따라 설정해야 하는 내용이 달라지는데, 인풋으로 설정할 수 있는 모든 타입은 온라인 문서를 참고해 작성하면 된다. 여기서는 인풋 타입을 log 로 설정했는데 log 타입은 paths에 지정된 파일의 로그를 한 줄씩 가져오는 것을 의미한다.

아웃풋은 하베스터가 읽어들인 데이터를 전달할 곳으로 엘라스틱서치, 로그스태시, 카프카, 특정 파일, 콘솔 등 여러 형태의 아웃풋중 하나를 지정할 수 있다.

|아웃풋 타입|설명|
|elasticsearch|가장 많이 사용되는 타입으로, 수집한 이벤트를 엘라스틱 서치로 직접 인덱싱한다.|
|logstash|다수의 비츠를 사용해 엘라스틱서치로 전송되는 인덱싱 리퀘스트의 양이 많거나, 비츠나 인제스트 노드 수준에서 처리하기 어려운 가공 작업이 필요할 때 별도의 로그스태시를 구축한 후 수집한 이벤트를 전송한다. 다수의 인덱싱 요쳥이 로그스태시에서 단일 벌크 리퀘스트로 묶여 인덱싱 효율의 개선을 기대할 수 있다. 이때 전송한 이벤트는 로그스태시의 beats 인풋을 이용해 입력받을 수 있다.|
|kafka|파일비트에서 1차원으로 수집한 이벤트를 카프카로 전송한다. 카프카는 좀 더 안정적인 수집 파이프라인을 구성할 때 신뢰할 만한 중간 저장소/큐이므로 수집 중 장애 발생 시 데이터손실을 최소화하기 위한 방안으로 활용된다. 최종적으로 엘라스틱서치의 인덱싱을 원할 경우 이후 다시 파일비트의 카프카 인풋을 이용하거나 로그스태시의 카프카 인풋을 이용해 입력할 수 있다.|
|console|수집한 이벤트를 시스템 콘솔에 출력한다. 일반적으로 수집이 정상적으로 이뤄지는지 테스트하기 위해 사용한다.|

엘라스틱서치를 아웃풋으로 지정하면 반드시 엘라스틱서치 호스트 주소를 적어줘야 한다. 마지막으로, setup.kibana를 지정하면 키바나 대시보드에서 파일비트 데이터를 확인할 수 있다. 이제, 실행해보도록 하자.

./filebeat setup -e

-e는 모니터에 오류나 로그를 보여주는 옵션이다.

엘라스틱서치 인덱스 템플릿, 수명주기 정책과 같은 인덱스 관리 정보와 인제스트 파이프라인, 그리고 키바나 샘플 대시보드까지 설치하기 때문에 셋업하는데 시간이 좀 걸린다.

위의 그림 처럼 마지막 로그인 “Loaded Ingest pipelines” 까지 보이면 셋업이 완료된다. 셋업이 끝나고 키바나에 가보면 파일비트 관련 부분이 추가된 것을 볼 수 있다. filebeat-* 와 같은 인덱스가 생성된다.

파일비트와 엘라스틱서치, 키바나 간의 셋업이 끝나면 이제 마지막으로 파일비트를 실행해야 한다.

./filebeat -e

엘라스틱서치로 인덱싱되었으니, 키바나 디스커버에 띄워보도록하자.

Management → Stack Management → Kibana → Index Patterns 를 선택하여 생성해주면 된다.

이제, 디스커버를 들어가면 다음과 같은 화면이 뜰 것이다.

💡 파일비트 설정

이번에는 파일비트 설정 파일을 수정해보자. 파일비트를 설치한 config 폴더를 보면 filebeat.reference.yml 이라는 파일이 있다. 파일비트의 모든 설정에 대한 설명과 기본값이 찍혀있는 참조 파일이다. 버전에 맞춰 추가/삭제된 옵션이 모두 포함되어 있으니 설정 파일을 수정할 때 참고하자.

🔎 유용한 설정

파일비트의 설정 중 자주 사용되는 옵션들을 좀 더 자세히 들여다 보자. 먼저 ignore_older 는 새로운 파일 탐색 시 오래된 파일은 읽어 들이지 않고 무시하기위한 설정이다.

ignore_older는 인풋 타입이 log인 경우 사용할 수 있는 옵션으로 ignore_older 값은 10h, 10m 처럼 타임스트링 형식으로 작성한다. 예를 들어, ignore_older를 10h로 설정하면 최근 10시간 전의 로그만 수집하겠다는 의미다. ignore_older의 기본값은 0으로, 특별히 값을 명시하지 않으면 파일의 생성/수정 시간과 무관하게 모든 내용을 읽어들인다. 다음은 특정 라인이나 파일을 추가/제외하는 옵션이다.

파일비트 수준에서 복잡한 정제 작업을 수행할 수는 없지만, 간단한 정제 작업을 비츠에서 처리하면 엘라스틱서치나 로그스태시에서 처리하는 작업량을 줄일 수 있다. include_lines 는 특정 라인을 정규 표현식을 이용해 필터링하고 매칭된 라인만 비츠에서 수용한다. 여기서 ERR이나 WARN 으로 시작하는 로그 라인은 파일비트가 수집한다.

exclude_lines 는 특정 라인을 정규식 표현식을 이용해 필터링하고 매칭된 라인은 비츠에서 수집하지 않는다. 여기서 DBG로 시작하는 로그 라인은 파일비트 내부에서 버린다.

exclude_files 는 패턴에 일치하는 파일을 무시할 때 사용한다. 여기서 확장자가 gz인 파일은 무시한다. 특정 폴더 내부에 분석해야 하는 로그파일과 분석하지 않아도 되는 파일들이 섞여 있을 때 유용하게 사용할 수 있다.

🔎 멀티라인 로그 처리

로그가 한 줄로 표현되면 좋지만 하나의 로그가 여러 줄로 나올 때는 어떻게 처리해야 할까? 파일비트는 이런 경우를 위해 멀티라인 옵션을 제공하고 있다.

멀티라인 처리를 위한 설정 방법을 알아보자.

인풋타입이 log인 경우에 멀티라인을 처리할 수 있다. 일반적으로 로그는 한 줄에 하나의 로그가 기록되며, 파일비트 또한 기본적으로 싱글라인 단위로 이벤트를 처리한다.

먼저, multiline.pattern 은 정규식을 이용해 패턴을 지정한다. 패턴과 일치하는 라인이 나타나면 멀티라인으로 인식한다. 위의 그림에서는 라인의 첫 번째 문자가 공백이면 멀티라인 패턴으로 인식된다.

multiline.nagate 는 true일 때 패턴 일치 조건을 반전시킨다. negate 조건을 true로 변경한다면 첫 번째 문자가 공백이 아닐 때 멀티라인으로 인식한다.

muliline.match 는 멀티라인을 처리하는 방식으로 before, after를 지정할 수 있다. 그럼 멀티라인 설정은 매칭 패턴에 일치하는 공백으로 시작하는 라인을 공백으로 시작하지 않는 라인 뒤에 붙이는 방식으로 멀티라인 자바 로그를 하나의 로그로 처리할 수 있다.

💡 모듈

모듈은 많이 사용되고 잘 알려진 시스템 데이터를 수집하기 위한 일반적인 설정을 사전 정의해둔 것이다. 모듈을 이용하면 복잡한 가공이 필요한 이벤트인 경우에도 최소한의 비츠 설정으로 손쉽게 로그들을 수집할 수 있다. 모듈의 핵심은 손쉬운 사용이다. 예를 들어, 엔진엑스나 아파치 서버의 로그를 수집한다고 가정해보자. 특별히 사용자가 설정 변경이 없었다면 설치 경로나 로그 발생 위치, 로그 형태는 동일할 것이다. 이처럼 잘 알려진 서비스들은 동일한 설정으로 수집할 수 있기 때문에 모듈이라는 형태로 사전 설정을 제공하고 있다.

파일비트의 경우 다음과 같은 모듈들을 지원한다.

모듈을 이용한 비트 동작 과정은 다음과 같다.

비트를 다운로드한다.
비트 설정 파일을 수정한다.
모듈을 활성화하고 모듈 설정 파일을 수정한다.
엘라스틱서치와 키바나 대시보드를 사용할 수 있게 설정한다.
비트를 시작한다.
키바나 대시보드에서 데이터를 확인한다.

기존 비트 실행 과정과 다른 점은 2번, 3번 부분이다. 비트 설정 파일에 모듈을 사용한다는 점을 기록해야 하고, 모듈을 활성화하는 부분을 추가해야 한다. 그 외에 나머지는 기존의 비트 실행 동작 과정을 따르면 된다.

모듈의 태생이 설정 없이 간단하게 비트를 사용하려는 목적으로 출발했기 때문에 실제 설정 파일 작성은 매우 간단하다.

🔎 비츠 설정 파일 수정

모듈을 사용하려면 먼저 비츠 설정 파일을 변경해야 한다. 인풋은 모듈 설정 파일에서 설정할 것이므로, 아웃풋만 적어주면 된다.

output.elasticsearch:
  hosts:  ["localhost:9200"]

setup.kibana:
  host: "localhost:5601"

filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml

인풋은 모듈 설정 파일에서 작성해야 하기 때문에 삭제했다. 아웃풋은 엘라스틱서치로 설정했고 setup.kibana를 추가해 키바나에 샘플 대시보드를 설치할 수 있도록 지정했다. 마지막으로, 모듈을 설정하기 위해서는 모듈 경로를 지정해줘야 한다. ${path.config} 는 파일비트가 설치된 경로다.

🔎 모듈 활성화

로그스태시 모듈을 사용해보도록 하자. 로그스태시 모듈은 로그스태시 로그를 가져오는 모듈이다. 비츠 설정 파일을 수정하여 모듈을 사용하기로 했으니 이제 콘솔에서 모듈을 활성화해보자.

./filebeat modules enable logstash

파일비트를 실행하고 modules 명령을 적어준다. 다음으로 enable/disable을 이용해 모듈을 활성화하거나 비활성화할 수 있다.

여러 개의 모듈을 enable로 활성화 하거나 disable로 비활성화할 수 있다. 여러 개의 모듈을 등록할 때는 모듈 사이에 공백을 두면 된다. 현재 활성화된 모듈이 무엇인지 확인하는 방법도 알아보자.

./filebeat modules list

위의 그림처럼 enble과 disable된 목록을 확인할 수 있다.

🔎 모듈 설정 파일 수정

이제 모듈 속성파일을 수정해보자. 모듈은 기본적으로 사람들이 많이 쓰는 기능들을 사전 정의했기 때문에 수정할 필요가 거의 없다. 하지만 모든 사용자의 요구사항을 맞추기는 힘들기 때문에 모듈 수정 파일을 두어 개별적인 설정이 가능하게 한다.

모듈 설정 파일은 파일비트 디렉토리 아래의 modules.d 라는 디렉토리에 있다. 비활성화된 모듈은 disabled 확장자가 붙어 있고, 활성화된 모듈은 disabled 확장자가 빠진다.

방금 활성화한 logstash.yml 만 뒤에 disabled가 없다. 이제 모듈 설정 파일인 logstash.yml을 수정해보자.

var.paths 에는 로그파일의 경로를 써주면 된다.

🔎 setup 명령과 비트 실행

비트 설정과 모듈 설정까지 완료했으니 비트를 실행하자. 먼저 setup 명령을 통해 엘라스틱 인덱스 템플릿을 생성하고 키바나 대시보드를 사용할 수 있게 한다. 이때는 특별히 -e 옵션을 붙이지 않더라도 로그가 표시된다.

위의 그림은 파일비트 setup 명령을 실행한 결과다. setup 명령은 엘라스틱서치와 키바나에 API를 이용해 인제스트 파이프라인, 대시보드 등을 설치하므로 엘라스틱서치와 키바나는 반드시 실행 중이어야 하며 네트워크 접근에도 문제가 없어야 한다. 환경에 따라서 셋업 시간이 오래 걸리기도 한다. 셋업까지 완료되면 이제 비트를 실행하면 된다. 비트를 실행하기 전에 먼저 확인해야 할 것이 있다. 키바나 대시보드에 가보면 파일비트 샘플 대시보드들이 많이 설치되어 있다. 로그스태시 모듈과 관련된 대시보는 [Filebeat Logstash] Logstash Logs ECS, [Filebeat Logstash] slowlogs ECS 두 가지가 있다. 이 중 [Filebeat Logstash] Logstash Logs ECS 를 선택해서 대시보드를 확인해보자.