Loki

"metric은 Prometheus로 모으는데, 로그는 어디에 모으고 어떻게 찾는가?" 이 페이지는 그 질문에 답한다. Loki는 로그를 저장하고 조회하는 시스템이며, Prometheus와 같은 라벨 모델로 로그를 색인한다.^[1] Prometheus가 metric을 담당한다면 Loki는 로그를 담당해 서로를 보완하고, 조회는 Grafana에서 LogQL로 한다.^[1:1]

구성 요소와 수집 방향

• 위 표는 원문의 구성 요소 정리를 옮긴 것이다.^[1:2]
• 수집 방향이 Prometheus와 반대다. Prometheus는 대상의 metric을 pull하지만, Loki에서는 Promtail이 로그를 Loki로 push한다.^[1:3]
• 라벨만 색인하고 내용은 색인하지 않으므로, 조회할 때는 라벨 선택자로 대상 스트림을 먼저 좁히고 그 안에서 내용을 거르는 순서가 된다. 이는 색인 방식에서 이 Wiki가 도출한 해석이다.

로그에 라벨이 붙는 지점

• Docker 로그를 수집할 때 Promtail은 컨테이너 로그 파일 경로를 대상으로 잡고, pipeline_stages에서 Docker JSON 로그를 파싱한 뒤 컨테이너 이름과 이미지 이름을 라벨로 붙인다.^[1:4]

scrape_configs:
  - job_name: docker
    static_configs:
      - targets: [localhost]
        labels:
          job: docker
          __path__: /var/lib/docker/containers/*/*-json.log
    pipeline_stages:
      - docker: {}               # 도커 JSON 로그 파싱
      - labels:
          container: container_name
          image: image_name

• 같은 설정에서 syslog는 /var/log/*.log를 job: syslog 라벨로 수집한다. Promtail은 수집 결과를 http://loki:3100/loki/api/v1/push로 보낸다.^[1:5]
• 이렇게 붙은 job, container 라벨이 이후 LogQL 선택자의 기준이 된다.

LogQL 기본 쿼리

# 특정 컨테이너 로그
{job="docker", container="leafy_api"}

# ERROR 포함 로그만
{job="docker"} |= "ERROR"

# HTTP 5xx 카운트 (로그 기반)
sum by (container) (
  rate({job="docker"} |= " 5" |~ "HTTP/1.1\" 5[0-9]{2}" [5m])
)

• 첫 쿼리는 라벨 선택자로 스트림을 고르고, 두 번째는 |=로 문자열이 포함된 줄만 남기며, 세 번째는 |~ 정규식으로 거른 로그 줄의 비율을 PromQL처럼 rate와 sum by로 집계한다.^[1:6]
• 원문은 세 번째 쿼리를 "로그 기반" HTTP 5xx 카운트로 소개한다.^[1:7] 로그 줄을 metric처럼 세는 방식이라, 별도 metric이 없는 서비스의 5xx 비율도 로그에서 구할 수 있다고 볼 수 있다.

장애 관제 Agent에서의 쓰임

• 장애 관제 Agent는 Prometheus metric과 함께 Loki 로그를 조회해 장애 원인을 분석하며, 로그 조회는 Agent가 호출하는 도구(LokiQueryService)로 노출된다.^[2]
• metric이 "무엇이 이상한가"를 보여준다면 로그는 "그때 무슨 일이 있었나"를 보여주므로, 두 도구를 함께 주는 설계로 볼 수 있다.

설정 예시의 경계

• 원문의 최소 설정은 이미지 grafana/loki:3.1.1·grafana/promtail:3.1.1, 저장소 filesystem, schema tsdb/v13을 쓴다.^[1:8] 버전과 schema 값은 배포 환경과 Loki 버전에 묶인 값이라 일반 규칙이 아니다.
• 원문 설정의 ruler에는 alertmanager_url: http://alertmanager:9093이 들어 있다.^[1:9] Loki 쪽 rule 평가 결과를 Alertmanager로 보낼 수 있게 구성한 예지만, 원문은 로그 기반 alert rule 자체를 설명하지 않는다.
• Promtail은 /var/lib/docker/containers와 /var/log를 읽기 전용으로 마운트한다.^[1:10]

관련

• Prometheus: 같은 라벨 모델을 쓰지만 metric을 pull로 수집한다는 점에서 Loki의 push 수집과 대비된다.
• Grafana: Loki를 데이터소스로 연결해 LogQL 조회와 시각화를 맡는다.
• PromQL: LogQL의 metric 쿼리(rate, sum by)가 PromQL의 집계 문법을 닮았다.

테스트 질문

• Loki는 로그 내용을 색인하는가? 색인하지 않는다면 조회는 어떤 순서로 좁히는가?
• Prometheus와 Loki의 수집 방향은 어떻게 다른가?
• 별도 metric이 없는 서비스의 5xx 비율을 로그로 구하려면 LogQL을 어떻게 쓰는가?

출처