[NCP] NKS로 개발환경 구성하기 Chapter 5. Loki, Promtail, Grafana를 활용한 로그 통합 모니터링 구축 - Feat Loki-Stack

서론

loki-stack은 grafana labs에서 좀 더 쉽게 loki-promtail-grafana 스택을 구축할 수 있도록 개발한 하나의 스택입니다. 때문에 loki-stack을 활용한 통합 모니터링 구축은 정말 쉽습니다. 다만 하나의 클러스터에 모든 자원이 설치되기 때문에, 현업에서 사용하기에는 추천할 수 없는 방법이라고 생각하였습니다. 

 

본 포스팅에서는 loki-stack을 활용해서 하나의 클러스터에 통합 모니터링을 구축하는 방법부터 시작하여, 두 개 이상의 클러스터에서 (mgt-cluster 및 dev-cluster) 알맞은 소프트웨어를 설치하여 그 상호작용을 통해 제가 Loki-promtail-grafana 스택을 구축한 방법을 포스팅해보려 합니다.

 

dev-cluster 및 mgt-cluster가 궁금하신 분들은 이전 포스팅을 참고해 주시기 바랍니다.

 

[이전글]

[NCP] NKS로 개발환경 구성하기 Chapter 4. Service, Ingress, Ingress Controller를 이용한 DNS의 네트워킹 구성 w

---

본론

1. ELK/EFK, Loki-Promtail-Grafana 스택의 장단점

최근 Kubernetes 클러스터의 로그 모니터링 및 분석 도구로 ELK/EFK 스택이 널리 사용되지만, 저는 Loki-Promtail-Grafana 스택을 선택했습니다. 그 이유는 여러 측면에서 보다 경량화되고 운영이 용이하며, 특히 Kubernetes 환경에 최적화되어 있기 때문입니다.

 

1-1. ELK/EFK 스택의 장점

1. 강력한 검색 및 분석 기능
   • ElasticSearch를 기반으로 하여 복잡한 쿼리와 필터링, 그리고 대규모 로그 데이터에 대한 빠른 검색이 가능합니다.
   • Kibana를 활용한 다양한 시각화 및 대시보드 구성으로 심도 있는 로그 분석이 용이합니다.
2. 확장성과 유연성
   • 대량의 로그 데이터 처리에 적합하며, 확장성이 뛰어나 대규모 클러스터에서도 안정적인 운영이 가능합니다.
3. 다양한 플러그인과 생태계
   • Elastic Stack은 다양한 플러그인과 오픈소스 도구와의 연동이 잘 되어 있어 커스터마이징이 가능합니다.

1-2. ELK/EFK 스택의 단점

1. 높은 리소스 소비
   • ElasticSearch와 Kibana는 메모리와 CPU 등 리소스를 많이 사용합니다. 특히 Kubernetes와 같이 리소스 제약이 있는 환경에서는 부담이 될 수 있습니다.
2. 운영 및 유지보수의 복잡성
   • 클러스터 구성, 인덱스 관리, 샤딩 및 리플리카 설정 등 운영에 필요한 관리 포인트가 많아 초기 설정 및 유지보수에 많은 노력이 필요합니다.
3. 설정 및 최적화의 어려움
   • 효율적인 로그 저장 및 검색을 위해서는 복잡한 설정과 주기적인 최적화가 필요해 운영 부담이 늘어납니다.

1-3. Loki-Promtail-Grafana 스택의 장점

 

1. 경량화된 로그 저장소
   • Loki는 로그 메시지를 그대로 저장하면서 메타데이터(라벨)를 이용해 인덱싱 하기 때문에, ElasticSearch처럼 모든 로그를 인덱싱 하지 않아 리소스 소비가 적습니다.
2. Kubernetes 환경에 최적화
   • Promtail은 Kubernetes Pod 로그 수집에 특화되어 있으며, 자동으로 라벨을 부여하여 로그를 손쉽게 분류할 수 있습니다.
   • Pod 기반의 동적 환경에서도 로그 수집이 원활하게 이루어집니다.
3. 쉬운 설치와 운영
   • 설정이 상대적으로 단순하며, 클러스터에 부담을 주지 않아 운영과 유지보수가 용이합니다.
   • Grafana와의 네이티브 연동을 통해 시각화 대시보드 구성이 매우 직관적입니다.
4. 비용 효율성
   • 불필요한 인덱싱 비용과 리소스 소비가 적어, 클러스터 리소스를 보다 효율적으로 사용할 수 있습니다.

1-4. Loki-Promtail-Grafana 스택의 단점

 

• 제한적인 검색 기능
  • ElasticSearch 기반의 강력한 쿼리 기능에 비해, Loki는 메타데이터 기반 검색으로 일부 복잡한 로그 분석에는 한계가 있을 수 있습니다.
• 고급 분석 기능 부재
  • 로그의 심층 분석이나 머신 러닝 기반의 이상 징후 탐지 등 고급 기능은 별도의 도구나 추가 개발이 필요합니다.

 

---

 

2. 제가 Loki 스택을 선택한 이유

 

1. Kubernetes 네이티브 통합
   • Kubernetes 환경에서는 Pod 로그가 빠르게 증발(에페멀)되기 때문에, 로그 수집 에이전트인 Promtail이 Pod 메타데이터를 그대로 활용하여 로그를 수집하는 방식이 매우 효율적입니다.
   • 클러스터 전체에 대한 로그 모니터링을 간편하게 설정할 수 있습니다.
2. 리소스 최적화 및 운영 효율성
   • ElasticSearch를 운영하기 위한 추가적인 인프라 부담 없이, 로그 저장과 검색에 필요한 리소스 소비를 최소화할 수 있습니다.
   • 운영 및 유지보수 측면에서 단순함은 실제 프로덕션 환경에서 큰 장점으로 작용합니다.
3. Grafana와의 완벽한 통합
   • NKS에서는 이미 Grafana를 기본 노드 모니터링 툴로 제공해주고 있었습니다. 때문에 동일한 대시보드 환경 내에서 로그와 메트릭을 통합해 볼 수 있어 운영 효율성을 높일 수 있다고 판단했습니다.
4. 비용 효율성
   • 클라우드나 온프레미스 환경에서 리소스 비용이 중요한 경우, 불필요한 인덱싱 오버헤드를 줄인 Loki의 경량화된 특성이 매우 매력적입니다.

 

 

 

 

ELK/EFK 스택은 강력한 검색과 분석 기능을 제공하지만, 리소스 사용량, 운영 복잡성 등에서 단점이 있습니다. 반면, Loki-Promtail-Grafana 스택은 Kubernetes 환경에 최적화된 경량화된 로그 솔루션으로, 설치와 운영이 간편하고 비용 효율적입니다.
저는 이러한 이유로 Kubernetes 클러스터에 Loki 스택을 선택하게 되었으며, 이를 통해 보다 안정적이고 효율적인 통합 모니터링 시스템을 구축할 수 있었습니다.

 

---

 

3. Loki, Promtail, Grafana 각각의 설명

로키, 프롬테일, 그라파나 각각 어떤 역할을 담당하는 친구들인지 먼저 간단하게 알아보겠습니다.

프롬테일은 각 노드(서버)에서 쿠버네티스 파드에서 출력되는 로그들을 수집하여 로키라는 친구에게 보내주는 역할을 합니다.

로키는 프롬테일로부터 받은 로그들을 관리 및 보관하는 역할을 하게 됩니다.

그라파나는 로키와 연동하여 관리 및 보관되고 있는 로그들을 UI적으로 친숙하게 보여주어 모니터링을 용이하게 해주는 친구들입니다.

 

---

 

4. Loki-stack을 활용한 단일 클러스터에 통합 모니터링 구축

아래처럼 1개의 values.yaml 파일을 사용하여 loki-stack helm에 맞는 설정값들을 세팅할 수 있습니다. 저는 loki, promtail, grafana 만 사용하였지만 실제로는 prometheus, filebeat 등의 더 많은 오픈소스들을 활용할 수 있습니다.

 

loki:
  enabled: true
  isDefault: true
  url: http://{{(include "loki.serviceName" .)}}:{{ .Values.loki.service.port }}
  readinessProbe:
    httpGet:
      path: /ready
      port: http-metrics
    initialDelaySeconds: 45
  livenessProbe:
    httpGet:
      path: /ready
      port: http-metrics
    initialDelaySeconds: 45
  datasource:
    jsonData: "{}"
    uid: ""

promtail:
  enabled: true
  config:
    logLevel: info
    serverPort: 3101
    clients:
      - url: http://{{ .Release.Name }}:3100/loki/api/v1/push

grafana:
  enabled: true
  sidecar:
    datasources:
      label: ""
      labelValue: ""
      enabled: true
      maxLines: 1000
  image:
    tag: 10.3.3

위 파일을 작성하였다면, helm 명령어를 통해 grafana/loki-stack을 사용하여 원하는 네임스페이스에 통합 모니터링 툴을 설치할 수 있게 됩니다. 저는 monitoring이라는 namespace에 loki-stack이라는 이름으로 위에서 만들어놓은 values를 사용해 grafka/loki-stack을 설치하였습니다.

helm install loki-stack grafana/loki-stack --values ./loki-stack-values.yaml -n monitoring

helm에 대해서는 추후 자세히 포스팅하도록 하겠습니다. 지금은 그냥 helm이라는 쿠버네티스 전용 오픈소스 패키지 매니저라고만 알고 계시면 될 것 같습니다.

 

위 명령어를 통해서 내가 원하는 클러스터에 로키, 프롬테일, 그라파나 모두를 설치하고 각각 로그 수집, 보존 및 관리, 모니터링할 수 있게 연관 짓는 것까지 모든 것을 끝맞힐 수 있게 되었습니다.

---

 

5. Loki-stack을 추천할 수 없는 이유

5-1. 쿠버에서 로그를 관리하는 방법

쿠버네티스에서 각 파드가 실행 중인 Node에 Log가 저장됩니다. 저장 위치는 /var/log/pods/{namespace}_{pod_name}/{container-name}/{count-number}. log 형식으로 저장됩니다. 하지만 위 위치로 접속하면 각 파드에 따라 디렉터리별로 나뉘어 저 저장되어 있기 때문에 로그를 한눈에 보기가 어렵긴 합니다.

 

때문에 이러한 로그들의 연결파일들을 모아놔 준 곳이 있는데 그곳이 /var/log/containers입니다. 이곳에 모든 pod에 대한 로그파일들이 {pod_name}_{namespace}_{container-name}. logs 형태로 존재하고 있습니다.

 

5-2. 프롬테일, 로키, 그라파나의 설치 노드

프롬테일은 k8s의 DaemonSets라는 오브젝트를 이용하여 설치됩니다. 때문에 각 노드별로 최소 1개는 무조건 설치가 되고, 해당 프롬테일이 위에서 이야기한 로그에 접근하여 로그들을 수집 및 로키로 전송할 수 있는 역할을 하게 되는 것입니다.

 

애플리케이션이 실행되는 파드가 존재하는 노드에서 로그를 수집하는 프롬테일이 설치되는 것은 어찌보면 당연합니다.

 

하지만, 어플리케이션이 실행 중인 파드가 존재하는 노드에 로그를 저장 및 보관하는 로키와 모니터링툴을 지원하는 그라파나가 설치되는 건 저는 아니라고 생각하였습니다.

 

혹여 많은 트래픽이 몰리거나 런타임 장애들이 연달아 발생하면서 해당 노드가 죽게 된다면 모니터링 자체를 할 수 없어지기 때문입니다. 그래서 첫 글에서 생성한 mgt-cluster를 활용하기로 하였습니다.

 

---

결론

다음 포스팅에서는 loki와 grafana는 mgt-cluster에 각각 설치하고, dev-cluster에 promtail을 설치하여 어떻게 로그를 mgt-cluster에 설치되어 있는 loki에게 보내고, 어떻게 grafana와 loki를 연동하는지, 그렇게 하여 전체적인 Loki-Promtail-Garafana 로그 통합 모니터링 스택을 구축하였는지 상세히 포스팅해 보도록 하겠습니다.