SpringBoot 및 Micrometer를 사용하여 애플리케이션 메트릭 생성

소개

Observability는 최신 마이크로서비스 아키텍처의 기둥 중 하나입니다. 애플리케이션 메트릭은 해당 관찰 가능성의 한 차원입니다. 애플리케이션이 프로덕션 환경에서 실행될 때 우리는 메모리, CPU, 스레드 풀 사용량 등과 같은 다양한 운영 메트릭과 비즈니스 메트릭(예: 특정 작업에 대한 요청 수)을 알고 싶을 수 있습니다.
마이크로미터의 도움으로 스프링 부트를 사용하면 애플리케이션 개발자가 다양한 메트릭을 노출할 수 있습니다.

메트릭 설정

메트릭에 대한 지원을 추가하려면 액추에이터 종속성을 추가해야 합니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

또한 다음과 같이 메트릭 엔드포인트를 활성화해야 합니다.

management:
  endpoints:
    web:
      exposure:
        include: metrics

이것이 우리 애플리케이션이 이제 메트릭을 노출하도록 설정한 것입니다.

아래 컬

curl localhost:8080/actuator/metrics | jq .

-와 같은 응답을 줄 것입니다.

{
  "names": [
    "application.ready.time",
    "application.started.time",
    "disk.free",
    "disk.total",
    "executor.active",
    "executor.completed",
    "executor.pool.core",
    "executor.pool.max",
    "executor.pool.size",
    "executor.queue.remaining",
    "executor.queued",
    "hikaricp.connections",
    "hikaricp.connections.acquire",
    "hikaricp.connections.active",
    "hikaricp.connections.creation",
    "hikaricp.connections.idle",
    "hikaricp.connections.max",
    "hikaricp.connections.min",
    "hikaricp.connections.pending",
    "hikaricp.connections.timeout",
    "hikaricp.connections.usage",
    "http.server.requests",
    "jdbc.connections.active",
    "jdbc.connections.idle",
    "jdbc.connections.max",
    "jdbc.connections.min",
    "jvm.buffer.count",
    "jvm.buffer.memory.used",
    "jvm.buffer.total.capacity",
    "jvm.classes.loaded",
    "jvm.classes.unloaded",
    "jvm.gc.live.data.size",
    "jvm.gc.max.data.size",
    "jvm.gc.memory.allocated",
    "jvm.gc.memory.promoted",
    "jvm.gc.overhead",
    "jvm.gc.pause",
    "jvm.memory.committed",
    "jvm.memory.max",
    "jvm.memory.usage.after.gc",
    "jvm.memory.used",
    "jvm.threads.daemon",
    "jvm.threads.live",
    "jvm.threads.peak",
    "jvm.threads.states",
    "logback.events",
    "process.cpu.usage",
    "process.files.max",
    "process.files.open",
    "process.start.time",
    "process.uptime",
    "system.cpu.count",
    "system.cpu.usage",
    "system.load.average.1m",
    "tomcat.sessions.active.current",
    "tomcat.sessions.active.max",
    "tomcat.sessions.alive.max",
    "tomcat.sessions.created",
    "tomcat.sessions.expired",
    "tomcat.sessions.rejected"
  ]
}

이것은 스프링 부트가 즉시 제공하는 메트릭입니다. jvm 메모리, 스레드, CPU 사용량 등이 포함되어 있음을 알 수 있습니다.

아래 요청은 사용된 jvm 메모리를 보여줍니다.

 curl 'http://localhost:8080/actuator/metrics/jvm.memory.max'| jq .


 {
  "name": "jvm.memory.max",
  "description": "The maximum amount of memory in bytes that can be used for memory management",
  "baseUnit": "bytes",
  "measurements": [
    {
      "statistic": "VALUE",
      "value": 5620367357
    }
  ],
  "availableTags": [
    {
      "tag": "area",
      "values": [
        "heap",
        "nonheap"
      ]
    },
    {
      "tag": "id",
      "values": [
        "CodeHeap 'profiled nmethods'",
        "G1 Old Gen",
        "CodeHeap 'non-profiled nmethods'",
        "G1 Survivor Space",
        "Compressed Class Space",
        "Metaspace",
        "G1 Eden Space",
        "CodeHeap 'non-nmethods'"
      ]
    }
  ]
}

지표는 여러 차원을 가질 수 있습니다. 예를 들어 jvm.memory.max의 크기는 heap 및 nonheap입니다. 와 같은 태그를 사용하여 메트릭을 드릴다운할 수 있습니다.

curl 'http://localhost:8080/actuator/metrics/jvm.memory.max?tag=area:heap' | jq .

{
  "name": "jvm.memory.max",
  "description": "The maximum amount of memory in bytes that can be used for memory management",
  "baseUnit": "bytes",
  "measurements": [
    {
      "statistic": "VALUE",
      "value": 4294967294
    }
  ],
  "availableTags": [
    {
      "tag": "id",
      "values": [
        "G1 Old Gen",
        "G1 Survivor Space",
        "G1 Eden Space"
      ]
    }
  ]
}

지금까지 우리는 스프링 부트가 메트릭을 노출하고 해당 메트릭을 얻기 위해 메트릭 엔드포인트를 요청할 수 있으며 필요한 경우 사용 가능한 태그를 사용하여 이 메트릭을 드릴다운할 수 있다는 것을 알고 있습니다.

맞춤 측정항목

더 많은 메트릭이 필요한 경우 어떻게 해야 합니까?

Spring은 Micrometer (https://micrometer.io/)을 사용하여 메트릭 생성 및 노출을 처리합니다.MeterRegistry는 여러 메트릭을 보유하는 마이크로미터의 핵심 개념입니다.

아래와 같이 사용자 지정 메트릭 공급자에 MeterRegistry의 인스턴스를 간단히 주입할 수 있습니다.

@Component
public class InventoryMetrics{
    private Counter inventoryCounter;

    public InventoryMetrics(MeterRegistry meterRegistry){
        inventoryCounter = Counter.builder("products")
                .description("Product Count")
                .register(meterRegistry);
    }

    public void inventoryAdded(int count){
        inventoryCounter.increment(count);
    }
}

여기에서 products라는 새 메트릭을 생성했으며 새 제품을 추가할 때마다 값이 증가합니다.

이제 메트릭 끝점을 컬링하면 제품 수를 얻습니다.

curl 'http://localhost:8080/actuator/metrics/products' | jq .

{
  "name": "products",
  "description": "Product Count",
  "baseUnit": null,
  "measurements": [
    {
      "statistic": "COUNT",
      "value": 2
    }
  ],
  "availableTags": []
}

스트리밍 지표

프로덕션 환경에서 Elasticsearch, influxdb 등과 같은 데이터 저장소로 메트릭을 스트리밍하려고 합니다. Spring Boot는 기본적으로 다양한 데이터 싱크https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.metrics를 지원합니다.

이 게시물에서는 influxdb 도커 이미지를 로컬에서 실행했습니다. 사용자 정의 측정항목이 유입되는 것을 볼 수 있습니다.



응용 프로그램 측 구성은 다음과 같습니다.

management:
  metrics:
    export:
      influx:
        uri: 'http://localhost:8086'
        token: '<your-token>'
        bucket: '<your bucket>'
        org: '<your org>'
        autoCreateDb: false

NOTE: Config properties for influxdb 1.x and 2.x different.
The above config is for influxdb 2.x. For 1.x we need to use username , password and db instead of token,bucket and org. Also autoCreateDb should be false as otherwise springboot will try to create a db named mydb .

마이크로미터 메트릭 유형

카운터 카운터는 단조롭게 증가하는 메트릭입니다. 항상 양수인 고정된 양만큼 증가할 수 있습니다.

게이지 게이지는 올라가거나 내려갈 수 있는 즉각적인 지표입니다.

타이머 타이머는 짧은 기간의 대기 시간과 이벤트 빈도입니다.

우리의 커스텀 메트릭은 추가된 제품을 측정하기 위한 일종의 카운터입니다.

이것은 매우 높은 수준에서 메트릭을 노출하는 방법입니다.

프로덕션에서는 메트릭의 볼륨을 인식해야 합니다. 볼륨과 빈도가 높으면 대시보드가 ​​정말 느려질 수 있기 때문입니다.

불필요한 오래된 데이터를 저장하지 않도록 데이터 보존 정책도 생각해야 합니다. 이렇게 하면 저장 공간을 절약하는 데 도움이 됩니다.

결론적으로 메트릭은 서비스의 필수 부분이며 스프링 부트를 사용하면 쉽게 수집하고 다양한 데이터 싱크에 노출할 수 있습니다.