[클라우드 네이티브] 5편: Fluent Bit와 Loki, 가볍고 강력한 로그 모니터링 맛보기

1~2 편에서는 ELK 스택을 통한 로깅 아키텍처를, 3~4편에서는 Prometheus를 이용한 메트릭 고가용성을 다뤄보았다.

운영을 하다가 초당 수만 줄의 로그를 처리하기 위해 Elasticsearch 클러스터를 계속 키우는 것은 비용과 운영 측면에서 큰 부담이 될 수 있다.

 

그래서 이번 5편에서는 저비용 고효율의 로깅 스택인 Loki를 구축해본다.

 

1. Loki는 ELK와 어떤 부분이 다른지

ELK의 경우 매우 강력한 도구지만, 반대로 너무 무거운 도구이긴하다.

 

모든 것을 인덱싱할 것인가?

ELK와 Loki의 가장 큰 차이는 "무엇을 인덱싱하는가?"에 있다.

• ELK: 로그의 모든 단어를 인덱싱한다. 검색은 빠르지만, 로그 양이 늘어나면 인덱스 크기가 비대해져 SSD 비용이 기하급수적으로 상승한다.
• Loki: 로그 본문은 건드리지 않고, 이미지에서 확인한 namespace, pod같은 라벨만 인덱싱한다.

인덱스 크기가 ELK대비 1% 수준으로 작으며, 로그 원본은 Thanos처럼 S3에 압축 저장하여 비용을 극적으로 절감할 수 있다.

 

Grafana를 사용하고 있나?

만약 메트릭 정보를 Grafana로 보고 있다면 Loki만 올려서 그대로 사용할 수 있다.

관리포인트가 줄어 인프라 관리 비용이 감소한다.

 

Kafka 없는 고가용성

전통적인 대규모 ELK 환경에서는 로그 유실을 막기 위해 앞에 Kafka를 두는 것이 표준이었다.

 

하지만 Fluent Bit는 자체 디스크 버퍼링 기능을 갖추고 있어, Loki가 잠시 멈춰도 에이전트가 로그를 노드 디스크에 보관했다가 전송한다.

그렇기에 무거운 Kafka 클러스터 없이도 충분한 고가용성을 확보할 수 있다.

 

2.  인프라 구성

먼저 차트 의존성을 추가한다. Loki를 단독으로 올리기보다 loki-stack을 활용하면 Grafana와의 연동이 훨씬 매끄럽다.

dependencies:
  - name: loki-stack
    version: 2.10.2
    repository: "https://grafana.github.io/helm-charts"
  - name: fluent-bit
    version: 0.48.x
    repository: "https://fluent.github.io/helm-charts"

 

그다음 values.yaml 설정을 진행한다.

일단 사용해보는 것으로 Host정보를 하드코딩 하고 진행한다.

loki-stack:
  loki:
    enabled: true
    persistence:
      enabled: true
      size: 10Gi

fluent-bit:
  enabled: true
  config:
    service: |
      [SERVICE]
          storage.path              /var/log/fluent-bit/storage
          storage.sync              normal
          storage.checksum          off
          storage.backpressure_mem_limit 5M

    filters: |
      [FILTER]
          Name                kubernetes
          Match               kube.*
          Merge_Log           On
          Keep_Log            Off
          K8S-Logging.Parser  On
          K8S-Logging.Exclude Off

    outputs: |
      [OUTPUT]
          Name   loki
          Match  *
          Host   infra-loki.infra.svc.cluster.local
          Port   3100
          Labels job=fluent-bit, namespace=$kubernetes['namespace_name'], container=$kubernetes['container_name'], pod=$kubernetes['pod_name']

 

Fluent Bit은 Filebeat와 동일한 Input Path(/var/log/containers/*.log)를 기본으로 사용하므로 경로 설정은 따로 필요 없다.

대신 Loki가 검색 인덱스로 사용하는 'Labels'를 우리 인프라의 메트릭 체계와 동일하게 맞춰주어야 한다.

 

3. 통합 관측 Grafana

 

로그 시스템을 구축하고 나서 단순히 텍스트로만 나열한다면 ELK보다 기능이 부족한 느낌이 있다.

Loki는 이미 구축된 Thanos 메트릭과 결합하여 사용이 가능하다.

 

4. 마치며: 어떤 것을 선택해야 할까?

지금까지 고가용성 로깅(ELK)과 메트릭(Thanos), 그리고 가벼운 로깅(Loki)까지 모두 살펴보았다.

사용해보고 난 후 각 특징에 따라 사용 여부를 판단해야 할 것으로 생각된다.

 

 

Loki를 선택해야 하는 이유

Loki는 "예상된 에러의 빈도와 패턴"을 분석하는데 최적화 되어있다.

Prometheus 메트릭을 오버레이하여 에러 시점에 요청량이 많았는지, CPU가 튀었는지 즉시 확인하고 싶을 때 좋다.

또한, 로그 양이 많아지면 모든 단어를 Index하지 않아 인프라 비용을 최소화 할 수 있다.

이미 Prometheus와 Grafana를 사용하고 있다면, 관리 포인트를 단일화하여 운영 리소스를 줄일 수 있다.

 

ELK를 선택해야 하는 이유

반면, 로그의 텍스트를 뜯어서 분석해야 하는 상황이라면 ELK가 여전히 강력하다.

텍스트를 뜯어 역색인을 설정하는 방식이 매우 강력하긴 하다.

예를 들어 특정 유저의 ID가 포함된 모든 로그를 빠르게 찾아야 하는 경우 ELK가 훨씬 더 빠르고 편리하다.

 

둘다 각자만의 장점이 있어서 필자의 경우 어떤 하나를 정해놓고 사용하지는 않을 것 같다.