1. 마이크로미터란

   

   모니터링 툴에 지표 전달

   

   모니터링 툴 변경하는 경우

   1. CPU, JVM 커넥션 정보를 JMX에 전달하는 예제
   2. 이처럼 전달하기 위해서는 각 모니터링 툴에 맞춰 정보를 포멧에 맞추어 전달해야함
   3. 만약 모니터링 툴을 변경한다면 각 툴에 맞게 다시 수정해야함
   4. 이러한 문제를 해결하는 것이 마이크로미터 라이브러리

2. 마이크로미터 추상화

   

   1. 마이크로미터는 애플리케이션 메트릭 파사드(파서?)라고 불리는데, 애플리케이션 매트릭(측정 지표)를 마이크로미터가 정한 표준 방식으로 모아서 제공
   2. 스프링이 자주 사용하는 추상화 방법이며, 이미 잘 만들어진 상태이기 때문에 스프링도 마이크로미터를 공식 사용
   3. 개발자는 마이크로미터 기준에 맞춰 메트릭(지표 전달)을 전달하고 모니터링 툴은 취향에 맞게 선택
   4. 마이크로미터가 지원하는 모니터링 툴
      1. 참고: https://micrometer.io/docs
      2. AppOptics
      3. Atlas
      4. Elastic

3. 메트릭 확인

   

   1. 마이크로미터는 다양한 지표 수집 기능을 제공

   2. 스프링부트 액츄에이터는 마이크로미터가 제공하는 지표 수집을 자동 구성으로 제공

   3. /actuator/metrics 에서 기본 제공 메트릭 확인 가능

   4. /actuator/metrics/{name} 으로 names별로 확인 가능

   5. tag 필터

      

      1. availableTags를 통해 사용할 수 있는 tag 조회 가능(필터 유사)
      2. tag=key:value 형식으로 사용(예: tag=area:heap)
      3. /actuator/metrics/jvm.memory.used?tag=area:heap 으로 jvm 메모리 사용량 중에서 파라미터로 넘겨진 heap영역만 조회

4. 다양한 메트릭(추가 메트릭 많음)

   1. 참조: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.metrics.supported

   2. JVM 메트릭

      1. jvm. 으로 시작
      2. 메모리 및 버퍼 풀 세부 정보
      3. 가비지 수집 관련 통계
      4. 스레드 활용
      5. 로드 및 언로드된 클래스 수
      6. JVM 버전 정보
      7. JIT(JUST IN TIME: 즉시) 컴파일 시간

   3. 시스템 메트릭

      1. system. process. disk. 로 시작
      2. CPU 지표
      3. 파일 디스크립터 메트릭
      4. 가동 시간 메트릭
      5. 사용 가능한 디스크 공간

   4. 애플리케이션 시작 메트릭

      1. application.started.time: 애플리케이션 시작하는데 걸리는 시간(ApplicationStartedEvent로 측정)
      2. application.ready.time: 애플리케이션이 요청을 처리한 준비가 되는데 걸리는 시간(ApplicationReadyEvent로 측정)
      3. ApplicationStartedEvent: 스프링 컨테이너가 완전히 실행된 상태, 이후 커맨드 라인 러너 실행
      4. ApplicationReadyEvent: 커맨드 라인 러너가 실행된 이후에 호출

   5. 스프링 MVC 메트릭

      1. 스프링 MVC 컨트롤러가 처리하는 모든 요청을 다룸
      2. http.server.requests 로 접근
      3. Tag를 통해 상세 접근 가능
         1. uri: 요청 URI
         2. method: GET, POST와 같은 메서드
         3. status: 200, 400 등과 같은 상태 코드
         4. exception: 예외
         5. outcome
            1. 상태코드를 그룹으로 모아서 확인
            2. 1xx: INFORMATION
            3. 2xx: SUCCESS
            4. 3xx: REDIRECTION
            5. 4xx: CLIENT_ERROR
            6. 5xx: SERVER_ERROR

   6. 데이터소스 메트릭

      1. 커넥션 풀에 대한 메트릭 확인
      2. jdbc.connections 으로 시작
      3. 최대 커넥션
      4. 최소 커넥션
      5. 활성 커넥션
      6. 대기 커넥션
      7. hikaricp를 사용하는 경우 hikaricp.connections 에서 좀 더 상세한 정보 확인 가능

   7. 로그 메트릭

      1. logback.events 로 시작
      2. logback 로그에 대한 메트릭 확인
      3. trace, debug, info, warn, error 각 레벨에 따른 로그 수 확인 가능
      4. 예시로 error가 급격히 늘어난다면 시스템 장애를 예상할 수 있음

   8. 톰캣 메트릭

      

      1. tomcat. 으로 시작
      2. 톰캣 메트릭을 모두 사용하려면 위 처럼 옵션을 사용하도록 해야함
      3. 옵션을 키지 않는 경우 tomcat.session. 관련 정보만 노출
      4. 활성화 옵션 중 tomcat.threads.busy, tomcat.threads.config.max 메트릭은 유용함

   9. 사용자 정의 메트릭

      1. 사용자가 필요한 정보를 직접 메트릭 작성
      2. 마이크로미터를 먼저 이해해야 작성 가능 좀 있다 작성

5. 전체 구조

   

   

   1. 스프링 부트 액츄에이터, 마이크로미터를 사용하면 많은 메트릭을 자동 생성
   2. 프로메테우스는 표준에 맞춰 수집된 메트릭을 수집
   3. 수집한 메트릭을 내부 DB에 저장
   4. 사용자는 그라파나 대시보드 툴을 통해 그래프로 메트릭 조회, 필요한 정보는 프로메테우스를 통해 조회

6. 프로메테우스란

   1. 애플리케이션에서 발생한 메트릭을 순간뿐만 아니라 과거 이력까지 함께 조회하기 위해 DB가 필요함
   2. 프로메테우스가 수집, DB 저장 등의 역할을 담당
   3. 연동을 위한 2가지 작업
      1. 애플리케이션 설정: 프로메테우스가 애플리케이션 메트릭을 가져갈 수 있도록 애플리케이션에서 프로메테우스 포멧에 맞추어 메트릭 생성
      2. 프로메테우스 설정: 프로메테우스가 애플리케이션 메트릭을 주기적으로 가져가도록 설정
   4. 애플리케이션 설정

      1. 프로메테우스는 /actuator/metrics 를 통해 보았던 JSON 이해하지 못지만 마이크로미터를 통해 해결 가능

      2. 각 메트릭은 마이크로미터 표준을 사용하기 때문에 구현만 지정해주면됨

      3. gradle

         

         1. 자동으로 마이크로미터 프로메테우스 구현체를 등록해서 동작하도록 설정

         2. /actuator/prometheus 엔드포인트 자동 추가

            

      4. 포맷의 차이

         1. jvm.info → jvm_info 와 같이 . 대신 _ 사용
         2. logback.events → logback_events_total 로그수 처럼 숫자가 증가하는 메트릭은 카운터라고 하는데, 프로메테우스에서는 카운트 메트릭의 마지막에 _total 이 관례
         3. http.server.requests 내부 요청수, 시간 합, 최대 시간 정보를 가지는데 프로메테우스는 분리해서 사용
            1. http_server_requests_seconds_count: 요청수
            2. http_server_requests_seconds_sum: 시간 합(요청수의 시간을 합함)
            3. http_server_requests_seconds_max: 최대 시간(가장 오래걸린 요청의 시간 → 최근 x분)

![Untitled](<https://s3-us-west-2.amazonaws.com/secure.notion-static.com/1a3133a2-edff-4a57-ab05-16589d1122c1/Untitled.png>)

![Untitled](<https://s3-us-west-2.amazonaws.com/secure.notion-static.com/3531143e-0bf6-4983-bd8c-1140849e8763/Untitled.png>)

1. 애플리케이션에서 프로메테우스가 수집할 수 있는 데이터를 만들었으니 주기적으로 수집할 수 있도록 설정해야함
2. 프로메테우스 폴더의 `prometheus.yml`을 수정(depth 주의)
    1. `job_name`: 수집하는 이름, 임의의 이름 사용해도 됨
    2. `metrics_path`: 수집할 경로(애플리케이션에서 metrics 경로)
    3. `scrape_interval`: 수집할 주기를 설정(기본값은 1분이며 보통 운영 단계에서 10s ~ 1m 정도 권장 → 너무 빠를 경우 성능 저하 원인)
    4. `targets`: 수집할 애플리케이션 IP, PORT를 지정
    5. 위 설정을 하게되면 1초마다 애플리케이션 metrics를 수집
3. [<http://localhost:9090>](<http://localhost:9090>)에서 확인 가능(status → targets)

8. 프로메테우스 기본 설정
9. 프로메테우스 게이지와 카운터
10. 프로메테우스 참조 자료
11. 그라파나란
12. 그라파나 연동
13. 그라파나 대시보드 만들기
14. 그라파나 공유 대시보드 활용
15. 그라파나를 활용한 문제 확인