Metric Design

Metric Design

Test Monitoring 관련으로 메트릭 디자인하면서 진행했던 내용 공유 

🔎 Metrics

💊 USE / RED

USE/RED는 메트릭 디자인 방법론의 종류. 
USE는 물리적 하드웨어(서버) 위주의 메트릭 디자인 방법을,
RED는 어플리케이션 레벨의 메트릭 디자인 방법을 제시함.  

📒 USE

For every resource, check utilization, saturation, and errors.
- 모든 자원에 대해서 점유율, 포화율, 오류를 확인하자. 

• 주로 물리적 자원에 대한 메트릭을 수집하는데 사용되는 기준이라고 이해함.
• Resource(자원) : 물리적 서버의 모든 기능 구성 요소
• Utilization(점유율) : 리소스가 서비스에 대하여 바쁘게 사용되는 평균 시간
  -> 점유율이 높다 = 리소스가 처리되지않고 밀려있을 가능성(bottle neck 등)이 있다.
• Saturation(포화율) : 리소스가 처리하지 못한 여분의 일(extra work)의 정도. 리소스가 처리할 수 있는 한계를 넘어 처리하지 못한 작업의 정도.
• Errors(오류) : 에러 이벤트의 횟수
• 세 지표를 사용해서 낮은 레벨의(서버의 물리적 자원 - 네트워크) 모니터링이 가능하다.
  CPU 점유율은 낮은데 포화율이 높다? -> 스레드나 프로세스 분배가 잘못되어 있어서 하나의 CPU 코어에 일이 몰려있다. -> 스레드 풀을 사용해서 하나의 스레드에 몰린 작업을 분배하는 등의 조치를 취할 수 있음.

Pros and cons

• Pros :
• Cons :

참고 사이트

📕 RED

“The USE Method doesn’t really apply to services; it applies to hardware, network disks, things like this,”
“We really wanted a microservices-oriented monitoring philosophy, so we came up with the RED Method.”

• USE와

참고 사이트

📝 Metrics Design

USE/RED 방법론을 참고해서 사용할 시스템에 적합한 메트릭 선정하기

모니터링 대상 시스템

• Backend App (Spring Actuator)
• Frontend App (Node Exporter)
• Nginx (Nginx Exporter)
• Opensearch (Opensearch Exporter)
• MySQL (MySQL Exporter)
• Redis (Redis Exporter)
• Node: Springboot, Vue.js 등의 동작하는 WorkerNode 모니터링 (Node Exporter)

시스템 별 기본 제공 메트릭

• Spring Acutator (http://localhost:8080/metrics)

{
  "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",
    "http.server.requests",
    "http.server.requests.active",
    "jvm.buffer.count",
    "jvm.buffer.memory.used",
    "jvm.buffer.total.capacity",
    "jvm.classes.loaded",
    "jvm.classes.unloaded",
    "jvm.compilation.time",
    "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.info",
    "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.started",
    "jvm.threads.states",
    "logback.events",
    "process.cpu.time",
    "process.cpu.usage",
    "process.start.time",
    "process.uptime",
    "system.cpu.count",
    "system.cpu.usage",
    "tomcat.sessions.active.current",
    "tomcat.sessions.active.max",
    "tomcat.sessions.alive.max",
    "tomcat.sessions.created",
    "tomcat.sessions.expired",
    "tomcat.sessions.rejected"
  ]
}

*Spring
USE
U
(disk.total - disk.free) / disk.total ( (전체 용량 - 여유 용량) / 전체 용량)
system.cpu.usage (전체 시스템 cpu 사용률)
process.cpu.usage (프로세스 cpu 사용률) 
(jvm.memory.max - jvm.memory.used) / jvm.memory.max (jvm 메모리 사용률)
(executor.pool.size - executor.queue.remaining) / executor.pool.size (현재 풀 사용량)

S
(executor.pool.size - executor.queued) / executor.pool.size ( 스레드 풀의 포화 상태 )
executor.queued (스레드 풀의 대기열에 현재 대기 중인 작업의 수) 
jvm.gc.overhead

E
??기본 제공 merics중에서 에러 카운트 할만한 메트릭이 뭐가 있는지 


RED
R
http.server.requests (총 HTTP 요청 수) 
http.server.requests.active ( 현재 처리 중인 HTTP 요청 수 )
-> 1분 단위로 끊어서 (총 HTTP 요청 - 현재 처리 중인 HTTP 요청) / 총 HTTP 요청 하면 
요청이 얼마나 남아있는지를 알 수 있을 듯


??

D
??


Opensearch
USE
U
CPU_Utilization (CPU 사용률) 
Disk_Utilization (디스크 사용률) 
Heap_Used / Heap_Maxed (메모리 사용률)
IO_ReadThroughput (지난 5초간 디스크에서 읽어온 데이터 양)

S
(ThreadPool_TotalThreads - ThreadPool_ActiveThreads) / ThreadPool_TotalThreads
(스레드 풀 잔여량) 

E
Paging_MajfltRate (초당 발생한 주요한 오류 수)
Paging_MinfltRate (초당 발생한 마이너 오류 수)

RED
R
HTTP_TotalRequest 
HTTP_RequestDocs
Disk_ServiceRate

E
ThreadPool_RejectedReqs(거부된  executions 수)

D
Disk_WaitTime( 지난 5초간 디스크 r/w 평균 응답시간)
GC_Collection_Time

Q. CD과정도 모니터링이 필요한지?
-> 실제 환경에서도 배포는 주로 사용자가 적은 야간에 진행할 거 같은데 
이걸 모니터링하는게 의미가 있을지 모르겠음