Grafana Loki 실전 가이드: ELK 없이 Kubernetes 로그 관리하기

로그는 시스템의 언어입니다. 서비스가 복잡해질수록 그 언어를 얼마나 빠르고 저렴하게 해독하느냐가 장애 대응 속도와 운영 비용을 결정합니다. 오랫동안 ELK 스택(Elasticsearch, Logstash, Kibana)이 업계 표준이었지만, 클라우드 네이티브 환경에서는 그 무게가 부담이 되기 시작했습니다. 인덱스 크기, 메모리 요구량, 운영 복잡도 — 모두 만만치 않습니다.

Grafana Labs가 2018년 공개한 Grafana Loki는 "Prometheus, but for logs"라는 슬로건 아래 이 문제를 정면으로 돌파했습니다. Grafana Labs 자체 사례에 따르면 ELK 대비 스토리지 비용을 최대 80% 이상 절감한 사례가 보고되고 있으며, 그 핵심은 로그 본문을 인덱싱하지 않는 역발상 설계에 있습니다. 이 글은 Loki의 설계 원리부터 실전 Kubernetes 배포, 레이블 설계 베스트 프랙티스, 2025~2026년 최신 변화까지를 Kubernetes 환경을 운영하는 백엔드 및 DevOps 엔지니어를 대상으로 정리합니다.

이 글에서 다루는 내용: Loki vs ELK 인덱싱 전략 차이 → 핵심 구성 요소 및 LogQL 쿼리 문법 → Helm 기반 Kubernetes 배포 실전 예시 → Trace-to-Log 연동 및 알림 자동화 → 장단점 및 운영 실수 방지 가이드

Prometheus와 Grafana를 이미 운영 중이거나, ELK의 높은 비용에 대안을 찾고 있다면 이 글이 의사결정에 실질적인 도움이 될 것입니다.

핵심 개념

인덱싱 전략의 차이가 모든 것을 결정합니다

Elasticsearch가 로그 본문의 모든 단어를 역색인(inverted index)으로 만들어 빠른 전문 검색을 지원하는 것과 달리, Loki는 레이블(label) 메타데이터만 인덱싱합니다. 로그 본문은 압축된 청크(chunk)로 S3, GCS 같은 오브젝트 스토리지에 그대로 저장됩니다.

비교 항목	Elasticsearch (ELK)	Grafana Loki
인덱싱 대상	로그 전체 (full-text)	레이블 메타데이터만
스토리지 비용	높음	낮음 (오브젝트 스토리지)
검색 속도	키워드 검색 빠름	범위 쿼리에서 ELK 대비 느릴 수 있음 (청크 스캔 방식)
운영 복잡도	높음	낮음
Kubernetes 친화성	중간	높음 (Pod 레이블 자동 매핑)

청크(Chunk): 일정 시간 범위의 로그 데이터를 압축한 단위 파일입니다. Loki의 Ingester 컴포넌트는 수신된 로그를 메모리에 청크 단위로 모은 뒤, 일정 크기 또는 시간 기준으로 오브젝트 스토리지에 플러시합니다. 예기치 않은 재시작에 대비해 WAL(Write-Ahead Log)을 통해 유실을 방지합니다. 쿼리 시에는 레이블에 매칭되는 청크만 읽어 스캔하므로, 레이블 설계가 쿼리 성능에 직결됩니다.

3대 구성 요소

Loki 생태계는 세 가지 역할로 나뉩니다.

Grafana Alloy (구 Promtail): 각 노드에서 로그를 수집해 Loki로 전송하는 에이전트. 2026년 2월 28일자로 Promtail의 상업 지원이 종료되었으며, Alloy가 메트릭·로그·트레이스·프로파일링을 단일 에이전트에서 통합 수집합니다.
Loki: 로그 저장 및 쿼리 처리 엔진
Grafana: LogQL 쿼리 결과를 시각화하는 대시보드

LogQL — PromQL에서 영감을 받은 로그 쿼리 언어

LogQL은 Prometheus의 PromQL을 기반으로 설계되어, Prometheus 사용 경험이 있다면 학습 곡선이 완만합니다. 크게 두 가지 쿼리 유형이 있습니다.

Log Query: 로그 스트림을 직접 필터링합니다.

logql

# production 네임스페이스의 api-server에서 ERROR 로그만 필터링하고 JSON 파싱
{namespace="production", app="api-server"} |= "ERROR" | json | line_format "{{.message}}"

line_format "{{.message}}" 에서 이중 중괄호는 Go 템플릿 문법입니다. json 파이프로 파싱된 필드 중 message 키 값만 출력 형식으로 지정하는 역할을 합니다.

Metric Query: 로그 패턴을 메트릭으로 집계합니다.

logql

# payment-service의 ERROR 발생 건수를 5분 단위로 집계
sum(rate({app="payment-service"} |= "ERROR" [5m])) by (namespace)

레이블 선택자 {}: PromQL과 동일한 형식으로, 쿼리할 로그 스트림을 좁히는 역할을 합니다. 이 선택자가 효율적일수록 스캔할 청크가 줄어들어 쿼리 성능이 향상됩니다.

운영 모드 선택 가이드

모드	설명	적합 환경
Single Binary	단일 프로세스로 전체 실행	개발, 일 로그량 수 GB 이하 소규모 테스트
Simple Scalable	읽기/쓰기 역할 분리 2티어 구조	일 로그량 수십~~수백 GB 수준의 중규모 프로덕션. 읽기/쓰기 Pod를 각 2~~3개로 시작하고 부하에 따라 수평 확장하는 방식으로 운영합니다.
Microservices	Ingester, Querier 등 컴포넌트 완전 분리	일 로그량 TB 이상의 대규모 엔터프라이즈. 컴포넌트별 독립 스케일링이 필요한 경우에 해당합니다.

실전 적용

이 섹션의 세 예시는 순서대로 연결됩니다. 먼저 Kubernetes에 기본 배포를 완료하고, 이후 로그-트레이스 연동으로 관측 범위를 확장한 뒤, 마지막으로 알림 자동화로 운영 효율을 높이는 흐름입니다. 이 예시들은 Kubernetes 환경을 전제합니다.

예시 1: Kubernetes 클러스터 로그 중앙화 (Helm 배포)

Grafana Alloy를 DaemonSet으로 배포하면 Pod 레이블(namespace, app, pod 이름 등)을 자동으로 수집해 Loki 레이블로 매핑합니다. Helm을 통한 배포 예시입니다.

yaml

# helm install loki grafana/loki-stack -f values.yaml
loki:
  enabled: true
  persistence:
    enabled: true
    storageClassName: standard   # 로컬/테스트 전용. 프로덕션에서는 반드시 S3/GCS 백엔드로 교체하는 것을 권장합니다.
    size: 10Gi
 
alloy:
  enabled: true
  extraEnv:
    - name: CLUSTER_NAME
      value: "prod-k8s"

설정 항목	역할
`loki.persistence`	로컬 스토리지 사용 (프로덕션에서는 S3 권장)
`alloy.enabled`	DaemonSet으로 Alloy 배포 활성화
`CLUSTER_NAME`	멀티클러스터 환경에서 로그 출처 구분용 레이블

2026년 3월 변경사항: Loki Helm 차트가 grafana-community/helm-charts 레포로 이전되었습니다. 아래 명령어로 최신 차트를 받아볼 수 있습니다.
bash
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install loki grafana/loki-stack -f values.yaml

예시 2: Grafana Tempo와 연동한 Trace-to-Log 점프

마이크로서비스 환경에서 특정 트랜잭션에 문제가 생겼을 때, 트레이스 뷰에서 관련 로그로 바로 이동할 수 있습니다. Grafana Tempo(트레이스)와 Loki(로그)를 연결하려면 Grafana 데이터소스 설정에서 Derived Field를 구성합니다.

yaml

# Grafana 데이터소스 설정 (loki-datasource.yaml)
# Grafana 9.x 이상 기준. 버전에 따라 url 필드 표기가 다를 수 있으므로
# 공식 문서(https://grafana.com/docs/grafana/latest/datasources/loki/)에서 버전별 확인을 권장합니다.
apiVersion: 1
datasources:
  - name: Loki
    type: loki
    url: http://loki:3100
    jsonData:
      derivedFields:
        - datasourceUid: tempo
          matcherRegex: "traceID=(\\w+)"
          name: TraceID
          url: "${__value.raw}"

이 설정이 적용되면 로그 라인에 traceID=abc123 패턴이 있을 때 Tempo 트레이스 상세 패널로 바로 이동하는 링크가 자동으로 생성됩니다. 2025년 말 도입된 새 로그 시각화 패널은 이 연동을 더욱 직관적으로 지원합니다.

예시 3: 에러 알림 자동화

LogQL의 metric query를 Grafana Alerting과 연결하면 특정 패턴의 에러 급증을 실시간으로 감지할 수 있습니다.

logql

# Grafana Alert Rule의 쿼리 필드에 입력합니다
# 1분 내 payment-service ERROR 로그 수를 집계한 메트릭 반환
sum(count_over_time({app="payment-service"} |= "ERROR" [1m])) by (namespace)

주의: LogQL 쿼리 자체에 > 10 같은 임계값 조건을 포함하지 않습니다. 임계값은 Grafana Alert Rule 설정 화면의 Condition 필드에서 별도로 지정합니다. 쿼리는 메트릭 값을 반환하는 역할만 담당하고, 알림 조건 판단은 Grafana Alerting 엔진이 처리합니다.

이 쿼리를 Grafana Alert Rule로 등록하고 Contact Point를 Slack 또는 PagerDuty로 설정하면, 운영팀이 로그를 직접 확인하지 않아도 임계값 초과 시 자동으로 알림을 받을 수 있습니다.

장단점 분석

장점

항목	내용
저비용	로그 본문 미인덱싱으로 스토리지·메모리 비용 대폭 절감. Grafana Labs 자체 사례 기준 ELK 대비 스토리지 비용 80% 이상 절감 가능
Prometheus 친화성	동일한 레이블 체계와 쿼리 철학, PromQL 경험자에게 낮은 학습 곡선
수평 확장	Ingester, Querier 컴포넌트를 독립적으로 스케일링 가능
운영 단순성	ELK 대비 구성 요소가 적고 관리 오버헤드가 낮음
Grafana 네이티브 통합	메트릭-로그-트레이스를 단일 UI에서 상관 분석 (LGTM 스택)

단점 및 주의사항

항목	내용	대응 방안
Full-text 검색 속도	로그 본문 인덱싱이 없어 범위 쿼리에서 ELK 대비 느릴 수 있음	레이블로 스트림 범위를 먼저 좁힌 뒤 쿼리하는 것이 좋습니다
카디널리티 문제	`user_id` 같은 고유값 레이블 사용 시 인덱스 폭발, 성능 급락	저카디널리티 레이블만 사용하고 고유값은 구조화 메타데이터로 처리합니다
쿼리 타임아웃	복잡한 정규표현식이나 대규모 시간 범위 쿼리 시 타임아웃 발생 가능	2026년 1월 도입된 Query Limit Policies로 자동 가드레일 설정이 가능합니다
SIEM 보안 분석 한계	심층 전문 검색이 필요한 보안 분석에는 부적합	보안 목적 로그는 Elasticsearch와 역할을 분리하는 것을 권장합니다
HA 설정 복잡도	Simple Scalable, Microservices 모드는 설정 난이도가 높음	규모에 맞는 모드부터 시작해 점진적으로 확장하는 방법이 있습니다
Windows 로그 수집	Windows Event Log 네이티브 지원 제한적	FluentBit 또는 Vector를 중간 수집기로 활용할 수 있습니다

카디널리티(Cardinality): 레이블이 가질 수 있는 고유값의 수입니다. env 레이블은 prod, staging, dev 정도로 카디널리티가 낮지만, user_id는 수백만 개의 고유값을 가질 수 있어 카디널리티가 매우 높습니다. 높은 카디널리티 레이블은 Loki 인덱스 크기를 폭발적으로 증가시킵니다.

실무에서 가장 흔한 실수

고카디널리티 레이블 남용: request_id, user_id, session_id 등을 레이블로 지정하면 인덱스가 폭발적으로 커집니다. 이런 값들은 로그 본문이나 구조화 메타데이터에 포함하고, 레이블은 namespace, app, env 수준의 5개 이내 저카디널리티 값만 사용하는 것을 권장합니다.
시간 범위를 지정하지 않은 쿼리: 레이블 선택자만으로 넓은 시간 범위를 쿼리하면 방대한 청크를 스캔하게 됩니다. 항상 필요한 시간 범위를 명확히 제한하고, 가능하면 rate() 또는 count_over_time() 같은 집계 함수를 활용하는 것이 좋습니다.
Promtail을 계속 사용하는 경우: 2026년 2월 28일자로 Promtail의 상업 지원이 공식 종료되었습니다. 신규 배포는 물론, 기존 Promtail 환경도 Grafana Alloy로 마이그레이션을 검토하는 것을 권장합니다.

마치며

Grafana Loki는 "완벽한 로그 시스템"이 아니라 "Kubernetes 시대에 최적화된 실용적 로그 시스템"입니다. 전문 검색보다 비용 효율과 Prometheus 생태계 통합이 우선인 환경이라면, Loki는 현재 가장 합리적인 선택지 중 하나입니다.

지금 바로 시작해볼 수 있는 3단계를 안내합니다.

로컬 환경에서 Single Binary 모드로 먼저 체험해볼 수 있습니다. Grafana Labs 공식 Loki Quickstart 가이드에서 제공하는 docker-compose.yaml을 내려받아 실행하면 Loki + Grafana 환경을 빠르게 구성할 수 있습니다. LogQL 쿼리를 직접 입력해보는 것으로 시작하면 됩니다.
Kubernetes 환경이 있다면 Helm으로 loki-stack을 배포해볼 수 있습니다. helm repo add grafana https://grafana.github.io/helm-charts && helm install loki grafana/loki-stack 명령어로 Alloy + Loki + Grafana를 한 번에 배포할 수 있습니다. 단, storageClassName은 반드시 클러스터 환경에 맞게 수정하는 것을 권장합니다.
레이블 설계 원칙을 먼저 팀과 합의하는 것을 권장합니다. 아래 체크리스트를 기준으로 시작해볼 수 있습니다.

레이블	카디널리티	권장 여부
`namespace`	낮음 (수~수십)	권장
`app`	낮음 (수십)	권장
`env`	매우 낮음 (3~5)	권장
`pod`	중간~높음	상황에 따라
`user_id`	매우 높음	사용 자제 — 구조화 메타데이터 활용
`request_id`	매우 높음	사용 자제 — 로그 본문에 포함

다음 글: LogQL 심화 — 구조화 메타데이터와 파이프라인 파서를 활용해 비정형 로그에서 원하는 필드를 추출하는 실전 쿼리 작성법

참고 자료

공식 문서

커뮤니티 사례 및 가이드

비교 분석

DevOps

Grafana Loki 실전 가이드: ELK 없이 Kubernetes 로그 관리하기

이 글에서 다루는 내용: Loki vs ELK 인덱싱 전략 차이 → 핵심 구성 요소 및 LogQL 쿼리 문법 → Helm 기반 Kubernetes 배포 실전 예시 → Trace-to-Log 연동 및 알림 자동화 → 장단점 및 운영 실수 방지 가이드

Prometheus와 Grafana를 이미 운영 중이거나, ELK의 높은 비용에 대안을 찾고 있다면 이 글이 의사결정에 실질적인 도움이 될 것입니다.

핵심 개념

인덱싱 전략의 차이가 모든 것을 결정합니다

비교 항목	Elasticsearch (ELK)	Grafana Loki
인덱싱 대상	로그 전체 (full-text)	레이블 메타데이터만
스토리지 비용	높음	낮음 (오브젝트 스토리지)
검색 속도	키워드 검색 빠름	범위 쿼리에서 ELK 대비 느릴 수 있음 (청크 스캔 방식)
운영 복잡도	높음	낮음
Kubernetes 친화성	중간	높음 (Pod 레이블 자동 매핑)

청크(Chunk): 일정 시간 범위의 로그 데이터를 압축한 단위 파일입니다. Loki의 Ingester 컴포넌트는 수신된 로그를 메모리에 청크 단위로 모은 뒤, 일정 크기 또는 시간 기준으로 오브젝트 스토리지에 플러시합니다. 예기치 않은 재시작에 대비해 WAL(Write-Ahead Log)을 통해 유실을 방지합니다. 쿼리 시에는 레이블에 매칭되는 청크만 읽어 스캔하므로, 레이블 설계가 쿼리 성능에 직결됩니다.

3대 구성 요소

Loki 생태계는 세 가지 역할로 나뉩니다.

Grafana Alloy (구 Promtail): 각 노드에서 로그를 수집해 Loki로 전송하는 에이전트. 2026년 2월 28일자로 Promtail의 상업 지원이 종료되었으며, Alloy가 메트릭·로그·트레이스·프로파일링을 단일 에이전트에서 통합 수집합니다.
Loki: 로그 저장 및 쿼리 처리 엔진
Grafana: LogQL 쿼리 결과를 시각화하는 대시보드

LogQL — PromQL에서 영감을 받은 로그 쿼리 언어

LogQL은 Prometheus의 PromQL을 기반으로 설계되어, Prometheus 사용 경험이 있다면 학습 곡선이 완만합니다. 크게 두 가지 쿼리 유형이 있습니다.

Log Query: 로그 스트림을 직접 필터링합니다.

logql

# production 네임스페이스의 api-server에서 ERROR 로그만 필터링하고 JSON 파싱
{namespace="production", app="api-server"} |= "ERROR" | json | line_format "{{.message}}"

line_format "{{.message}}" 에서 이중 중괄호는 Go 템플릿 문법입니다. json 파이프로 파싱된 필드 중 message 키 값만 출력 형식으로 지정하는 역할을 합니다.

Metric Query: 로그 패턴을 메트릭으로 집계합니다.

logql

# payment-service의 ERROR 발생 건수를 5분 단위로 집계
sum(rate({app="payment-service"} |= "ERROR" [5m])) by (namespace)

레이블 선택자 {}: PromQL과 동일한 형식으로, 쿼리할 로그 스트림을 좁히는 역할을 합니다. 이 선택자가 효율적일수록 스캔할 청크가 줄어들어 쿼리 성능이 향상됩니다.

운영 모드 선택 가이드

모드	설명	적합 환경
Single Binary	단일 프로세스로 전체 실행	개발, 일 로그량 수 GB 이하 소규모 테스트
Simple Scalable	읽기/쓰기 역할 분리 2티어 구조	일 로그량 수십~~수백 GB 수준의 중규모 프로덕션. 읽기/쓰기 Pod를 각 2~~3개로 시작하고 부하에 따라 수평 확장하는 방식으로 운영합니다.
Microservices	Ingester, Querier 등 컴포넌트 완전 분리	일 로그량 TB 이상의 대규모 엔터프라이즈. 컴포넌트별 독립 스케일링이 필요한 경우에 해당합니다.

실전 적용

예시 1: Kubernetes 클러스터 로그 중앙화 (Helm 배포)

Grafana Alloy를 DaemonSet으로 배포하면 Pod 레이블(namespace, app, pod 이름 등)을 자동으로 수집해 Loki 레이블로 매핑합니다. Helm을 통한 배포 예시입니다.

yaml

# helm install loki grafana/loki-stack -f values.yaml
loki:
  enabled: true
  persistence:
    enabled: true
    storageClassName: standard   # 로컬/테스트 전용. 프로덕션에서는 반드시 S3/GCS 백엔드로 교체하는 것을 권장합니다.
    size: 10Gi
 
alloy:
  enabled: true
  extraEnv:
    - name: CLUSTER_NAME
      value: "prod-k8s"

설정 항목	역할
`loki.persistence`	로컬 스토리지 사용 (프로덕션에서는 S3 권장)
`alloy.enabled`	DaemonSet으로 Alloy 배포 활성화
`CLUSTER_NAME`	멀티클러스터 환경에서 로그 출처 구분용 레이블

2026년 3월 변경사항: Loki Helm 차트가 grafana-community/helm-charts 레포로 이전되었습니다. 아래 명령어로 최신 차트를 받아볼 수 있습니다.
bash
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install loki grafana/loki-stack -f values.yaml

예시 2: Grafana Tempo와 연동한 Trace-to-Log 점프

yaml

# Grafana 데이터소스 설정 (loki-datasource.yaml)
# Grafana 9.x 이상 기준. 버전에 따라 url 필드 표기가 다를 수 있으므로
# 공식 문서(https://grafana.com/docs/grafana/latest/datasources/loki/)에서 버전별 확인을 권장합니다.
apiVersion: 1
datasources:
  - name: Loki
    type: loki
    url: http://loki:3100
    jsonData:
      derivedFields:
        - datasourceUid: tempo
          matcherRegex: "traceID=(\\w+)"
          name: TraceID
          url: "${__value.raw}"

예시 3: 에러 알림 자동화

LogQL의 metric query를 Grafana Alerting과 연결하면 특정 패턴의 에러 급증을 실시간으로 감지할 수 있습니다.

logql

# Grafana Alert Rule의 쿼리 필드에 입력합니다
# 1분 내 payment-service ERROR 로그 수를 집계한 메트릭 반환
sum(count_over_time({app="payment-service"} |= "ERROR" [1m])) by (namespace)

주의: LogQL 쿼리 자체에 > 10 같은 임계값 조건을 포함하지 않습니다. 임계값은 Grafana Alert Rule 설정 화면의 Condition 필드에서 별도로 지정합니다. 쿼리는 메트릭 값을 반환하는 역할만 담당하고, 알림 조건 판단은 Grafana Alerting 엔진이 처리합니다.

장단점 분석

장점

항목	내용
저비용	로그 본문 미인덱싱으로 스토리지·메모리 비용 대폭 절감. Grafana Labs 자체 사례 기준 ELK 대비 스토리지 비용 80% 이상 절감 가능
Prometheus 친화성	동일한 레이블 체계와 쿼리 철학, PromQL 경험자에게 낮은 학습 곡선
수평 확장	Ingester, Querier 컴포넌트를 독립적으로 스케일링 가능
운영 단순성	ELK 대비 구성 요소가 적고 관리 오버헤드가 낮음
Grafana 네이티브 통합	메트릭-로그-트레이스를 단일 UI에서 상관 분석 (LGTM 스택)

단점 및 주의사항

항목	내용	대응 방안
Full-text 검색 속도	로그 본문 인덱싱이 없어 범위 쿼리에서 ELK 대비 느릴 수 있음	레이블로 스트림 범위를 먼저 좁힌 뒤 쿼리하는 것이 좋습니다
카디널리티 문제	`user_id` 같은 고유값 레이블 사용 시 인덱스 폭발, 성능 급락	저카디널리티 레이블만 사용하고 고유값은 구조화 메타데이터로 처리합니다
쿼리 타임아웃	복잡한 정규표현식이나 대규모 시간 범위 쿼리 시 타임아웃 발생 가능	2026년 1월 도입된 Query Limit Policies로 자동 가드레일 설정이 가능합니다
SIEM 보안 분석 한계	심층 전문 검색이 필요한 보안 분석에는 부적합	보안 목적 로그는 Elasticsearch와 역할을 분리하는 것을 권장합니다
HA 설정 복잡도	Simple Scalable, Microservices 모드는 설정 난이도가 높음	규모에 맞는 모드부터 시작해 점진적으로 확장하는 방법이 있습니다
Windows 로그 수집	Windows Event Log 네이티브 지원 제한적	FluentBit 또는 Vector를 중간 수집기로 활용할 수 있습니다

카디널리티(Cardinality): 레이블이 가질 수 있는 고유값의 수입니다. env 레이블은 prod, staging, dev 정도로 카디널리티가 낮지만, user_id는 수백만 개의 고유값을 가질 수 있어 카디널리티가 매우 높습니다. 높은 카디널리티 레이블은 Loki 인덱스 크기를 폭발적으로 증가시킵니다.

실무에서 가장 흔한 실수

고카디널리티 레이블 남용: request_id, user_id, session_id 등을 레이블로 지정하면 인덱스가 폭발적으로 커집니다. 이런 값들은 로그 본문이나 구조화 메타데이터에 포함하고, 레이블은 namespace, app, env 수준의 5개 이내 저카디널리티 값만 사용하는 것을 권장합니다.
시간 범위를 지정하지 않은 쿼리: 레이블 선택자만으로 넓은 시간 범위를 쿼리하면 방대한 청크를 스캔하게 됩니다. 항상 필요한 시간 범위를 명확히 제한하고, 가능하면 rate() 또는 count_over_time() 같은 집계 함수를 활용하는 것이 좋습니다.
Promtail을 계속 사용하는 경우: 2026년 2월 28일자로 Promtail의 상업 지원이 공식 종료되었습니다. 신규 배포는 물론, 기존 Promtail 환경도 Grafana Alloy로 마이그레이션을 검토하는 것을 권장합니다.

마치며

지금 바로 시작해볼 수 있는 3단계를 안내합니다.

로컬 환경에서 Single Binary 모드로 먼저 체험해볼 수 있습니다. Grafana Labs 공식 Loki Quickstart 가이드에서 제공하는 docker-compose.yaml을 내려받아 실행하면 Loki + Grafana 환경을 빠르게 구성할 수 있습니다. LogQL 쿼리를 직접 입력해보는 것으로 시작하면 됩니다.
Kubernetes 환경이 있다면 Helm으로 loki-stack을 배포해볼 수 있습니다. helm repo add grafana https://grafana.github.io/helm-charts && helm install loki grafana/loki-stack 명령어로 Alloy + Loki + Grafana를 한 번에 배포할 수 있습니다. 단, storageClassName은 반드시 클러스터 환경에 맞게 수정하는 것을 권장합니다.
레이블 설계 원칙을 먼저 팀과 합의하는 것을 권장합니다. 아래 체크리스트를 기준으로 시작해볼 수 있습니다.

레이블	카디널리티	권장 여부
`namespace`	낮음 (수~수십)	권장
`app`	낮음 (수십)	권장
`env`	매우 낮음 (3~5)	권장
`pod`	중간~높음	상황에 따라
`user_id`	매우 높음	사용 자제 — 구조화 메타데이터 활용
`request_id`	매우 높음	사용 자제 — 로그 본문에 포함

다음 글: LogQL 심화 — 구조화 메타데이터와 파이프라인 파서를 활용해 비정형 로그에서 원하는 필드를 추출하는 실전 쿼리 작성법

참고 자료

공식 문서

커뮤니티 사례 및 가이드

비교 분석