springboot2 actuator micrometer

마이크로 미터는 2017년  4월 중순  Jon Schneider (슈나이더?) 에 의해 시작되었다. 원래 넷플릭스 직원이었고, 우리도 애용하고 있는 nebula의 몇몇 플러그인 개발자 였다. 하여튼 (동일한 시기에 Pivotal로 이직을 해서인지?, 어떤 이유에서인지)  슈나이더는 micrometer를 시작하였고 "Experimental ground for Spring metrics work" 라는 최초의 커밋을 남겼다.

https://github.com/micrometer-metrics/micrometer/commit/4df27760

그가 micrometer에 대해서 소개한 글이다. 대충 필요하다고 생각되는 내용만 옮겨 적음

https://spring.io/blog/2018/03/16/micrometer-spring-boot-2-s-new-application-metrics-collector

What is it?

마이크로미터(Micrometer)는 벤더중립(vender neutral) API를 이용해서 내 코드를 시간, 카운트, 계측 할 수 있는 차원 우선 계측 집합의 facade이다. (dimensional-first metrics collection facade) 클래스패스나 설정을 통해서 하나 또는 이상의 모니터링 시스템에 메트릭 데이터를 보낼수(export) 할 수 있다.  메트릭 계의 SLF4J 라고 생각하면 된다. 

마이크로미터는 스프링부트1에 존재했던 카운터, 게이지에 더 풍족한 기본 요소를 추가하였다. 예로 단일 마이크로미터 타이머(Timer)는  처리량(throughput), 총 시간(total time), 샘플의 최대 지연시간(maximum latency of recent samples),  퍼센테이지(& 히스토그램)등을 생성 할 수 있다.

차원 측정(dimensional metrics) 에 포커싱을 하고 있지만, 마이크로미터는 계층명(hierarchical names)에 매핑하여 Ganglia 나 JMX 같은 오래된 모니터링 솔루션을 계속 지원한다. 마이크로미터로 변경하게 된 이유는 좀 더 발전된 차원 모니터링 시스템(Prometheus, Datadog, Wavefront, SignalFx, Influx) 때문이다. 

스프링 프레임워크의 장점은 추상화를 이용한 선택을 할 수 있다는 것이다. 마이크로미터를 적용한 이후 하나 이상의 모니터링 시스템을 선택하고, 나중에 metrics 수집부분을 재작성 하지 않고도 모니터링 시스템을 교체할 수 있다.

What do I get out of the box?

스프링 부트 2는 몇가지 메트릭을 포함하고 있다.

* JVM, CPU, Spring Request, RestTemplate, Cache, DataSource, Logback, Tomcat 등등

Which monitoring systems does Micrometer support ?

마이크로미터는 벤더중립적인 메트릭 수집 API(io.micrometer.core.instrument.MeterRegistry) 를 제공하며, 여러 구현체도 가지고 있다.

* Netflix Atlas, Datadog, Influx, JMX, NewRelic, Prometheus 등등

마이크로미터 1.1.0 에서는 다음도 지원할 예정이다.

* AppOptics, Azure Application Insights, Dynatrace, Elasticsearch, StackDriver

스프링부트2는 여러개의 registry implementations 를 등록할 수 있는 MeterRegistry 를 복합(composite) 설정하여 여러개의 모니터링 시스템으로 전송 할 수 있다.  MeterRegistryCustomizer 를 이용한다면 한번에 레지스트리 셋트나 개별 구현을 커스텀마이즈 할 수 있다.

예를 들어 1) Prometheus , CloudWatch로 각각 메트릭을 보내거나 2) 호스트와 Application Tag같은 공통 태그 집합을 추가하거나 3) CloudWatch에는 일부 메트릭에 whitelist를 추가하거나 등등이다.

The distinction between metrics and tracing

메트릭(metrics) 이란 시스템의 성능을 추록할 수 있는 정보 클래스를 뜻한다.  중요한 점은 single request가 여러 구성 요소를 지날때의 대기 시간(total latency) 는 제외(excldue)된다. 이것은 Spring Cloud Sleuth 와 같은 분산 트레이싱 수집기의 역할입니다.

분산 트레이싱 시스템은 subsystem latency 에 대한 자세한 정보를 제공하지만 일반적으로 확장을 위해서 샘플링을 한다. (예를 들어 Sleuthsms 디폴트로 10%만 샘플링한다) 메트릭 데이터는 일반적으로 사전 집계(pre aggregated) 하지만 샘플링을 하지 않는다.

그래서 B와 상호작용을 하는 A의 100,000건의 요청에 대해서

- 메트릭 관점에서 보면 A서비스의 스루풋은 100K, B 처리량은 60K,  A 전체 평균 지연 시간은 100ms, B는 50ms 등을 알 수 있다. 또한 최대 지연 시간 및 다른 통계등도 확인 할 수 있다

- 트레이싱 시스템은 특정한 요청(particular request / 샘플링이기 때문에 전체가 아니다)이 A에서 50ms B에서 90ms가 걸렸을 알려줄 수 있다.

The importance of dimensionality

스프링 부트1 의 메트릭은 계층적 ( hierarchical ) 이었다. 이 말은 수집된 메트릭은 이름으로 인해서 식별이 가능했다. 그래서 jvm.memory.used 라는 메트릭이 있을 수 있다. 단일 어플리케이션 인스턴스에서 메트릭을 확인 하는 경우 적합하지만, 10개의 인스턴스일 경우는 어떻할 것인가? 메모리 소비량이 예상외로 급증하면 어떻게 구별할 것인가? 일반적으로는 이름에 접두/접미사를 추가한다 따라서 이름을 {HOST}.jvm.memory.used로 변경 할 수 있다. 그리고 일반적인 계층 모니터링 시스템(hierarchical monitoring system) 에서는 이름을 와일드카드로 지정(*.jvm.memory.used)해서 메모리의 합계를 확인 할 수 있다. 

이런식으로 region 까지 확장해 나간다면 *.*.jvm.memory.used 라고 사용 할 수는 있다. 하지만 이렇게 새로운 메트릭을 설정해서 전부 배포되기 전까지 제대로 메트릭 정보를 얻을 수 없다. 이 예시는 기존의 계층 모니터링 시스템의 제한 중 하나의 예에 불과하다.

차원 모니터링 시스템(Dimensional monitoring systems) 은 자연스럽게 jvm.memory.used를 하나이상의 태그를 drill 하기전까지 모든 태그에 걸쳐 자연스럽게 표시한다. 우선 이름(jvm.memory.used)를 선택하고  이후 태그에 의한 필터링을 한다 문제가 되는 이전 시나리오처럼 기존 차트가 생성된 다음 나중에 region tag를 추가한 경우에는 기존 메트릭도 중단없이 계속 동작 한다. 

Meter filters

Meter 필터를 이용하면 미터가 등록되는 방법,시기,통계의 종류 등을 제어 할 수 있다. 미터는 3가지 기본 기능을 제공한다.

. 거부 : 미터 등록을 거부/승인 한다.
. 변환 : 이름, 태그의 추가 삭제, 설명이나 기본단위 변경 등을 바꿀 수 있다.
. 설정 : 백분위 수, 타이머 SLA등의 통계 구성을 설정 할 수 있다.

스프링 부트2는 속성을 통해 미터 필터에 바인딩 할 수 있다.

management.metrics.enable.jvm=false
management.metrics.distribution.percentiles-histogram.http.server.requests=true
management.metrics.distribution.sla.http.server.requests=1ms,5ms

위의 설정은 jvm metrics을 해제하고, SpringBoot에 의 http-request 백분위 메트릭을 설정하고, sla 주기를 1ms, 5ms 이하로 셋팅한 것이다.

Why the /actuator/metrics endpoint changed in Spring Boot 2

스프링 부트1 에서는 단지 카운터/게이지만 있었기 때문에 하나의 REST 포인트에 계층적으로 제공하는 것이 간단했습니다. 하지만 차원 모니터링 시스템으로 변경되면서 모든 정보를 하나의 페이로드에 출력할 수 있는 방법이 없다는 사실을 알았다. 

커스텀 된 UI를 원한다면 UI에 필요한 데이터만 표시하는 컴포넌트를 구성하는 것이 좋다. MeterRegistry 를 컴포넌트에 삽입하여 find, get 메소드를 이용해서 필요한 메트릭을 expose 한 뒤 용도에 맞게 직렬화해서 사용하라.