[ELK] 로그모니터링을 위한 ELK Stack 개념들!!

로컬에서 개인적인 개발을 진행할 경우에는 로그의 중요성을 체감하기 어렵다. 어차피 내가 진행한 작업환경이고 에러가 날 경우 시스템의 히스토리를  알기에 일일이 찾아서 수정하면 되기 때문이다.

그러나 회사 시스템 환경에서는 일일이 그럴 수 없기에 로그를 남기는 것이 필수적이고 시스템에 장애가 나면 로그를 빨리 분석해야 하기에 로그 수집을 위한 아키텍처 설계 작업이 매우 중요하다.

 

[로그란??]

• Log 란, 컴퓨터가 수행하는 도중 유의미한 내용을 남기는 기록을 말한다. 통상 파일로 남기는 기록을 말한다.
• 로그의 내용 로그에는 통상 다음 내용이 들어가야 한다.
  • 로그를 남긴 시간
  • 로그 레벨 (심각성의 정도)
    • FATAL > ERROR > WARN > DEBUG > TRACE 
  • 로그 내용
  • 로그가 발생한 위치
    • 로그를 남긴 패키지, 클래스의 정보는 필수로 남겨야 한다.
    • 로그가 WARN, ERROR라면, 해당 로그가 발생한 코드의 위치(정확한 Line)를 알 수 있다면 문제점을 파악하는 데 도움이 많이 된다.
  • 로그를 수집하는 이유!!
    • 시스템(HW)에 장애가 나면 로그파일에 다시 접근할 수 없을 수 있다
    • 사용하는 프로그램이 많아지거나, 인스턴스의 수가 많다면 일일히 들어가서 확인하기 어렵다.
    • 필터링, 그룹, 검색 등을 이용해서 로그를 활용해서 더 신뢰성 있는 시스템을 만들 수 있다.

---

[ELK Stack]

Elasticsearch / Logstash /Kibana

ELK는 위 그림처럼 세 가지 기술로 구성된다.

• Elasticsearch    로그 저장 및 검색
• Logstash           로그 수집 엔진
• Kibana               로그 시각화 및 관리

 

물론 세 모듈은 각자의 독립된 기술이기 때문에 필요에 따라 일부만 써도 된다.

하지만 서로 호환이 잘되고 합쳤을 때 시너지가 좋기 때문에 같이 구축된다.

https://logz.io/learn/complete-guide-elk-stack/#what-elk-stack 순서상 LEK아닌가...?

최근에는 ELK Stack에 주로 Beats라는 경량 데이터 수집 도구가 추가하기도 한다.

즉, Beats는 경량 데이터 수집기, Logstash는 데이터 처리 파이프라인 도구, Elastic Search는 검색 엔진, Kibana는 데이터 시각화 대시보드로 이해하면 된다.

ELK 스택에서 데이터는 어디서, 어떻게 발생하고 흘러가며 저장되고 검색되어 시각화될까?

• Beats는 로그 혹은 메트릭이 발생하는 서버에 에이전트로 설치되어 데이터를 수집하고, 이 데이터를 Logstash로 전송한다.
• 위 다이어그램에는 Beats와 Logstash 사이에 Redis, Kafka, Rabbit MQ와 같은 메시지 큐가 위치하는 것을 확인할 수 있는데, 이는 안정성 또는 확장성 등을 위함이다.
• Beats (혹은 메시지큐) 로부터 데이터를 전달받은 Logstash는 데이터를 적절히 필터링, 가공하여 Elastic Search로 전달한다.
• 따로 Beats를 구축하지 않고 바로 Logstash에서 로그 데이터를 수집하고 전송하는 아키텍처도 흔히 볼 수 있는 아키텍처이다.
• Logstash 로부터 데이터를 전달받은 Elastic Search는 데이터를 굉장히 빠른 속도로 검색될 수 있도록 인덱싱한다.
• Kibana는 REST를 통해 Elastic Search로부터 데이터를 가져와 유저에게 시각화와 간편한 데이터 검색 기능 등을 제공한다.

---

[Elastic Search]

ELK 스택은 Elastic Search로부터 시작된다.

• Elastic Search는 Lucene 기반 검색엔진 (경우에 따라 NoSQL 데이터베이스로 분류하기도 한다) 이며, 대용량 데이터를 신속하게 저장하고 검색할 수 있다.
• 데이터를 빠르게 검색하기 위해 데이터를 역 인덱싱 (Inverted Index) 하여 저장한다. 
• 역 인덱싱이란 키워드를 통해 문서를 찾아내는 방식으로 매우 빠르다는 장점이 있다.
• Elastic Search는 클러스터 구조로 분산되어 구성되어 있으며, 따라서 높은 가용성과 확장성이라는 특징을 갖는다.
• 또한 일반적인 관계형 데이터베이스와 다르게 SQL을 지원하지 않으며, RESTful API를 통해 데이터를 추가하고 검색한다. SQL의 Select, Insert, Update, Delete 명령은 REST 기반의 엘라스틱 서치에서 각각 GET, POST, PUT, DELETE 에 대응된다.
• 관계형 데이터베이스의 Database, Table, Row, Column, Schema는 엘라스틱 서치에서는 각각 Index, Type, Document, Field, Mapping 에 대응된다.

관계형 데이터베이스	Elastic Search
Database	Index
Table	Type
Row	Document
Column	Filed
Schema	Mapping

(엘라스틱 서치에서 쓰는 용어들이 다른 곳에서도 일반적으로 쓰이는 게 많아 헷갈린다.)

 

[Logstash]

Elastic Search를 사용하면서 데이터를 손쉽게 수집할 방법이 필요해졌다. 따라서 데이터 처리 파이프라인 도구인 Logstash가 등장한다. Logstash는 Input → Filter → Output 순서로 데이터를 수집하고, 가공하고, 전달한다.

1. Input

Logstash는 다수의 데이터 소스로부터 동시에 로그 혹은 메트릭 데이터를 수집한다. 수집하는 데이터 소스는 Beats, File, TCP, HTTP, Kafka, Redis 등이 있다. 

 

2. Filter

Logstash는 Input과 Ouput 사이에 데이터를 Filter하여 아래와 같은 일을 할 수 있다.

• grok 플러그인을 사용하여 정규표현식을 통해 비정형 데이터로부터 구조를 도출해낼 수 있다.
• IP 주소로부터 위치 좌표를 얻어올 수 있다.
• 개인 식별 정보를 익명화하거나 완전히 제외할 수 있다.

위와 같은 데이터의 가공은 200개가 넘는 플러그인으로 코딩 없이 간단히 적용할 수 있다.

 

3. Output

Input과 마찬가지로 Logstash는 다양한 데이터 소스로 출력할 수 있다. Ouput의 예시로는 Elastic Search, Email, File, TCP, HTTP, Kafka, RabbitMQ, MongoDB, Redis, S3, Websocket 등이 있다. 

 

[Kibana]

https://www.elastic.co/kr/kibana

Elastic Search 만으로 데이터를 검색할 수 있지만, Elastic Search 단독으로 사용하면 RESTful API를 호출해야만하기 때문에 불편하다. 따라서 Elastic Search에 저장된 데이터를 보기 쉽도록 시각화 할 도구가 필요했다. 그렇게 Kibana가 등장하였다. Kibana는 HTML + Javascript 엔진으로 사용자가 Elastic Search에 저장된 데이터를 쉽게 검색하고, 분석하는데 도움을 준다.

 

Kibana는 일반적인 텍스트 데이터를 포함하여, 히스토그램, 차트, 위치 데이터, 시계열, 그래프 등 정말 다양한 시각화를 제공한다. 또한 사용자가 데이터를 쉽게 검색하고 필터링할 수 있는 기능을 제공한다. 추가로 키바나는 데이터를 모니터링 하며 사용자에게 경고 알림을 제공하는 기능도 제공한다.

---

[ELK Stack의 기업화]

그러나 아쉽게도 ELK는 라이센스 정책 변경으로 인해 현재는 유료화가 되어 있었다.

필자도 기업에서 ELK Stack의 라이센스가 있냐는 수행사의 물음에 "어 원래 오픈소스 아니었나?" 해서 당황한 기억이 있다.

그렇기에 블로그의 실습에서는 우선 Logstash의 오픈소스 대체제인 Fluentd, Elasticsearch의 오픈소스 대체제인 Opensearch와, 역시 Kibana의 대체재인 Opensearch Dashboard를 활용해 실습을 진행하고자 한다.

https://semizero.tistory.com/38

[ELK] 오픈소스(Fluentd, OpenSearch)로 ELK 스택 설치 후 실습해보기