[액추에이터] - 마이크로미터(Micrometer)와 메트릭(Metric)

 

 

 

 

🧐 마이크로미터

서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수와 같은 많은 지표(metric)들을 확인하는 것이 필요합니다.

그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생하더라도 원인을 빠르게 파악해서 대처할 수 있습니다.

 

예를 들어 모니터링을 통해 메모리 사용량이 가득 찼다는 것을 발견했다면, 메모리 문제와 관련있는 곳을 빠르게 찾아서 대응할 수 있을 것입니다.

 

현재 수많은 모니터링 툴이 있므여, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용하게 됩니다.

 

 

다음은 많이 사용되는 모니터링 툴들의 예시입니다.

그라파나 대시보드

 

 

네이버 핀포인트

 

 

 

위와 같은 모니터링 툴들을 사용하기 위해서는, 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 합니다.

(대체로 이 과정은 라이브러리 등을 통해서 자동화되는 경우가 많습니다.)

 

 

 

 

 

 

 

📕 모니터링 툴에 지표 전달

예를 들어서 CPU, JVM, CON(커넥션) 정보 등을 JMX 툴에 전달한다고 가정하겠습니다.

그러면 각각의 정보들을 JMX 모니터링 툴이 정한 형식에 맞추어 측정하고 전달해야 합니다.

 

 

그런데 이 상황에서 만약 모니터링 툴을 변경하게 되면 어떻게 될까요?

기존에 측정했던 코드를 모두 변경한 툴에 맞도록 다시 변경해야 합니다.

모니터링 툴을 변경하는 상황

 

개발자 입장에서는 단순히 모니터링 툴을 변경했을 뿐인데, 지표를 측정하는 코드까지 모두 변경해야 하는 문제가 발생합니다.

 

이러한 문제를 해결하는 것이 바로 마이크로미터(Micrometer)라는 라이브러리입니다.

 

 

 

 

 

 

 

 

 

🧐 마이크로미터 추상화

마이크로미터는 CPU, JVM 등등 여러가지 메트릭(측정 지표)에 대한 표준 측정 방식을 제공합니다.

개발자는 해당 표준에 맞춰서 정보를 전달하기만 하면, 여러 마이크로미터 구현체들을 선택하여 사용할 수 있게 됩니다.

이러한 이유로 마이크로미터는 애플리케이션 메트릭 파사드(Facade)라고 불립니다.

보통 이러한 추상화는 스프링이 직접 만들어서 제공하지만, 마이크로미터라는 이미 잘 만들어진 추상화가 있기 때문에 스프링은 이를 활용합니다. 스프링부트 액추에이터는 마이크로미터를 기본으로 내장해서 사용합니다.

 

개발자는 마이크로미터가 정한 표준 방법으로 메트릭(측정 지표)를 전달하면 됩니다.

그리고 사용하는 모니터링 툴에 맞는 구현체를 선택하면 됩니다.

이후에 모니터링 툴이 변경되어도 해당 구현체만 변경하면 됩니다.

애플리케이션 코드는 모니터링 툴이 변경되어도 그대로 유지할 수 있습니다.

마이크로미터가 제공하는 여러 모니터링 툴들에 대한 정보는 마이크로미터 공식 문서에 나와 있습니다.
https://micrometer.io/docs

 

 

 

 

 

 

 

 

 

 

 

🧐 메트릭 확인하기

CPU, JVM, CON(커넥션) 등등 수 많은 지표들이 존재합니다.

이러한 지표들을 개발자가 하나하나 직접 수집하기는 어려울 것입니다.

 

이를 돕기 위해 마이크로미터는 다양한 지표 수집 기능을 이미 만들어서 제공합니다.

그리고 스프링 부트 액추에이터는 마이크로미터가 제공하는 지표 수집을 @AutoConfiguration을 통해 자동으로 등록해줍니다.

 

따라서 스프링 부트 액추에이터를 사용한다면, 수 많은 메트릭(지표)들을 편리하게 사용할 수 있게 되는 것입니다.

 

 

이제부터 기본적으로 제공되는 메트릭들을 확인해보겠습니다.

(아직 모니터링 툴을 연결한 것은 아니고, 등록된 메트릭들을 확인해보는 과정입니다.)

 

 

 

 

📕 metrics 엔드포인트

액추에이터의 'metrics' 엔드포인트를 사용하면 기본으로 제공되는 메트릭들을 확인할 수 있습니다.

http://localhost:8080/actuator/metrics

 

결과는 다음과 같습니다.

액추에이터가 마이크로미터를 통해서 등록한 기본 메트릭들을 확인할 수 있습니다.

 

 

 

📙 metric 자세히 확인하기

`metrics` 엔드포인트는 다음과 같은 패턴을 사용해서 더 자세한 정보를 확인할 수 있습니다.

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

 

예를 들어 JVM 메모리 사용량은 다음과 같은 주소를 통해 확인할 수 있습니다.

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

 

결과는 다음과 같습니다.

 

 

 

 

 

 

 

📒 Tag 필터

위 사진에서 availableTags를 보면 다음과 같은 항목을 확인할 수 있습니다.

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

 

 

 

한가지 예시를 더 살펴보도록 하겠습니다.

HTTP 요청 관련 메트릭은 다음 주소에서 확인할 수 있습니다.

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

이때 Tag를 통해서 HTTP 요청 관련 일부 내용을 필터링해보겠습니다.

 

 

/log 요청만 필터

http://localhost:8080/actuator/metrics/http.server.requests?tag=uri:/log

 

 

/log요청이면서 HTTP Status 가 200인 것들

http://localhost:8080/actuator/metrics/http.server.requests?tag=uri:/log&tag=status:200

 

 

 

 

 

 

 

 

 

 

🧐 다양한 메트릭

마이크로미터와 액추에이터가 기본으로 제공하는 다양한 메트릭을 간략히 알아보도록 하겠습니다.

종류는 아래와 같습니다.

• JVM
• 시스템
• 애플리케이션 시작
• 스프링 MVC
• 톰캣
• 데이터 소스(DataSource)
• 로그
• 기타 등등..
• 사용자가 직접 메트릭을 정의하는 것도 가능합니다.

 

 

 

 

 

 

🤔 JVM 메트릭

JVM 관련된 메트릭은 jvm. 으로 시작합니다.

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

 

 

 

 

 

 

🤔 시스템 메트릭

시스템 메트릭은 `system.`, `process.`, `disk.` 으로 시작합니다. 

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

 

 

 

 

 

 

🤔 애플리케이션 시작 메트릭

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

 

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

• ApplicationStartedEvent : 스프링 컨테이너가 완전히 실행된 상태일때 발행됩니다. 이후에 CommandLineRunner 가 호출됩니다.
• ApplicationReadyEvent : CommandLineRunner가 실행된 이후에 호출됩니다.

 

 

 

 

 

 

🤔 스프링 MVC 메트릭

스프링 MVC가 처리하는 모든 요청을 다룹니다.

메트릭 이름: http.server.requests

 

 

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

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

 

 

 

 

 

 

🤔 데이터소스 메트릭

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

'jdbc.connections.' 으로 시작합니다.

 

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

 

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

 

 

 

 

 

 

🤔 로그 메트릭

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

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

 

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

 

 

 

 

 

 

🤔 톰캣 메트릭

톰캣 메트릭은 'tomcat.' 으로 시작합니다.

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

 

 

⚙️ application.yml

server:
  tomcat:
    mbeanregistry:
      enabled: true

 

위와 같이 설정하면 다음과 같은 다양한 지표들을 확인할 수 있습니다.

특히 유용한 두개

 

 

tomcat.threads.config.max 최대 스레드 수(동시 처리 가능한 요청 수)를 보여주며,

tomcat.threads.busy는 현재 작동하는 스레드 수를 보여줍니다.

tomcat.threads.config.max

 

tomcat.threads.busy

 

 

 

 

 

 

🤔 기타

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

 

 

 

 

 

 

 

 

🤔 사용자 정의 메트릭

사용자가 직접 메트릭을 정의할 수도 있습니다.

예를 들어 주문수, 취소수를 메트릭으로 만들 수 있습니다.

사용자 정의 메트릭을 만들기 위해서는 마이크로미터의 사용법을 먼저 이해해야 하는데, 이부분은 뒤에서 알아보겠습니다

 

 

 

 

 

 

 

 

🤔 정리

액추에이터를 통해 많은 메트릭이 자동으로 만들어지는 것을 확인했습니다.

그런데 이러한 메트릭들을 어딘가에 지속해서 보관해야 과거의 데이터들도 확인할 수 있을 것입니다.

따라서 메트릭을 지속적으로 수집하고 보관할 데이터베이스가 필요합니다.

그리고 이러한 메트릭들을 그래프를 통해서 한눈에 쉽게 확인할 수 있는 대시보드도 필요합니다.

 

 

참고: 액추에이터가 지원하는 다양한 메트릭은 다음 공식 메뉴얼에 있습니다.
https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.metrics.supported

 

 

 

 

 

 

 

 

 

📚 Reference

[스프링 부트 - 핵심 원리와 활용. 섹션 9] - 김영한님