[ELK] Beats 정리

Beats

• 경량 데이터 수집기로 다양한 원격 시스템과 서비스에서 데이터를 수집하여 Elasticsearch 또는 Logstash로 전송하는 역할 수행
• Elastic Stack의 중요한 구성 요소 중 하나로 다양한 유형의 데이터를 중앙 집중식으로 수집하고 분석 가능하도록 지원
• 역할만을 보면 Elastic Stack의 또 다른 구성요소인 Logstash와 유사해 보일 수 있으나 Logstash는 다양한 플러그인을 포함해 범용성이 높은 만큼 무겁게 움직이는 반면, Beats는 범용성을 포기하고 특정 목적만 수행하도록 가볍게 구성되어 애플리케이션의 성능에 영향을 미치지 않고 필요한 이벤트 수집 가능
• 오픈소스 라이선스를 따르며 립비트(Libbeat)라는 프레임워크를 제공하므로  사용자들이 직접 필요한 각 비트 구현 가능

 

Beats 특징

• 경량화: Beats는 경량 데이터 수집기이기 때문에 서버 리소스를 최소화하면서 데이터 수집
• 모듈화: 각 Beats는 특정 유형의 데이터를 수집하는 데 최적화되어 있으며, 필요에 따라 여러 Beats를 함께 사용 가능
• 확장성: 다양한 입력 소스와 출력 대상(Elasticsearch, Logstash)을 지원하여 확장성이 뛰어남
• 보안: 수집된 데이터를 전송할 때 SSL/TLS 암호화를 지원하여 데이터의 무결성과 기밀성을 보장
• 자동화된 배포 및 관리: Elastic Agent를 사용하여 Beats의 설치, 구성 및 업데이트를 중앙에서 관리

 

Beats 종류

 

1. Filebeat

• 기능: 로그 파일에서 로그 데이터를 수집하여 Elasticsearch나 Logstash로 전송
• 사용 사례: 웹 서버 로그, 애플리케이션 로그, 시스템 로그 등 다양한 로그 파일을 수집할 때 사용

 

2. Metricbeat

• 기능: 시스템 및 서비스의 메트릭 데이터를 수집하여 Elasticsearch나 Logstash로 전송
• 사용 사례: CPU, 메모리, 네트워크 트래픽 등 시스템 성능 메트릭이나 MySQL, Redis 등의 서비스 성능 메트릭을 수집할 때 사용

 

3. Packetbeat

• 기능: 네트워크 트래픽 데이터를 캡처하여 Elasticsearch나 Logstash로 전송
• 사용 사례: 네트워크 성능 모니터링, 애플리케이션 성능 분석, 네트워크 보안 모니터링 등에 사용

 

4. Winlogbeat

• 기능: Windows 이벤트 로그를 수집하여 Elasticsearch나 Logstash로 전송
• 사용 사례: Windows 서버 및 클라이언트의 이벤트 로그를 중앙 집중식으로 관리할 때 사용

 

5. Auditbeat

• 기능: Linux Audit Framework에서 생성된 보안 관련 이벤트 및 시스템 무결성 데이터를 수집하여 Elasticsearch나 Logstash로 전송
• 사용 사례: 보안 모니터링 및 컴플라이언스 준수 목적으로 사용

 

6. Heartbeat

• 기능: 서비스 가용성을 모니터링하고, HTTP, TCP, ICMP 등의 프로토콜을 사용하여 서비스의 상태를 주기적으로 체크하여 Elasticsearch나 Logstash로 전송
• 사용 사례: 웹 사이트, API, 데이터베이스 등의 가용성을 모니터링할 때 사용

 

7. Packetbeat

• 기능: 네트워크 트래픽 데이터를 실시간으로 캡처하여 다양한 프로토콜(HTTP, MySQL, Redis, DNS 등)의 트랜잭션을 분석하고 Elasticsearch나 Logstash로 전송
• 사용 사례: 네트워크 성능 모니터링, 웹 애플리케이션의 요청 및 응답 시간 분석, 데이터베이스 쿼리 성능 모니터링, 보안 위협 탐지

 

8. Journalbeat

• 기능: Linux 시스템에서 systemd의 journal 로그를 수집하여 Elasticsearch나 Logstash로 전송
• 사용 사례: systemd를 사용하는 Linux 시스템의 이벤트를 중앙에서 모니터링, 시스템 오류 및 보안 이벤트 실시간 탐지 및 분석, 컴플라이언스 및 규제 요구 사항 충족

 

9. Functionbeat

• 기능: AWS Lambda나 Google Cloud Functions 같은 서버리스 컴퓨팅 환경에서 로그 및 이벤트 데이터를 수집하여 Elasticsearch나 Logstash로 전송
• 사용 사례: AWS Lambda 함수의 로그를 수집하여 분석, 서버리스 환경의 이벤트 데이터를 실시간으로 모니터링, 클라우드 인프라의 리소스 사용량 및 성능 중앙 모니터링

 

10. Custom Beats

• 기능: 특정 데이터 소스를 수집할 수 있도록 사용자 정의 데이터 수집기를 개발하여 Elasticsearch나 Logstash로 전송
• 사용 사례: 기존 Beats가 지원하지 않는 특수한 로그 파일이나 데이터 소스를 수집, 특정 비즈니스 로직에 맞춘 데이터 수집기 커스터마이징, 산업별 또는 회사별 요구사항에 맞춘 데이터 수집기 제작

 

Beats 사용법

• Filebeat의 사용 방법을 익혀두면 다른 beats를 사용하는 것도 어려집 않기 때문에 가장 많이 사용되는 Filebeat 위주로 beat 사용법 소개

 

1. Filebeat 동작 과정

• 로그 데이터가 위치한 경로를 지정해주면 filebeat는 harvester를 시작하고 각각의 harvester는 각 로그를 읽고 로그 데이터를 beat 라이브러리로 전송
• beat 라이브러리는 이벤트를 집계해서 다양한 output으로 전달

 

https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html

 

2. Filebeat 동작 원리

• 두 가지 핵심 모듈로 동작

 

2.1 harvester

• 단일 파일의 데이터를 읽는 역할
• 각 파일을 line by line으로 읽고 내용을 출력으로 전송
• 각 파일에 대해 하나의 harvester가 시작되며 파일이 수집되는 동안 파일이 제거되거나 이름이 변경되면 Filebeat는 계속해서 파일을 읽음
• harvester는 파일을 열고 닫을 책임이 있으므로 하베스터가 실행되는 동안 파일 설명자는 열려 있는 상태로 유지
• 로그 파일을 모니터링하는 동안 해당 로그 파일명이 변경될 경우 Filebeat는 기본적으로 새로운 파일로 인식하기 때문에 로그 파일에 대한 새로운 harvester가 시작되고 기존 harvester는 종료됨
  • 파일이 중복 수집될 위험이 있음

 

2.2 input

• harvester를 관리하고 읽을 모든 소스를 찾는 일을 담당
• 입력 유형이 로그인 경우 입력은 정의된 경로와 일치하는 드라이브의 모든 파일을 찾아 각 파일에 대한 harvester를 시작
• 로그 파일의 위치, 로그 파일의 패턴, 로그 파일을 읽는 방식 등을 포함
• 다양한 input 지원
  • s3,
  • http json
  • filestream
  • tcp
  • container
  • etc.

 

	filebeat.inputs:
	- type: log
	enabled: true
	paths:
	- /var/log/*.log
	- /home/user/logs/special/*.log
	# Include lines that match the regular expression
	include_lines: ['^ERR', '^WARN']
	# Exclude lines that match the regular expression
	exclude_lines: ['^DEBUG']
	# Exclude files which names match the regular expression
	exclude_files: ['.gz$']
	# Optional additional fields. These fields can be freely picked
	# to add additional information to the crawled log files for filtering
	# fields:
	# level: debug
	# review: 1

view raw .yml hosted with ❤ by GitHub

 

 

부연 설명

• type: log -> 로그 파일을 수집
• enabled: true -> 입력 활성화
• paths: 모니터링할 로그 파일 경로를 지정
• include_lines, exclude_lines: 특정 패턴의 로그 라인을 포함 또는 제외시킴
• exclude_files: 특정 패턴의 파일을 제외시킴

 

3. Filebeat registry

• registry라는 내부 상태 관리 시스템을 통해 파일 상태 유지
• Filebeat가 로그 파일을 어디까지 읽었는지, 어떤 파일을 읽었는지 등의 정보를 추적하는 역할
• Filebeat가 중단되었다가 다시 시작될 때, 마지막으로 읽었던 위치에서 로그 파일의 읽기를 재개할 수 있게 지원
  • 로그 데이터의 중복 수집을 방지
  • 로그 파일의 정확한 처리를 보장

 

• 이벤트의 손실없이 전송을 보장
  • 이벤트의 전송 상태를 registry 파일에 저장하기 때문에 최소 한 번 이상 전송(at-least-once delivery)되도록 보장
  • output에서 이벤트를 수신했음을 인식할 때까지 Filebeat가 계속 이벤트를 전송하려고 시도
  • Filebeat가 이벤트를 전송하는 도중 종료되는 경우, 확인하는 로직 존재
  • 따라서 이벤트가 전송되었더라도 Filebeat가 종료되기 전에 확인되지 않은 모든 이벤트는 Filebeat가 재기동될 때 다시 전송됨
  • 주의: 파일이 rolling되면서 Filebeat가 output 처리를 하기도 전에 삭제가 빠르게 되어버릴 경우 손실 발생할 수 있음

 

4. Filebeat 사용 예시

• Apache Web 로그를 ES에 적재하는 예시

 

4.1 Filebeat의 apache module 활성화

• Filebeat의 모듈은 특정 유형의 로그 데이터를 수집하고 처리하는데 필요한 구성과 파싱 로직을 제공하는 미리 정의된 구성 요소
• Filebeat의 모듈은 기본적으로 Filebeat와 함께 제공되며, 다양한 소스에서 데이터를 수집하고 구조화된 형식으로 Elasticsearch에 전송할 수 있게 해 줌
• 별도 설정 안 했을 경우 초기에는 모두 비활성화되어 있음 (*.yml.disabled)
• ./filebeat modules enable apache 명령어를 통해 apache module 활성화

 

 

 

4.2 apache.yml 수정

• access.enabled true로 지정
• var.paths에 Apache Web 로그 경로 설정

 

 

4.3 filebeat 실행

• ./filebeat -e 명령어 실행

 

4.4 Elasticsearch 인덱스 확인

• GET _cat/indices를 통해 Filebeat에 의해 생성된 인덱스명 확인
• 해당 인덱스 조회

 

인덱스 조회

 

 

4.5 kibana 대시보드 setup

• ./filebeat setup -e 명령어를 통해 대시보드 구성

 

 

자동으로 설정된 대시보드

 

참고

• 패스트 캠퍼스 -  고성능 검색 엔진 구축으로 한 번에 끝내는 Elasticsearch
• 엘라스틱 개발부터 운영까지 (김준영, 정상운 저)