Elasticsearch는 Java 기반으로 동작을 합니다. Java는 가비시 컬렉터 (garbage-collected)에 의해서 관리가 되며, Java 객체는 힙(Heap) 이라고하는 메모리의 런타임 영역에 상주합니다.
Elasticsearch는 기본적으로 1GB의 Heap 으로 구성이 되어 있습니다. 이 기본값은 대부분의 클러스터 구성에서 매우 작기 때문에 Elasticsearch에서 충분히 사용이 가능하도록 메모리 크기를 늘려 주어야 합니다.
Elasticsearch에서 힙 크기를 변경하는 방법에는 두 가지가 있습니다. 가장 쉬운 것은 ES_HEAP_SIZE 이라는 환경 변수를 설정하는 것 입니다. 서버 프로세스가 시작되면이 환경 변수를 읽고 이에 따라 힙을 설정합니다. 예를 들어, 다음과 같이 명령 행을 통해 설정할 수 있습니다.
export ES_HEAP_SIZE=16g
또는 프로세스를 시작할 때 JVM 플래그를 통해 힙 크기를 전달할 수 있습니다
ES_JAVA_OPTS = "-Xms10g -Xmx10g" ./ bin / elasticsearch
jvm 플래그 옵션은 jvm.option 파일을 통해서 설정을 할 수도 있습니다. Elasticsearch는 전체적인 Heap 사이즈를 jvm.option의 Xms (minimum heap size) and Xmx (maximum heap size) 값을 통해 조절이 가능합니다. 단, 두개의 사이즈 값은 모두 동일하게 세팅해 주어야 합니다.
vi /etc/elasticsearch/jvm.option
-Xmx16g
-Xms16g
"32G 이하"
여기서 그러면 Heap 메모리의 적당한 값은 얼마가 되어야 할까요?
적당한 heap 메모리가 얼마인지는 워크로드에 따라 달라지겠지만, 너무 작은 Heap 메모리는 Out-of-Memory를 일으킬수 있고, 또 반대로 너무 큰 메모리는 GC(Gabage Colection)가 발생할 경우 응답 대기 시간이 길어질 수 있습니다.
Elasticsearch에서는 힙(Heap) 크기를 32G이하로 사용하도록 권장하고 있습니다.
jvm은 자신이 사용하기 위해 필요한 데이터를 heap 메모리에 올려 두고 사용을 하는데 이때 이 데이터 단위를 object라고 합니다. 그리고 이 object에 접근하기 위한 가상의 주소를 ordinary object pointers(이하 oop) 라고 부릅니다.
jvm은 32bit에서는 2의 32제곱인 4G까지 32bit의 oop를 사용을 하며 4G 이상은 64bit의 oop를 사용을 하게 됩니다. 그런데 64bit는 32bit에 비해 포인터가 크기 때문에(8배) 성능 저하가 발생을 하게 됩니다. 그래서 나온것이 64bit 에서도 32bit의 oop를 사용할 수 있는 compressed ordinary object pointers ( compressed oops ) 입니다.
native oop는 object 자체이지만, compressed oops 는 object의 주소의 오프셋을 가리킵니다. 64bi의 jvm object pointer는 8바이트 단위이며, 8의 n의 배수마다 object 주소의 오프셋인 compressed oops를 사용하여 32bit 처럼 동작을 하게 됩니다. 8바이트 단위인 0, 8, 16, 24 의 object에 32bit의 0, 1, 2, 3을 사용하여 기존보다 8배 이상 사용이 가능하게 됩니다. 즉 사용 가능한 메모리가 32bit 4G 의 8배, 32G가 되는 것입니다.
만약 heap 사이즈가 32G를 넘어가게 되면 jvm이 64bit oop를 사용하게 되어 성능이 급격하게 떨어집니다. 그래서 Elastic에서는 32G 이상의 메모리를 사용하지 않도록 권고 하고 있는 것입니다.
그리고 시스템 전체 메모리의 절반인 약 50% 정도만 사용하는 것이 좋습니다. Elasticsearch에는 JVM 힙 이외의 용도로 메모리가 필요하므로 이를위한 공간을 확보하는 것이 중요합니다.
이번시간에는 ELK 를 활용하여 Fortigate 방화벽 로그를 수집하고 구성하는 방법에 대해서 알아보도록 하겠습니다.
로그 수집시 중요한 것은 장비 밴더사나 로그 특성등에 따라서 형식이 다 다르기 때문에 수집한 로그에 대해서 적절한 필터링을 통해 정형화 해 주어야 로그 분석 및 탐지가 용이하게 됩니다.
여기서는 방화벽에서 ELK Stack으로 로그를 전송을 Logstash.conf 필터를 통해서 로그 데이터 파싱하고 인덱싱하는 부분에 대해서 살펴보도록 하겠습니다. .
1. Fortigate 방화벽 Syslog 설정.
우선 Fortigate 방화벽 장비 CLI 접속하여 Logstash 서버로 로그 데이터를 전송하도록 설정을 해 줍니다.
syslog 설정은 최대 4개까지 설정이 가능하며, Fortigate Web UI 에서는 첫번채 syslogd 만 세팅이 가능하여 중복설정등이 필요할 경우 CLI를 통해 설정하는 것을 추천 드립니다.
config log syslogd2 setting
set status enable
set server "192.168.0.100"
set port 5514
저는 syslogd2에 설정하였으며, 로그 수집 서버 IP와 포트를 지정을 해 주고 enable 활성화 해 주시면 됩니다.
syslog 포트는 default 514(udp) 인데 udp 514는 다른 로그 수집용 포트로 사용하고 있어서 구분을 위해서 5514로 지정하였습니다.
- syslog 설정 확인.
Fortigate # config log syslogd3 setting
Fortigate (setting) # show
config log syslogd3 setting
set status enable
set server "192.168.0.100"
set port 5514
end
Fortigate (setting) #
2. ELK 로그 서버 Logstash.conf 필터 설정
방화벽에서 로그 전송 설정을 했으면 이제 Logstash.conf 설정 파일을 통해 로그를 수집하여 필터링 해 주시면 됩니다.
logstash.conf 파일은 /etc/logstash/conf.d/logstash.conf 에 만들었으며 아래와 같은 형식으로 만들었습니다.
Input
- udp 플러그인을 사용. - 0.0.0.0 네트워크 바인딩. - 5514 포트 활성화 - 로그 수집시 Tag 필드에 에 "FWlog" 생성. ( Kibana 대시보드 구성시 tag를 활용하여 로그 데이터 구분 )
5. 환경 설정 ELK 설치가 완료되면 아래와 같이 추가적으로 설정값을 변경해 주면 됩니다. 디스크 용량 관리차원에 서 로그 데이터 파티션을 별도 분리하여 관리하고, Java heap 메모리 설정 및 성능 튜닝등을 통해 퍼포먼스를 향상킬 수 있습니다.
1) Elasticsearch.yml 파일 수정 및 디렉토리 생성 - elasticsearch가 환경 설정 파일 : /etc/elasticsearch/elasticsearch.yml
[root@localhost ~]# vi /etc/elasticsearch/elasticsearch.yml
cluster.name: clustername // 클러스터 이름 변경(선택)
path.logs: /ELK/log/elasticsearch // elasticsearch 로그 파일 위치
path.data: /ELK/elasticsearch // elasticsearch 데이터 파일 위치
network.host: 0.0.0.0 // elasticsearch 바인딩 정보
http.port: 9200 // elasticsearch 서비스 포트(default 9200)
## 성능 튜닝 관련 설정.
thread_pool.search.queue_size: 10000
indices.memory.index_buffer_size : 512mb
cluster.max_shards_per_node : 3000
- elasticsearch 디렉토리 생성 및 소유권 변경
mkdir /ELK/log // 로그 파일 디렉토리 생성
mkdir /ELK/log/elasticsearch // elasticsearch 로그 디렉토리 생성
mkdir /ELK/elasticsearch // elasticsearch 데이터 디렉토리 생성
## 디렉토리 소유권 변경 ( root => elasticsearch )
chown elasticsearch.elasticsearch /ELK/log/elasticsearch -R
chown elasticsearch.elasticsearch /ELK/elasticsearch -R
2) elasticsearch jvm.options heap 메모리 사이즈 조절
Heap 메모리 사이즈는 최대 32G 이하로 세팅하는 것을 권장하며, 여기서는 32G 메모리의 절반인 16G 로 세팅하였습니다. heap 메모리 관련이나 성능 튜닝관련해서는 차후에 따로 포스팅을 하도록 하겠습니다.
vi /etc/elasticsearch/jvm.option
-Xms1g => Xms16g
-Xmx1g => Xms16g
3) logstash.yml 파일 수정 및 디렉토리 생성 - logstash 환경 설정 파일 : /etc/logstash/logstash.yml
vi /etc/logstash/logstash.yml
path.data: /ELK/logstash/
path.logs: /ELK/log/logstash
- logstash 디렉토리 생성 및 소유권 변경
mkdir /ELK/log/logstash // logstash 로그 디렉토리 생성
mkdir /ELK/logstash // logstash 데이터 디렉토리 생성
## 디렉토리 소유권 변경 ( root => logstash )
chown logstash.logstash /ELK/log/logstash -R
chown logstash.logstash /ELK/logstash -R
4) logstash jvm 옵션 heap 메모리 조절 ( 1G => 4G ) logstash heap 메모리도 시스템 사양에 따라 적절하게 값을 할당해 주시면 됩니다. 여기서는 4G로 할당하였습니다
vi /etc/logstash/jvm.option
-Xms1g => Xms4g
-Xmx1g => Xms4g
5) kibana.yml 환경 설정
- kibana 환경 설정 파일 : /etc/kibana/kibana.yml
vi /etc/kibana/kibana.yml
server.host: 0.0.0.0
elasticsearch.hosts: "http://localhost:9200"
7. Logstash 파일 생성 및 Logstash 실행
Logstash는 외부 로그데이터 전송시 로그를 수집하고(Input), 변환한 후(filter), elasticsearch로 전송(output) 해주는 역할을 합니다. logstash 실행시 데이터 수집 및 변환 출력을 위한 필터가 필요합니다.
1) logstash 필터 파일 구조 ( logstash.conf , 파일 이름 임의 생성 가능 )
원하는 이름으로 생성하시면 되며 아래와 같은 구조로 작성을 합니다.
"ELK"는 Elasticsearch, Logstash 및 Kibana, 이 세게의 프로젝트의 각 첫글자의 조합입니다.
Elasticsearch는 검색 및 분석 앤진, Logstash는 데이터를 수집 및 변환하는 데이터 처리 파이프라인 Kibana는 데이터를 차트와 그래프등을 이용해 볼수 있는 시각화 도구
최근에는 ELK Stack에 단일 목적 데이터 수집기 제품인 Beat 를 추가했으며, 이 네개의 조합을 합쳐서 Elastic Stack 이라고 부르고 있습니다. 즉, Elastic Stack은 ELK Stack이 그 다음 단계로 발전한 것이라고 할 수 있습니다.
Elasticsearch
Elasticsearch는 Lucene 검색 엔진을 기반으로하며 RESTful API로 구축 된 NoSQL 데이터베이스입니다. 매우 유연하고 분산 된 검색 및 분석 엔진입니다. 또한 수평 확장 성을 통해 간단한 배포, 최대 안정성 및 손쉬운 관리 기능을 제공합니다. 고급 쿼리를 제공하여 상세 분석을 수행하고 문서를 빠르게 검색 할 수 있도록 모든 데이터를 중앙에 저장합니다.
Logstash Logstash는 데이터 수집 파이프 라인 도구입니다. 데이터 입력을 수집하여 Elasticsearch에 공급하는 ELK Stack의 첫 번째 구성 요소입니다. 다양한 소스에서 다양한 유형의 데이터를 한꺼번에 수집하여 즉시 사용할 수 있습니다.
Kibana
Kibana는 데이터 시각화 도구입니다. Elasticsearch 문서를 시각화하는 데 사용되며 개발자가 문서에 대한 즉각적인 통찰력을 갖도록 도와줍니다. Kibana 대시 보드는 Elasticsearch를 사용하여 수행 한 복잡한 쿼리를 시각화하기 위해 다양한 대화 형 다이어그램, 지리 공간 데이터, 타임 라인 및 그래프를 제공합니다.Kibana를 사용하면 특정 요구에 따라 사용자 정의 그래프를 작성하고 저장할 수 있습니다.
ELK Stack Architecture
다양한 형태의 로그는 Logstash에 수집이 되고, 필터 기준에 따라 변환이 이루어 집니다. 그 다음 Logstash는 해당 로그를 Elasticsearch로 전달 한 후 Elasticsearch는 해당 로그를 분석하고 검색합니다. 마지막으로 Kibana를 사용하여 원하는 형태에 따라 로그를 시각화 하고 관리하게 됩니다.
여기에 Beats 가 추가가 되었습니다.
단일 목적의 데이터 수집기 플랫폼인 Beats는 수백 수천 개의 장비와 시스템으로부터 Logstash나 Elasticsearch에 데이터를 전송합니다.
Beats 동작 방식.
Beat는 서버에 에이전트 형식으로 설치하는 오픈소스 데이터 수집기 입니다. Beats 는 데이터를 Elasticsearch에 직접 전송할 수 있으며, Logstash를 통해서 데이터를 전송할 수도 있습니다.
Beats 제품군
Filebeat - Real-time insight into log data 로그와 파일을 경량화된 방식으로 전달하고 중앙 집중화하여 작업을 보다 간편하게 만들어 주는 역할을 합니다 Download
Packetbeat - Analyze network packet data. Packetbeat는 데이터에 실시간으로 접근하여 내용을 분석하면 네트워크 트래픽의 흐름이 어떤지 파악할 수 있습니다 Download
Winlogbeat Analyze Windows event logs. Winlogbeat를 이용해 Windows 이벤트 로그를 Elasticsearch와 Logstash로 스트리밍할 수 있습니다 Download
Metricbeat - Ship and analyze metrics. CPU부터 메모리, Redis, NGINX까지 Metricbeat를 통해 다양한 시스템 서비스 통계를 가볍게 전송할 수 있습니다 Download
Heartbeat Ping your Infrastructure. Heartbeat를 통해 가동 시간과 반응 시간등 활성 상태를 탐지하고 서비스가 가능한지 모니터링합니다 Download
Auditbeat Send audit data to Elasticsearch. Auditbeat는 Linux 감사 프레임워크 데이터를 수집하고 수집한 데이터를 Elastic Stack에 실시간 전송합니다 Download
Functionbeat Ship cloud data with serverless infrastructure. 클라우드 서비스의 Function-as-a-Service (FaaS) 플랫폼에서 기능으로 배포하여 데이터를 수집, 전송, 모니터링합니다 Download