본문 바로가기

CS study/opentelemetry

Opentelemetry 대표적 수집 metric 정리 (24.05.28)

목차

    Heap Memory (jvm.memory.used)

    • 요약
      1. PS Old Gen (Permanent Space Old Generation)
        • 역할: 오래된 객체를 저장하는 공간이다.
        • 상세 설명:
          • Old Gen 또는 **Tenured Gen**으로도 불린다.
          • 대부분의 객체는 생성 후 곧바로 소멸되지만, 오랫동안 참조되는 객체는 **Old Gen**으로 이동한다.
          • Old Gen 영역에서 객체가 차지하는 메모리가 많아지면 Full Garbage Collection(Full GC)이 발생하여 오래된 객체들을 정리한다.
          • Full GC는 응답 시간이 길어질 수 있기 때문에, **Old Gen**의 메모리 사용량을 모니터링하는 것이 중요하다.
      2. PS Survivor Space
        • 역할: 새롭게 생성된 객체들이 일시적으로 머무르는 공간이다.
        • 상세 설명:
          • Survivor Space는 두 개의 영역으로 나누어진다 (S0, S1 또는 From, To).
          • 객체가 처음 생성되면 **Eden Space**에 할당되며, Minor GC가 발생하면 살아남은 객체는 한쪽 Survivor Space로 이동한다.
          • 다음 Minor GC 시점에서 살아남은 객체는 다른 쪽 Survivor Space로 이동하거나 **Old Gen**으로 이동한다.
          • 이 두 Survivor Space 영역은 교대로 사용되며, 한쪽이 비어있을 때 다른 쪽이 사용된다.
      3. PS Eden Space
        • 역할: 새로 생성된 객체들이 처음으로 할당되는 공간이다.
        • 상세 설명:
          • **Eden Space**는 Young Generation의 일부분으로, 대부분의 객체가 이 공간에서 생성된다.
          • 대부분의 객체는 매우 짧은 생애를 가지며, **Eden Space**에서 곧바로 소멸된다.
          • **Eden Space**가 가득 차면 Minor GC가 발생하여 살아남은 객체가 Survivor Space로 이동한다.
          • Minor GC는 상대적으로 빠르며, **Eden Space**를 비우고 다시 새로운 객체를 할당할 수 있도록 한다.
      JVM 메모리 관리 요약
      • Young Generation:
        • Young Generation은 **Eden Space**와 두 개의 **Survivor Space**로 구성된다.
        • 새로 생성된 객체는 **Eden Space**에 할당되며, Minor GC가 발생하면 살아남은 객체는 **Survivor Space**로 이동한다.
      • Old Generation:
        • Young Generation을 여러 번 거친 객체가 **Old Gen**으로 이동한다.
        • **Old Gen**은 Full GC에서 주로 정리되며, 이는 애플리케이션의 응답 시간에 영향을 줄 수 있다.
    • 힙 메모리 풀 설명

    Non-Heap Memory (jvm.memory.used)

    • 요약
      1. Code Cache
        • 역할: Just-In-Time (JIT) 컴파일된 바이트코드를 저장하는 공간이다.
        • 상세 설명:
          • JVM은 애플리케이션의 성능을 최적화하기 위해 자주 사용되는 메서드를 JIT 컴파일하여 네이티브 코드로 변환한다.
          • 이러한 네이티브 코드는 **Code Cache**에 저장된다.
          • **Code Cache**의 크기가 부족하면 JIT 컴파일러는 추가적인 최적화를 수행할 수 없게 되어 성능 저하가 발생할 수 있다.
      2. Metaspace
        • 역할: 클래스 메타데이터를 저장하는 공간이다.
        • 상세 설명:
          • 이전 JVM 버전에서는 PermGen(Permanent Generation)이라는 이름으로 불렸으나, Java 8부터는 Metaspace로 대체되었다.
          • 클래스 로더가 클래스를 메모리에 로드할 때 클래스 메타데이터가 Metaspace에 저장된다.
          • Metaspace는 기본적으로 시스템 메모리를 사용하며, 필요에 따라 자동으로 확장된다.
          • Metaspace 크기를 제한하려면 JVM 옵션을 사용하여 설정할 수 있다 (XX:MaxMetaspaceSize).
      3. Compressed Class Space
        • 역할: 클래스 메타데이터 중 압축된 클래스를 저장하는 공간이다.
        • 상세 설명:
          • **Compressed Class Space**는 Metaspace의 일부로, 압축된 클래스 참조를 저장하는 데 사용된다.
          • 이는 메모리 효율성을 높이기 위해 클래스 참조를 압축된 형태로 저장하는 방식이다.
          • **Compressed Class Space**의 크기는 JVM이 자동으로 관리하지만, **Metaspace**와 함께 크기를 설정할 수 있다.
    • 주요 non-heap 메모리 풀 설명

    데몬 쓰레드 (jvm.thread.count)

    • 요약
      1. 데몬 스레드 (Daemon Thread)
        • 특징:
          • 데몬 스레드는 JVM이 종료될 때 자동으로 종료된다.
          • 애플리케이션의 백그라운드 작업을 수행하는 데 주로 사용된다.
          • 주 스레드가 모두 종료된 후에도 데몬 스레드는 계속 실행되지만, JVM이 모든 비데몬 스레드가 종료되면 데몬 스레드를 강제로 종료하고 JVM을 종료한다.
        • :
          • 가비지 컬렉터, 스레드 풀 관리 스레드, 타이머 스레드 등 시스템에서 백그라운드로 돌아가는 작업에 주로 사용된다.
      2. 비데몬 스레드 (Non-Daemon Thread)
        • 특징:
          • 비데몬 스레드는 애플리케이션의 주요 작업을 수행하는 스레드이다.
          • 모든 비데몬 스레드가 종료되기 전까지 JVM은 종료되지 않는다.
          • 애플리케이션의 주 스레드와 직접적인 작업을 수행하는 스레드는 대부분 비데몬 스레드이다.
        • :
          • 사용자 요청을 처리하는 스레드, 애플리케이션의 주요 로직을 수행하는 스레드 등.
    • 스레드 유형 설명

    jvm.memory.used_after_last_gc

    • 요약
      • Metric: jvm.memory.used_after_last_gc
      • 출처: MemoryPoolMXBean#getCollectionUsage() 메서드를 통해 수집.
      • 타입: UpDownCounter
      • 단위 (UCUM): By (바이트)
      • 설명: 해당 메모리 풀에서 가장 최근 가비지 컬렉션 이벤트 이후 사용된 메모리 양.
      • 안정성: Stable
      속성 (Attributes)
      1. jvm.memory.pool.name:
        • 유형: string
        • 설명: 메모리 풀의 이름.
        • 예시: "G1 Old Gen", "G1 Eden space", "G1 Survivor Space"
        • 요구 수준: Recommended
        • 안정성: Stable
      2. jvm.memory.type:
        • 유형: string
        • 설명: 메모리의 유형.
        • 예시: "heap", "non_heap"
        • 요구 수준: Recommended
        • 안정성: Stable
      사용 예시 및 해석예시의미와 중요성
      1. 성능 모니터링:
        • GC 후에 메모리 풀에 남아 있는 사용량을 모니터링하여 메모리 관리 성능을 평가할 수 있다. 메모리가 많이 남아 있다면, GC가 비효율적이거나 메모리 누수가 있을 수 있다.
      2. 자원 최적화:
        • GC 후 남은 메모리 양을 지속적으로 모니터링함으로써 메모리 풀의 크기를 최적화하고, 불필요한 메모리 낭비를 줄일 수 있다.
      3. 병목 현상 식별:
        • GC 후 사용된 메모리 양이 비정상적으로 많으면 애플리케이션의 특정 부분이 과도한 메모리를 소비하고 있을 가능성이 있다. 이를 통해 성능 문제를 진단하고 해결할 수 있다.
      참고 자료 요약
    • jvm.memory.used_after_last_gc 메트릭은 JVM에서 가장 최근 가비지 컬렉션 후 사용된 메모리 양을 측정하며, 메모리 관리, 성능 모니터링, 자원 최적화 및 병목 현상 식별에 중요한 역할을 한다. 이 메트릭을 통해 GC 후의 메모리 사용 패턴을 분석하고 최적의 성능을 유지할 수 있다.
    • 이 메트릭은 JVM에서 가장 최근의 가비지 컬렉션(GC) 이벤트 이후 특정 메모리 풀에 사용된 메모리 양을 측정한다. 이는 GC가 완료된 후 남아 있는 메모리 사용량을 나타내며, 메모리 관리와 최적화에 중요한 정보를 제공한다.
    • 정의 및 설명

    JVM Memory Commit (Heap, Non-Heap), (jvm.memory.committed)

    • 요약메모리 커밋 과정 이해
      1. 메모리 예약 (Memory Reservation):
        • JVM이 시작할 때, 설정에 따라 특정 양의 메모리를 예약한다. 예약된 메모리는 실제로 할당되지는 않지만, JVM이 필요할 때 할당할 수 있도록 예약된 상태로 유지된다.
      2. 메모리 커밋 (Memory Commitment):
        • JVM이 실제로 메모리를 사용하기 시작하면, 운영 체제로부터 메모리를 할당받아 커밋한다. 이 커밋된 메모리는 JVM이 실제로 사용할 수 있는 메모리이다.
        • jvm_memory_committed 메트릭은 이 커밋된 메모리의 양을 나타낸다.
      JVM 성능 최적화에 중요한 이유
      1. 메모리 사용 패턴 파악:
        • 커밋된 메모리 양은 JVM이 실제로 사용할 수 있는 메모리 양을 나타낸다. 이 수치는 JVM의 메모리 사용 패턴을 파악하는 데 중요한 지표가 된다. 예를 들어, 특정 메모리 풀의 커밋된 메모리 양이 계속해서 증가한다면, 이는 해당 메모리 풀이 과도하게 사용되고 있다는 신호일 수 있다.
      2. 메모리 부족 예방:
        • JVM이 예약한 메모리보다 커밋된 메모리가 더 많아지면 메모리 부족 현상이 발생할 수 있다. 이를 통해 메모리 부족 현상을 미리 예방하고, 필요에 따라 메모리 설정을 조정할 수 있다.
      3. 가비지 컬렉션 최적화:
        • 커밋된 메모리 양을 모니터링함으로써 가비지 컬렉션(GC)의 빈도와 강도를 조절할 수 있다. 예를 들어, 커밋된 메모리가 많다면 GC가 덜 자주 발생하여 성능에 긍정적인 영향을 미칠 수 있다. 반면, 커밋된 메모리가 적다면 GC가 자주 발생하여 응답 시간에 영향을 줄 수 있다.
      4. 성능 병목 파악:
        • 커밋된 메모리 양을 모니터링함으로써 특정 메모리 풀에서 발생하는 성능 병목을 파악할 수 있다. 예를 들어, **PS Old Gen**의 커밋된 메모리가 급격히 증가하면, 이는 많은 객체가 오래 살아남아 Old Generation으로 이동하고 있다는 의미일 수 있다. 이러한 경우, 메모리 할당 전략이나 GC 설정을 조정하여 성능을 최적화할 수 있다.
      5. 메모리 할당 효율성 향상:
        • JVM이 커밋한 메모리 양이 실제 사용량과 큰 차이가 난다면, 이는 메모리 할당이 비효율적으로 이루어지고 있음을 나타낼 수 있다. 이를 통해 메모리 할당 전략을 개선하여 메모리 사용 효율성을 향상시킬 수 있다.
    • jvm_memory_committed 메트릭은 JVM이 특정 메모리 풀에 대해 운영 체제로부터 확보한 메모리 양을 나타낸다. 이 메모리는 실제로 할당되어 JVM이 사용할 준비가 된 상태의 메모리이다. 이 메트릭은 JVM의 메모리 관리 상태를 파악하는 데 중요한 역할을 한다.

    예약 메모리(최대 메모리 한도)와 커밋 메모리 차이

    jvm_memory_limit 과 jvm_memory_committed

    • 요약jvm_memory_limit
      • 정의: jvm_memory_limit 메트릭은 JVM이 특정 메모리 풀에 대해 사용할 수 있는 최대 메모리 크기를 나타낸다. 이는 JVM이 해당 메모리 풀에 대해 설정한 최대 메모리 한도를 의미하며, 일반적으로 **Xmx**와 같은 JVM 옵션을 통해 설정된다.
      • 의미: JVM이 메모리 풀에 대해 사용할 수 있는 최대 메모리 양. 이는 JVM이 확장될 수 있는 최대 메모리 크기를 나타낸다.
      jvm_memory_committed
      • 정의: jvm_memory_committed 메트릭은 JVM이 현재 메모리 풀에 커밋한 메모리 양을 나타낸다. 커밋된 메모리는 JVM이 운영 체제로부터 실제로 할당받아 사용할 준비가 된 메모리 양이다.
      • 의미: JVM이 현재 사용 가능하도록 운영 체제로부터 확보한 메모리 양. 이는 실제 메모리 사용량과는 다를 수 있으며, JVM이 필요에 따라 추가 메모리를 요청할 수 있는 상태를 의미한다.
      두 메트릭 간의 관계
      • jvm_memory_committed ≤ jvm_memory_limit:
        • 커밋된 메모리(jvm_memory_committed)는 항상 최대 메모리 한도(jvm_memory_limit) 이하이다. 이는 JVM이 최대 메모리 한도를 초과하여 메모리를 커밋할 수 없음을 의미한다.
        • **jvm_memory_limit**은 JVM이 특정 메모리 풀에 대해 사용할 수 있는 최대 메모리 크기를 설정하며, 이는 JVM이 실제로 커밋할 수 있는 메모리의 상한선을 나타낸다.
      • 메모리 관리와 성능:
        • 커밋된 메모리의 증가: 애플리케이션의 메모리 사용량이 증가하면 JVM은 필요에 따라 추가 메모리를 운영 체제로부터 할당받아 커밋할 수 있다. 커밋된 메모리가 증가하면, 이는 JVM이 메모리를 더 많이 사용하고 있다는 것을 의미한다.
        • 최대 메모리 한도의 역할: 최대 메모리 한도는 JVM이 사용할 수 있는 메모리의 상한선을 설정하여 메모리 사용을 제한한다. 이를 통해 메모리 부족 상황을 예방하고, 안정적인 성능을 유지할 수 있다.
      예시를 통한 설명
      plaintext코드 복사
      {
        "jvm.memory.limit": 2048 MB,       // 최대 메모리 한도
        "jvm.memory.committed": 1024 MB    // 커밋된 메모리
      }
      
      
      • 이 예시에서, JVM의 특정 메모리 풀에 대해 설정된 최대 메모리 한도는 2048MB이고, 현재 커밋된 메모리 양은 1024MB이다.
      • JVM은 현재 1024MB의 메모리를 사용하도록 운영 체제로부터 할당받았으며, 최대 2048MB까지 메모리를 커밋할 수 있다.
      • 성능 최적화: 커밋된 메모리가 최대 메모리 한도에 가까워지면, JVM의 메모리 사용량이 증가하고 있음을 나타내며, 이 경우 추가 메모리 확보가 필요할 수 있다.
      성능 최적화 전략
      • 메모리 모니터링: **jvm_memory_committed**와 **jvm_memory_limit**을 모니터링하여 JVM의 메모리 사용 패턴을 파악하고, 필요에 따라 JVM 옵션을 조정하여 메모리 설정을 최적화한다.
      • GC 튜닝: 커밋된 메모리와 최대 메모리 한도를 기반으로 가비지 컬렉션의 빈도와 강도를 조절하여 메모리 관리 효율성을 높인다.
      • 예방적 조치: 커밋된 메모리가 최대 메모리 한도에 근접하면, 메모리 부족 상황을 예방하기 위해 메모리 설정을 조정하거나 애플리케이션의 메모리 사용 패턴을 최적화한다.
    • 예를 들어, 다음과 같은 메트릭 값을 통해 **jvm_memory_limit**과 **jvm_memory_committed**의 관계를 이해할 수 있다:
    • **jvm_memory_limit**와 **jvm_memory_committed**는 JVM의 메모리 관리에서 중요한 두 가지 지표로, 각각의 의미와 이들 간의 관계는 다음과 같다:

    No-Attribute

    jvm_class_count, jvm_class_loaded, jvm_class_unloaded

    • 설명
      1. jvm.class.loaded
        • 설명: JVM 시작 이후 로드된 클래스의 총 수.
        • 출처: ClassLoadingMXBean#getTotalLoadedClassCount()
        • 유형: Counter
        • 단위: {class}
        • 안정성: Stable
      2. jvm.class.unloaded
        • 설명: JVM 시작 이후 언로드된 클래스의 총 수.
        • 출처: ClassLoadingMXBean#getUnloadedClassCount()
        • 유형: Counter
        • 단위: {class}
        • 안정성: Stable
      3. jvm.class.count
        • 설명: 현재 JVM에 로드된 클래스의 수.
        • 출처: ClassLoadingMXBean#getLoadedClassCount()
        • 유형: UpDownCounter
        • 단위: {class}
        • 안정성: Stable
      관계 및 일관성 검토jvm.class.loaded−jvm.class.unloaded=jvm.class.count이는 **jvm.class.loaded**가 JVM 시작 이후 로드된 클래스의 총 수를 나타내고, **jvm.class.unloaded**가 JVM 시작 이후 언로드된 클래스의 총 수를 나타내기 때문이다. 따라서 현재 로드된 클래스의 수인 **jvm.class.count**는 총 로드된 클래스에서 총 언로드된 클래스를 뺀 값이어야 한다.만약 다음과 같은 값을 가진다면:
      • jvm.class.loaded: 10,000
      • jvm.class.unloaded: 1,000
      • jvm.class.count: 9,000
      그러면 다음 관계가 성립한다: 10,000−1,000=9,00010,000−1,000=9,000
    • 예시
    • jvm.class.loaded−jvm.class.unloaded=jvm.class.count
    • 각 메트릭의 정의를 토대로 정상적인 상황에서의 관계는 다음과 같다:
    • 정의

    jvm_cpu_count

    • 설명
      • Metric: jvm.cpu.count
      • 출처: 이 메트릭은 Runtime#availableProcessors() 메서드를 통해 얻어진다.
      • 값의 특성: 항상 정수 값을 가지며, 소수나 밀리코어를 나타내지 않는다.
      • 추천 이유: JVM이 실행 중인 시스템의 가용 CPU 수를 나타내는 중요한 지표이다.
      사용 예시 및 해석예시의미와 중요성
      1. 자원 관리 최적화:
        • JVM이 사용할 수 있는 CPU 코어 수를 알면, 애플리케이션의 스레드 풀 크기와 병렬 작업 수를 최적화할 수 있다.
        • CPU 바인딩 작업이 많은 애플리케이션의 경우, 이 메트릭을 활용하여 작업을 분배하고 최적의 성능을 유지할 수 있다.
      2. 애플리케이션 성능 모니터링:
        • 애플리케이션이 여러 CPU 코어를 효율적으로 사용하는지 확인할 수 있다.
        • 가용 CPU 코어 수와 실제 CPU 사용률을 비교하여 성능 병목을 진단할 수 있다.
      3. 자동 조정:
        • 클라우드 환경에서는 가용 CPU 수가 동적으로 변경될 수 있다. jvm.cpu.count 메트릭을 활용하여 애플리케이션이 자동으로 자원을 조정할 수 있다.
      참고 자료 이 메트릭은 시스템의 물리적 또는 논리적 CPU 코어 수를 정확하게 반영하며, 이는 JVM 기반 애플리케이션의 성능 최적화와 자원 관리에 중요한 역할을 한다.
    • Runtime runtime = Runtime.getRuntime(); int availableProcessors = runtime.availableProcessors(); System.out.println("Available processors (cores): " + availableProcessors);
    • 이 메트릭은 JVM이 실행되는 환경에서 사용 가능한 프로세서의 수를 나타낸다. 이는 시스템의 성능과 자원 사용량을 모니터링하고 최적화하는 데 유용하다.
    • 정의 및 설명

    jvm_cpu_time

    • 설명
      • Metric: jvm.cpu.time
      • 출처:
        • HotSpot JVM에서는 com.sun.management.OperatingSystemMXBean#getProcessCpuTime() 메서드를 통해 수집된다.
        • OpenJ9 JVM에서는 com.ibm.lang.management.OperatingSystemMXBean#getProcessCpuTime() 메서드를 통해 수집된다.
      • 타입: Counter
      • 단위 (UCUM): s (초)
      • 설명: JVM이 보고한 프로세스의 CPU 사용 시간.
      • 안정성: Stable
      사용 예시 및 해석예시의미와 중요성
      1. 성능 모니터링:
        • 이 메트릭은 JVM 애플리케이션의 CPU 사용 패턴을 모니터링하는 데 유용하다. CPU 사용 시간이 높다면 애플리케이션이 CPU 바인딩 작업을 많이 수행하고 있음을 나타낼 수 있다.
      2. 자원 최적화:
        • CPU 사용 시간을 추적하여 애플리케이션의 자원 사용을 최적화할 수 있다. 특정 시점에서 CPU 사용 시간이 급증하면, 그 시점에서 어떤 작업이 수행되었는지 분석할 수 있다.
      3. 병목 현상 식별:
        • CPU 사용 시간이 비정상적으로 높거나 급증하는 경우, 이는 애플리케이션의 병목 현상이나 비효율적인 코드 실행을 나타낼 수 있다. 이를 통해 성능 문제를 식별하고 해결할 수 있다.
      참고 자료 요약
    • jvm.cpu.time 메트릭은 JVM이 실행 중인 프로세스가 사용한 총 CPU 시간을 나타내며, 성능 모니터링, 자원 최적화, 병목 현상 식별 등에 중요한 역할을 한다. 이 메트릭을 통해 JVM 애플리케이션의 CPU 사용 패턴을 분석하고, 필요한 경우 성능 최적화를 도모할 수 있다.
    • import com.sun.management.OperatingSystemMXBean; import java.lang.management.ManagementFactory; public class CpuTimeMetric { public static void main(String[] args) { OperatingSystemMXBean osBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class); long processCpuTime = osBean.getProcessCpuTime(); System.out.println("Process CPU Time (ns): " + processCpuTime); // Convert nanoseconds to seconds double processCpuTimeSec = processCpuTime / 1_000_000_000.0; System.out.println("Process CPU Time (s): " + processCpuTimeSec); } }
    • 이 메트릭은 JVM이 실행 중인 프로세스가 사용한 총 CPU 시간을 나타낸다. 이 값은 누적된 시간으로, JVM이 시작된 이후 CPU가 실제로 작업을 수행한 시간을 측정한다.
    • 정의 및 설명

    jvm.cpu.recent_utilization

    • 설명
      • Metric: jvm.cpu.recent_utilization
      • 출처:
        • HotSpot JVM에서는 com.sun.management.OperatingSystemMXBean#getProcessCpuLoad() 메서드를 통해 수집된다.
        • OpenJ9 JVM에서는 com.ibm.lang.management.OperatingSystemMXBean#getProcessCpuLoad() 메서드를 통해 수집된다.
      • 타입: Gauge
      • 단위 (UCUM): 1 (단위 없음)
      • 설명: JVM이 보고한 최근 프로세스의 CPU 사용률.
      • 안정성: Stable
      사용 예시 및 해석이 메트릭은 JVM이 실행 중인 프로세스의 최근 CPU 사용률을 나타낸다. 값의 범위는 0.0에서 1.0 사이이며, 이는 CPU 사용률을 백분율로 변환하지 않고 직접적으로 나타낸 값이다.
      import com.sun.management.OperatingSystemMXBean;
      import java.lang.management.ManagementFactory;
      
      public class CpuUtilizationMetric {
          public static void main(String[] args) {
              OperatingSystemMXBean osBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);
              double processCpuLoad = osBean.getProcessCpuLoad();
              System.out.println("Recent CPU Utilization: " + processCpuLoad);
          }
      }
      
      
      의미와 중요성
      1. 성능 모니터링:
        • 이 메트릭은 애플리케이션의 CPU 사용 패턴을 실시간으로 모니터링하는 데 유용하다. CPU 사용률이 높으면 애플리케이션이 CPU 집약적인 작업을 수행하고 있음을 나타낸다.
      2. 자원 최적화:
        • CPU 사용률을 지속적으로 모니터링함으로써 애플리케이션의 자원 사용을 최적화할 수 있다. 특정 시점에서 CPU 사용률이 급증하면 그 시점의 작업을 분석하여 최적화할 수 있다.
      3. 병목 현상 식별:
        • CPU 사용률이 비정상적으로 높거나 지속적으로 높은 경우, 이는 애플리케이션의 병목 현상이나 비효율적인 코드 실행을 나타낼 수 있다. 이를 통해 성능 문제를 식별하고 해결할 수 있다.
      참고 자료 요약
    • jvm.cpu.recent_utilization 메트릭은 JVM이 실행 중인 프로세스의 최근 CPU 사용률을 나타내며, 성능 모니터링, 자원 최적화, 병목 현상 식별 등에 중요한 역할을 한다. 이 메트릭을 통해 JVM 애플리케이션의 CPU 사용 패턴을 분석하고, 필요한 경우 성능 최적화를 도모할 수 있다.
    • 예시
    • JVM 프로세스 자체의 최근 CPU 사용률
    • 정의 및 설명

    Histogram

    jvm.gc.duration

    정의 및 설명

    • Metric: jvm.gc.duration
    • 출처: **GarbageCollectorMXBean**에서 제공하는 GarbageCollectionNotificationInfo 이벤트를 구독하여 수집된다. GC 작업의 지속 시간 값은 **GcInfo**에서 가져온다.
    • 타입: Histogram
    • 단위 (UCUM): s (초)
    • 설명: JVM 가비지 컬렉션 작업의 지속 시간.
    • 안정성: Stable

    속성 (Attributes)

    1. jvm.gc.action:
      • 유형: string
      • 설명: 가비지 컬렉터 작업의 이름.
      • 예시: "end of minor GC", "end of major GC"
      • 요구 수준: Recommended
      • 안정성: Stable
    2. jvm.gc.name:
      • 유형: string
      • 설명: 가비지 컬렉터의 이름.
      • 예시: "G1 Young Generation", "G1 Old Generation"
      • 요구 수준: Recommended
      • 안정성: Stable

    사용 예시 및 해석

    이 메트릭은 JVM이 수행하는 각 가비지 컬렉션(GC) 작업의 지속 시간을 측정. 히스토그램을 사용하여 다양한 지속 시간 범위에 대한 분포를 제공하며, 이는 GC 작업이 성능에 미치는 영향을 분석하는 데 유용하다.

    예시

    
    import javax.management.Notification;
    import javax.management.NotificationEmitter;
    import javax.management.NotificationListener;
    import com.sun.management.GarbageCollectionNotificationInfo;
    import java.lang.management.ManagementFactory;
    import java.lang.management.GarbageCollectorMXBean;
    import java.util.List;
    
    public class GCDurationMetric {
        public static void main(String[] args) {
            List<GarbageCollectorMXBean> gcBeans = ManagementFactory.getGarbageCollectorMXBeans();
            for (GarbageCollectorMXBean gcBean : gcBeans) {
                NotificationEmitter emitter = (NotificationEmitter) gcBean;
                emitter.addNotificationListener(new NotificationListener() {
                    @Override
                    public void handleNotification(Notification notification, Object handback) {
                        if (notification.getType().equals(GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION)) {
                            GarbageCollectionNotificationInfo info = GarbageCollectionNotificationInfo.from((CompositeData) notification.getUserData());
                            long duration = info.getGcInfo().getDuration();
                            String gcAction = info.getGcAction();
                            String gcName = info.getGcName();
                            System.out.println("Garbage Collection Action: " + gcAction);
                            System.out.println("Garbage Collection Name: " + gcName);
                            System.out.println("Duration: " + duration + "ms");
                        }
                    }
                }, null, null);
            }
        }
    }

    의미와 중요성

    1. 성능 모니터링:
      • GC 작업의 지속 시간을 모니터링하여 애플리케이션의 성능에 미치는 영향을 파악할 수 있다. 긴 GC 시간이 반복적으로 발생하면 애플리케이션의 성능이 저하될 수 있다.
    2. 자원 최적화:
      • GC 히스토그램을 통해 다양한 지속 시간 범위의 빈도를 분석하여 GC 튜닝을 수행할 수 있다. 예를 들어, Young Generation과 Old Generation의 GC 지속 시간을 비교하고 최적화할 수 있다.
    3. 병목 현상 식별:
      • GC 작업의 지속 시간이 비정상적으로 길면 메모리 병목 현상이나 객체 할당 패턴의 비효율성을 나타낼 수 있다. 이를 통해 성능 문제를 진단하고 해결할 수 있다.

    참고 자료

    요약

    jvm.gc.duration 메트릭은 JVM의 가비지 컬렉션 작업의 지속 시간을 측정하여 성능 모니터링, 자원 최적화, 병목 현상 식별 등에 중요한 정보를 제공한다. 이 메트릭을 통해 GC 작업의 효율성을 분석하고 JVM 애플리케이션의 성능을 최적화할 수 있다.