gonnux.com

LIT-lgtm-stack-overview

2026-02-20

topic/observability
topic/infrastructure

요약

LGTM Stack은 Grafana Labs가 만든 오픈소스 옵저버빌리티 스택으로, 로그(Loki), 시각화(Grafana), 트레이스(Tempo), 메트릭(Mimir)을 각각 전문화된 컴포넌트로 처리한다. 세 백엔드(Loki, Mimir, Tempo)가 모두 오브젝트 스토리지 기반의 수평 확장 가능한 아키텍처를 공유하며, Grafana가 단일 대시보드에서 모든 텔레메트리 데이터를 통합 시각화하는 구조이다. OpenTelemetry와 네이티브로 통합되며, Grafana Alloy가 데이터 수집 파이프라인 역할을 담당한다.

핵심 포인트

LGTM 약자의 의미

  • L = Loki (로그 수집·저장)
  • G = Grafana (시각화·대시보드·알림)
  • T = Tempo (분산 트레이싱)
  • M = Mimir (메트릭 장기 저장)

각 컴포넌트의 역할

Loki (로그)

  • Prometheus에서 영감을 받은 로그 집계 시스템이다. 로그 내용 자체를 인덱싱하지 않고, 레이블(메타데이터)만 인덱싱하는 것이 핵심 설계 철학이다. 이를 통해 인덱스 크기를 크게 줄여 스토리지 비용을 절감한다. 로그 데이터는 압축되어 오브젝트 스토리지(S3, GCS 등)에 청크 단위로 저장된다. LogQL이라는 쿼리 언어를 사용하며, PromQL에 익숙하다면 자연스럽게 사용할 수 있다.

Grafana (시각화)

  • LGTM 스택의 중심 허브이다. 로그, 메트릭, 트레이스를 하나의 대시보드에서 통합 조회할 수 있다. 메트릭에서 이상치를 발견하면 관련 트레이스로, 다시 해당 서비스의 로그로 피벗하는 워크플로우가 가능하다. 이로 인해 MTTD(장애 감지 시간)와 MTTR(장애 복구 시간)을 단축할 수 있다.

Tempo (트레이스)

  • 오브젝트 스토리지만 있으면 동작하는 경량 분산 트레이싱 백엔드이다. Jaeger, Zipkin, OpenTelemetry 등 다양한 트레이싱 프로토콜과 호환된다. TraceQL이라는 전용 쿼리 언어로 스팬을 정밀하게 검색할 수 있다. 별도의 인덱싱 레이어 없이 오브젝트 스토리지에 직접 저장하므로 대량의 트레이스를 저비용으로 보관할 수 있다.

Mimir (메트릭)

  • Prometheus의 장기 저장소 역할을 하는 시스템이다. Prometheus remote write를 지원하여 기존 Prometheus 환경에서 자연스럽게 통합된다. PromQL 호환이므로 기존 쿼리와 알림 규칙을 그대로 사용할 수 있다. 10억 개 이상의 활성 시리즈까지 확장 가능하다.

공통 아키텍처 패턴

세 백엔드(Loki, Mimir, Tempo)는 놀라울 정도로 유사한 아키텍처를 공유한다:

  1. Distributor → Ingester → Object Storage: 데이터가 들어오면 Distributor가 검증하고 해싱하여 Ingester에 라우팅한다. Ingester는 임시로 데이터를 보관하다가 주기적으로 오브젝트 스토리지(S3, GCS, Azure Blob 등)에 플러시한다.
  2. Read/Write 경로 분리: 읽기와 쓰기 경로가 독립적으로 분리되어 있어 각각의 부하에 맞게 독립적으로 스케일링할 수 있다.
  3. 수평 확장: 세 컴포넌트 모두 마이크로서비스 아키텍처로 수평 확장이 가능하다.
  4. 멀티테넌시: 테넌트 간 데이터 격리와 공정한 자원 할당을 지원한다.

Grafana Alloy와 OpenTelemetry 통합

  • Grafana Alloy는 OpenTelemetry Collector의 Grafana Labs 배포판이다. OTLP 100% 호환이며 Prometheus와 OpenTelemetry 두 가지 파이프라인을 네이티브로 지원한다.
  • 데이터 흐름: 애플리케이션 → Alloy(수집) → Loki/Mimir/Tempo(저장) → Grafana(시각화)
  • OTLP 데이터를 직접 Loki, Mimir, Tempo에 전송할 수도 있고, Alloy를 중간에 두고 처리·라우팅할 수도 있다.
  • grafana/otel-lgtm Docker 이미지를 사용하면 OpenTelemetry Collector + 전체 LGTM 스택을 단일 이미지로 5초 내에 구동할 수 있다(개발/테스트 환경용).

ELK Stack과의 비교

항목LGTM StackELK Stack (Elasticsearch, Logstash, Kibana)
인덱싱 방식Loki는 레이블(메타데이터)만 인덱싱Elasticsearch는 전문(full-text) 인덱싱
스토리지 비용오브젝트 스토리지 기반으로 저렴전용 디스크/클러스터 필요, 상대적으로 고비용
확장성각 컴포넌트 독립 수평 확장Elasticsearch 클러스터 확장 필요
관측 범위로그 + 메트릭 + 트레이스 통합기본적으로 로그 중심 (APM 추가 시 트레이스 가능)
쿼리 언어LogQL, PromQL, TraceQL (각각 다름)KQL/Lucene (통일된 쿼리 언어)
OpenTelemetry네이티브 지원 (Alloy)지원하지만 네이티브는 아님
운영 복잡도세 개의 분산 시스템을 각각 운영해야 함단일 Elasticsearch 클러스터이나 대규모에서 복잡
전문 검색Loki는 전문 검색에 약함Elasticsearch의 핵심 강점

기존 Prometheus + Grafana 조합과의 비교

LGTM 스택은 기존 Prometheus + Grafana 조합을 확장한 것이다. Prometheus 단독으로는 장기 저장, 수평 확장, 멀티테넌시에 한계가 있었는데, Mimir가 이를 해결한다. 여기에 Loki(로그)와 Tempo(트레이스)를 추가하여 옵저버빌리티 세 기둥(메트릭, 로그, 트레이스)을 모두 커버하는 풀 스택이 된다.

장점

  • 비용 효율: 레이블 기반 인덱싱(Loki)과 오브젝트 스토리지 기반 저장으로 ELK 대비 스토리지 비용이 크게 절감된다.
  • Prometheus 생태계 호환: PromQL, remote write 등 기존 Prometheus 인프라를 그대로 활용할 수 있다.
  • OpenTelemetry 네이티브: Alloy를 통한 OTLP 네이티브 지원으로 벤더 락인 없이 표준 프로토콜 사용이 가능하다.
  • 통합 시각화: Grafana 단일 대시보드에서 메트릭 → 트레이스 → 로그 간 피벗이 가능하다.
  • 컴포넌트 독립 확장: 로그, 메트릭, 트레이스 각각의 부하에 맞춰 독립적으로 스케일링할 수 있다.
  • 오픈소스: 라이선스 비용 없이 사용 가능하다.

단점

  • 운영 복잡도: 세 개의 분산 시스템(Loki, Mimir, Tempo)을 동시에 운영해야 하므로 전담 인력이 필요할 수 있다.
  • 쿼리 언어 분산: LogQL, PromQL, TraceQL이 각각 다른 쿼리 언어여서, 인시던트 대응 시 여러 언어를 오가야 하는 비효율이 있다.
  • 전문 검색 약점: Loki는 레이블 인덱싱만 하므로 로그 내용에 대한 전문(full-text) 검색 성능은 Elasticsearch에 비해 떨어진다.
  • 성숙도: Mimir(2022년 공개)와 Tempo는 Elasticsearch에 비해 역사가 짧다.

적합한 사용 사례

  • 클라우드 네이티브(Kubernetes) 환경에서 옵저버빌리티 스택이 필요한 경우
  • 이미 Prometheus + Grafana를 사용 중이고, 장기 메트릭 저장과 로그/트레이스를 통합하고 싶은 경우
  • 스토리지 비용을 절감하면서 대규모 로그를 처리해야 하는 경우
  • OpenTelemetry 표준을 기반으로 벤더 중립적 옵저버빌리티를 구축하려는 경우
  • 전문 로그 검색보다는 레이블 기반 필터링으로 충분한 경우

나의 생각

  • LGTM 스택의 핵심 설계 철학은 "각 텔레메트리 유형에 특화된 도구를 조합"하는 것이다. ELK가 하나의 엔진(Elasticsearch)으로 모든 것을 처리하려는 접근이라면, LGTM은 각 도구가 한 가지를 잘 하도록 분리한 UNIX 철학에 가깝다.
  • 세 백엔드가 동일한 아키텍처 패턴(Distributor → Ingester → Object Storage)을 공유한다는 점이 흥미롭다. 학습 곡선이 하나를 익히면 나머지도 비슷하게 이해할 수 있다는 의미이기도 하다.
  • Loki의 레이블 기반 인덱싱은 비용과 검색 능력 사이의 의도적인 트레이드오프이다. 대부분의 운영 환경에서 로그 검색은 서비스명, 환경, 파드 이름 등 레이블로 필터링한 후 grep하는 패턴이 주된 사용 방식이므로, 전문 인덱싱이 꼭 필요하지 않다는 판단이 깔려 있다.
  • 쿼리 언어가 세 가지로 분산되어 있다는 것은 실제 인시던트 대응 시 마찰이 될 수 있다. 이 부분은 Grafana가 대시보드 수준에서 상관 분석(correlation)을 제공하여 어느 정도 완화하고 있다.
  • 운영 복잡도는 Grafana Cloud(관리형 서비스)를 사용하면 해결되지만, 자체 운영 시에는 상당한 인력과 전문성이 필요하다. 소규모 팀이라면 관리형 서비스나 보다 단순한 올인원 솔루션이 적합할 수 있다.

Links

  • 원본: REF-grafana-lgtm-stack
  • 관련 Permanent Note: [[]]