ELK Stack, 완성된 시스템의 화룡점정

로그 추적과 수집 및 분석은 왜 필요할까?

개발 단계에서는 시스템 장애가 발생되면 천천히 로그를 분석하고 디버깅 과정을 거치고 다시 개발하면 된다.

하지만 실제 상용되는 서비스에 장애가 발생한다면?

개발 단계에서의 과정을 똑같이 할 수 있을까?

만약 당신의 시스템이 MSA와 같은 분산된 서비스나 특히 클라우드로 이동할 수록 발빠르게 분산 로그 추적, 수집 및 분석은 필수적이게 될 것이다.

즉, 당신의 완성된 시스템에 방점을 찍을 수 있도록 오늘은 가장 유명하고 많이 사용되는 ELK Stack에 대해 실제 사내 서버에 내가 구축한 구조에 대해 설명하도록 하겠다.

ELK에 대한 설명은 아래 포스팅을 참고바란다.
https://theworldaswillandidea.tistory.com/102

ELK Stack의 삼두마차, ELK

ELK Stack

ELK는 Elasticsearch, Logstash 및 Kibana, 이 오픈 소스 프로젝트 세 개의 머리글자에서 따왔다.

ELK Stack은 이 ELK가 그 다음 단계로 발전한 것 ELK 사용자들이 “파일을 추적하고 싶다"고 말했고, 2015년 ELK는 Beats라는 경량의 단일 목적 데이터 수집기 제품군을 도입하였다.

이렇듯 ELK라는 기본 틀(ELK중에서도 사용자가 원하는 기술로 바꿀 수도 있다)에서 MQ 혹은 Beats 등을 같이 쓰는 경우를 ELK Stack이라 부른다.


자, 이제 실제 구축한 구조에 대해 알아보자.

일단 구조는 Service(Filebeat) - Logstash - EK(Elastic, Kibana) 이렇게 된다.

왜 ELK에서 L을 떼내어 구축했냐면 Logstash가 가장 무거운 녀석이기에 리소스를 너무 잡아먹었다.

그렇다고 서비스단에 Logstash를 두는건 더욱이 문제가 되기에 서비스단에는 가벼운 Filebeat를 두었다.


동작방식을 간단히 설명하겠다.

Logback

MSA 각각의 서비스는 Logback을 이용해 로그를 로그파일 형태로 저장한다.

Filebeat

Filebeat에서 Prospector가 이 분산된 로그들을 경로에 따라 식별한다.

이후 Harvesters가 한 개 혹은 그 이상의 파일들을 열고 닫으며 행 단위로 읽는다.

읽은 로그는 Spooler에게 보낸지고 Spooler는 이벤트를 집계하고 설정한 출력으로 전달한다.

Logstash

이제 Logstash에서 형식이나 복잡성과 관계 없이 데이터를 동적으로 수집, 전환, 전송한다.

즉, 입력, 필터, 출력 세가지 단계를 거쳐서 Elasticsearch로 보낸다.

Elasticsearch

이제 검색엔진인 Logstash에서 받은 데이터를 원하는 방식으로 검색하고 결합할 수 있게 된다.

Kibana

Kibana는 Elasticsearch의 데이터를 시각화해준다..

이렇게 당신의 시스템을 빛내줄 ELK Stack을 구축해보자.

각각을 구축하는 것들은 하나하나 찾아보면 쉬울 것이다.

이외에도 ELK Stack은 여러가지 방식으로, 여러가지 조합으로 사용될 수 있다.

여러분의 서비스에 맞춰 커스터마이징하여 구축하길 바란다.

Thanks for watching, Have a nice day.