모니터링 툴 씬의 맛없없 조합: Spring Boot Actuator X Prometheus X Grafana

들어가기 전에

작년 12월, 테오의 스프린트에 참여해 '부꾸러미' 서비스를 만들었다.

부꾸러미

부꾸러미 has 2 repositories available. Follow their code on GitHub.

github.com

서비스의 특성상 사용자들의 적극적인 공유와 참여가 중요했다 보니 자연스럽게 API 호출 수와 서버 부하를 고민했었다. 그래서 당시 백엔드 팀원들과 여러 가지 개선해야 할 점을 이야기하면서 모니터링 툴 도입도 논의했지만, 홍보 일정과 겹쳐 결국 실행하진 못했었다.

그러던 중, 최근 회사에서 이상 거래 모니터링 시스템을 개발하면서 다시 한번 모니터링에 대해 관심을 가지게 됐다. 그때 도입하지 못했던 것이 계속 아쉬움으로 남아 있던 터라 이번 기회에 직접 경험해 보면 좋을 것 같다는 생각이 들었다. 마침 부꾸러미 서버도 아직 유지되고 있어 실제 트래픽을 모니터링하며 실습해 보기로 했다.

Prometheus와 Grafana를 선택한 이유

우선, 사용자들의 API 호출 집계나 서버 부하를 모니터링 하는 게 목적인 만큼 그에 맞는 툴을 선택하고 싶었다. 부꾸러미 서버는 단일 서버였기 때문에 분산 환경을 크게 고려하지 않았고, 로그 분석에 특화된 툴 또한 목적에 맞지 않아 대상에서 제외됐다. 결국엔 Prometheus와 Grafana를 선택했는데 그 이유를 간략하게 정리해 보았다.

Spring boot 애플리케이션의 메트릭 정보 연동 간편
직관적인 UI로 인한 데이터 파악 용이

Spring Boot에서는 actuator라는 의존성을 제공하는데, 이 의존성을 추가하면 애플리케이션의 메트릭 정보를 쉽게 수집할 수 있어 구현이 간편해진다. 또 Prometheus와 쉽게 연동할 수 있다는 것이 장점이었다. 그렇다 보니 Prometheus가 제공해 주는 정보들을 쉽게 UI로 볼 수 있게 해주는 Grafana를 선택한 것은 자연스러운 수순이었다.

개념 익히기

우선 실습을 시작하기 전에 기본 개념과 도입하려는 기술들을 알아보자.

[1] 기본 개념

전체적인 실습을 이해하며 진행하려면 메트릭과 시계열 데이터를 아는 것이 중요하다.

단어	의미
메트릭(Metrics)	어떤 시스템이나 애플리케이션에서 일어나는 일을 측정하여 숫자로 표현한 값 (e.g . 웹사이트 방문자 수, 서버의 처리 시간 etc.)
시계열 데이터(Time Series Data)	시간에 따라 변화하는 데이터를 순차적으로 기록한 데이터 (e.g. 온도 변화, CPU 사용량, 웹사이트 트래픽 etc.)

[2] Spring actuactor

Actuator는 운영 환경에 필요한 도구들을 바로 활용할 수 있는 기능들을 제공하는 라이브러리이다. 그래서 직접 개발자가 구현하지 않아도 다음과 같은 작업들을 쉽게 수행할 수 있다.

모니터링
메트릭 수집
트래픽 및 데이터베이스 상태 파악 등

Spring Boot가 내장된 여러 엔드포인트를 제공해주기 때문에 애플리케이션을 모니터링하거나 상태 정보 등을 알기 쉽다는 큰 장점이 있다. 기본적으로 모든 엔드포인트가 활성화되어 있지만 노출되어 있는 엔드포인트는 "/health"(헬스 체크)와, "/info"(정보) 두 개 뿐이다. 그래서 원격에서 모든 엔드포인트에 접근할 수 있게 하기 위해 아래와 같이 exposure 정보를 설정해줘야 한다. include는 노출할 엔드포인트이고, 이와 반대되는 exclude로는 노출하지 않을 엔드포인트를 설정할 수 있다.

management:
  endpoints:
    web:
      exposure:
        include: *

참고 표. include, exclude에 설정할 수 있는 엔드포인트 종류

ID	설명	기본 활성화 여부
auditevents	현재 애플리케이션의 audit(감사) 이벤트 정보를 제공한다.	⭕️
beans	애플리케이션 내 모든 Spring 빈의 전체 목록을 표시한다.	⭕️
caches	사용 가능한 캐시를 노출한다.	⭕️
conditions	자동 설정 클래스와 설정에서 평가된 조건과 해당 조건이 일치하거나 일치하지 않은 이유를 표시한다.(e.g. 특정 기능이 활성화되지 않은 이유)	⭕️
configprops	모든 @ConfigurationProperties를 모아 정리하여 표시한다.	⭕️
env	ConfigurableEnvironment에서 가져온 속성을 노출한다.	⭕️
flyway	적용된 Flyway 데이터베이스 마이그레이션 정보를 표시한다.	⭕️
health	애플리케이션의 상태(헬스 체크) 정보를 표시한다.	⭕️
httptrace	최근 100개의 HTTP 요청 및 응답 기록을 표시한다.	⭕️
info	애플리케이션에 대한 임의의 정보를 표시한다.	⭕️
integrationgraph	Spring integration 그래프를 표시한다.	⭕️
loggers	애플리케이션 내 로거의 설정을 표시하고 변경할 수 있도록 한다.	⭕️
liquibase	적용된 Liquibase 데이터베이스 마이그레이션 정보를 표시한다.	⭕️
metrics	현재 애플리케이션의 메트릭 정보를 표시한다.	⭕️
mappings	모든 @RequestMapping 경로 목록을 정리하여 표시한다.	⭕️
scheduledtasks	애플리케이션 내에서 예약된 작업 목록을 표시한다.	⭕️
sessions	Spring Session 기반 세션 저장소에서 사용자 세션을 검색하고 삭제할 수 있도록 한다. (Spring WebFlux에서는 사용 불가)	⭕️
shutdown	애플리케이션을 정상적으로 종료할 수 있도록 한다.	❌
threaddump	현재 애플리케이션의 스레드 덤프를 수행한다.	⭕️
웹 애플리케이션(Spring MVC, Spring WebFlux, Jersey)에서 추가로 사용할 수 있는 엔드포인트
heapdump	hprof 형식의 힙 덤프 파일을 반환한다.	⭕️
jolokia	HTTP를 통해 JMX 빈을 노출한다.	⭕️
logfile	logging.file 또는 logging.path 속성이 설정되어 있을 경우, 로그 파일의 내용을 반환한다. HTTP Range 헤더를 사용하여 특정 부분만 검색할 수 있다.	⭕️
prometheus	Prometheus 서버가 수집할 수 있는 형식으로 메트릭을 노출한다.	⭕️

[3] Prometheus

Prometheus는 오픈 소스 모니터링 툴로 시계열 데이터(Time Series Data) 모델을 기반으로 각 메트릭 정보를 측정된 시간(timestamp)과 함께 수집하고 저장한다. 추가적으로 레이블(labels)이라는 key-value 쌍 데이터를 저장할 수 있는데 아래의 메트릭 정보처럼 중괄호 내부에 레이블 구조로 데이터가 저장된다.

application_started_time_seconds{main_application_class="teo.lab.buggureomi.BuggureomiApplication"} 6.325

이외에도 다양한 주요 특징들이 있다.

1. PromQL(Prometheus Query Language)을 제공하기 때문에 다양한 질의가 가능하다.
2. 단일 서버 노드만으로 독립적으로 동작한다.
3. HTTP 기반의 Pull 방식으로 데이터를 수집한다. 기본적으로는 직접 대상(target)에서 데이터를 가져오지만, 필요하면 Gateway를 통한 Push 방식도 지원한다.
4. 동적으로 모니터링 대상(target)을 자동으로 검색하거나 수동으로 등록할 수 있다.
5. 그래프 및 대시보드 기능을 제공하며 Grafana 같은 외부 도구와 연동이 가능하다.

그리고 프로메테우스에는 시계열 데이터를 스크래핑하고 저장하는 서버뿐만 아니라 다양한 서비스에 대한 메트릭을 수집할 수 있게 도와주는 Exporters, 알림을 설정할 수 있는 Alertmanager 등이 있다. 이번 실습에서는 node-exporter를 활용해서 EC2 서버의 성능과 상태를 모니터링할 수 있었다.

The Prometheus Node Exporter exposes a wide variety of hardware- and kernel-related metrics.
Prometheus Node Exporter는 다양한 하드웨어 및 커널 관련 메트릭을 노출한다.

출처 : Prometheus 공식 문서

[4] Grafana

Grafana는 시계열 데이터베이스, 로그 도구, NoSQL/SQL 데이터베이스 등을 포함한 다양한 데이터 소스에서 데이터를 쿼리 해서 실시간 대시보드로 그래프와 시각화를 제공하는 도구이다. 오픈 소스 소프트웨어와 엔터프라이즈가 따로 제공된다.

실습

[1] 서버 구성

배포 서버와 모니터링 서버를 따로 두려고 했는데 실습용이니 굳이 서버를 하나 만들지 않고 로컬에서 메트릭 정보를 확인하기로 했다.

서버 구성
EC2(배포 서버)	- 스프링 부트 애플리케이션에 actuator와 prometheus 설정 - 서버 메트릭 정보 수집을 위한 node-exporter 설치
Local(모니터링 서버)	메트릭 정보 확인

[2] EC2 서버

1️⃣ SpringBoot 애플리케이션

1. 의존성 추가

build.gradle에 actuator와 prometheus 의존성을 추가한다.

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

2. Spring Security 설정

Spring Security를 사용 중이어서 SecurityFilter의 허용 요청 URI에 actuator 경로를 추가해줬다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity httpSecurity, ConversionService conversionService) throws Exception {
    httpSecurity
        ...
        .authorizeHttpRequests(authorizeRequests ->
            authorizeRequests
                .requestMatchers("/actuator/**").permitAll()
                .anyRequest().authenticated()
        )
        ...

    return httpSecurity.build();
}

🔉 설정 시 보안 취약점
이번 글에서는 별다른 처리를 해주지 않고 있지만, 이렇게 설정 하면 외부에서도 악의적인 의도를 가지고 애플리케이션 내부의 중요한 정보들에 접근할 수 있다. 그래서 서비스 운영에 사용되는 포트와 다른 포트를 사용하거나, 경로 변경 혹은 권한이 있는 사용자만 접근 가능하도록 제어하는 등의 처리가 필요하다. 관련 내용은 우아한기술블로그의 Actuator 안전하게 사용하기에서 확인할 수 있다.

3. EndPoints 설정

include에 "prometheus"를 설정해서 Prometheus 서버가 데이터를 수집할 수 있는 메트릭을 제공받기로 한다.

management:
  endpoints:
    web:
      exposure:
        include: "prometheus"

2️⃣ node-exporter

1. docker 이미지 Pull 및 실행

간단하게 docker를 사용해서 node-exporter를 pull 받은 후 9100 포트로 실행했다.

docker pull prom/node-exporter
docker run --name node-exporter -d -p 9100:9100 prom/node-exporter

2. nginx 설정 파일 수정

배포 서버에서 CORS 문제를 해결하기 위해 nginx를 쓰고 있어서 여기에 metrics 경로에 접근할 수 있게 따로 설정을 해줘야했다. "[서버 도메인 주소]/metrics"로 접근하면 서버 내부의 9100포트의 metrics 경로로 요청이 갈 수 있게 했다.

# Node Exporter 프록시 설정 추가
location /metrics {
    proxy_pass http://127.0.0.1:9100/metrics;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

3. nginx 설정 파일 검사 후 재시작

파일 수정이 끝나면 -t 옵션으로 설정 파일에 문제가 없는지 검사한 후에 재시작을 해준다.

sudo nginx -t
sudo systemctl restart nginx

[3] Local

1️⃣ Prometheus, Grafana 설정 및 컨테이너 실행

설정 파일 관리를 위해 별도 디렉토리를 만들어 이동 후 아래 작업을 수행했다.

1. docker-compose.yml 파일 생성 및 작성

Prometheus와 Grafana를 Docker 컨테이너로 관리하기 위해 아래와 같이 docker-compose.yml 파일을 생성하고 작성한다.

version: '3.8' # Docker Compose 버전 

services: # 서비스 정의
  prometheus: # 프로메테우스 설정
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml # 로컬 파일 -> 컨테이너 내부 파일 연결
      - prometheus_data:/prometheus # 컨테이너 내부 데이터 저장
    ports:
      - "9090:9090"
    restart: unless-stopped # 컨테이너가 예기치 않게 종료되면 자동 재시작
    networks:
     - promnet # Grafana와 동일한 네트워크에서 동작하도록 하여 연결 

  grafana: # 그라파나 설정
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    restart: unless-stopped
    networks:
     - promnet # Prometheus와 동일한 네트워크에서 동작하도록 하여 연결 

networks:
  promnet: # 두 컨테이너가 통신하기 위한 네트워크 
    driver: bridge # 컨테이너 간 통신을 위한 bridge 네트워크 사용

2. prometheus.yml 파일 생성 및 작성

Prometheus가 Target에서 메트릭을 가져오는 방법을 설정하기 위해 prometheus.yml 파일을 생성하고 작성한다.

global:
  scrape_interval: 15s # 15초마다 메트릭 수집

scrape_configs: # 메트릭을 가져올 API 엔드포인트 경로
  - job_name: 'node_exporter' # node-exporter 설정
    metrics_path: /metrics
    scheme: https # HTTPS 프로토콜 사용
    static_configs: # 대상 서버
      - targets: ['서버 도메인 주소']
  - job_name: 'actuator'
    metrics_path: /actuator/prometheus
    scheme: https
    params:
     format: ['json'] # 메트릭 형식 지정
    static_configs:
      - targets: ['서버 도메인 주소']

⚠️ unsupported Content-Type 에러가 발생할 경우, params.format 옵션으로 메트릭 형식을 설정해 주면 된다.

time=2025-02-22T06:19:46.274Z level=ERROR source=scrape.go:1609 msg="Failed to determine correct type of scrape target." component="scrape manager" scrape_pool=actuator target=http://[서버 도메인 주소]:8080/actuator/prometheus content_type=application/json fallback_media_type="" err="received unsupported Content-Type \"application/json\" and no fallback_scrape_protocol specified for target”

3. docker-compose.yml 파일 실행

이미지가 없다면 pull, 있다면 그대로 컨테이너를 생성 후에 백그라운드에서 실행해 주는 명령어이다.

docker compose up -d

4. Prometheus 메트릭 수집 정보 확인

prometheus.yml에 설정해둔 경로로 접속해 메트릭 수집 정보를 확인할 수 있다.

2️⃣ Prometheus URL 접속 (http://localhost:9090)

1. Target Server Health Check

Status > Tartget health 페이지에서 스프링 부트 애플리케이션에 설정해 준 actuator 경로와, node-exporter 경로에 대해 모두 State가 UP인 것을 확인해야 한다.

2. Query 테스트

Prometheus가 제공하는 메트릭 이름을 입력하고 쿼리를 실행하면 Table | Graph | Explain 탭을 통해서 수집한 데이터를 확인할 수 있다.

3️⃣ Grafana URL 접속 (http://localhost:3000)

1. 로그인

아래 정보로 로그인 후 비밀번호를 변경한다.

초기 비밀번호
username: admin
password: admin

⚠️ 로그인 화면에서 invalid 에러가 발생할 경우, 아래와 같이 비밀번호를 초기화해 주면 된다.

# grafana-cli admin reset-admin-password [사용할 패스워드]
grafana-cli admin reset-admin-password admin

출처: https://nirsa.tistory.com/260

2. Data source 추가

1) Connections > Data sources 탭에서 Prometheus를 클릭해 추가한다.

2) Prometheus server URL(http://localhost:9090)을 입력하고 스크롤을 내려 Save & Test를 클릭한다.

⚠️ connection refused 에러가 발생할 경우, localhost가 아닌 prometheus 라고 기입해 주면 정상적으로 연결할 수 있다.

3. 대시보드 추가

Dashboard > New > Import 를 클릭한 후 템플릿 ID 혹은 URL을 입력한다.

이번 글에 사용한 템플릿 ID
Node Exporter Full: 1860
Spring Boot Statistics & Endpoint Metrics: 14430

4. 대시보드 확인

원하는 대시보드를 위의 작업을 통해 로드했다면 아래와 같은 화면을 만날 수 있다.

⚠️ Spring Boot Statistics & Endpoint Metrics에서 HTTP Statistic > Response Time이 No Data로 노출 될 경우, 쿼리를 확인해 보자. 나의 경우 exception="None"을 제거하니 데이터를 확인할 수 있었다.

참고. irate vs. rate
- irate는 최근 두 데이터를 기반으로 계산하는 함수로 급격한 변화나 짧은 시간 동안의 변화를 감지할 때 사용한다.
- rate는 주어진 시간 범위 동안의 평균 요청 비율을 계산하는 함수로 irate에 비해 안정적이다.

더해보기

글또에서 <데이터 중심 애플리케이션 설계>, aka 멧돼지 책 스터디에 참여하고 있다. 1장을 읽으면서 새롭게 알게 되면서 흥미로웠던 주제가 바로 "응답 시간"이었다. 응답을 기다리지 않는 비동기 처리는 경험해 봤어도 응답 시간을 측정하고 그걸 통해 서비스를 개선해 본 경험은 없었기 때문에 더 흥미롭고 재미있었다. 최근에 토스에서 진행한 멘토링 프로그램인 "Learner's High 서버 1기"에 선정되어 세션을 들었는데 해당 세션을 통해서도 메트릭에 대한 중요성을 알게 되어서 더 관심이 생기기도 했었다.

[응답 시간 계산법]
일반적으로 상위 백분위에서 사용하는 백분위는 95분위, 99분위, 99.9분위이다. 요청의 95%, 99%, 99.9%가 특정 기준치보다 더 빠르면 해당 특정 기준치가 각 백분위의 응답 시간 기준치가 된다. 99.9분위 같은 최상위 백분위는 통제할 수 없는 임의 이벤트에 쉽게 영향을 받기 때문에 응답 시간을 줄이기가 매우 어렵다.

[실전 백분위]
병렬로 호출하더라도 병렬 호출 중 가장 느린 호출이 완료되길 기다려야 하기 때문에 그 하나로 인해 전체 최종 사용자의 요청이 느리게 될 수 있다. 서비스의 모니터링 대시보드에 응답 시간 백분위를 추가하려면 지속적으로 백분위를 효율적으로 계산할 필요가 있다. 응답 시간 데이터를 집계하는 올바른 방법은 히스토그램을 추가하는 것이다.

<데이터 중심 애플리케이션 설계>, 마틴 클레프만

그리고 1장 발표 시간에 내가 흥미 있어하는 포인트에 대해 이야기했었는데 너무 감사하게도 같이 스터디에 참여하고 계신 경환님께서 Prometheus에서 p9x 시리즈 데이터를 볼 수 있는 옵션을 알려주셔서 해당 챕터를 작성할 수 있었다.

[1] metrics type

응답 시간 데이터를 집계하는 올바른 방법은 히스토그램을 추가하는 것이다.

Prometheus에서 제공하는 메트릭 타입은 총 4가지로, 위에서 이야기하는 히스토그램은 관찰 대상을 샘플링해서 버킷 별로 구분하고 저장해서 조회할 수 있도록 하는 메트릭이다.

타입	의미	예제
Counter	축적되는 단방향으로 증가하는 숫자 메트릭	요청 수 \| 완료된 태스크의 수
Gauge	증가하거나 감소할 수 있는 숫자 값을 나타낼 때 쓰는 메트릭	최근 기온 \| 활성화 쓰레드 수
Histogram	관찰 대상을 일정 시간 간격으로 나누어 기록(샘플링)하고, 그 값을 범위(버킷) 별로 구분 및 저장하고 조회할 수 있는 메트릭	데이터베이스 I/O Latency
Summary	관찰 대상을 일정 시간 간격으로 나누어 기록(샘플링)하고, 총 발생 횟수나 합계를 제공하는 메트릭	응답 시간의 합

메트릭 목록 페이지를 보다 보면 아래와 같이 메트릭 이름 뒤에 타입 정보가 나와있어 확인이 가능하다.

[2] Histogram 설정

메트릭 목록 페이지를 유심히 들여다봤다면 알 수 있었을 테지만 히스토그램 메트릭 정보는 자동으로 제공해주지 않는다. 그래서 Spring Boot 애플리케이션의 application.yml에 아래 설정을 해줘야 한다.

management:
  # 생략
  metrics:
    enable:
      http.server.requests: true
    distribution:
      percentiles:
        http.server.requests: 0.5, 0.95, 0.99
      percentiles-histogram:
        http.server.requests: true

[3] 응답 시간 데이터 비교

1️⃣ Summary

웹 서버의 평균 응답 시간을 계산하는 쿼리이다. 5분 동안 일어난 HTTP 요청에 대한 총 응답 시간을 총 요청 수로 나눈 값이 평균 응답 시간이 되는 것이다.

rate(
	http_server_requests_seconds_sum{
    	instance="$instance", 
        application="$application", 
        uri!~".*actuator.*"
    }[5m]) 
/ rate(
	http_server_requests_seconds_count{
    	instance="$instance", 
        application="$application", 
        uri!~".*actuator.*"
    }[5m])

2️⃣ Histogram

웹 서버의 95분위, 99분위 응답 시간을 계산하는 쿼리이다. 5분 동안 각 버킷 별로 기록된 요청 수의 증가율을 합산해서 95% 또는 99%의 요청이 완료되는 데 걸린 시간을 나타낸 것이다.

histogram_quantile([백분위(0.95 | 0.99],
  sum(
    rate(http_server_requests_seconds_bucket{
      instance="$instance",
      application="$application",
      uri!~"/actuator/.*"
    }[5m])
  ) by (le, instance, application, uri)
)

[4] 정리

Summary와는 다르게 Histogram 정보를 활용하면 더 세부적인 응답 시간 분포를 확인할 수 있었다.

[Summary]
0.0682초

[Histgram]
p95 응답 시간: 0.0861 (100개의 요청 중 95개는 0.0861초 미만, 5개는 초과 소요)
p99 응답 시간: 0.382 (100개의 요청 중 99개는 0.382 미만, 1개는 초과 소요)

95%의 요청은 0.0861초 이내로 응답을 받았지만, 99%의 지표에서는 95%에서는 놓쳤던 느린 응답이 발견된다. 이렇게 성능 개선의 포인트를 유용하게 찾아낼 수 있다는 점이 히스토그램 정보를 활용하는 이유인 듯싶다.

일부 요청에서 발생하는 느린 응답이 전체 성능에 영향을 주는 현상을 꼬리 지연(Tail Latency)이라고 하는데 자세한 정의는 다음과 같다. 아마존에서는 p999를 지표로 삼아 1000개의 요청 중 1개의 느린 응답을 개선하는 작업을 해나간다고 하는데, 결국에는 이런 노력들이 모여 우리가 안정적이고 일관성있는 서비스를 이용하게 된 것이 아닐까 싶다.

꼬리 지연(tail latency)이란 high-percentil latency라고도 부르며 드물게 높은 지연이 발생하는 현상을 말한다. p99에서 레이턴시가 10ms이면 100명중 99명은 10ms이하의 요청을 경험한다. p99.9에서 레이턴시가 100ms이면 1000명 중 한 명은 100ms를 경험한다는 표현이다.

출처 : 프리퀄 | 마이크로 서비스 시대의 부하 분산 정책

마무리

모니터링 툴 도입을 고민하게 된 계기부터 기본 실습, 그리고 히스토그램을 통해 상위 백분위를 활용한 응답 시간 분석과 성능 개선 포인트를 찾는 과정까지 학습했다. 복잡한 설정 없이도 다양한 메트릭 정보를 제공받아 활용할 수 있을뿐만 아니라, 이를 통해 사용자 경험도 개선할 수 있음을 알 수 있는 시간이었다. 물론 환경과 니즈에 따라 다르겠지만, Spring Boot 애플리케이션을 운영 중이라면 충분히 고려해볼 만한 선택지라고 생각한다.

참고

저작자표시 (새창열림)

'노트' 카테고리의 다른 글

[내 프로젝트 성능 진단기] #1. 처리량과 지연 시간, 응답 시간으로 병목 찾기 (2)	2025.06.01
Github Actions (CI) (0)	2023.02.23
Testcontainers (0)	2023.02.20

들어가기 전에

Prometheus와 Grafana를 선택한 이유

개념 익히기

[1] 기본 개념

[2] Spring actuactor

[3] Prometheus

[4] Grafana

실습

[1] 서버 구성

[2] EC2 서버

1️⃣ SpringBoot 애플리케이션

2️⃣ node-exporter

[3] Local

1️⃣ Prometheus, Grafana 설정 및 컨테이너 실행

2️⃣ Prometheus URL 접속 (http://localhost:9090)

3️⃣ Grafana URL 접속 (http://localhost:3000)

더해보기

[1] metrics type

[2] Histogram 설정

[3] 응답 시간 데이터 비교

1️⃣ Summary

2️⃣ Histogram

[4] 정리

마무리

참고

'노트' 카테고리의 다른 글

티스토리툴바

1️⃣ Prometheus, Grafana 설정 및 컨테이너 실행