모니터링 서버(2)

모식했던 커스텀 모니터링을 계획했으면 이제 구축 단계에 들어서는데, 들어서기 전에 어떤 정보를 수집해올 것인지를 확실히 해야 했다. 스프링 액추에이터를 통해 프로메테우스가 수집하는 메트릭 데이터들의 종류가 상당히 많기 때문에 사용 목적에 맞춰서 커스텀 메트릭 세팅 및 수집이 필수다.

시스템 및 JVM 등과 관련해서는 이미 수집된 데이터들이 표면적으로 드러나며 PromQL로 쉽게 접근이 가능하다. 그렇기 때문에 이런 부분들은 배제시켰고, 개발자들이 직접적으로 건드리는 비즈니스 로직과 관련해서 코드의 객체지향성, 외부 의존성 등의 유무 및 영향력을 파악할 수 있는 주요 방법은 API의 호출 수단, 즉 컨트롤러에 위치한 메소드들의 메트릭 데이터라고 생각했다. 예외 발생 빈도수나 응답 시간 계측 등을 주기적으로 확인하고, 이를 좀 더 확장해서 경고 체계 등을 갖추면 된다고 생각했다.

1. 모니터링 대상

임시로 개발해둔 도서 대여 관리 서버가 있어서 이걸 바탕으로 테스트 모니터링을 수행하기로 했다. 간단한 3계층 아키텍처 패턴을 기반으로 별도의 스프링 관련 의존성 없이 JPA와 MySQL 기반으로 API 요청 및 응답이 이뤄지는 서버다. 현재 해당 프로젝트의 의존성은 다음과 같다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    runtimeOnly 'com.mysql:mysql-connector-j'
}

1) 의존성 추가 및 메트릭 데이터 노출

우선 모니터링 대상이 메트릭 데이터를 노출시키고 이걸 프로메테우스가 수집해갈 수 있도록 의존성을 추가한다.

    // ...

    // actuator + prometheus
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
    runtimeOnly 'io.micrometer:micrometer-registry-prometheus'
}

액추에이터는 기본적으로 해당 스프링부트 프로젝트가 메트릭 데이터를 노출시켜서 확인할 수 있게 한다. 해당 메트릭 데이터들은 서버가 동작하는 루트 엔드포인트에서 /actuator/metrics로 접근하면 확인할 수 있는 정보들을 파악할 수 있다.

기본적으로 애플리케이션의 성능 및 상태, 리소스 사용량을 확인할 수 있으며, 저것들에 대한 실 계측은 일전에 추가했던 의존성인 micrometer가 담당한다. /actuator/prometheus로 접근하면 계측된 메트릭 데이터 값을 확인할 수 있다.

물론, 저 상태로는 읽기가 참 힘들다... 그렇기 때문에 프로메테우스 & 그라파나 등의 모니터링 툴을 활용해서 시각화 및 확장된 기능을 활용하는 것이다.

2) 프로메테우스(+ 그라파나) 도커 컴포즈 기반 세팅

사실, 저렇게 메트릭 데이터가 노출됐으면 곧바로 저 모니터링 대상으로부터 메트릭 데이터를 가져올 수도 있지만, 그렇게 될 경우 별개의 API를 구축하면서 그에 대한 호출 역시 모니터링 대상의 리소스 소모로 이어지고 또한 프로메테우스의 장점인 Pull-based 방식으로 인한 추가 부하 없음이라는 장점을 활용하기 위해서 프로메테우스를 거쳐서 메트릭 데이터를 수집하기 위해 프로메테우스를 세팅하기로 결정했다.

또한, 향후의 포스팅에서 자세히 다루겠지만, PromQL을 통해 커스텀 메트릭 데이터를 좀 더 효과적으로 수집할 수 있어서 프로메테우스 구축을 생각한 것 역시 있다.

사실 프로메테우스만을 세팅할 거면 직접 설치하거나 아니면 도커를 활용하면 되지만 혹시 모를 활용을 예상해서 그라파나까지 구축하기로 생각했고, 둘을 같은 호스트에서 구축할 거면 도커 컴포즈로 같이 컨테이너를 관리하는 것이 편하겠다는 생각에 도커 컴포즈를 구축함과 동시에 prometheus.yml을 세팅했다.

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    ports:
      - "9090:9090"
    networks:
      - monitoring-network

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    networks:
      - monitoring-network

networks:
  monitoring-network:
    driver: bridge

둘 다 최신의 이미지들을 바탕으로 컨테이너를 구축하며 동일 네트워크 내에서 프로메테우스와 그라파나가 상호작용할 수 있도록 세팅하였으며, 호스트의 루프백 주소를 통해 프로메테우스 및 그라파나의 UI에 접근할 수 있다.

global:
  scrape_interval: 15s
  scrape_timeout: 15s
  evaluation_interval: 2m

  external_labels:
    monitor: 'system-monitor'
  query_log_file: query_log_file.log

rule_files:
  - "rule.yaml"

scrape_configs:
  - job_name: prometheus
    metrics_path: '/actuator/prometheus'
    scrape_interval: 15s
    static_configs:
      - targets: ['host.docker.internal:8080']

프로메테우스 관련 설정 파일에는 전역 설정으로 수집 주기, 로그 파일 저장 위치, 메트릭 데이터 접근 엔드포인트 등을 설정해둔다. 참조할 점은, 두 파일은 동일 위치에 존재하도록 도커 컴포즈 세팅에서 정해뒀다.

노출된 메트릭 데이터를 프로메테우스가 수집해오는 것을 확인할 수 있다.

또한, 같이 세팅한 그라파나 역시 잘 동작한다. 다만 그라파나를 본격적으로 다루는 것은 후일이기 때문에 그라파나는 현재 단계에서 멈추고 프로메테우스에서 확인된 커스텀 메트릭 데이터를 수집하기 위한 모니터링 서버 세팅 단계로 진입한다.