모니터링 메트릭(지표) 및 모니터링 도구

1. 모니터링의 필요성

서비스가 성장하거나 사용자가 몰리는 이벤트가 있을 때, 시스템은 얼마나 버틸 수 있을까? 이 질문에 대한 답을 얻기 위해 부하 테스트(Load Testing) 는 필수다. 하지만 부하만 주는 것으로는 부족하다. 어디에서 병목이 발생하고, 어떤 리소스가 부족한지 파악하기 위해선 정확한 모니터링(Monitoring) 이 함께 이루어져야 한다.

2. 부하 테스트에서 주로 사용하는 모니터링 지표 (Metrics)

아래는 부하 테스트 시 모니터링하는 주요 지표들이다.

지표명	설명
응답 시간 (Response Time)	요청을 보낸 시점부터 응답을 받을 때까지 걸리는 시간
처리량 (Throughput)	초당 처리된 요청 수 (RPS 또는 TPS)
TPS (Transactions Per Second)	초당 완료된 트랜잭션 수
에러율 (Error Rate)	전체 요청 중 오류가 발생한 비율
동시 사용자 수 (Concurrent Users)	동시에 접속하여 작업을 수행하는 사용자 수
CPU / Memory 사용량	애플리케이션 또는 서버 자원의 사용 현황
Disk I/O / Network I/O	입출력 또는 네트워크 트래픽 사용량
GC 시간 / 횟수	JVM 기반 서비스의 Garbage Collection 성능 분석
Latency vs Throughput	지연시간과 처리량 간의 상호 관계 (느려지면 처리량도 감소함)

3. 모니터링 도구 종류 및 특징

부하 테스트에서 발생하는 수많은 지표들을 잘 수집하고 분석하기 위해선, 상황에 맞는 모니터링 도구를 선택해야 한다. 크게 애플리케이션 성능 모니터링(APM), 인프라 자원 모니터링, 로그 기반 분석 도구로 나눌 수 있다.

APM (Application Performance Monitoring)

APM 도구는 애플리케이션의 내부 동작을 추적하고 분석하는 데 최적화되어 있다. 요청이 어떤 경로로 흘러갔는지, 어떤 메서드에서 병목이 발생했는지, 데이터베이스 쿼리는 얼마나 느렸는지 등을 실시간으로 보여준다.
New Relic, Datadog, Dynatrace 등이 대표적이며, 클라우드 환경이나 마이크로서비스 구조에서 특히 유용하다. 대부분 상용이지만, 문제 지점 식별과 경고 알림 기능이 강력해 DevOps 팀에서 많이 사용된다.

서버/인프라 자원 모니터링 도구

애플리케이션이 배포되는 서버나 컨테이너, VM의 상태를 모니터링하는 도구다. CPU 사용률, 메모리 사용량, 네트워크 트래픽, 디스크 I/O 같은 하드웨어 자원을 중심으로 지표를 수집한다.
Prometheus는 시계열 데이터 수집에 특화된 오픈소스 도구이며, 이를 시각화해주는 Grafana와 함께 사용하는 것이 일반적이다. AWS 같은 클라우드 환경에서는 CloudWatch로도 충분한 모니터링이 가능하다.

로그 기반 모니터링 도구

시스템 로그, 애플리케이션 로그, 오류 메시지를 중심으로 분석하는 도구다. 특히 장애나 예외가 발생했을 때 정확한 원인 파악에 유용하다.
ELK Stack (Elasticsearch, Logstash, Kibana) 은 구조화되지 않은 로그를 수집하고, 이를 검색 가능하게 만든 뒤, 시각화할 수 있게 해주는 대표적인 오픈소스 스택이다. Loki는 Grafana와 함께 사용하는 로그 수집 도구로, 경량 로그 시스템을 원하는 경우에 적합하다.

 

위의 내용을 표로 정리하면 다음과 같다.

분류도구	예시	특징
APM (Application Performance Monitoring)	New Relic, Datadog, Dynatrace	코드 단위 성능 추적, 트랜잭션 분석에 강함
서버/인프라 모니터링	Prometheus + Grafana, CloudWatch, Zabbix	리소스 사용량, 서비스 상태 모니터링
로그 기반 모니터링	ELK Stack (Elasticsearch, Logstash, Kibana), Loki	에러 로그, 접근 로그 기반 분석

 

또한 도구를 사용하기 위해서는 실시간성과 비용 발생 여부도 검토가 필요하다.

실시간 vs 비실시간 도구

• 실시간 도구는 현재 시스템 상태를 즉시 확인할 수 있어 빠른 대응이 필요한 상황에 적합하다.
  예: Prometheus + Grafana
• 비실시간 도구는 로그 기반의 사후 분석에 더 적합하며, 이슈가 발생한 이후에 원인을 추적하는 데 유리하다.
  예: ELK Stack

오픈소스 vs 상용 도구

• 오픈소스 도구는 비용이 없고 커스터마이징이 자유롭지만, 설치/운영에 시간과 경험이 필요하다.
  대표 예: Prometheus, Grafana, ELK
• 상용 도구는 설치가 간편하고 UI/UX가 뛰어나며, 다양한 통합 기능을 제공하지만, 비용이 발생한다.
  대표 예: Datadog, New Relic, Dynatrace

검토 사항	선택지	설명
실시간 vs 비실시간	실시간 (Grafana), 비실시간 (ELK 분석용)	상황에 따라 조합 가능
오픈소스 vs 상용	오픈소스 (Prometheus), 상용 (Datadog)	기능과 비용에 따라 선택 필요

 

4. JMeter, Prometheus, Grafana를 활용한 실시간 성능 모니터링

JMeter와 Prometheus를 이용한 실시간 매트릭 수집

Apache JMeter는 오픈 소스 부하 테스트 도구로, 다양한 프로토콜에 대한 성능 테스트를 지원한다. Prometheus는 시계열 데이터베이스로 모니터링 및 경고 시스템에 사용되며, Grafana는 이러한 데이터를 시각화하는 대시보드 도구이다.​

1. JMeter 설치 및 테스트 스크립트 작성
   • Apache JMeter 공식 웹사이트에서 JMeter를 다운로드하여 설치한다.​
   • 부하 테스트를 수행할 스크립트를 작성한다.​
2. Prometheus Listener 플러그인 설치
   • JMeter-Prometheus Plugin에서 최신 릴리스의 JAR 파일을 다운로드한다.​
   • 다운로드한 JAR 파일을 JMeter의 lib/ext 디렉토리에 복사한다.​
   • JMeter를 재시작한 후, 테스트 계획에 Prometheus Listener를 추가한다.​
3. Prometheus 설정
   • Prometheus 공식 웹사이트에서 Prometheus를 다운로드하여 설치한다.​
   • prometheus.yml 설정 파일에 JMeter의 메트릭을 수집하도록 작업(job)을 추가한다
   • Prometheus를 실행하고, http://localhost:9090에서 웹 인터페이스에 접속하여 설정을 확인한다.​
4. Grafana 설정 및 대시보드 구성
   • Grafana 공식 웹사이트에서 Grafana를 다운로드하여 설치한다.​
   • Grafana에 로그인한 후, 데이터 소스로 Prometheus를 추가한다.​
   • 새로운 대시보드를 생성하고, JMeter 메트릭을 시각화하기 위한 패널을 구성한다.​

이러한 구성을 통해 JMeter로 부하 테스트를 수행하면서, Prometheus와 Grafana를 활용하여 테스트 결과를 실시간으로 모니터링하고 시각화할 수 있다.​

Prometheus와 Grafana를 활용한 모니터링

Prometheus에서 수집한 지표들을 Grafana에서 시각화하고, 이 데이터를 해석해 성능 상태를 분석할 수 있다.

 

Prometheus는 시계열 데이터를 수집하는 데 강하지만, 시각화 기능은 매우 제한적이다. 이 데이터를 직관적이고 인터랙티브하게 보여주는 역할은 Grafana의 몫이다.

먼저 Grafana를 설치하고 웹 UI에 접속하면, 가장 먼저 해야 할 일은 데이터 소스 연결이다.

 

이미지 출처: https://ttl-blog.tistory.com/1366

왼쪽 메뉴에서 Configuration > Data Sources를 클릭하고, Prometheus를 선택한 뒤 http://localhost:9090을 입력해 연결해주면 된다. 연결이 완료되면 이제 대시보드에서 Prometheus의 데이터를 자유롭게 사용할 수 있다.

 

5. Grafana를 이용한 시각화 및 부하 테스트 결과 해석

대시보드 구성 및 메트릭 시각화

대시보드를 새로 만들고 패널을 추가하면, 쿼리 편집기를 통해 Prometheus에서 수집한 지표들을 불러올 수 있다.
JMeter로부터 수집한 대표적인 메트릭은 다음과 같다

메트릭 이름	설명
jmeter_sample_count	요청 수
jmeter_sample_error_count	오류 수
jmeter_sample_avg	평균 응답 시간
jmeter_sample_max	최대 응답 시간
jmeter_sample_min	최소 응답 시간

예를 들어, 평균 응답 시간의 변화를 보고 싶다면 다음과 같은 쿼리를 사용할 수 있다.

avg_over_time(jmeter_sample_avg[1m])

 

TPS(초당 트랜잭션 수)는 요청 수 메트릭을 기준으로 rate() 함수를 사용하면 추출 가능하다.

rate(jmeter_sample_count[1m])

 

에러율은 오류 수를 총 요청 수로 나눈 다음 시각화할 수 있다.

rate(jmeter_sample_error_count[1m]) / rate(jmeter_sample_count[1m])

 

이러한 쿼리를 다양한 시각화 방식(라인 그래프, 게이지, 막대 차트 등)으로 패널에 구성하면, 실시간으로 부하 테스트의 주요 지표를 한눈에 모니터링할 수 있는 환경이 완성된다.

Grafana에서 부하 테스트 결과 해석하기

응답 시간 추이

평균 응답 시간이 부하와 함께 점진적으로 상승하고 있다면, 시스템이 점점 버거워지고 있다는 신호다.
만약 그래프가 갑자기 튄다면, 그 시점에 GC, DB Lock, Thread Pool Saturation 같은 병목이 발생했을 가능성이 크다.

 

TPS 정체

TPS는 부하가 증가함에 따라 함께 올라야 한다.
어느 시점에서부터 TPS가 고정된 채 응답 시간만 증가하고 있다면, 시스템이 처리 가능한 최대 처리량에 도달한 것이다.

 

오류율 증가

정상적인 부하 환경에서는 오류가 거의 없어야 한다. 특정 시간대에 오류율이 급증했다면,

• API 타임아웃 발생
• 애플리케이션 예외
• 백엔드 연결 실패
  와 같은 문제가 발생했을 수 있다. 이 시점에 로그를 함께 확인해보는 것이 좋다.

시계열 간 상관관계

지표는 조합해서 볼 때 진짜 인사이트가 나온다.
TPS가 떨어지면서 동시에 오류율이 증가하고, 응답 시간도 늘어났다면, 그 시점이 바로 시스템 임계 지점이다.

 

Grafana Best Practice

아래 링크에서 Grafana Best Practice를 확인할 수 있다.

https://grafana.com/grafana/dashboards/

Grafana dashboards | Grafana Labs

 

참고 자료

https://qainsights.com/jmeter-prometheus-and-grafana-integration/

JMeter, Prometheus, and Grafana Integration

https://www.frugaltesting.com/blog/jmeter-and-grafana-real-time-performance-monitoring

JMeter and Grafana: Real-Time Performance Monitoring

https://ttl-blog.tistory.com/1366

[그라파나] - [1] 그라파나(Grafana) 대시보드 생성

https://jennifersoft.com/ko/blog/kubernetes/2024-01-04-kubernetes-15/?utm_source=chatgpt.com

15. 모니터링 대시보드 구축