DevOps/Docker

[Docker] Docker Compose로 Grafana / Prometheus / Loki 로컬 테스트 환경 구성하기

러러 2026. 2. 10. 22:41

애플리케이션 개발과 운영에서 모니터링은 필수적인 요소이다. 하지만 Grafana, Prometheus, Loki와 같은 강력한 모니터링 도구들을 처음부터 완벽하게 구축하는 것은 결코 쉬운 일이 아니다. 특히 로컬 개발 환경이나 소규모 테스트 환경에서는 복잡한 설정보다는 빠르고 쉽게 동작하는 모니터링 스택이 필요하다.

위 환경을 AWS EC2 (Amazon Linux) 환경에서 Docker Compose를 활용하여 Grafana, Prometheus, Loki 스택을 구축하고, 나아가 Spring Boot 애플리케이션의 메트릭과 로그를 연동하는 방법을 알아보자.

목표

  • AWS EC2 (Amazon Linux 2023) 인스턴스 위에서
  • Docker Compose를 사용하여
  • Grafana, Prometheus, Loki를 단일 인스턴스에 통합 구축
  • 주로 테스트 및 개발 목적으로, 복잡한 운영 환경보다는 학습에 중점
  • 로컬 또는 EC2 내에서 실행되는 서비스(예: Spring Boot, Node.js)의 메트릭과 로그를 손쉽게 수집하고 시각화할 수 있도록 한다.

전체 아키텍처 개요

구축될 모니터링 스택의 아키텍처는 다음과 같다.

[Local/Remote Service (e.g., Spring Boot)]
  ├─ /actuator/prometheus  ─ (HTTP GET) ─▶ Prometheus (메트릭 수집)
  ├─ Standard Output / Docker Logs ─ (File Beat) ─▶ Promtail ─▶ Loki (로그 수집)
  └─ 시각화/대시보드 ─────────────── (HTTP) ───────────▶ Grafana

[AWS EC2 단일 인스턴스]
  ├─ Prometheus: 메트릭 저장 및 쿼리
  ├─ Loki: 로그 저장 및 쿼리
  ├─ Promtail: Docker 컨테이너 로그 수집 에이전트
  └─ Grafana: 메트릭/로그 시각화 대시보드
  • Prometheus: 애플리케이션에서 노출하는 메트릭을 주기적으로 Pull 방식으로 수집
  • Loki: Promtail을 통해 수집된 애플리케이션 로그를 저장하고 인덱싱
  • Promtail: EC2 인스턴스의 Docker 데몬이 관리하는 컨테이너들의 로그 파일을 읽어 Loki로 전송하는 에이전트 역할
  • Grafana: Prometheus와 Loki의 데이터를 활용하여 아름다운 대시보드를 구축하고, 메트릭과 로그를 통합적으로 시각화

인스턴스 사양 및 선택 이유

비용 효율적인 t4g.small 인스턴스를 사용

  • Instance Type: t4g.small (ARM 기반 Graviton2 프로세서)
  • vCPU: 2
  • RAM: 2GB
  • OS: Amazon Linux 2023
  • Disk: gp3 8GB

선택 이유: t4g.small은 ARM 아키텍처를 기반으로 하여 t3.small 등 x86 기반 인스턴스보다 뛰어난 가성비를 제공하고 테스트 및 개발 환경에서는 이 정도 사양으로도 충분하며, 비용 부담을 최소화할 수 있다.

메모리 부족을 방지하는 Swap 설정

Prometheus와 Loki는 평상시에는 메모리 사용량이 크게 높지 않지만, 특정 작업을 수행할 때 순간적으로 많은 메모리를 필요로 한다. 예를 들어, Prometheus는 내부 시계열 데이터를 정리할 때, Loki는 대량의 로그를 묶어 저장할 때 많은 메모리를 필요로 한다.

2GB와 같이 메모리가 제한적인 환경에서는 이러한 순간적인 메모리 사용량 증가를 감당하지 못해 OOM Killer (Out-Of-Memory Killer)가 동작하여 메모리를 많이 사용하는 프로세스를 강제로 종료시킬 수 있다. 이는 Docker 컨테이너가 예기치 않게 종료되는 주된 원인이 된다.

테스트 환경에서는 잠시 시스템이 느려지는 것은 큰 문제가 아니지만, 컨테이너가 자꾸 죽는 것은 굉장히 번거로운 일이다. 따라서 Swap 공간을 활성화하여 부족한 물리 메모리를 보완하고, swappiness 값을 낮게 설정하여 평소에는 RAM을 최우선으로 사용하되, 정말 필요할 때만 디스크의 Swap을 사용하도록 설정한다.

5-1. Swap 파일 생성 및 활성화

# 1. 2GB 크기의 swap 파일을 생성 (bs=1M은 1MB 단위, count=2048은 2048번 반복)
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

# 2. swap 파일의 권한을 root 전용으로 제한 (보안상 필수)
sudo chmod 600 /swapfile

# 3. 일반 파일을 리눅스 swap 영역으로 포맷
sudo mkswap /swapfile

# 4. 생성한 swap 파일을 즉시 활성화
sudo swapon /swapfile

5-2. 재부팅 후에도 Swap 유지 설정

# 서버 재부팅 시에도 /swapfile을 자동으로 swap으로 사용하도록 /etc/fstab에 등록
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

5-3. swappiness 값 조정

swappiness는 리눅스 커널이 스왑 공간을 얼마나 적극적으로 사용할지 결정하는 값.
값이 낮을수록 물리 메모리(RAM)를 최대한 사용하려 하고, 높을수록 스왑 공간을 일찍부터 사용한다.

# 1. 현재 세션에서 swappiness 값을 10으로 설정
#    (RAM이 10%만 남았을 때부터 swap을 사용하기 시작)
sudo sysctl -w vm.swappiness=10

# 2. 재부팅 후에도 swappiness 설정이 유지되도록 /etc/sysctl.conf에 영구 설정
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
swappiness 값 의미
0 물리 메모리를 최대한 활용하며, 거의 스왑을 사용하지 않음 (단, OOM 발생 가능성 증가)
10 물리 메모리가 상당히 부족해질 때만 스왑 사용 (테스트 서버 권장)
60 기본값, 스왑을 비교적 적극적으로 사용
100 물리 메모리보다 스왑을 우선 사용

Docker 설치

모니터링 스택을 컨테이너로 관리하기 위해 Docker를 설치한다.

# 1. 시스템 패키지 목록을 최신 상태로 업데이트한다.
sudo dnf update -y

# 2. Docker 엔진을 설치한다.
sudo dnf install -y docker

# 3. Docker 서비스를 즉시 시작한다.
sudo systemctl start docker

# 4. 서버 재부팅 시 Docker가 자동으로 실행되도록 설정한다.
sudo systemctl enable docker

매번 sudo docker ... 명령어를 입력하는 것은 번거롭기에 현재 사용자에게 docker 그룹 권한을 부여하여 sudo 없이 Docker 명령어를 사용할 수 있도록 설정한다.

# 현재 사용자($USER)를 'docker' 그룹에 추가한다.
sudo usermod -aG docker $USER

Docker Compose 설치 (v2)

Prometheus, Grafana, Loki처럼 여러 컨테이너가 연동되어 동작하는 환경에서는 Docker Compose가 필수적이다.

# 1. Docker CLI 플러그인을 설치할 디렉토리를 생성한다.
sudo mkdir -p /usr/local/lib/docker/cli-plugins

# 2. Docker Compose v2 실행 파일을 다운로드한다.
#    t4g 인스턴스는 ARM 기반이므로 'aarch64' 버전을 다운로드한다.
sudo curl -SL https://github.com/docker/compose/releases/download/v2.25.0/docker-compose-linux-aarch64 -o /usr/local/lib/docker/cli-plugins/docker-compose

# 3. 다운로드한 파일에 실행 권한을 부여한다.
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

설치 확인:

docker compose version

위 명령어를 실행했을 때 Docker Compose 버전 정보가 출력되면 성공적으로 설치된 것이다.

디렉토리 구조

모니터링 스택의 설정 파일들을 체계적으로 관리하기 위해 다음과 같은 디렉토리 구조를 생성한다.

mkdir -p monitoring/{prometheus,grafana,loki,promtail}
cd monitoring

이 구조는 각 컴포넌트의 설정 파일을 명확히 분리하여 유지보수를 용이하게 한다.

monitoring/
 ├─ prometheus/   # Prometheus 서버 설정 파일 (prometheus.yml)
 ├─ grafana/      # Grafana 대시보드, 데이터소스 등 설정 (운영 환경에서 주로 사용)
 ├─ loki/         # Loki 서버 설정 파일 (loki-config.yml)
 └─ promtail/     # Promtail 로그 수집 에이전트 설정 파일 (promtail-config.yml)

Prometheus 설정

prometheus/prometheus.yml 파일을 생성하여 Prometheus가 메트릭을 어떻게 수집할지 정의한다.

# prometheus/prometheus.yml
global:
  scrape_interval: 30s # 메트릭 수집 주기 (30초마다)
  evaluation_interval: 30s # 알람 규칙 평가 주기 (메트릭 수집 주기와 일치시키는 것이 일반적)

scrape_configs:
  - job_name: "local-services" # 스크랩 작업의 이름
    static_configs:
      - targets:
          # Spring Boot 애플리케이션의 /actuator/prometheus 엔드포인트를 지정한다.
          # 'host.docker.internal'은 Docker 컨테이너가 호스트 머신에 접근할 때 사용하는 특수 호스트명
          # 로컬 개발 환경에서 Spring Boot 앱이 8080 포트에서 실행 중이라면, 이 설정으로 메트릭을 수집
          - host.docker.internal:8080
            # 만약 EC2 인스턴스 내에서 다른 Docker 컨테이너의 메트릭을 수집하려면,
            # 해당 컨테이너의 서비스 이름을 사용하거나 내부 IP를 지정하여 사용
          # - 호스팅서버주소:8080

설정 의미 상세

  • global.scrape_interval: Prometheus가 설정된 타겟으로부터 메트릭을 가져오는 주기. 너무 짧게 설정하면 리소스 사용량이 증가할 수 있다.
  • global.evaluation_interval: 알람 규칙(Alerting Rules)이 평가되는 주기.
  • scrape_configs: 메트릭을 수집할 대상을 정의하는 섹션.
    • job_name: 이 스크랩 설정에 대한 식별자 역할을 한다. Grafana에서 쿼리할 때 유용.
    • static_configs.targets: 메트릭을 수집할 서버(타겟)의 주소 목록.

Loki 설정: 로그 수집 및 저장

loki/loki-config.yml 파일을 생성하여 Loki 서버의 동작 방식을 정의한다.

# loki/loki-config.yml
auth_enabled: false # 테스트 환경이므로 인증 비활성화

server:
  http_listen_port: 3100 # Loki 서버가 수신할 HTTP 포트

common:
  path_prefix: /loki # Loki 데이터 파일 저장 경로 접두사
  storage:
    filesystem:
      chunks_directory: /loki/chunks # 로그 청크 데이터 저장 디렉토리
      rules_directory: /loki/rules # Loki 알람 규칙 저장 디렉토리
  replication_factor: 1 # 복제 계수 (단일 인스턴스이므로 1)
  ring:
    kvstore:
      store: inmemory # 링 데이터를 메모리에 저장 (단일 인스턴스용)

schema_config: # 로그 저장 스키마 설정
  configs:
    - from: 2026-02-01 # 스키마 적용 시작일
      store: tsdb # 스토어 타입 (TSDB는 시계열 데이터베이스)
      object_store: filesystem # 객체 스토리지 (파일 시스템 사용)
      schema: v13 # 스키마 버전
      index:
        prefix: index_ # 인덱스 파일 접두사
        period: 24h # 인덱스 주기 (24시간마다 새 인덱스 생성)

limits_config:
  retention_period: 72h # 로그 보관 기간 (72시간 = 3일)

설정 의미 상세

  • auth_enabled: false: 테스트 환경에서는 보안을 위해 인증을 비활성화한다. 운영 환경에서는 반드시 인증을 활성화해야 한다.
  • server.http_listen_port: Loki가 Promtail로부터 로그를 수신하고 Grafana에 쿼리 응답을 보낼 포트.
  • common.storage.filesystem: Loki의 데이터 저장 방식을 파일 시스템으로 지정하고, 관련 디렉토리를 정의한다.
  • schema_config: Loki가 로그를 어떻게 저장하고 인덱싱할지 정의한다. tsdb와 filesystem 조합은 소규모 환경에 적합.
  • limits_config.retention_period: 매우 중요한다. 로그 데이터를 얼마나 오래 보관할지 설정한다. 여기서는 72시간(3일)로 설정. 테스트 환경에서는 디스크 공간이 제한적이고 오래된 로그를 자주 볼 필요가 없으므로, 이 값을 짧게 설정하는 것이 디스크 사용량을 효율적으로 관리하는 데 도움이 된다.

Promtail 설정: 로그 수집 에이전트

promtail/promtail-config.yml 파일을 생성하여 Promtail이 로그를 어떻게 수집하고 Loki로 전송할지 정의한다.

# promtail/promtail-config.yml
server:
  http_listen_port: 9080 # Promtail의 HTTP 서버 포트 (디버깅용)
  grpc_listen_port: 0 # gRPC 서버 비활성화 (필요 없으면 0)

positions:
  filename: /tmp/positions.yaml # Promtail이 마지막으로 읽은 로그 위치를 기록하는 파일

clients:
  - url: http://loki:3100/loki/api/v1/push # 로그를 전송할 Loki 서버의 주소

scrape_configs:
  - job_name: docker-logs # 이 로그 수집 작업의 이름
    static_configs:
      - targets:
          - localhost # Promtail은 로컬 파일 시스템에서 로그를 읽는다.
        labels:
          job: docker # Loki에서 이 로그를 필터링할 때 사용할 레이블
          __path__: /var/lib/docker/containers/*/*.log # Docker 컨테이너 로그 파일의 실제 경로

설정 의미 상세

  • clients.url: Promtail이 로그를 전송할 Loki 서버의 HTTP 주소입니다. Docker Compose 내부에서는 서비스 이름을 loki로 지정했으므로, http://loki:3100/loki/api/v1/push로 접근한다.
  • scrape_configs: 로그를 수집할 대상을 정의한다.
    • job_name: Loki/Grafana에서 로그를 구분하고 쿼리할 때 사용되는 식별자이다.
    • static_configs.targets: localhost: Promtail은 자신이 실행되는 EC2 인스턴스의 로컬 파일 시스템에서 로그를 읽기 때문에 localhost를 지정한다.
    • labels: 수집된 로그에 붙여질 메타데이터. 이 레이블을 통해 Grafana에서 특정 로그 스트림을 쉽게 필터링하고 검색할 수 있다.
    • __path__: /var/lib/docker/containers/*/*.log: 이 경로가 가장 중요하다.
      Docker 컨테이너의 표준 출력(stdout/stderr) 로그는 EC2 인스턴스의 /var/lib/docker/containers/<container-id>/<container-id>-json.log 경로에 파일 형태로 저장되고, Promtail은 이 경로에 있는 모든 로그 파일을 읽어서 Loki로 전송한다.
      현재는 컨테이너 로그를 보내지만 애플리케이션 로그를 보낸다면, 애플리케이션 로그 저장 경로를 입력해주면 된다.

Spring Boot 애플리케이션 연동: 메트릭과 로그

이제 로컬 또는 EC2 인스턴스 내에서 실행되는 Spring Boot 애플리케이션을 우리의 모니터링 스택에 연동하는 방법을 알아보자.

1. Prometheus 메트릭 연동 (Micrometer + Actuator)

Spring Boot 애플리케이션에서 Prometheus 메트릭을 노출하기 위해서는 micrometer-registry-prometheus와 spring-boot-starter-actuator 의존성이 필요하다.

build.gradle 에 의존성 추가:

// build.gradle
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
    implementation 'io.micrometer:micrometer-registry-prometheus'
    // ... 다른 의존성들
}

application.yml 또는 application.properties 설정:

application.yml 파일에 다음 설정을 추가하여 /actuator/prometheus 엔드포인트를 노출하고, 다른 액추에이터 엔드포인트들도 웹으로 접근 가능하게 한다.

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: prometheus,health,info # prometheus 엔드포인트 포함
  metrics:
    export:
      prometheus:
        enabled: true # Prometheus 메트릭 노출 활성화

작동 방식:

  1. Spring Boot 애플리케이션이 시작되면 micrometer-registry-prometheus가 다양한 시스템(JVM, CPU, 디스크 등) 및 Spring 애플리케이션 내부 메트릭을 자동으로 수집한다.
  2. /actuator/prometheus 엔드포인트로 HTTP 요청이 들어오면, 이 수집된 메트릭들을 Prometheus가 이해할 수 있는 텍스트 기반 형식으로 응답한다.
  3. 앞서 설정한 Prometheus(prometheus/prometheus.yml)는 scrape_configs에 정의된 host.docker.internal:8080 (또는 실제 애플리케이션 주소)으로 주기적으로 요청을 보내 메트릭을 수집한다.

2. Loki 로그 연동 (표준 출력/Docker Logs 이용)

Spring Boot 애플리케이션의 로그를 Loki로 보내는 가장 간단한 방법은 애플리케이션이 표준 출력(stdout)으로 로그를 남기도록 하고, 이 로그를 Docker 컨테이너가 파일로 저장하도록 하는 것이다. 이후 Promtail이 이 Docker 로그 파일을 읽어 Loki로 전송한다.

Spring Boot 로그 설정:

기본적으로 Spring Boot는 spring-boot-starter-logging (Logback 사용)을 포함하고 있으며, 별도의 설정이 없다면 콘솔(표준 출력)로 로그를 출력한다. 대부분의 경우 추가적인 로그 설정 없이 바로 Docker 컨테이너에 의해 파일로 저장됩니다.

만약 application.yml 등에서 로그 파일로 직접 출력하도록 설정했다면, 해당 파일을 Promtail이 접근할 수 있는 경로로 변경하거나, Docker 컨테이너의 stdout으로 다시 라우팅하는 방법을 고려해야 한다.

작동 방식:

  1. Spring Boot 애플리케이션은 Logback 등을 통해 로그를 표준 출력(콘솔)으로 보냅니다.
  2. 애플리케이션이 Docker 컨테이너 내에서 실행되면, Docker 데몬은 이 표준 출력 로그를 /var/lib/docker/containers/<container-id>/<container-id>-json.log 경로의 파일로 저장한다.
  3. EC2 인스턴스에 배포된 Promtail은 이 /var/lib/docker/containers/*/*.log 경로를 감시하며, 새로운 로그 라인이 추가될 때마다 이를 읽어 Loki로 전송한다.

docker-compose.yml: 모든 서비스 통합 정의

monitoring 디렉토리 내에 docker-compose.yml 파일을 생성한다.

# monitoring/docker-compose.yml
version: "3.9" # Docker Compose 파일 형식 버전 지정

services:
  prometheus: # Prometheus 서비스 정의
    image: prom/prometheus:latest # Prometheus 최신 이미지 사용
    container_name: prometheus # 컨테이너 이름 지정
    command: # Prometheus 실행 명령어
      - "--config.file=/etc/prometheus/prometheus.yml" # 설정 파일 경로
      - "--storage.tsdb.retention.time=3d" # 메트릭 보관 기간 (3일)
      - "--storage.tsdb.retention.size=5GB" # 메트릭 최대 저장 공간 (5GB)
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro # 호스트의 설정 파일을 컨테이너에 마운트 (읽기 전용)
    ports:
      - "9090:9090" # 호스트의 9090 포트를 컨테이너의 9090 포트에 연결 (Prometheus UI)

  loki: # Loki 서비스 정의
    image: grafana/loki:latest # Loki 최신 이미지 사용
    container_name: loki # 컨테이너 이름 지정
    volumes:
      - ./loki/loki-config.yml:/etc/loki/config.yml:ro # 호스트의 설정 파일을 컨테이너에 마운트 (읽기 전용)
    command: -config.file=/etc/loki/config.yml # Loki 실행 명령어
    ports:
      - "3100:3100" # 호스트의 3100 포트를 컨테이너의 3100 포트에 연결 (Loki API)

  promtail: # Promtail 서비스 정의
    image: grafana/promtail:latest # Promtail 최신 이미지 사용
    container_name: promtail # 컨테이너 이름 지정
    volumes:
      - ./promtail/promtail-config.yml:/etc/promtail/config.yml:ro # 호스트의 설정 파일을 컨테이너에 마운트 (읽기 전용)
      # 호스트의 Docker 컨테이너 로그 디렉토리를 Promtail 컨테이너에 마운트한다. (읽기 전용)
      # 이를 통해 Promtail이 실제 로그 파일을 읽을 수 있다.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
    command: -config.file=/etc/promtail/config.yml # Promtail 실행 명령어
    depends_on: # Loki 서비스가 먼저 시작되어야 한다.
      - loki

  grafana: # Grafana 서비스 정의
    image: grafana/grafana:latest # Grafana 최신 이미지 사용
    container_name: grafana # 컨테이너 이름 지정
    ports:
      - "3000:3000" # 호스트의 3000 포트를 컨테이너의 3000 포트에 연결 (Grafana UI)
    depends_on: # Prometheus와 Loki 서비스가 먼저 시작되어야 한다.
      - prometheus
      - loki

docker-compose.yml 상세 설명

  • version: "3.9": Docker Compose 파일 형식 버전을 지정한다.
  • services: 이 섹션 아래에 각 컨테이너 서비스들을 정의한다.
    • image: 사용할 Docker 이미지와 태그를 지정한다 (:latest는 최신 버전을 의미).
    • container_name: 컨테이너의 이름을 지정하여 식별하기 쉽게 한다.
    • command: 컨테이너가 실행될 때 수행할 명령어를 정의한다. 주로 설정 파일 경로를 지정한다.
    • volumes: 호스트 머신의 경로와 컨테이너 내부의 경로를 연결(마운트)한다. ro는 읽기 전용을 의미한다.
      • Prometheus, Loki, Promtail의 설정 파일을 호스트에서 작성하고 컨테이너 내부로 주입한다.
      • Promtail의 /var/lib/docker/containers:/var/lib/docker/containers:ro 볼륨 마운트는 필수적입니다. Promtail이 호스트의 Docker 로그 파일을 읽으려면 이 디렉토리에 접근할 수 있어야 한다.
    • ports: 호스트 머신의 포트와 컨테이너 내부의 포트를 매핑하여 외부에서 서비스에 접근할 수 있도록 한다.
    • depends_on: 서비스 간의 의존성을 정의한다. 예를 들어 Grafana는 Prometheus와 Loki가 먼저 실행되어야 정상적으로 동작할 수 있다.

스택 실행 및 확인

이제 모든 설정이 완료되었습니다. monitoring 디렉토리에서 다음 명령어를 실행하여 모니터링 스택을 시작한다.

# 모든 서비스를 백그라운드(-d)로 실행한다.
docker compose up -d

상태 확인

# 실행 중인 Docker Compose 서비스 목록을 확인한다.
docker compose ps

모든 서비스(prometheus, loki, promtail, grafana)의 상태가 Up으로 표시되면 성공적으로 실행된 것이다.

로그 확인

# 모든 서비스의 통합 로그를 실시간(-f)으로 확인한다.
docker compose logs -f

각 서비스의 로그를 확인하여 오류가 없는지, Promtail이 로그를 정상적으로 수집하고 Loki로 보내고 있는지 등을 확인할 수 있다.

서비스 접속 및 Grafana 설정

이제 웹 브라우저를 통해 각 서비스에 접속할 수 있다. (보안 그룹 설정 필요)

서비스 주소 기본 로그인 정보 (Grafana)
Grafana http://EC2_IP:3000 admin / admin
Prometheus UI http://EC2_IP:9090 -
Loki API http://EC2_IP:3100 -

Grafana 데이터 소스 설정

Grafana에 접속한 후, Prometheus와 Loki를 데이터 소스로 추가해야 대시보드를 구축할 수 있다.

  1. Grafana 접속: http://EC2_IP:3000으로 접속하여 admin/admin으로 로그인한다.
  2. Configuration (⚙️ 아이콘) -> Data sources 로 이동한다.
  3. "Add data source" 버튼을 클릭한다.
    • Prometheus 설정:
      • Name: Prometheus (원하는 이름)
      • URL: http://prometheus:9090 (Docker Compose 내부 네트워크에서 Prometheus 서비스 이름)
      • Save & Test 클릭
    • Loki 설정:
      • Name: Loki (원하는 이름)
      • URL: http://loki:3100 (Docker Compose 내부 네트워크에서 Loki 서비스 이름)
      • Save & Test 클릭

두 데이터 소스가 성공적으로 연결되면, 이제 Grafana에서 Prometheus 메트릭과 Loki 로그를 쿼리하고 시각화할 준비가 되었다.

마무리

이 가이드를 통해 구축된 환경은 테스트 및 학습 목적에 최적화된 최소한의 모니터링 스택이다. 실제 운영 환경에서는 보안 강화, 스토리지 분리, 인증 설정, Alertmanager 연동, Grafana 대시보드 버전 관리 등 추가적인 고려 사항이 많다.

하지만 이 구성만으로도 여러분은 다음을 충분히 경험하고 이해할 수 있다

  • Prometheus를 이용한 메트릭 수집 및 시계열 데이터 관리의 기본 흐름
  • Loki와 Promtail을 활용한 로그 수집 및 중앙화의 원리
  • Grafana에서 메트릭과 로그를 통합적으로 시각화하고 문제 해결에 활용하는 방법
  • Spring Boot 애플리케이션을 오픈 소스 모니터링 스택에 연동하는 실질적인 경험