액츄에이터로 해왔던 정보들은 한눈에 알아보기가 쉽지 않다. 한눈에 알아보기위해서는 모니터링 툴을 사용해야 하는데 요즘 같은 경우는 그라파나, 핀포인트 를 주로 사용한다.
모니터링 툴을 어떻게 사용하는지 알아보자
모니터링 툴에 지표 전달
특정 모니터링 툴을 사용하려면 그 모니터링에서 요구하는 조건에 맞춰 데이터를 보내야 한다. 하지만 모니터링 툴이 갑자귀 바뀐다면?? 또 다시 하나하나 요구하는 조건에 맞춰줘야 한다.
이러한 점을 보안하고자 마이크로미터 라는 라이브러리를 사용할 예정이다.
마이크로미터는 애플리케이션 메트릭 파사드라고 불리는데 애플리케이션의 메트릭을 마이크로미터가 정한 표준 방법으로 모아서 제공해줌. 즉 애플리케이션에서 나온 정보들을 마이크로미터가 정한 방법으로 알아서 바꿔준다.
마이크로미터 추상화를 통해 구현체만 갈아껴주면 된다.
스프링부트 액츄에이터는 마이크로미터를 기본으로 내장하고 있다.
마이크로미터가 정한 표준 방법으로 메트릭만 전달하면 됀다
마이크로미터가 제공하는 표준 방법에 따라 등록해보자. 다행히도 스프링 부트 액츄에이터는 마이크로미터가 제공하는 지표 수집을 @AutoConfiguration 을 통해 자동으로 등록 해준다.
액츄에터를 사용하면 메트릭을 편리하게 사용할 수 있다.
availableTags 의 tag 이름으로 데이터를 필터링해서 확인할 수 있다.
tag=KEY:VALUE
- JVM 메트릭
- 시스템 메트릭
- 애플리케이션 시작 메트릭
- 스프링 MVC 메트릭
- 톰캣 메트릭
- 데이터 소스 메트릭
- 로그 메트릭
등등 수많은 메트릭들이 존재한다.
사용 방법은 지금까지 본것들과 비슷하며 톰캣 메트릭만 주의해서 보면 된다.
-> 액츄에이터를 통해 수 많은 메트릭이 자동으로 만들어 진다. 이 수많은 메트릭들을 어딘가에 저장하고 관리할 공간이 필요하다.(과거의 데이터도 확인가능)
이때 사용할 수 있는 데이터베이스가 바로 프로메테우스다.
프로메테우스: 메트릭을 지속적으로 저장 관리하는 데이터 베이스
그라파나: 프로메테우스에서 나오는 데이터 값들을 사용자가 보기편하게 뷰 대시보드로 전환시켜주는 툴이다.
- 애플리케이션 설정: 프로메테우스가 애플리케이션의 메트릭을 가져갈 수 있도록 애플리케이션에서 프로메테우스 포멧에 맞추어 메트릭 만들기
- 프로메테우스 설정: 프로메테우스가 우리 애플리케이션의 메트릭을 주기적으로 수집하도록 설정
implementation 'io.micrometer:micrometer-registry-prometheus'
마이크로미터 프로메테우스 구현 라이브러리 추가
이렇게 하면 스프링 뿌트와 액츄에이터가 자동으로 마이크로미터 프로메테우스 구현체를 등록해서 동작하도록 설정 해줌
이런식으로 모든 메트릭이 프로메테우스 포맷으로 만들어 진 것을 확인할 수 있다.
프로메테우스는 . 대신에 _ 포맷을 사용한다
ex: jvm.info -> jvm_info
지속해서 숫자가 증가하는 메트릭을 카운터라 한다. 프로메테우스에서는 카운트 메트릭 맨 마지막에 관례상 _total을 붙인다.
http_server_requests_seconds_count : 요청 수 http_server_requests_seconds_sum : 시간 합(요청수의 시간을 합함) http_server_requests_seconds_max : 최대 시간(가장 오래걸린 요청 수)
메트릭을 프로메테우스가 원하는 형식으로 맞춰 줬다면 이제 프로메테우스 쪽에서 주기적으로 그 데이터들을 수집하도록 설정 해주자
프로메테우스가 깔려있는 경로에서 yml에 추가해 준다
위에서부터 순서대로 수집하는이름, 수집할 경로, 수집할주기 , 수집할 서버의 IP,PORT
localhost:9090/targets
yml 설정후 다시 프로메테우스를 껏다키면 잘 동작하는걸 볼 수 있다.
메트릭은 크게 두가지로 분류할 수 있다.
1.게이지
-임의로 오르내릴 수 있는 값
2.카운터
- 단순하게 증가하는 단일 누적 값
ex -> increase(http_server_requests_seconds_count{uri="/log"}[1m])
즉, 간단히 말해 초당 얼마나 증가하는지 나타낸다.
애플리케이션 ->메트릭정보를 -> 프로메테우스에서 수집하고 조회가능 하지만 한눈에 보기 어렵다
한눈에 보기쉬운 대쉬보드 즉 그라파나를 만들어보자
설치하고 bin 폴더에서 ./grafana-server , 사전오류는 프로메테우스 처럼 설정가서 풀어주면 됌
이렇게 원하는 데이터들을 패널로 수집해 패널을 채워 나갈수 있다. 하지만 이런식으로 하나하나 다 커스터 마이징 하는건 시간이 오래 걸린다. 그래서 우린 누군가가 잘 만들어 놓은 대시보드를 사용하는 방법도 있다!
https://grafana.com/grafana/dashboards/11378-justai-system-monitor/
단일값, 하나씩증가 , 누적이므로 전차 값을 포함(total)
프로메테우스에서는 일반적으로 카운터의 이름 마지막에 _total을 붙임
값을 증가하거나 0으로 초기화 하는 것만 가능
카운터를 통해 주문과 주문 취소시 카운트를 하는 메서드를 만들었다.Counter.builder(name) name에는 메트릭 이름을 지정한다.
tag는 프로메테우스에서 필터할 수 있는 레이블로 사용된다
regitser로 만든 카운터를 MeterRegistry에 등록 한다
- 여기서 AtomicInter란 멀티쓰레드 상황에서 안전하게 값을 증가시킬 수 있는 Integer
=> 이렇게 하면 액츄에이터에서 메트릭 확인가능, 즉 프로메테우스에서 도 확인 가능하다는 말!
등록1 방법으로도 메트릭을 등록할 수 있지만 더 쉬운 방법도 존재한다. 또한 방법 1의 가장 큰 문제는 메트릭을 관리하는 로직이 핵심 비즈니스 개발 로직에 침범 했다는 점!
이럴때는 AOP를 사용하면 된다! 하지만 이미 마이크로미터는 이런 상황에 필요한 AOP를 구현해 놨다.
@Counted(메트릭 이름) 을 통해 측정을 원하는 메서드에 적용만 시켜주면 된다. 이렇게 적용만 시켜주면 tag에 method를 기준으로 분류해서 적용한다.
주의 해야할점은 Bean 등록을 통해 CountedAspect를 등록 해줘야 한다는점! 이것을 적용시켜줘야 @Counted를 인지해서 Counter을 사용하는 AOP를 적용한다.
- seconds_count : 누적실행수-카운터
- seconds_sum : 실행 시간의 합 -sum
- seconds_max : 가장 오래걸린 실행 시간 - 게이지
사용법은 counter와 매우 흡사해 비슷한 부분은 설명을 생략한다
주문과 취소 메트릭 이름은 같지만 tag로 구별하게 만들었다.
카운터처럼 increment() 대신 timer.record() 를 사용
걸리는 시간을 확인하기 위해 주문은 0.5초 , 취소는 0.2초 대기하도록 함.
액츄에이터 메트릭을 확인해보면 누적실행수, 실행시간의 합, 최대 실행 시간을 알 수 있다.
프로메테우스에서는 seconds_count , seconds_sum , seconds_max 접두사가 붙으면서 나온다. (카운터는 _total)
이 데이터를 토대로 해당 PromQl로 그라파나에 적용시킬 수 있다.(프로메테우스에서 가져온 데이터들, my_order 뒤에 seconds_xxx접두사가 붙은걸 보면 알수있다.
increase(my_order_seconds_count{method="order"}[1m])
increase(my_order_seconds_count{method="cancel"}[1m])
- 카운터와 게이지를 구분할 때는 값이 감소할 수 있는가를 고민해보자