Loki, Promtail, Grafana를 사용한 로그 모니터링 구축

서론

LMS 3차 요구사항으로 모니터링 대시보드 구성이 주어졌다.

우리는 CloudWatch를 통해 EC2 인스턴스에 대해 모니터링 대시보드를 구성했었는데, 처음에는 이것만으로도 충분하다고 생각했었기 때문이다.

 

그런데 개발 서버에서 500 에러가 계속해서 발생하고 프론트엔드 팀원에게 문의를 받아야 대응할 수 있는 상황이 빈번하게 발생했다.

따라서 로그 모니터링에 대한 필요성을 느끼고 이를 구축하기로 결정했다.

 

🤔 로그 모니터링 필요 이유 

1. 직접 EC2 서버에 접속하지 않고도 로그를 확인할 수 있다.

왜 필요해?

일단 모니터링을 구축하기 전, 로그 프레임워크을 적용하면서 스프링 서버의 로그를 파일로 저장하고 있었다.

해당 로그 파일은 EC2 인스턴스 내의 파일 시스템에 저장이 되는데, 이를 확인하기 위해서는 EC2 인스턴스에 직접 접속하여야 했다.

 

그런데 이 방식에는 문제가 하나 있었다.

현재 우테코의 AWS 계정을 지원받아 사용하고 있는데 우테코의 보안그룹 설정이, 인스턴스 접속은 우테코 캠퍼스 내의 네트워크만을 통해서 가능했다.

 

즉, 기존 방식에서는 우테코 캠퍼스 내에서만 로그를 확인할 수 있었다.

 

퇴근하고 집가서 500 대응해달라고 하면 암후것도 못하는 바보가 되어버린다

뭐가 개선되지?

이런 상황에서 로그 모니터링을 구축한다면 해결되는 것을 확인해보자.

로그 대시보드를 통해 로그를 확인할 수 있게 되면 우리는 굳이 인스턴스에 접속하지 않아도 되며, 캠퍼스 외부에서도 로그 확인에 대한 대응이 가능해진다.

 

2. 로그에 대한 알람을 받을 수 있다.

왜 필요해?

앞서 말했듯이 발생되는 500 에러를 인지하지 못하고 있다가 프론트엔드 개발자에게 직접 듣고 그때서야 대응을 하는 일이 빈번했다.

아무리 우리 API를 가장 많이 사용하는 사람은 프론트엔드 개발자라지만... 백엔드 개발자들은 500이 계속 발생해도 모르고 있다가 프론트 개발자들이 알려줘야 나서는 게 마음에 들지 않았다.......ㅠㅠ

 

그렇다고 백엔드가 직접 1시간마다 대시보드에 접속해서 로그를 확인하고 있을 수는 없지 않는가???????????

따라서 500이 지속해서 발생할 경우, 프론트엔드 알람 말고 자동으로 알람을 주는 기능이 필요했다.

 

뭐가 개선되지?

당연히 프론트 개발자들이 직접 말하지 않아도 되는 수고로움이 줄고, 백엔드 개발자들은 서버에 문제가 생겼을 경우에도 이를 빨리 캐치하고 대응할 수 있어진다.

---

 

자 이제 필요성을 깨달았으니 Loki, Promtail, Grafana를 사용한 로그 모니터링 구축을 해보자.

🌊 로그 모니터링 구성 흐름

로그 모니터링은 크게 아래의 5단계로 구축할 수 있다.

1. 로그 생성
2. 로그 수집
3. 로그 전송
4. 로그 저장 및 인덱싱
5. 로그 조회 및 시각화

일단 모니터링할 로그가 있어야한다.

그 후 생성된 로그를 수집하여 로그 저장소에 전송을 하고 이를 받은 로그 저장소는 로그를 저장하고 인덱싱한다.

최종적으로 대시보드 툴을 사용하여 저장소의 로그들을 조회하고 시각화할 수 있다.

😀 로그 모니터링 툴 선택하기

일단 우리는 이미 로그 프레임워크로 로그백을 선택하여 사용하고 있었다. 로그백은 지정된 위치로 로그 파일들을 생성하고 있었기 때문에 생성은 넘어가고...

ELK vs Loki, Promtail, Grafana

보통 로그 모니터링은 ELK 스택과 Loki, Promtail 조합 두가지를 사용해서 구축하는 듯했다.

 

내가 알아본 두 선택 사항에 대한 특징은 다음과 같았다. (더 많은데 나한테 와닺은 것만 씀...)

	Loki, Promtail, Grafana을 사용했을 때	ELK 스택을 사용했을 때
로그 수집 및 인덱싱	Promtail이 로그를 수집 - 설정 간단 - 파일 기반 로그에 특화 - 설정파일에 작성한 레이블으로 로그를 인덱싱	Logstash/Filebeat가 로그를 수집 - 파일이 아닌 다양한 형태의 로그를 수집가능 - full-text 인덱싱
로그 전송	Promtail -> Loki로 전송 - HTTP 프로토콜 요청을 통해 전송	Logstash/Filebeat -> Elasticsearch로 전송 - Beats 프로토콜 사용
로그 저장	Loki가 저장소	Elasticsearch 가 저정소 - 로그 검색에 유리
로그 조회 및 시각화	Grafana 대시보드 - 다양한 데이터 소스 지원(다른 모니터링과 함께 사용 가능)	Kibana 대시보드 - Elasticsearch에 최적화

 

Loki, Promtail, Grafana를 선택한 이유

결론적으로 ELK 스택이 아닌 Loki, Promtail, Grafana를 선택했는데, 그 이유는 다음과 같다.

1. Beats 프로토콜, full-text 모르겠고 모니터링 구축에 시간을 많이 쏟을 수 없었다. 간단한 설정 파일만으로 구축되길 원했다.
2. 현재 프로젝트 규모에서는 로그 조회 시 status, filename 만으로 충분하다고 생각하였다. 크게 검색을 활용하지 않을 것 같았다.
3. 매트릭과 로그 모니터링을 통합된 대시보드로 구축하고 싶었다.

이제 선택을 했으니 진짜진짜 구축을 해보자

로그 모니터링 구축하기

전체적인 구축과정은 아래와 같다.

 

 

모니터링 인스턴스를 분리한 이유?

WAS가 있는 인스턴스에 CPU 사용량이 급증하면서 인스턴스가 중단되는 일이 종종 있었다.
모니터링 인스턴스를 분리하지 않는다면, WAS 인스턴스가 죽을 때 대시보드도 함께 죽어 외부에서 로그를 확인할 수 없다. 흑흑

1. 로그 생성

• SLF4J와 Logback을 사용하여 지정된 폴더에 Spring 애플리케이션 로그 파일이 생성
• Nginx 실행 시 기본적인 로그 설정이 제공
  • nginx는 접근 로그(access log)와 오류 로그(error log)가 각각 별도의 파일로 저장된다.

2. Promtail 설정을 통해 로그 수집 및 분류, 전송

Promtail 설정 파일을 작성하여 로그 파일들을 지속적으로 모니터링하고 새로운 로그 항목을 감지하도록했다.

Promtail은 감지한 새로운 로그 항목을 HTTP POST 요청을 통해 Loki 서버로 전송한다.

설정 파일(promtail-config.yml)에는 다음의 내용들이 포함된다.

• 수집할 로그 파일들과 그에 대한 레이블을 지정
  • 레이블 지정은 로그 분류를 위한 용도
• 로그를 전송할 Loki 서버의 주소
• 각 로그 파일을 어디까지 읽었는지 위치
  
  • 새로운 로그 파일들을 지속적으로 추적하고 중복 수집을 막기 위한 용도

3. Loki 설정을 통해 인덱싱된 로그를 저장 및 분류, 전송 

Loki는 Promtail로부터 받은 로그 데이터를 저장하고 인덱싱한다.

이때 Promtail의 레이블을 기반으로 인덱스를 생성한다.

4. 로그 조회 및 시각화 (Grafana)

Loki를 데이터 소스로 설정하고 저장된 로그를 Grafana 대시보드를 통해 로그를 확인할 수 있다.

또한 Alerting 기능을 통해 알람 설정도 간편하게 할 수 있다.