[spring boot] 마이크로미터, 프로메테우스, 그라파나

현서황·2024년 10월 16일
Spring boot김영한

SPRING BOOT-핵심원리와활용

목록 보기
11/11

마이크로미터

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

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

그라파나 대시보드

핀포인트

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

모니터링 툴에 지표 전달

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

모니터링 툴 변경

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

마이크로미터 추상화

마이크로미터 전체 그림

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

마이크로미터가 지원하는 모니터링 툴은 다음과 같다.
AppOptics
Atlas
CloudWatch
Datadog
Dynatrace
Elastic
Ganglia
Graphite
Humio
Influx
Instana
JMX
KairosDB
New Relic
Prometheus
SignalFx
Stackdriver
StatsD
Wavefront

메트릭 확인하기

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

쉽게 이야기해서 스프링 부트 액츄에이터를 사용하면 수 많은 메트릭(지표)를 편리하게 사용할 수 있다.
이제 기본으로 제공하는 메트릭들을 확인해보자.
아직 모니터링 툴을 연결한 것은 아니고, 등록된 메트릭들을 확인해보는 단계이다.

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

  • 액츄에이터가 마이크로미터를 통해 등록한 기본 메트릭들을 확인할 수 있다.
  • 내용이 너무 많아 일부만 남겨두었다.

metrics 엔드포인트는 다음과 같은 패턴을 사용해서 더 자세히 확인할 수 있다.
http://localhost:8080/actuator/metrics/{name}

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

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

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

  • tag:area, values[heap, nonheap]
  • tag:id, values[G1 Survivor Space, ...]
    해당 Tag를 기반으로 정보를 필터링해서 확인할 수 있다.
    tag=KEY:VALUE와 같은 형식을 사용해야 한다.

다음과 같이 실행해보자.

또 다른 예시는 다음과 같다.

다양한 메트릭

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

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

JVM 메트릭

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

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

시스템 메트릭

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

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

애플리케이션 시작 메트릭

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

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

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

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

스프링 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
profile
현서황
노는 게 제일 좋은 뽀로로
이전 포스트

[spring boot] 액츄에이터

0개의 댓글