E3. 지표의 의미 — 무엇을 보고 판단하나
Diátaxis: Explanation(이해) · 대상: 운영자 / 관리자 ← 목차로 · ← E2 핵심 개념
OPENMARU APM 화면에는 숫자와 그래프가 많습니다. 이 문서는 그중 자주 보는 지표가 각각 무엇을 뜻하고, 어떤 모양일 때 정상이고 언제 의심해야 하는지를 개념으로 설명합니다.
핵심 이 문서는 개념입니다. 차트 하나하나의 정확한 임계치와 점검 항목은 R2. 차트 지표 레퍼런스에 정리되어 있습 니다. E3에서 큰 그림을 잡고, 실제 값을 볼 때 R2를 옆에 두면 됩니다. 화면에서는 차트 제목 옆
?아이콘이 같은 설명을 보여 줍니다.
지표는 결국 세 가지 질문에 답하기 위한 것입니다.
| 질문 | 보는 지표 | 절 |
|---|---|---|
| 서비스가 빠르고·많이·오류 없이 도는가? | TPS · 응답시간 · APDEX · 오류율 | E3.1 |
| 그걸 처리하는 WAS(JVM)는 건강한가? | 힙 · GC · 스레드 · 클래스 · 파일 | E3.2 |
| 약속한 수준을 지키고 있는가? | SLA · 가용성 | E3.3 |
E3.1 처리량 · 응답 — "서비스가 잘 도는가"
아래 네 지표 — TPS·응답시간·APDEX·오류율 — 는 WAS 대시보드 한 화면에서 함께 봅니다.
TPS (초당 처리 건수)
TPS(Transactions Per Second)는 1초에 처리한 요청 수, 즉 처리량입니다. 보통 높을수록 좋습니다. 중요한 건 절대값보다 평소 패턴과의 비교입니다 — 갑작스러운 하락은 트래픽 감소가 아니라 서비스 장애일 수 있으므로, 항상 응답시간·오류율과 함께 봅니다.
응답시간 (Response Time)
요청 하나를 처리하는 데 걸린 시간(밀리초, ms)입니다. 일반적 기준으로 2초 이하가 정상, 3초 이상이면 사용자가 지연을 체감, 12초 이상은 심각한 상태입니다.
평균만 보면 함정이 있습니다. 평균과 최대값의 차이가 크면 대부분은 빠른데 일부 요청만 비정상적으로 느린 것입니다. 이때는 그 느린 트랜잭션 하나를 열어 원인을 봐야 합니다 → H6. 느린 트랜잭션 원인 찾기. 응답이 느려지는 전형적 원인은 느린 SQL, 외부 API 호출, GC 일시중지, 자원 경합입니다.
APDEX (사용자 만족도 지수)
APDEX(Application Performance Index)는 응답시간을 사용자 만족도 관점으로 바꾼 0~100 점수입니다. 응답을 세 부류로 나눠 계산합니다.
- Satisfied (만족): 기준 시간 T 이내
- Tolerating (참을 만함): T ~ 4T
- Frustrated (불만): 4T 초과 또는 오류
점수 구간은 94100 우수 · 8593 양호 · 7084 보통 · 5069 나쁨 · 50 미만 심각입니다.
응답시간이 "몇 ms인가"라면, APDEX는 "사용자가 만족했는가"를 한 숫자로 압축한 것이라
보고용·추세 판단에 유용합니다.
오류율 (Error Rate)
전체 요청 중 4xx/5xx 오류 응답의 비율(%) 입니다. 이상적인 값은 0%에 가까운 것입니다. 오류율이 오르면 트래픽 문제가 아니라 코드·배포·의존 서비스 문제일 가능성이 크므로, 오류 로그·최근 배포 이력·의존 서비스 장애를 함께 봅니다.
참고 이 네 지표는 따로 보지 않습니다. "TPS 정상 + 응답시간 급등 + 오류율 0%"라면 외부 호출이나 DB 지연을, "오류율 급등"이라면 배포·의존성을 먼저 의심하는 식으로 조합으로 읽습니다.
실시간 진행중 트랜잭션 — 요청 뷰어 · 실시간 요청 모니터링
앞의 네 지표가 "방금 끝난 요청들"을 집계한 값이라면, 요청 뷰어(Request Viewer)와 실시간 요청 모니터링(Request Velocity)은 바로 지금 처리 중인(아직 끝나지 않은, Pending) 트랜잭션을 실시간으로 보여 줍니다. 화면 가운데 숫자가 현재 진행중(Pending) 트랜잭션 개수이고, 각 요청은 지금까지 걸린 경과 시간에 따라 세 가지 색으로 칠해집니다.
핵심 서비스 모니터링에서 가장 먼저 볼 것은 "Pending에 빨강이 있는가"입니다. 진행중(Pending) 트랜잭션에 빨강이 하나도 없으면 모든 요청이 기준 시간 안에 처리되고 있다는 뜻이라 서비스는 건강한 상태입니다. 빨강이 보이면 다른 지표를 보기 전에 그것부터 확인합니다 — 평균·집계 지표는 장애가 끝난 뒤에야 움직이지만, 진행중 빨강은 장애가 지금 만들어지는 순간을 가장 먼저 알려 주기 때문입니다. 그래서 "빨강이 없는지"가 실시간 서비스 점검의 1순위입니다.
이 색 분류는 위에서 본 APDEX와 똑같은 기준(기준 시간 T, 기본 3초)을 진행중 요청 하나하나에 실시간으로 적용한 것입니다.
| 색 | 상태 | 경과 시간 | 의미 |
|---|---|---|---|
| 초록 | Satisfying (만족) | T 이내 (기본 3초 이하) | 정상 속도로 처리 중 |
| 주황 | Tolerating (참을 만함) | T ~ 4T (기본 3~12초) | 느려지는 중 — 사용자가 지연을 체감하기 시작하는 구간 |
| 빨강 | Frustrating (불만) | 4T 초과 (기본 12초 이상) | 심각하게 느림 — 12초 넘게 끝나지 않고 멈춰 있는 요청 |
읽는 법 — 색의 비율로 지금 상태를 봅니다.
- 대부분 초록: 정상. 들어온 요청이 빠르게 빠져나가고 있습니다.
- 주황이 늘어남: 처리가 느려지는 전조입니다. 곧 평균 응답시간이 오를 수 있으니 주시합니다.
- 빨강이 많아짐: 12초가 넘도록 끝나지 않은 트랜잭션이 쌓이고 있다는 뜻입니다. 느린 SQL, 외부 API 지연, GC 일시중지, 자원 경합 등으로 요청이 멈춰 있는 상태입니다. 방치하면 진행중 요청이 스레드 풀을 점유한 채 풀리지 않아(아래 E3.2 스레드 참고) 새 요청까지 대기·오류로 번집니다. 빨강이 계속 쌓이면 그 느린 트랜잭션 하나를 열어 원인을 봅니다 → H6. 느린 트랜잭션 원인 찾기.
참고 평균 응답시간(위)이 "결과"라면, 이 색 분포는 "지금 만들어지고 있는 결과"입니다. 빨강이 늘기 시작할 때 손을 쓰면, 평균 응답시간·오류율이 망가지기 전에 대응할 수 있습니다.
E3.2 JVM 건강 — "처리하는 엔진은 괜찮은가"
WAS는 자바 가상 머신(JVM) 위에서 돕니다. JVM이 흔들리면 응답시간·오류가 따라 흔들리므로, 아래 지표로 엔진 상태를 봅니다.
힙(Heap) 메모리 — 모양이 핵심
힙은 자바 객체가 쌓이는 메모리 공간입니다. 정상 패턴은 톱니 모양입니다 — 객체가 쌓이며 올라가다가 GC(가비지 컬렉션)가 청소하면 뚝 떨어지는 모습이 반복됩니다.
- 위험 신호: 사용률이 높은 채로 평탄하거나(청소가 안 됨) 80% 이상이 지속되면 메모리 누수를 의심합니다.
- 누수가 진행되면 결국 OutOfMemoryError로 이어집니다.
힙 사용률(%)과 크기(MB)를 함께 보며, 의심되면 힙 히스토그램·힙덤프로 파고듭니다 → H7. 메모리 누수 의심 시 점검.
GC (가비지 컬렉션) — 멈춤의 원인
GC는 힙을 청소하는 작업인데, 청소하는 동안 애플리케이션이 잠깐 멈춥 니다(Stop-the-World). 짧고 가끔이면 정상이지만, 긴 GC 일시중지(예: 500ms 이상)가 잦으면 사용자가 멈춤을 체감합니다. 힙 크기·객체 생성 빈도·GC 알고리즘 설정이 원인일 수 있습니다.
스레드 (Thread)
요청을 처리하는 일꾼입니다. 상태 분포(Runnable·Blocked·Waiting)로 건강을 봅니다.
- Blocked 스레드 多 → 잠금 경합(Lock Contention) 의심
- Waiting 스레드 多 → 스레드 풀 고갈 의심
- 원인은 스레드 덤프로 분석합니다.
그 밖의 JVM 지표
| 지표 | 정상/위험 |
|---|---|
| 클래스 수 | 언로딩 없이 계속 증가 → 클래스로더 누수 의심(잦은 재배포 환경), Metaspace OOM 발생 가능 |
| Open Files (열린 파일 디스크립터) | 최대 한도 근접 → 'Too many open files' 오류. 소켓 누수·미닫힌 스트림·ulimit 점검 |
| JVM CPU | 높으면 연산 집약 작업 진행 중. 시스템 전체 CPU와 비교해 JVM이 주 소비자인지 확인 |
각 차트의 구체 수치·점검 항목은 R2.1 WAS 차트를 보세요.
E3.3 SLA · 가용성 — "약속을 지키고 있는가"
SLA(Service Level Agreement, 서비스 수준 협약)는 "이 서비스를 어느 수준으로 제공하겠다"는 약속입니다. 보통 가용성(서비스가 정상 응답한 시간의 비율, 예: 99.9%)으로 표현합니다.
앞의 지표들이 "지금 이 순간 빠른가/건강한가"를 본다면, SLA는 "기간 전체로 봤을 때 약속한 수준을 지켰는가" 를 봅니다. 그래서 관점이 다릅니다.
- 순간적으로 응답이 느린 적이 있어도 전체 가용성은 목표를 지킬 수 있고,
- 반대로 짧지만 잦은 장애가 누적되면 가용성 목표가 깨질 수 있습니다.
SLA 대시보드는 이 "지금 SLA를 지키고 있는가"를 한눈에 보여 주고, 보고서는 기간별 달성률을 정리합니다. 설정·확인 방법은 H17. SLA 목표 설정하고 보고서 받기에서 다룹니다.
정리
| 지표군 | 답하는 질문 | 정상 모습 | 의심 신호 |
|---|---|---|---|
| TPS·응답시간·APDEX·오류율 | 서비스가 잘 도는가 | 평소 패턴 유지, 오류율 ~0% | TPS 급락 / 응답 급등 / 오류율 상승 |
| 힙·GC·스레드 | 엔진이 건강한가 | 힙 톱니, 짧은 GC | 힙 평탄·80%+, 긴 GC 빈번, Blocked/Waiting 多 |
| SLA·가용성 | 약속을 지키는가 | 목표 달성률 유지 | 누적 장애로 달성률 하락 |
다음으로 읽을 것
- R2. 차트 지표 레퍼런스 — 위 개념을 차트별 구체 임계치로
- H6. 느린 트랜잭션 원인 찾기 · H7. 메모리 누수 점검
- 용어 정의만 빠르게 — R8. 용어집