← 글 목록

Promtail, Loki, Grafana 로그 수집 삽질기: AI가 만든 로그의 함정에서 탈출하기

/ 7분 분량
#모니터링

오늘은 Promtail, Loki, Grafana를 이용한 로그 모니터링 시스템 구축 여정을 공유하고자 합니다. 특히 AI가 생성한 로그의 예상치 못한 함정과 'empty ring'이라는 오류를 극복하고, 로그 수집 파이프라인을 완성하기까지의 과정을 상세하게 담았습니다.

오늘은 Promtail, Loki, Grafana를 이용한 로그 모니터링 시스템 구축 여정을 공유하고자 합니다. 특히 AI가 생성한 로그의 예상치 못한 함정과 'empty ring'이라는 오류를 극복하고, 로그 수집 파이프라인을 완성하기까지의 과정을 상세하게 담았습니다.

학습 주제

  • 주제: Promtail, Loki, Grafana를 이용한 로그 수집 및 모니터링 시스템 구축
  • 학습 날짜: 2026년 2월 8일

질문과 탐구

처음에는 라즈베리파이에서 실행 중인 LearningCollector 애플리케이션의 로그를 Grafana에서 시각화하고 싶다는 단순한 목표에서 시작했습니다. 하지만 Promtail이 파일을 감지하는 것처럼 보이는데도 Loki로 데이터가 전혀 전송되지 않는 현상에 부딪히면서 본격적인 탐구가 시작되었습니다.

  • Promtail은 파일을 감지하는데 왜 Loki로 로그가 전송되지 않을까?
  • Loki의 Ingester 상태가 'not ready'인 이유는 무엇일까?
  • "empty ring" 에러의 근본적인 원인은 무엇이며 어떻게 해결해야 할까?
  • AI가 생성한 로그 파일의 구조가 왜 이렇게 일관성이 없을까?
  • Promtail 설정에서 로그 레이블을 어떻게 효율적으로 설계해야 할까?

이러한 궁금증들을 해결하기 위해 Promtail 로그, Loki 로그, Docker 네트워크 상태, 그리고 설정 파일들을 실마리를 찾아 나갔습니다.

핵심 학습 내용

1. Promtail, Loki, Grafana 시스템 아키텍처 이해

데이터 흐름은 다음과 같았습니다.

로그 파일 → Promtail (수집) → Loki (저장) → Grafana (시각화)

핵심은 Promtail이 로그를 읽어 Loki로 보내고, Grafana는 Loki로부터 데이터를 쿼리하여 보여준다는 것입니다. Loki는 외부로 데이터를 보내는 역할은 하지 않습니다.

2. 'empty ring' 오류의 정체와 해결

Loki의 Ingester가 'empty ring' 오류를 내며 제대로 시작하지 못하는 것이 문제였습니다. 이는 주로 다음과 같은 설정 충돌 및 누락 때문에 발생했습니다.

  • memberlist와 inmemory kvstore의 공존: Loki가 단독으로 실행되는지, 클러스터를 구성하는지 혼란을 겪으며 발생하는 문제입니다. memberlist 섹션을 제거하고 common.ring.kvstore.store: inmemory로 통일하여 해결했습니다.
  • lifecycler 설정 누락: Ingester가 스스로를 Loki의 ring에 등록하는 메커니즘인데, 이 설정이 없으면 Ingester가 ring에 진입하지 못합니다. ingester.lifecycler 설정을 추가하여 Ingester가 정상적으로 등록되도록 했습니다.
  • tsdb_shipper 설정 누락: Time Series Database(TSDB)의 인덱스 저장 위치를 명시하지 않아 데이터 저장에 문제가 발생했습니다. storage_config.tsdb_shipper를 추가하여 해결했습니다.

3. AI가 만든 로그 구조의 비일관성

가장 예상치 못한 난관은 AI가 생성한 로그 파일의 구조가 매우 불규칙하다는 점이었습니다. 어떤 로그는 {"timestamp": ...} 형식을 따르는 반면, 다른 로그는 {"ts": ...} 형식을 사용했습니다. 또한, api 필드처럼 실제로 존재하지 않는 필드를 Promtail 설정에서 추출하려 시도하는 오류도 있었습니다.

이 문제를 해결하기 위해 jq -s 'map(keys) | add | unique' 명령어를 활용하여 실제 로그 파일에 존재하는 모든 키를 파악하고, Promtail 설정을 이에 맞게 현실적으로 수정해야 했습니다.

4. 효율적인 로그 레이블 설계

모든 로그 필드를 레이블로 사용하면 Loki의 성능이 급격히 저하될 수 있습니다. 따라서 level, event, component와 같이 카디널리티(값의 다양성)가 낮은 필드들만 레이블로 사용하고, title, url과 같이 카디널리티가 높은 필드는 레이블에서 제외하는 전략을 채택했습니다.

  • 핵심 레이블: level, event, component
  • 레이블 제외 필드: title, url, message (성능 저하 방지)

이해한 내용

이번 학습을 통해 Loki와 Promtail의 동작 원리를 깊이 이해할 수 있었습니다. 특히 'empty ring'과 같은 복잡한 오류의 원인이 설정 파일의 미묘한 차이에서 비롯될 수 있다는 것을 알게 되었습니다. 또한, AI가 생성한 콘텐츠라도 그 결과물을 맹신하지 않고 검증하는 과정이 얼마나 중요한지도 깨달았습니다. 로그 구조의 일관성이 왜 중요한지, 그리고 카디널리티를 고려한 레이블 설계가 로그 모니터링 시스템의 성능에 얼마나 큰 영향을 미치는지 이해하게 되었습니다.

실전 적용

  • 적용 분야: 앞으로 개발하는 서비스들의 로그 수집 및 모니터링 시스템 구축에 바로 적용할 수 있습니다.
  • 실습 계획:
    • Promtail 설정에서 labeldrop을 활용하여 불필요한 기본 레이블(detected_level, service_name)을 제거하는 실험을 해볼 예정입니다.
    • 다양한 애플리케이션의 로그를 Promtail로 수집하고, Grafana에서 복잡한 쿼리를 작성하여 분석하는 연습을 할 것입니다.
  • 응용 아이디어: Promtail의 pipeline_stages 기능을 더 깊이 활용하여 로그 필터링, 변환, 그리고 더 정교한 레이블링 규칙을 적용하는 방법을 연구하고 싶습니다.

추가 학습 계획

  • 더 깊이 공부하고 싶은 부분:
    • Loki의 스케일링 및 고가용성 구성 방법
    • Promtail의 다양한 pipeline_stages (예: template, output 등) 활용법
    • Grafana에서 로그 시각화를 위한 대시보드 구축 및 쿼리 최적화
  • 관련 자료 찾기: Loki 공식 문서, Promtail 공식 문서, Grafana 공식 문서, 그리고 관련 기술 블로그들을 추가적으로 탐독할 계획입니다.

참고 자료