Filebeat 메모리 과다 점유

오픈소스/Filebeat

Filebeat 메모리 과다 점유

민둥곰 2021. 5. 16. 19:20

라이브 스테이지 서버에서 파일비트 초기 시작 시 메모리 3Gb까지 올라감에 따라 swap memory 사용이 늘었다.
- 기존 DB 서버에서 사용 가능한 메모리는 300Mb로 확인됨

- 전체 시스템 메모리 부족으로 Linux swap mermoy architecutre에 따라 mysql daemon이 swap memory 사용

옵션 및 Filebeat arichitecure

아래 옵션 및 작동 방식을 기록.

Filbeat 첫 기동 시

아래 3가지 방법으로 택 1하여 진행 필요

해당 파일의 전체를 읽는것이 아닌 Filebeat 기동 시점 부터 새로 수집된 data만 전송
관련 옵션 값: tail_files: true Filebeat DOCS (default: false)
bulk_max_size 를 크게 잡아(8192(8Kb) 이상) memory 사용랑 감소
관련 옵션 값: bulk_max_size: 8192 Filebeat DOCS (default: 2048)
filebeat queue 관련 설정 값 조정
관련 옵션 값: Filebeat DOCS
1. queue.mem:
events: 2048 # queue가 저장할수 있는 max event 값 (default: 4096)
flush.min_events: 1024 # 전송이 필요한 최소한의 이벤트 값 (default: 2048)
flush.timeout: 1 #default: 1s
Filebeat queue를 memory가 아닌 disk로 이용
Filbeat DOCS

파일비트 작동 방식:

옵션 별 세부 정보:

tail_files: regisry file에 파일 정보가 없을 경우 마지막줄에서 파일을 읽고 전송(하베스트가 파일 읽음)

bulk_max_size: event 개수 지정(한번에 보내는 데이터의 량으로 유추 가능)

bulk_max_size를 작게 잡을 경우 event가 작게 쪼개짐에 따라 processors가 늘어남 -> 파일비트 메모리 사용 증가
filbeat 의 경우 event → processors1 → event1 → processors2 → event2 로 data 전송

processors 의 경우
mulitiline 으로 잡힐 경우 하나의 event로 됨
ex) 아래가 전체 데이터일 경우

# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: user[user] @ localhost []  Id:  4540
# Query_time: 1.012936  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1608626939;
select sleep(1)
LIMIT 0, 300;

# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: dba_MDGome[dba_MDGome] @  [ip]  Id: 132325
# Query_time: 1.012936  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1608626939;
select sleep(1)
LIMIT 0, 300;

# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: user[user] @ localhost []  Id:  4540
# Query_time: 1.012936  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1608626939;
use test1;
select sleep(1)
LIMIT 0, 300;

# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: dba_MDGome[dba_MDGome] @  [ip]  Id: 132325
# Query_time: 1.000360  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
use test2;
SET timestamp=1608627224;
select sleep(1)
LIMIT 0, 300;



event 1:

# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: user[user] @ localhost []  Id:  4540
# Query_time: 1.012936  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1608626939;
select sleep(1)
LIMIT 0, 300;

event 2:
# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: dba_MDGome[dba_MDGome] @  [ip]  Id: 132325
# Query_time: 1.012936  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1608626939;
select sleep(1)
LIMIT 0, 300;

event 3:
# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: user[user] @ localhost []  Id:  4540
# Query_time: 1.012936  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1608626939;
use test1;
select sleep(1)
LIMIT 0, 300;

event 4:
# Time: 2020-12-22T17:48:59.613103+09:00
# User@Host: dba_MDGome[dba_MDGome] @  [ip]  Id: 132325
# Query_time: 1.000360  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
use test2;
SET timestamp=1608627224;
select sleep(1)
LIMIT 0, 300;

성능 테스트 진행

1. ES(elasticsearch) 싱글 노드, logstash, mysql-filebeat 서버(총 3서버) 테스트 환경 구성

기존에 작성 해둔 ansible play book 활용하여 docker로 환경 구성

환경 정보:

	OS 정보	version 정보
Local PC	Windows 10 Pro AND	-
ansible	CentOS 7	latest(최신 버젼)
elasticsaerch	CentOS 7	7.5.2
logstash	CentOS 7	7.5.2
filebeat	CentOS 7	7.5.2
mysql	CentOS 7	5.7

Docker-Compose

리눅스 모니터링 방법

1. 툴 사용

2. 명령어 사용

elasticsearch 환경 구성

play-book:

logstash 환경 구성

play-book:

mysql-filebeat 환경 구성

play-book:

2. 현상 재현을 위한 MySQL slow query 발생 스크립트 작성 혹은 기존 log 활용

- MySQL slow-query 스크립트: python으로 작성

- 현 상황에서는 기한이 임박하여 기존 log 활용 추후 스크립트 작성 예정

slow query log 파일 사이즈: 약 4.7G

3. 파일비트 메모리 설정 값 변경 파일비트 메모리 점유율 확인'

테스트할 옵션 값:

queue.mem:
events: 2048 # queue가 저장할수 있는 max event 값 (default: 4096)
flush.min_events: 1024 # 전송이 필요한 최소한의 이벤트 값 (default: 2048)
flush.timeout: 1 #default: 1s

테스트 스크립트:

sudo systemctl start filebeat

sudo rm -f /etc/...

sudo systemctl restart filebeat