Grafana Monitoring 스택 LGTM 구성기 (Loki, Mimir, Tempo)

아직 LGTM(Loki , Grafana , Tempo , Mimir)관련 한글 자료가 별로 없어서 간략하게 작성해본다.
회사에서 도입을 고민하고 있거나 PoC 중이라면 이 글이 조금의 도움은 될 수 있겠다고 본다. 

 

 

LGTM이란 무엇일까?

 
Grafana에서 밀고 있는 LGTM(Loki , Grafana , Tempo , Mimir)이란 무엇일까?
 
L : Loki (로그 수집 저장소)
G : Grafana (시각화)
T : Tempo (분산 추적 저장소 , APM)
M : Mimr (시계열 메트릭 저장소)
 
 
그럼 왜 Grafana에서는 LGTM을 밀고 있는 것일까?
 
잘 생각해보면 답은 은근히 간단한데,
 
보통 시스템 모니터링 , 로깅 , 애플리케이션 성능 모니터링을 구성하기 위해 대부분의 회사에서 여러가지 오픈소스 및 SaaS를 구성하여 사용한다.
 
시스템 모니터링
- Prometheus , Grafana
- Zabbix
- Datadog or NewRelic 과 같은 유로 SaaS
 
로깅
- ELK (ElasticSearch , Logstash , Kibana)
- Loki , Grafana
- CloudWatch
- ..
 
APM
- Scouter
- Elastic APM
- PinPoint
- Datadog or ..
 
 
그럼 CPU , Memory , Disk , Network Bytes 등의 리소스를 확인하기 위해서는 A에서 확인하고,
Application Log를 확인하기 위해서는 B에서 확인하고
APM을 확인하기 위해서는 C에서 확인해야 한다는 것이다.
 
이를 해결하기 위해 Grafana에서는 단일 대시보드에서 시스템 메트릭과 로그 , 분산 트레이싱을 모두 확인할 수 있도록 LGTM(Loki , Grafana , Tempo , Mimir)를 요즘에 밀고 있는 것 같다.
 
단순히 단일 대시보드에서 조회하는게 끝이 아니라 이 3가지(시스템 메트릭 , 로그 , 분산트레이싱)를 서로 유기적으로 상호 연결하여 디버깅을 할 수 있다면 얼마나 좋을까?
 
Use Case로는 다음과 같을 것이다.
 
1. Latency가 유난히 높은 특정 HTTP 요청 메트릭으로부터 Trace와 Log를 같이 조회하고 싶다.
 
https://grafana.com/docs/grafana/latest/fundamentals/exemplars/

Introduction to exemplars |  Grafana documentation

 
 
2. 5xx가 발생한 Trace에 대해서 Log를 같이 조회하고 싶다.
 
https://community.grafana.com/t/how-to-jump-from-traces-to-logs/72477/2

How to jump from traces to logs?

 
 
3. Log를 조회하던 중 특정 Log와 연관된 Trace를 같이 조회하고 싶다.
 
https://grafana.com/blog/2020/11/09/trace-discovery-in-grafana-tempo-using-prometheus-exemplars-loki-2.0-queries-and-more/

Trace discovery in Grafana Tempo using Prometheus exemplars, Loki 2.0 queries, and more | Grafana Labs

 
 
4. Trace를 조회하던 중 서비스의 특정 Span에 대한 평균 Latency를 조회하고 싶다.
 
https://grafana.com/blog/2022/08/18/new-in-grafana-9.1-trace-to-metrics-allows-users-to-navigate-from-a-trace-span-to-a-selected-data-source/

New in Grafana 9.1: Trace to metrics allows users to navigate from a trace span to a selected data source | Grafana Labs

 
 
이 모든 것이 LGTM을 통해서 가능하다.
 
 

LGTM 각 Stack에 대해서 알아보자.

아직 Loki , Grafana , Mimir , Tempo에 대해 잘 모르는 분들이 있을 것이라 생각되어 간략하게 정리해본다.
 
1. Mimir : 시계열(Time Series) 메트릭을 저장하는 백엔드
Mimir는 Cortex의 fork이며 확장 가능한 장기 스토리지를 제공한다.
 
Prometheus의 단점으로는 수평 확장이 불가능하다는 것이였는데 2EA 이상으로 운영하려면 Thanos 같은 외부 오픈소스 솔루션을 써야 한다는 뜻이었다.
 
Grafana Mimir를 이런 단점을 해결해준다.
 
수평으로 확장이 가능하며 Block Storage에 데이터를 저장하는게 아닌 장기 스토리지(ex. S3, Minio, ..)에 저장함으로써 비용 효율적으로 시계열 메트릭을 보관할 수 있다.
 
장점으로는 저렴한 비용으로 장기 스토리지에 저장할 수 있다는 점과 수평 확장이 가능하다는 점이다.
 
당연히 단점도 존재하기 마련인데, 장기 스토리지에 저장하는 만큼 기본적인 성능 튜닝을 하지 않으면 n일치 데이터를 읽어올 때 상당히 느리고 OOM(Out of memory) 또한 발생하기 쉽다.
또한 Retention(보관 기간)을 설정하기 위해서는 Multi Tenant 설정을 해줘야만 한다. 예를 들어 개발계는 1달만 보관하고 운영계는 12달을 보관하려 한다면 이를 위해 Grafana MImir에서 Multi Tenant 설정을 해줘야한다는 의미이다.
 
그 중 읽기 속도 이슈를 해결하기 위해 Grafana Mimir는 여러가지 컴포넌트들을 조합하며 해결하고 있다.
 
Grafana Mimir는 Cortex의 Fork이기 때문에 당연히 Cortex도 위 내용에 포함된다고 생각하면 된다.
 
그럼에도 불구하고 수평으로 확장 가능하다는 점과 Object Storage에 저장함으로써 비용 효율적으로 관리할 수 있다는 점, Loki와 Tempo와 통합이 쉽다는 점을 생각해보면 이정도 단점들은 충분히 커버 가능하다고 보여진다.
 
Grafana Mimir라고 Prometheus와 다른건 아니다.
 
그냥 각 Prometheus Agent들이 Mimir로 remoteWrite를 하고 보관 주체가 Prometheus -> Mimir로 바뀐 것 뿐 Grafana에서는 동일하게 PromQL로 조회하여 대시보드를 만들고 알람 규칙 또한 손쉽게 설정할 수 있다.
 

---

 
2. Loki : 로그 수집 시스템
Grafana Loki는 'Like Prometheus, But for logs'란 철학을 가지고 있다.
 
Prometheus와 유사하면서 로그를 손쉽게 조회하기 위해 만들어진 것이다.
 
유명한 로그 백엔드 시스템인 ElasticSearch와 비교해보자.
 
ElasticSearch는 Full Text Search에 강점이 있으며 Block Storage에 샤딩하여 로그들을 저장하다보니 Grafana Loki에 비해 훨씬 빠른 속도로 로그를 조회할 수 있다는 장점이 있다. 하지만 이를 관리해본 사람들은 알겠지만 유지보수하기 위해 상당한 노력이 수반된다.
 
그에 반해 Grafana Loki는 S3 Path만 설정해주면 끝이다.
ES에 비해 유지보수 포인트가 상당히 줄어들고 Grafana와 통합하여 대시보드를 구성하기에도 매우 간단하다.
 
하지만 단점 또한 존재하는데 또 Object Storage이다.
S3는 비용이 매우 효율적이라는 장점과 동시에 Object Storage(ex. S3)에 있는 데이터를 직접 가져와서 Loki가 이를 분석해야 하기에 속도가 블록 스토리지에 비해 상대적으로 느리다는 단점이 있다.
 
이런 단점을 해소하기 위해 Grafana Loki는 로그에 대한 메타데이터인 레이블을 인덱싱한다는 아이디어를 중심으로 구성이 되었다.
 
무슨 말이냐면 로그를 조회하기 위해 1차로 메타 데이터 기반으로만 조회하고 메타 데이터에 매칭되는 레이블들의 고도로 압축된 로그 데이터(Chunk)만 따로 가져와서 User에게 보여주는 것이다.
 
예를 들어 Label이 {app="my-app", env="prod"}가 있다고 가정해보자.
 
app이 my-app이고 env가 prod인 레이블의 로그 데이터들은 별도로 압축되어 청크 단위로 저장이 되고,
실질적으로 로그가 조회될 때는 이 청크들을 기반으로 조회하는게 아니라 Metadata인 Label을 기반으로 먼저 조회하고 이와 매칭된 청크들만 별도로 가져온다는 것이다.
 
이를 통해 적은 데이터 조회만으로 원하는 로그들을 가져올 수 있게 되는 것이고 비용 효율적으로 로그 시스템을 구성할 수 있게 되는 것이다.
 
당연히 읽기 컴포넌트들을 좀 더 빠르게 조회할 수 있도록 하는 방법들은 여러가지이다.
 
Memcached 처럼 별도 Cache를 사용한다거나 주기적으로 Global Query를 날려 캐싱처럼 사용한다거나 병렬성(Parallelism)처리를 한다거나 여러가지 방법이 존재하게 된다.
 

---

 
3. Tempo : 분산 추적 시스템
Grafana Tempo 또한 Object Storage를 통해 Trace 데이터들을 저장한다.
 
본 글에서는 설명을 따로 안할 예정이지만 Opentelemetry Agent 혹은 SDK가 각 Application에서 Trace를 발생시키고 전파하며 Tempo로 최종적으로 전달이 되어야 한다.
당연히 중간에 Opentelemetry Collector를 거쳐갈 수도 있다. (Collector를 거쳐갈 수도 있다고 설명했지만 사실 거의 필수라고 생각함.)
 
또한 Grafana Mimir, Prometheus 같은 시계열 메트릭 뿐 만 아니라 Grafana Loki와 긴밀하게 통합되어 사용될 수 있다.
 
Tempo의 장점 중 하나로 Tempo로 들어오는 Trace , Span에 대해서 Prometheus 호환 Metric으로 변환시킬 수 있다.
(이는 아래에서 추가로 설명할 예정이다.)
 
예를 들어 A 서비스로 들어오는 요청(ex. Client -> Server)에 대한 모든 Span에 대해서 Metric으로 변환시켜서 Grafana Mimir로 보내고 Dashboard graph로 만든다거나 Alert로 처리할 수 있게 되는 것이다.

 

다만 Tempo는 아직 Mimir나 Loki에 비해 개발 및 개선되어야 할 내용들이 많다.

---

 
전체적으로 정리해보자면 아직 Grafana Tempo는 Production에서 만족하며 사용하기에는 다소 아쉬운 부분들이 있을 수 있다.

 
그럼에도 불구하고 Opentelemetry 생태계와 통합하여 사용하기 간편한 점과 Mimir , Loki와 상호 통합하여 디버깅하는걸 Grafana 라는 단일 대시보드에서 가능케한다는점, Trace 저장소가 객체 스토리지이기에 확장에 매우 용이하다라는 점에 있어 높게 평가할 수 있다.

 

 

(좀 더 세부적이거나 추가 내용들은 시간이 될 때 별도로 포스팅을 하고 있습니다.)