elk fleet서버를 이용하여 전사 서버의 system, web, db로그를 쌓고 있습니다.

단순 로그용도 서버로 cluster 불필요하여 docker 환경으로 구성했습니다. 

 

<설치 참고사이트>

https://github.com/peasead/elastic-container

 

서버 연동 후 30일 이상의 대량 로그 검색 시 아래와 같이 오류가 발생하여 jvm 옵션 조정 작업을 진행했습니다.

[esaggs] > [parent] Data too large, data for [decode async response] would be [1021554376/974.2mb], which is larger than the limit of [1020054732/972.7mb], real usage: [1021547080/974.2mb], new bytes reserved: [7296/7.1kb], usages [model_inference=0/0b, inflight_requests=0/0b, request=7296/7.1kb, fielddata=63612/62.1kb, eql_sequence=0/0b]

 

elasticsearch 7점대 버전에서 oom이 발생하거나 검색 지연이 발생하면 jvm.options 파일의 heap 메모리 값을 조정하여 운영했습니다.

elk 가이드 상 8점대 버전에서는 jvm 힙 크기를 자동으로 설정한다고 하지만 실제 운영 시 oom 및 메모리 부족으로 인한 검색 실패가 발생합니다.

 

관련하여 도커 컨테이너 환경에서 jvm 옵션 조정 작업 내역을 기록하려고 합니다.

 

1. 현재 jvm 옵션

1) 키바나  Dev Tools 를 활용하여 현재 사용하고 있는 jvm 값 확인

GET _nodes/_all/jvm 

 -> JVM 조정 이후 스크린 샷 

또는 OS 상에서 elastic 프로세스의  -Xms, -Xms값 확인

 

2)  jvm 옵션 조정값 추가 및 컨테이너 재구동

1) elasticsearch 컨테이너 접속 후 heap.conf 파일 생성 및 haep 메모리 값 입력

/usr/share/elasticsearch/config/jvm.options.d/heap.conf

-Xms4g

-Xmx4g

 

2) 컨테이너 재구동

docker restart ecp-elasticsearch

 

3) jvm 메모리 값 수정 내용 확인

키바나 dev tools: GET _nodes/_all/jvm

OS 프로세스: ps -ef | grep -i elasticsearch

 

jvm heap메모리 수정 후 오류 발생했던 검색 시 정상 적으로 출력되고 있습니다.

elasticsearch 8.15 가이드에서 jvm 옵션이 자등으로 조정된다고 하지만 실제 운영 시 메모리 

문제가 발생했습니다.

 

위와 같이 문제 발생 시 jvm 옵션을 수정하여 사용이 필요합니다.

 

 

 

 

 

'모니터링' 카테고리의 다른 글

graylog admin 비밀번호 변경  (0) 2024.07.16
elk snapshot & restore 테스트  (0) 2024.07.15
zabbix mysql 모니터링 연동  (0) 2024.02.29
zabbix 에이전트 연결 방법  (0) 2024.02.26

 

작업 방법
1. 비밀번호 생성

echo -n 비밀번호 | sha256sum
2b379a301a5122ddde7290baa0360035fa7835893baebef1d7da983e3dfd7cc9

 

2. root_password_sha2 값 변경

vim etc/graylog/server/server.conf
root_password_sha2 = 2b379a301a5122ddde7290baa0360035fa7835893baebef1d7da983e3dfd7cc9

 

3, 서비스 재구동

systemctl status graylog-server.service

 

elk 데이터 백업 테스트를 위해 snapshot & restore 기능 테스트 진행한 내용이다.

 

elk sanpshot은 파일시스템, s3와 같은 오브젝트 스토리지를 활용 할 수 있다.

파일시스템 타입의 경우 cluster node 전체가 읽기 쓰기가 가능해야 하기 때문에 shared file system(NFS)가 필요하다.

 

금번 실습은 외부 오브젝트인 네이버의 object storage를 사용했으며 cluster간 snapshop resotre 테스로 진행 했다

원본 cluster snapshot → 복구 cluster restore

 

1. 사전 작업
1) elasticsearch plugin list 확인하여 설치


plugin 확인하여 설치 (install 또는 설치 plugin 이관)

[root@devapp2 bin]# ./elasticsearch-plugin list
javacafe-analyzer

 

usr/share/elasticsearch/plugins/javacafe-analyzer/plugin-descriptor.properties
elasticsearch.version=7.5.2 elasticsearch 버전에 맞게 수정

 

※plugin 누락 시 plugin에 종속적인 데이터는 복구되지 않는다.

 

2) 원본 elasticsearch 서버에서 repolistory 구성 및 snapshot 백업 진행

 

2.상세 작업 내용
cluster 구성일 경우 모든 elastisearch node에 작업 진행

 

1) s3 plugin 설치

elasticsearch-plugin install repository-s3

 

2) aws cli 설치

pip-3 install awscli

 

3) access kye, secret kye 입력

elasticsearch-keystore add s3.client.default.access_key #access_key 입력
elasticsearch-keystore add s3.client.default.secret_key #secret_key 입력
elasticsearch-keystore list # key 추가 확인

 

※네이버 클라우드  access_key, secret_key 확인 필요

 

4) elastcsearch.yml repository 추가

vim /usrshare/elasticsearch/config
s3.client.default.endpoint: kr.object.ncloudstorage.com

 

5) elasticsearch 재구동

 

systemctl restart elaticsearch or docker 컨테이너 재구동

 

6) snapshot 생성

- 키바나 Dev Tools or culr 사용

PUT /_snapshot/ncp_s3 {
"type": "s3",
"settings": {
"bucket": "elk",
"client": "default",
"compress": true,
"base_path": "/elk_snapshot"
}
}

7) snapshot 내역 확인

GET /_snapshot/ncp_s3

 

7. restore 진행 (키바나 사용)
- 원본 서버와 동일한 snapshot 생성 및 접근이 가능하면 키바나에서 snapshot list 확인 가능
- 키바나 접속 -> Snapshot and Restore -> snapshot 선택 후 restore

 

shared file system(NFS), s3와 같은 object storage 통해 snapshot 스케쥴 설정을 하면 손쉽게 백업 구성이 가능하며

서버 교체 작업 및 오래된 파일 보관이 필요할 경우 유용하게 사용할 수 있다.

 

현재 운영중인 사이트에서 시스템 모니터링 용도로 zabbix를 사용하고 있다.

서버, 어플리케이션(web, db, container), 네트워크 장비까자 다양한 템플릿 및 snmp로 연동이 가능하며 

많은 레퍼런스로 쉽게 연동 정보를 확인할 수 있기 때문이다.

 

그리고 자체적인 트리거가 있어 관리자가 일일이 경보 설정을 하지 않아도 되며,

텔레그램 같은 메신저 프로그램과도 연동이 쉽다.

 

오늘은 mysql 모니터링 연동 방법을 기록하려고 한다.

zabbix-agent2 사용 시 별도의 userparameter 구성 없이 손쉽게 구성이 가능하다.

 

1. mysql 모니터링 계정 생성

mysql -u root -p
# Enter password:
mysql> CREATE USER 'zbx_monitor'@'%' IDENTIFIED BY '<password>';
mysql> GRANT REPLICATION CLIENT,PROCESS,SHOW DATABASES,SHOW VIEW ON *.* TO 'zbx_monitor'@'%';
mysql> quit;

 

2. 모니터링 대상 서버 mysql templates 추가 및 macro 수정

1) mysql templates 추가

Configurations → Hosts → 대상 서버 선택 -→ templates → Template DB MySQL by Zabbix agent 2 추가

 

2) Macros 수정

{$MYSQL.DSN} :  mysql socket이나 tcp 포트 입력

{$MYSQL.PASSWORD} : 모니터링 계정의 비밀번호

{$MYSQL.USER} : 모니터링 계정

 

3. 연동 확인

 zabbix 서버 버전 :  5.0.12

사전 작업 zabbix 서버 및 모니터링 대상 서버간 방화벽 오픈 

- zabbix서버 → 모니터링 대상 서버 10050

- 모니터링 대상 서버  →  zabbix서버 10051

 

1. zabbix 에이전트 서버의 정보를 확인하여 zabbix 공식 사이트에서 설치 가이드 확인

출처 :  zabbix 공식 사이트

2. 해당 내용으로 모니터링 대상 서버에서 에이전트 설치진행

 

3. zabbix 관리 페이지에서 모니터링 대상 서버 추가

1) Configureation → Hosts → Create host →모니터링 대상 정보 입력

 

2) Templates 에  리눅스 템플릿 선택 하여 추가

 

3. 모니터링 대상 서버의 /etc/zabbix/zabbix_agent2.conf 파일 수정

<수정 내용>

Server=127.0.0.1
ServerActive=127.0.0.1
Hostname=Zabbix server

 

Server, ServerActive  → zabbix 서버 IP 입력

Hostname  → 자빅스 관리 페이지에 등록한 모니터링 대상 서버 명 입력

 

4. 서비스 재구동 진행 및 자빅스 연동 확인

systemctl restart zabbix-agent2.service

 

Monitoring -> Hosts -> IP 또는 Name 검색 Graphs 선택

 

 

5. 연동 오류 발생 시 로그 확인

tail -f /var/log/zabbix/zabbix_agent2.log

 

 

+ Recent posts