Loki 란?

Loki는 Prometheus의 메트릭 기반 아키텍처를 벤치마킹하여 라벨 기반으로 로그를 관리하고, 전체 텍스트 인덱싱을 최소화하여 저비용으로 대규모 로그를 저장·분석할 수 있도록 설계됐다.

 

1. Loki의 특징

1. 라벨 기반 인덱싱(Label-based Indexing)
   • Elastic Stack(Elasticsearch)처럼 로그 본문을 전부 인덱싱하지 않고, 로그 라벨(메타데이터)만 인덱싱합니다.
   • 로그 본문은 원본 형태로 객체 저장소(또는 파일 시스템 등)에 압축 보관하며, 쿼리 시 라벨 필터링을 거쳐 필요한 범위만 검색합니다.
   • 이로 인해 인덱스 크기가 작아지고, 결과적으로 스토리지 비용이 낮아집니다.
2. Prometheus와 유사한 개념
   • 라벨(Label), 일정 기간별 샤딩, 수평 확장 등 Prometheus의 메트릭 아키텍처를 로그에도 적용했습니다.
   • Prometheus를 사용 중이라면, 라벨 체계나 쿼리 방식(Logging 쿼리는 LogQL)을 쉽게 이해할 수 있습니다.
3. LogQL 쿼리 언어
   • Loki는 LogQL이라는 쿼리 언어를 제공합니다.
   • PromQL 문법을 확장하여, |=(포함), !=(불포함), 정규식 필터 등 로그 전용 연산을 지원합니다.
   • {job="system_logs"} |= "ERROR"
   • 라벨 job="system_logs"를 가진 로그 중 "ERROR"가 포함된 라인만 필터링

 

• Push 모델
  • 일반적인 로그 수집에서는 Fluentd, Logstash, Beats, 혹은 Loki 프로젝트 자체의 Promtail 등을 통해 Loki로 푸시하는 구조를 택합니다.
  • Promtail은 Loki에서 공식 제공하는 lightweight 로그 수집기이며, 파일 시스템, Kubernetes, Systemd Journal 등 다양한 소스에서 로그를 가져옵니다.
• 클라우드 네이티브 설계
  • 마이크로서비스·쿠버네티스 환경을 우선 고려해, **분산 스토리지(예: S3, GCS, MinIO)**에 로그를 저장할 수 있고, 여러 컴포넌트(Distributor, Ingester, Querier)로 확장 가능합니다.
  • 확장 시 노드들이 자율적으로 리밸런싱(토큰 링)하여, 무중단으로 수평 확장이 가능합니다.
• Grafana와 긴밀한 통합
  • Grafana에서 “Explore” 탭이나 “Dashboard”로 Loki 쿼리를 실행하고, Prometheus 메트릭과 함께 통합 모니터링이 가능합니다.
  • 로그와 메트릭을 같은 라벨로 묶어, 한 대시보드에서 상태(메트릭)와 자세한 정보(로그)를 빠르게 연결해볼 수 있습니다.

 

5. 장점과 고려사항

장점

1. 저비용
   • 전체 로그 메시지를 인덱싱하지 않고 라벨만 인덱싱해, 저장 공간과 인덱싱 비용이 크게 절감됩니다.
   • 로그가 많아질수록 Elasticsearch 대비 비용 이점이 큽니다.
2. Prometheus와 자연스러운 통합
   • 라벨 기반 구조와 비슷한 쿼리 문법(LogQL ↔ PromQL) 덕에, 모니터링 & 로깅을 일원화하기 편합니다.
3. 분산 확장성 & 클라우드 네이티브
   • 객체 스토리지(S3, GCS 등)를 활용한 무한 확장 가능.
   • 고가용성과 고성능 쿼리(캐시, 분산 처리) 지원.

고려사항

1. 라벨 설계
   • 라벨 수와 종류가 너무 많으면 인덱스가 커지고 쿼리 성능이 저하될 수 있습니다.
   • 로깅 대상 서비스별로 적절한 라벨(예: job, service, instance)을 어떻게 할지 사전에 기획해야 합니다.
2. 부분 텍스트 검색
   • ElasticSearch처럼 전체 텍스트 검색 용도로 사용하기엔 적합하지 않습니다.
   • 라벨로 1차 필터링한 뒤, 범위를 좁혀서 로그 메시지 문자열 매칭을 수행하는 식의 워크플로를 염두에 둬야 합니다.
3. 로그 컬럼화 / 구조화 한계
   • Loki 자체는 간단한 파싱(LogQL에서 패턴 매칭 또는 JSON 파싱 정도)은 가능하지만, 데이터 웨어하우스 급의 SQL 쿼리나 집계 연산엔 제한이 있습니다.
   • 복잡한 분석에는 별도 파이프라인(예: Spark, ClickHouse 등)과의 결합을 고려해야 합니다.