[Monitoring/Loki] Loki 설치 & 설명에 대한 모든 것 (3)

이번글의 loki은 다음을 따른다.

1. promtail 설명 및 설치
2. 로그 수집 기초
3. loki 설명 및 설치
4. loki 설정 기초
5. LogQL

이번글에서 설명하는 내용은 3번이다.

프롬테일을 설정해야 loki를 제대로 활용할 수 있다.

[Monitoring/Promtail] 로그 수집 기초 (v2.x.x) & 고급 (다중 서버 로그 읽기) (2)

---

3. Loki 설명 및 설치

Loki가 뭔가요?

Loki는 분산 로그 수집 저장 조회 도구이다. 로그 데이터를 효율적으로 처리하기 위해서 사용되는 DB이다.

로그를 인덱싱만하고 실제 로그데이터는 별도로 저장하기 때문에 ELK보다 저장 공간 처리 속도가 효율적이다.

자원을 더 적게 사용하기 때문에 서버 자원이 부족한 요번 프로젝트에 잘 어울린다. (Grafana랑 호환성이 좋은건 덤이다.)

Loki 설치

바이너리 방식으로 다운로드해서 직접 설치할 수 있으나 권장되는 방식은 아니다.

공식 문서에서도 Docker를 사용하는 방식을 사용하기 때문에 Docker를 사용한 설치 방식으로 설명하겠다.

Loki를 dockerfile로 만드는 방식은 크게 2가지가 있다.

1. bitnami docker hub

FROM bitnami/grafana-loki:3

EXPOSE 3100

기본적인 설정이 들어있다. bash 같은 shell 도 깔려있어 빠른 간단한 설치가 가능해 bitnami를 사용하는 방식으로 글을 작성하겠다.

2. grafana docker hub

FROM grafana/grafana-loki:3

EXPOSE 3100

 

grafana에서 받는 loki는 설정이 최소화 되어있다.

만약 자신이 dockerfile을 잘생성하고 설정할줄 안다면 직접 받아서 필요한 기능만 받아서 설정해 줘도 된다.

Dockerfile

FROM bitnami/grafana-loki:3

ENV TZ=Asia/Seoul

ENV로 컨테이너의 TZ을 한국으로 설정했다.

ENV로 한국으로 설정해도 loki프로그램은 기본적으로 UTC를 사용하기 때문에 log는 UTC기반으로 받고 프로그램도 UTC기반으로 동작한다.

이는 중요한 개념이니 꼭 숙지하도록하자 (모니터링에서 중요한건 시간이지 않을까? 언제 무슨 일이)

따라서 나중에 loki에서 데이터 값을 가져올때 UTC 계산이 필수적이다.

지금 TZ를 넣은 이유는 나중에 loki의 하드웨어적인 자원을 모니터링 하기 위함이다

config.yaml파일을 여기서 지정해줘도 되지만 필자는 docker-compose파일에서 지정하는 방식을 더 선호한다.

Docker-comopse.yml

version: '3.7'

networks:
  loki_network:  # 네트워크 이름 정의

volumes:
  loki_data:                  # Loki 데이터를 위한 볼륨
  promtail_data:              # Promtail 데이터를 위한 볼륨

services:
  loki:
    build:
      context: .
      dockerfile: ./dockerfile/Dockerfile-loki  # Loki의 커스텀 Dockerfile 지정
    container_name: loki
    volumes:
      - loki_data:/loki
      - ./loki/local-config.yaml:/etc/loki/loki.yaml  # Loki 설정 파일 마운트
    ports:
      - "3100:3100"  # 외부 접근을 위한 포트 매핑
    command: -config.file=/etc/loki/loki.yaml
    restart: always
    environment:
      - TZ=Asia/Seoul
    networks:
      - loki_network

이전에 사용한 promtail과 같은network로 연결해주면 된다.

 

 

volumes를 사용해서 loki의 데이터가 컨테이너가 꺼져도 저장되도록 했으며 loki의 설정파일을 마운트 했다.

command를 통해서 loki.yaml 설정파일을 지정해줬고

3100 port를 열어서 외부에서 api를 사용할수 있도록 설정했다.

위방식대로 설계를 진행하면 다음 그림처럼 pormtail에서 loki로 data가 이동하게 된다.(promtail에서 데이터를 받자)

그럼 loki는 어떤식으로 log를 저장하는가?

https://www.atatus.com/blog/a-beginners-guide-for-grafana-loki/

Loki의 서비스는 크게 4가지 모듈로 나눌수 있다.

• Distributor (분배자)
  역할 : Distributor 모듈은 클라이언트(log전송자)가 보내는 데이터 스트림을 처리하고 검증한다.
  동작 : 유효한 데이터를 여러 chunk로 나눠서 여러 Ingester에 병렬로 전송한다.
  Label : 라벨을 통해서 로그데이터를 검증하고 각종 모듈에서 사용할수 있도록 준비한다. 즉 라벨이 없는 데이터를 저장할때는 Loki가 적합하지 않다
• Ingester (처리기)
  역할 : 데이터를 장기 저장소에 기록하는 역할을 한다.
  저장 방식 : Loki는 로그데이터 자체를 저장하는 대신 메타데이터를 인덱싱하게 된다. 이떄 AWS S3, Cassnadra같은 걸 사용할수 있다.
  인메모리 검색 : Ingester는 메모리에 저장된 데이터를 검색 요청에 응답으로 반환한다.
  데이터 손실 가능성 : Ingester가 충돌할 경우, 플러시 되지 않은 데이터는 손실될 수 있다. (설정을 잘해야한다)
• Querier (질의기)
  역할 : 사용자의 query를 처리해서 Ingester와 객체 저장소에서 데이터를 가져온다.
  동작 순서 : Local Storage에서 질의를 수행하고 그다음에 long-term Storage에서 검색한다.
  중복 데이터 처리 : 여러 위치에서 데이터를 질의하기 떄문 중복 데이터를 처리해야한다. Ingester는 데이터 작성중에 중복 로그를 확인하지 않음으로, Querier는 동일한 타임스탬프. 라벨 데이터, 로그 데이터를 한 번만 반환하도록 내부 메커니즘을 사용하게 된다.
• Query Frontent 
  역할 : 대규모 질의를 병렬화 한다.
  특징 : Query Frontend는 큰 검색 작업을 작은 단위로 나눠 병렬 로그를 읽는다.

Local Storage VS Long-term Storage

위치	서버 내부의 디스크	외부 객체 저장소 (S3, GCS, Azure Blob 등)
성능	빠른 검색 및 쓰기 성능 (저지연)	검색 및 복구 속도가 느림
확장성	디스크 용량에 의존하여 확장성 제한	무제한 확장 가능
내구성	하드웨어 장애 시 데이터 손실 가능	클라우드 내 데이터 복제 및 백업으로 높은 내구성 제공
비용	추가 비용 없음	데이터 저장, 읽기, 쓰기에 비용 발생
적합한 데이터	최근 데이터(HOT DATA)	과거 데이터(COLD DATA)
적합한 환경	소규모/테스트 환경	대규모/프로덕션 환경

그럼 다른 Software보다 좋은 점은?

Suite)의 장점을 표로 정리한 내용입니다.

항목Grafana LokiElasticsearch (ELK)SplunkGraylogElastic Observability Suite

항목	Grafana Loki	ELK	Splunk	GrayLog	Elastic Observability Suite
비용	오픈소스 무료 + 클라우드 스토리지 비용만 발생	무료(오픈소스) 사용 가능, 하지만 데이터 증가 시 리소스 비용 증가	라이선스 비용이 높음	무료 버전 있음, 프리미엄 기능은 유료	유료 플랜 필요, Elastic 클라우드 기반 비용 추가
설정 간소화	간단한 설정과 경량화된 아키텍처	복잡한 설정 및 클러스터 관리 필요	설정 복잡, 학습 곡선 높음	기본 설정은 간단하지만, 확장 시 복잡해질 수 있음	Elastic Stack 구성 복잡 (로그, 메트릭 분리)
저장소 효율성	로그 텍스트가 아닌 메타데이터(라벨)만 인덱싱 → 저장소 사용량 적음	로그 텍스트와 메타데이터 모두 인덱싱 → 저장소 사용량 큼	모든 데이터를 인덱싱 → 높은 저장소 요구	로그와 메타데이터를 인덱싱하며, 중간 정도의 저장 효율성	Elastic과 유사
검색 성능	라벨 기반 검색으로 빠르고 효율적	대규모 데이터에서 인덱스 최적화 필요	대규모 데이터에서 검색 속도가 느림	검색 속도는 빠르지만, 대규모 데이터에서 병목 가능성	ELK와 유사한 검색 성능
Prometheus 통합	Prometheus와 자연스럽게 통합, 동일한 라벨링 구조	기본 통합 지원하지 않음	통합 가능하지만 추가적인 설정 필요	Prometheus와 기본 통합 제공하지 않음	Prometheus 통합 가능하지만 Loki보다 복잡
확장성	클라우드 스토리지와의 통합으로 뛰어난 확장성 (AWS S3, GCS 등 지원)	클러스터 기반으로 확장 가능하지만, 스토리지 관리가 복잡	고가용성과 확장성 지원하지만, 매우 높은 비용 발생	확장성은 있지만 클러스터 구성 및 스토리지 관리 필요	Elastic Cloud 사용 시 확장 가능, 비용 발생
리소스 효율성	메타데이터만 처리하므로 CPU/메모리 사용량 낮음	전체 데이터를 처리하므로 리소스 요구량 큼	리소스 요구량 큼 (특히 대규모 데이터 처리 시)	적은 로그 데이터에서는 효율적, 대규모 데이터에서는 높은 리소스 사용	Elastic과 유사
장기 저장소 지원	AWS S3, GCS 등 다양한 객체 스토리지 지원	기본 파일 기반 저장소 또는 별도 설정 필요	Splunk 자체 저장소 사용 (비용 높음)	객체 스토리지와의 직접적인 통합 제한적	Elastic Cloud 기반으로 장기 저장소 지원