EFK 로그 수집 아키텍처 Elasricsearch + Fluentd + Opendashboard

ELK

Elasricsearch + Logstash + Kibana

Elastic stack으로 구성된 ELK (Loagsash) 라는 용어로 더 잘 불리운다.

EFK (EFO) 로그 수집 아키텍처

Elasricsearch + Fluentd + Kibana (Opendashboard)

Elastic stack의 유료화 때문에 Opensearch + Opendashboard를 사용한다.

 

Fluntd

로그의 수집, 파싱, 전송 역할
어플리케이션의 파일을 읽어야하므로 어플리케이션과 같은 호스트에 뜬다.
CRuby로 만들어져있다. (Fluenbit이라는 C기반 경량화 버전도 있으며, forwarder로서 사용하기에 적합)

장점

적은 리소스를 사용하면서 로그를 파싱하고 전송한다.
규칙을 태그방식으로 정하기때문에 사용성이 직관적이다.

Opensearch(Elasticsearch)

로그를 저장하는 저장소
Java로 만들어졌고, JVM 위에서 돌아간다.

장점

텍스트 데이터의 검색에 특화된 인덱싱 방법을 가지고 있다. => 로그의 저장소 겸 검색 시스템으로 사용하기 좋다.
미리 스키마를 선언하지 않아도 저장된 데이터 형식에 맞게 자동으로 인덱싱할 수 있다. => 로그는 다양한 시스템에서 다양한 목적으로 남기기 떄문에 로그 저장소는 데이터 타입과 형식에 대한 유연성을 제공하는 것을 선택해야한다.

OpenDashboard(Kibana)

Opensearch와 연동되는 사용하기 쉬운 시각화 도구.
timeline 방식의 로그 시각화를 제공한다.
Javascript로 만들어지고 Nodejs 서버로 동작한다.

장점

SQL을 모르더라도 UI를 통해서 원하는 로그를 쉽게 찾고 추이를 볼 수 있다.
검색 결과에 대한 link를 생성해서 빠르게 공유할 수 있다.
이미 데이터가 Opensearch에 쌓여있다면 다양한 그래프를 작성하고 통합된 Dashboard도 구성할 수 있다.

 

---

 

Filebeat + Logstash   VS   Fluntd

 

JRuby(Logstash)와 CRuby(Fluntd) 차이 때문에 Logstash가 조금 더 많은 메모리를 사용한다.

 

Fluntd가 더 좋은 이유

1. 메모리의 버퍼 큐 아키텍처 성능 차이

Logstash

메모리 상의 큐에 고정된 크기인 20개의 이벤트를 갖고 있다.
재시작 시 지속성, throughput 대비 높은 유입량에 대비하기 위해 Redis 또는 Kafka와 같은 외부 큐에 의존해야 한다.

Fluentd 

메모리상에 또는 디스크에 끝없는 배열로 구성되어있는 버퍼를 가진다.
유입량에 대한 관리를할 수 있고 재시작시 디스크에서 읽어서 재처리 할 수 있다.

 

2. 이벤트 라우팅 문법 차이

Logstash - if else 기반

output { if[loglevel] == "ERROR" and [devlopment] == "production" {{...}}

Fluentd - 태그 기반

<match logtype.error>type...</match>

Logstash 보다는 직관적이다.

하지만 많아진다면 설정이 복잡하고 성능이 떨어질 수 있다.
rsyslog -> fluentd로 파싱결과를 보내는 아키텍처도 선택가능하다.

---

 

기본 아키텍처

App    -->
fluntd  --> elasticsearch
log file -->

Application이 Logfile을 남김 => 수집기(fluentd)가 수집 => storage(Elasticsearch)로 전송

작은 규모 서비스

수집기(Fluntd) => 바로 storage(Opensearch)로 전송

 

---

로그 수집기 부하 원인

1. 실시간으로 쌓이는 로그의 양 > 수집기가 처리할 수 있는 양
2. 수집기에서 처리하는 파싱 로직이 복잡할 경우
3. 수집기의 리소스 < 처리하는 작업

로그 수집기 부하 개선 방법

로그 수집기에 부하가 생기면 로그 수집이 지연되거나 유실될 수 있다.

 

Fluentd를 forwarder와 collector로 나눈다.

App     -->
fluntd   --> fluentd (N) --> elasticsearch
log file -->

 

Forwarder

각 노드(또는 인스턴스)에서 fluentd는 최소한의 Parsing, 전송 한다.

Collector

Forwarder에 의해 전달된 로그를 파싱하고 적절한 스토리지로 전송
인스턴스 수를 늘리거나 줄이면서 로그의 유입량의 변화와 부하에 대응한다.

 

 

---

Fluentd를 클러스터 구성해서 운영하는 것이 어렵다면

 

kafka와 같은 메시지 큐를 이용하여 구성하여 다양한 트래픽과 로그를 대응할 수 있다.

 

 

로그 수집기들은 정상이지만 저장소에서 트래픽을 받아주지 못할 때 storage가 bottleneck이 될 수 있다.

원인

storage API에서 Error를 받게되면 로그 수집기에서 무한 재시도 또는 쌓여있는 로그때문에 buffer full로 인해 부하가 커지거나 로그가 유실될 수 있다.

해결

Opensearch 에서는 ingest node라는 서버로 스토리지 저장 효율을 높일 수 있다.

App    -->                                        elasticsearch
                                                               |
fluntd  --> kafka --> fluentd (N) --> ingest nodes
                                                               |
log file -->                                       data nodes