[스프링 핵심 원리와 활용] 섹션10. 마이크로미터, 프로메테우스, 그라파나 (1)

[seyeop03]

본격적으로 스프링 부트가 제공하는 액추에이터에다가 CPU 사용량, 메모리 사용량, 톰캣 쓰레드 등이 제공되는 metrics 를 활용한 모니터링 + 프로메테우스와 그라파나를 엮어서 실무에서 어떤식으로 모니터링을 구성하는지 설명한다.

0x01. 마이크로미터

스프링 액추에이터는 기본으로 마이크로미터를 내장한다.

1.1. 마이크로미터 소개

전투에서 실패한 지휘관은 용서할 수 있지만 경계에서 실패하는 지휘관은 용서할 수 없다 라는 말이 있다. 이 말을 서비스를 운영하는 개발자에게 맞추어 보면 장애는 언제든지 발생할 수 있다. 하지만 모니터링(경계)은 잘 대응하는 것이 중요하다.

서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 수 많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생해도 원인을 빠르게 파악해서 대처할 수 있다. 예를 들어서 메모리 사용량이 가득 찼다면 메모리 문제와 관련있는 곳을 빠르게 찾아서 대응할 수 있을 것이다.

세상에는 수 많은 모니터링 툴이 있고, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용하게 된다.
다음은 자주 사용되는 모니터링 툴이다.

(1) 모니터링 툴 1 → 그라파나 대시보드

(2) 모니터링 툴 2 → 핀포인트

이런 모니터링 툴이 작동하려면 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 한다.
(물론 실제로는 라이브러리등을 통해서 자동화 되는 경우가 많다.)

(3) 예시 1. 모니터링 툴에 지표 전달

예를 들어서 CPU, JVM, 커넥션 정보 등을 JMX 툴에 전달한다고 가정해보자. 그러면 각각의 정보를 JMX 모니터링 툴이 정한 포멧에 맞추어 측정하고 전달해야 한다.

(4) 예시 2. 문제: 모니터링 툴 변경 (JMX → 프로메테우스)

그런데 중간에 사용하는 모니터링 툴을 변경하면 어떻게 될까?
기존에 측정했던 코드를 모두 변경한 툴에 맞도록 다시 변경해야 한다. 개발자 입장에서는 단순히 툴 하나를 변경했을 뿐인데, 측정하는 코드까지 모두 변경해야 하는 문제가 발생한다.
이런 문제를 해결하는 것이 바로 **마이크로미터(Micrometer)**라는 라이브러리이다.

(5) 예시 3. 문제해결: 표준 측정 방식으로 추상화 ⇒ 마이크로미터

CPU, JVM, CON 등의 메트릭 등을 micrometer가 제공하는 표준 측정 방식에 맞춰서 전달하면 구현체는 우리가 그냥 갖다쓰기만하면 된다.

(6) 마이크로미터 전체 그림

• 마이크로미터는 애플리케이션 메트릭 퍼싸드(Facade: 중간에서 무언가를 해결해줌)라고 불리는데, 애플리케이션의 메트릭(측정 지표)을 마이크로미터가 정한 표준 방법으로 모아서 제공해준다.
  • 쉽게 이야기해서 마이크로미터가 추상화를 통해서 구현체를 쉽게 갈아끼울 수 있도록 해두었다.
• 보통은 스프링이 이런 추상화를 직접 만들어서 제공하지만, 마이크로미터라는 이미 잘 만들어진 추상화가 있기 때문에 스프링은 이것을 활용한다. 스프링 부트 액추에이터는 마이크로미터를 기본으로 내장해서 사용한다.
  • 로그를 추상화 하는 SLF4J 를 떠올려보면 쉽게 이해가 될 것이다.
• 개발자는 그저 마이크로미터가 정한 표준 방법으로 메트릭(측정 지표)를 전달하면 된다. 그리고 사용하는 모니터링 툴에 맞는 구현체를 선택하면 된다. 이후에 모니터링 툴이 변경되어도 해당 구현체만 변경하면 된다. 애플리케이션 코드는 모니터링 툴이 변경되어도 그대로 유지할 수 있다.

마이크로미터가 지원하는 모니터링 툴은 다음과 같다.

• AppOptics
• Atlas
• CloudWatch
• Datadog
• Dynatrace
• Elastic
• Ganglia
• Graphite
• Humio
• Influx
• Instana
• JMX
• KairosDB
• New Relic
• Prometheus
• SignalFx
• Stackdriver
• StatsD
• Wavefront

참고
각 모니터링 툴에 대한 자세한 내용은 마이크로미터 공식 메뉴얼을 참고하자
****https://micrometer.io/docs

1.2. 메트릭 확인하기

CPU, JVM, 커넥션 사용 등등 수 많은 지표들을 어떻게 수집해야 할까?
원래는 개발자가 각각의 지표를 직접 수집해서 그것을 마이크로미터가 제공하는 표준 방법에 따라 등록해야 한다.
근데 다행히도 마이크로미터는 다양한 지표 수집 기능을 이미 만들어서 제공한다. 그리고 스프링 부트 액추에이터는 마이크로미터가 제공하는 지표 수집을 @AutoConfiguration 을 통해 자동으로 등록해준다.

쉽게 이야기해서 스프링 부트 액추에이터를 사용하면 수 많은 메트릭(지표)를 편리하게 사용할 수 있다.

이제 기본으로 제공하는 메트릭들을 확인해보자.
아직 모니터링 툴을 연결한 것은 아니고, 등록된 메트릭들을 확인해보는 단계이다.

(1) /actuator/metrics 엔드포인트

metrics 엔드포인트를 사용하면 기본으로 제공되는 메트릭들을 확인할 수 있다.

http://localhost:8080/actuator/metrics

• 액추에이터가 마이크로미터를 통해서 등록한 기본 메트릭들을 확인할 수 있다.
  • disk.xxx : 디스크 사용량
  • system.cpu.count : CPU 수
  • system.cpu.usage : CPU 사용량
  • jvm.memory.max : jvm 메모리 최대치
  • jvm.memory.used : jvm 메모리 사용량
  • hikaricp.connections.xxx : 커넥션에 대한 것들
• 내용이 너무 많아서 일부만 남겨두었다.

(2) /actuator/metrics/{name} : 자세히 확인하기

metrics 엔드포인트는 다음과 같은 패턴을 사용해서 더 자세히 확인할 수 있다.

• http://localhost:8080/actuator/metrics/{name}

JVM 메모리 사용량을 확인해보자.

실행

http://localhost:8080/actuator/metrics/jvm.memory.used

실행 결과

현재 메모리 사용량을 확인할 수 있다.

(3) Tag 필터

availableTags 를 보면 다음과 같은 항목을 확인할 수 있다.

• values 에 heap 메모리 사용량, heap 메모리 아닌 사용량 태그가 있다.
• tag:area, values[heap, nonheap]
• tag:id, values[G1 Survivor Space, …]

해당 Tag를 기반으로 정보를 필터링해서 확인할 수 있다.

tag=KEY:VALUE 과 같은 형식을 사용해야 한다.

• 이 태그를 구분해서 볼 수도 있다.
  • http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:heap
  • http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:nonheap

tag 를 사용해서 힙 메모리, 힙이 아닌 메모리로 분류해서 데이터를 확인할 수 있다.

tag 필터링 결과

몇가지 예시를 더 살펴보자.

HTTP 요청수를 확인

• http://localhost:8080/actuator/metrics/http.server.requests

HTTP 요청수에서 일부 내용을 필터링 해서 확인해보자.

1. /log 요청만 필터 (사전에 /log 요청을 해야 확인할 수 있음)
   • http://localhost:8080/actuator/metrics/http.server.requests?tag=uri:/log
2. /log 요청 & HTTP Status = 200
   • http://localhost:8080/actuator/metrics/http.server.requests?tag=uri:/log&tag=status:200

1.3. 다양한 메트릭

마이크로미터와 액츄에이터가 기본으로 제공하는 다양한 메트릭을 확인해보자.

• JVM 메트릭 (jvm.)
• 시스템 메트릭 (system., process., disk.)
• 애플리케이션 시작 메트릭 (application.)
• 스프링 MVC 메트릭
• 톰캣 메트릭
• 데이터 소스 메트릭
• 로그 메트릭
• 기타 수 많은 메트릭이 있다.
• 사용자가 메트릭을 직접 정의하는 것도 가능하다. 뒤에서 예제로 만들어본다.

(1) JVM 메트릭

JVM 관련 메트릭을 제공한다. jvm. 으로 시작한다.

• 메모리 및 버퍼 풀 세부 정보
• 가비지 수집 관련 통계
• 스레드 활용
• 로드 및 언로드된 클래스 수
• JVM 버전 정보
• JIT 컴파일 시간

(2) 시스템 메트릭

시스템 메트릭을 제공한다. system., process., disk. 으로 시작한다.

• CPU 지표
• 파일 디스크립터 메트릭
• 가동 시간 메트릭
• 사용 가능한 디스크 공간

(3) 애플리케이션 시작 메트릭

애플리케이션 시작 시간 메트릭을 제공한다.

• application.started.time : 애플리케이션을 시작하는데 걸리는 시간
  (ApplicationStartedEvent 로 측정)
• application.ready.time : 애플리케이션이 요청을 처리할 준비가 되는데 걸리는 시간
  (ApplicationReadyEvent 로 측정)

스프링은 내부에 여러 초기화 단계가 있고 각 단계별로 내부에서 애플리케이션 이벤트를 발행한다.

• ApplicationStartedEvent : 스프링 컨테이너가 완전히 실행된 상태이다. 이후에 커맨드 라인 러너가 호출된다.
• ApplicationReadyEvent : 커맨드 라인 러너가 실행된 이후에 호출된다.

(4) 스프링 MVC 메트릭

스프링 MVC 컨트롤러가 처리하는 모든 요청을 다룬다.
메트릭 이름 : http.server.requests

TAG 를 사용해서 다음 정보를 분류해서 확인할 수 있다.

• uri : 요청 URI
• method : GET, POST 같은 HTTP 메서드
• status : 200, 400, 500 같은 HTTP Status 코드
• exception : 예외
• outcome : 상태코드를 그룹으로 모아서 확인
  • 1xx:INFORMATIONAL
  • 2xx:SUCCESS
  • 3xx:REDIRECTION
  • 4xx:CLIENT_ERROR
  • 5xx:SERVER_ERROR

(5) 데이터소스 메트릭

DataSource, 커넥션 풀에 관한 메트릭을 확인할 수 있다.

jdbc.connections. 으로 시작한다.

최대 커넥션, 최소 커넥션, 활성 커넥션, 대기 커넥션 수 등을 확인할 수 있다.

Hikari 커넥션 풀을 사용하면 hikaricp. 을 통해 히카리 커넥션 풀의 자세한 메트릭을 확인할 수 있다.

(6) 로그 메트릭

logback.events : logback 로그에 대한 메트릭을 확인할 수 있다.

trace, debug, info, warn, error 각각의 로그 레벨에 따른 로그 수를 확인할 수 있다.

예를 들어서 error 로그 수가 급격히 높아진다면 위험한 신호로 받아드릴 수 있다.

(7) 톰캣 메트릭

톰캣 메트릭은 tomcat. 으로 시작한다.

톰캣 메트릭을 모두 사용하려면 다음 옵션을 켜야한다. (옵션을 켜지 않으면 tomcat.session. 관련 정보만 노출된다.)

application.yml

server:
	tomcat:
		mbeanregistry:
			enabled: true

톰캣의 최대 쓰레드, 사용 쓰레드 수를 포함한 다양한 메트릭을 확인할 수 있다.

(8) 기타

• HTTP 클라이언트 메트릭 (RestTemplate, WebClient)
• 캐시 메트릭
• 작업 실행과 스케줄 메트릭
• 스프링 데이터 리포지토리 메트릭
• 몽고DB 메트릭
• 레디스 메트릭

(9) 사용자 정의 메트릭

사용자가 직접 메트릭을 정의할 수도 있다. 예를 들어서 주문수, 취소수를 메트릭으로 만들 수 있다.

사용자 정의 메트릭을 만들기 위해서는 마이크로미터의 사용법을 먼저 이해해야 한다. 이 부분은 뒤에서 다룬다.

---

정리

액츄에이터를 통해서 수 많은 메트릭이 자동으로 만들어지는 것을 확인했다. 그런데 이러한 메트릭들을 어딘가에 지속해서 보관해야 과거의 데이터들도 확인할 수 있을 것이다. 따라서 메트릭을 지속적으로 수집하고 보관할 데이터베이스가 필요하다. 그리고 이러한 메트릭들을 그래프를 통해서 한눈에 쉽게 확인할 수 있는 대시보드도 필요하다.

참고: 지원하는 다양한 메트릭들은 다음 공식 메뉴얼을 참고하자
https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.metrics.supported

0x02. 프로메테우스 & 그라파나

2.1. 프로메테우스, 그라파나 소개

💡

프로메테우스: 메트릭을 수집하고 보관하는 DB 이다. 애플리케이션에서 발생한 메트릭을 그 순간만 확인하는 것이 아니라 과거 이력까지 함께 확인하려면 메트릭을 보관하는 DB가 필요하다. 이렇게 하려면 어디선가 메트릭을 지속해서 수집하고 DB에 저장해야 한다. 프로메테우스가 바로 이런 역할을 담당한다.

💡

그라파나: 프로메테우스가 DB라고 하면, 이 DB에 있는 데이터를 불러서 사용자가 보기 편하게 보여주는 대시보드가 필요하다. 그라파나는 매우 유연하고, 데이터를 그래프로 보여주는 툴이다. 수 많은 그래프를 제공하고, 프로메테우스를 포함한 다양한 데이터소스를 지원한다.

(1) 전체 구조

1. 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다.
   • 마이크로미터 프로메테우스 구현체는 프로메테우스가 읽을 수 있는 포멧으로 메트릭을 생성한다.
2. 프로메테우스는 이렇게 만들어진 메트릭을 지속해서 수집한다.
3. 프로메테우스는 수집한 메트릭을 내부 DB에 저장한다.
4. 사용자는 그라파나 대시보드 툴을 통해 그래프로 편리하게 메트릭을 조회한다. 이때 필요한 데이터는 프로메테우스를 통해서 조회한다.

(2) 프로메테우스 아키텍처

참고: 프로메테우스와 그라파나는 그 내용만 다루는 책이 있을 정도로 내용이 방대하다. 프로메테우스와 그라파나에 대한 자세한 내용은 강의 범위를 벗어난다. 여기서는 각각의 기술들을 어떻게 다루고 활용해야 하는지, 기초 내용과 올바른 방향을 설명하는데 초점을 맞춘다. 더 자세한 내용이 필요한 경우 별도의 학습이 필요하다.