무색
기술블로그
에세이
연구
소개

무색

소프트웨어로 비즈니스의 가능성을 만듭니다. 웹·앱 개발, 음성 AI, 자동화 콘텐츠 제작까지 — 기술이 필요한 곳에 무색이 있습니다.

연락처

contact@museck.com

사업자 정보

상호: 무색

대표: 배성재

사업자등록번호: 577-58-00836

인천광역시 연수구 인천타워대로 323, 에이동 8층 801-802호 AB-132 (송도동, 송도 센트로드)

© 2026 무색. All rights reserved.
개인정보처리방침·이용약관·연락처
INCHEON, KR
홈랩 모니터링 — Prometheus에서 Loki로 전환
홈랩 삽질기
2026. 1. 1.

홈랩 모니터링, Prometheus 걷어내고 Loki로 갈아탄 이야기

lokiprometheusgrafanahomelabkubernetes

Prometheus, 홈랩에서는 과했다

홈랩 K8s 클러스터를 운영하면서 모니터링 스택을 고민할 때 가장 먼저 떠오르는 게 kube-prometheus-stack이다. Prometheus에 Grafana까지 한 방에 깔리고 Node Exporter와 kube-state-metrics도 다 따라온다. '모범 사례'라고 불리는 조합이니까 나도 처음엔 별 고민 없이 설치했다.

문제는 리소스였다. Node Exporter가 모든 노드에 DaemonSet으로 떠야 하고 kube-state-metrics도 따로 돌아가고 Prometheus 자체도 메모리를 꽤 잡아먹는다. 홈랩이라 노드 3대에 메모리가 넉넉지 않은데 모니터링 스택이 전체 리소스의 상당 부분을 차지하고 있었다. 정작 모니터링하려고 깐 것인데 모니터링 때문에 다른 워크로드가 밀려나는 상황이 된 거다.

그래서 실제로 뭘 보고 있었나

한 달쯤 운영하고 나서 돌아보니 Grafana 대시보드를 열어본 적이 거의 없었다. CPU 사용률 그래프나 메모리 추이 같은 메트릭 대시보드를 일상적으로 확인하는 일은 사실상 없었고, 실제로 내가 하던 건 Pod에 문제가 생겼을 때 로그를 검색하는 것뿐이었다.

그러고 보니 kubectl logs로 일일이 찾아보는 게 귀찮아서 모니터링 스택을 깔았던 건데 메트릭 수집이라는 무거운 기능이 끼어들면서 배보다 배꼽이 커진 셈이었다. 필요한 건 로그 검색이었고 메트릭은 없어도 됐다.

Loki + Promtail + Grafana, 경량 스택으로 전환

Prometheus를 들어내고 Loki 기반 로그 스택으로 교체했다. 구성은 단순하다.

  • Promtail - 모든 노드에서 Pod 로그를 수집하는 DaemonSet
  • Loki - 로그를 저장하고 검색하는 경량 로그 엔진
  • Grafana - Loki를 데이터소스로 연결해서 LogQL로 로그 검색

Loki는 SingleBinary 모드로 배포했다. 분산 모드(read/write/backend 분리)도 있지만 홈랩 규모에서 그런 건 과도하다. 단일 Pod 하나로 로그 수집과 검색을 전부 처리한다.

deploymentMode: SingleBinary
loki:
  auth_enabled: false
  commonConfig:
    replication_factor: 1
  storage:
    type: filesystem
  limits_config:
    retention_period: 168h  # 7일 보관
singleBinary:
  replicas: 1
  nodeSelector:
    node-role: infra
# 분산 모드 컴포넌트 비활성화
read:
  replicas: 0
write:
  replicas: 0
backend:
  replicas: 0

핵심 설정은 몇 가지 안 된다. auth_enabled: false로 인증을 끄고(내부망이니까) filesystem 스토리지에 7일 보관 기간을 두었다. S3 같은 오브젝트 스토리지 없이 로컬 디스크만으로 돌아간다. 캐시도 꺼 놓으면 메모리 사용량이 한층 더 줄어든다.

전환 결과는 만족스러웠다. Grafana의 Explore 화면에서 LogQL로 로그를 검색하는 것만으로 충분했다. {namespace="default"} |= "error" 같은 쿼리 한 줄이면 원하는 로그를 바로 찾을 수 있다. Prometheus 풀스택 대비 리소스 사용량도 눈에 띄게 줄었다.

인프라 상태 감시는 Pulse로 분리

메트릭을 전부 버린 건 아니다. Proxmox VM 상태나 K8s 노드 상태 정도는 한눈에 보고 싶었는데 이건 Prometheus보다 가벼운 방법이 있었다. Pulse라는 셀프호스팅 대시보드를 사용했다.

Pulse는 WSL Docker에서 실행하고 K8s 클러스터에서는 Traefik IngressRoute를 통해 HTTPS로 노출했다. 여기서 살짝 재밌는 패턴을 썼는데 K8s 외부에서 돌아가는 서비스(WSL Docker의 Pulse)를 클러스터 안에서 접근할 수 있게 수동 Endpoints를 만든 것이다.

apiVersion: v1
kind: Endpoints
metadata:
  name: pulse
  namespace: pulse
subsets:
  - addresses:
      - ip: 192.168.31.2  # Windows Host IP
    ports:
      - port: 7655

ExternalName 대신 IP를 직접 지정해서 DNS 의존성을 없앴다. 이 Endpoints에 Service를 연결하고 Traefik IngressRoute를 달면 pulse.xssh.org로 접근할 수 있게 된다. Pulse Agent는 K8s DaemonSet으로 배포해서 클러스터 정보를 Pulse에 보내는 구조다.

Proxmox 웹 UI도 프록시로 연결

인프라 관리 화면을 하나로 묶으려고 Proxmox 웹 UI도 K8s Traefik 뒤에 넣었다. Proxmox가 자체 서명 인증서(8006 포트)를 쓰기 때문에 Traefik에서 ServersTransport와 insecureSkipVerify를 설정해야 했다. 이걸 해두면 pve1.xssh.org나 pve2.xssh.org로 Proxmox 관리 화면에 바로 들어갈 수 있다.

도구 선택은 '뭘 보는가'부터

이번에 배운 건 단순하다. 모니터링 도구를 고를 때 '모범 사례'를 그대로 따르기보다 내가 실제로 뭘 보고 싶은지부터 생각해야 한다는 거다.

  • 로그 검색이 주 목적이면 Loki면 충분하다
  • VM이나 노드 상태는 가벼운 대시보드로 분리하면 된다
  • 풀스택 메트릭 수집은 규모가 커졌을 때 도입해도 늦지 않다

홈랩처럼 리소스가 제한된 환경에서는 역할별로 최적의 도구를 조합하는 게 하나의 만능 스택보다 효율적이다. Prometheus가 나쁜 도구라서 걷어낸 게 아니라 내 상황에서 필요 이상이었을 뿐이다. 적재적소가 답이었다.

자주 묻는 질문

홈랩에서 Prometheus 대신 Loki를 쓰는 이유는?
홈랩처럼 리소스가 제한된 환경에서 실제로 필요한 건 로그 검색인 경우가 많습니다. Loki는 메트릭 수집 없이 로그만 저장·검색하므로 Prometheus 풀스택 대비 메모리와 CPU 사용량이 크게 줄어듭니다.
Loki SingleBinary 모드와 분산 모드의 차이는?
SingleBinary는 단일 Pod에서 로그 수집과 검색을 모두 처리하는 방식이고, 분산 모드는 read/write/backend를 별도 Pod으로 분리합니다. 홈랩 규모에서는 SingleBinary가 설정이 간단하고 충분합니다.
K8s 외부 서비스를 클러스터 안에서 접근하려면?
Service와 수동 Endpoints를 생성해서 외부 IP를 직접 지정하면 됩니다. ExternalName 대신 IP를 쓰면 DNS 의존성 없이 Traefik IngressRoute로 HTTPS 접근이 가능합니다.
홈랩 삽질기(5/19)
Prev

Cloudflare Tunnel로 홈랩을 인터넷에 공개한 이야기

Next

MetalLB L2 Failover가 안 되던 날 - Cilium과 ARP의 함정