4.1. 분석 시나리오 한눈에
어떤 분석을 고를지 — 목록이 왜 바뀌는지, 무엇을 골라야 하는지
분석 프롬프트 빌더를 열면 시나리오 목록이 나옵니다. 이 장은 그 목록이 왜 바뀌는지, 그리고 무엇을 골라야 하는지를 다룹니다.
먼저 — 데이터소스를 고릅니다
분석 빌더 위쪽에 데이터소스 선택 칸이 있습니다. 여기서 고른 것에 따라 아래 시나리오 목록이 바뀝니다.
| 고르는 값 | 어디서 온 데이터 | 보이는 시나리오 |
|---|---|---|
observ | OPENMARU Observability 가 수집한 쿠버네티스·노드 지표 | 13종 |
apm | OPENMARU APM 이 수집한 WAS·트랜잭션 지표 | 10종 |
같은 화면에서 데이터소스만 바꾼 모습입니다. 목록이 통째로 달라집니다.
데이터소스는 위젯을 연 화면과 무관합니다
어느 콘솔에서 위젯을 열든 두 데이터소스가 모두 보입니다. 목록은 호스트가 아니라
서버가 내려줍니다. COP Console 에서 열어도 observ 와 apm 을 고를 수 있습니다.
COP Console 은 자기 데이터소스를 따로 두지 않습니다. 쿠버네티스 지표를 보려면 observ,
WAS 지표를 보려면 apm 을 고릅니다.
둘 다 Prometheus 로 읽습니다.
apm도 Prometheus 호환 엔드포인트라 조회 방식은 같습니다. 다른 것은 어떤 지표가 들어 있느냐입니다:observ에는 컨테이너· 노드 지표가,apm에는 Apdex·TPS·SQL 응답시간 같은 APM 지표가 있습니다.
문서에서 본 시나리오가 화면에 없다면 대개 데이터소스를 다른 것으로 고른 것입니다. 위쪽 선택 칸을 먼저 확인하십시오.
세 갈래 — 무엇을 묻는가
시나리오는 이름이 달라도 묻는 방식은 셋 중 하나입니다. 이것만 알면 처음 보는 시나리오도 무엇을 해 줄지 짐작할 수 있습니다.
| 갈래 | 묻는 것 | 답의 모양 | 종수 |
|---|---|---|---|
| 상관 | 두 지표가 함께 움직이는가 | 상관계수, 선행·후행 관계 | 11 |
| 예측 | 이대로 가면 언제 한계에 닿는가 | 미래 값과 신뢰구간 띠 | 6 |
| 이상 탐지 | 평소와 다른 구간이 있는가 | 시점과 정도 | 6 |
어느 갈래를 고르나
무엇을 알고 싶은지로 정합니다.
- "왜 느려졌나" → 상관. 응답시간과 함께 움직인 지표를 찾습니다.
- "언제 늘려야 하나" → 예측. 추세를 이어 그려 한계 도달 시점을 봅니다.
- "이상한 데가 있나" → 이상 탐지. 어디를 봐야 할지 모를 때 먼저 씁니다.
원인을 모를 때는 이상 탐지 → 상관 순서가 편합니다. 이상 탐지로 시점을 찾고, 그 구간을 상관 분석으로 자세히 봅니다.
apm 데이터소스 — 10종
OPENMARU APM 이 수집한 WAS·트랜잭션 지표를 봅니다. Apdex·TPS·SQL 응답시간이 대상입니다.
| 갈래 | 시나리오 | 대상 | 무엇을 보나 |
|---|---|---|---|
| 상관 | 힙 메모리·TPS 상관 분석 | 애플리케이션 | 힙·GC·TPS·응답시간을 묶어 메모리 압박을 본다 |
| 상관 | MSA 장애 전파 상관 분석 | 애플리케이션 | 응답시간→에러율 전파 경로를 추적 |
| 상관 | JVM 메모리 분석 | 애플리케이션 | 힙 사용률을 예측·추세·상관 세 관점에서 |
| 상관 | 트래픽 ↔ 에러율 상관관계 | 애플리케이션 | 요청이 늘 때 에러가 따라 느는가 |
| 상관 | 응답 지연 원인 분석 | 애플리케이션 | Apdex 응답시간과 부하·자원·GC 의 관계 |
| 상관 | DB 성능 영향 분석 | 애플리케이션 | SQL 응답시간이 앱 응답시간에 영향을 주는가 |
| 예측 | 호스트 자원 예측 | 노드 | 에이전트가 수집한 호스트 CPU·메모리 추세 |
| 예측 | 앱 자원 사용량 예측 | 애플리케이션 | WAS 인스턴스의 힙·프로세스 CPU 추세 |
| 이상 | 서비스 이상 징후 탐지 | 애플리케이션 | 에러율·5xx·Apdex·불만족 트랜잭션 |
| 이상 | 스레드 풀 이상 분석 | 애플리케이션 | Blocked·Waiting·Deadlock 패턴 |
observ 데이터소스 — 13종
OPENMARU Observability 가 수집한 쿠버네티스·노드 지표를 봅니다. 컨테이너 CPU·메모리, 노드 디스크가 대상입니다.
| 갈래 | 시나리오 | 대상 | 무엇을 보나 |
|---|---|---|---|
| 상관 | 응답 지연 원인 분석 (컨테이너) | 애플리케이션 | 컨테이너 CPU 와 HTTP 응답시간 |
| 상관 | 응답 지연 원인 분석 (Web·WAS) | 애플리케이션 | Web 서버 응답시간과 부하·자원·에러 |
| 상관 | DB 성능 영향 분석 | 애플리케이션 | DB 쿼리 수와 서비스 응답시간 |
| 상관 | 쓰레드 풀 부하 분석 | 애플리케이션 | 활성 스레드와 트래픽·응답시간·힙 |
| 상관 | 골든 시그널 종합 분석 | 애플리케이션 | 응답시간·트래픽·에러율·CPU 네 가지를 한 번에 |
| 예측 | 리소스 사용량 예측 (컨테이너) | 애플리케이션 | 컨테이너 CPU·메모리 추세 |
| 예측 | 리소스 사용량 예측 (Web 서버) | 애플리케이션 | Web 서버 CPU·메모리 추세 |
| 예측 | 노드 상태 예측 | 노드 | 노드 CPU·메모리·로드 평균 |
| 예측 | 디스크 고갈 예측 | 노드 | 디스크 사용률 → Pod Eviction 위험 |
| 이상 | 서비스 이상 징후 탐지 (컨테이너) | 애플리케이션 | 요청량·응답시간·재시작 |
| 이상 | 서비스 이상 징후 탐지 (Web·WAS) | 애플리케이션 | 응답시간·에러율·트래픽 |
| 이상 | JVM 메모리 분석 (컨테이너) | 애플리케이션 | 힙·GC 시간·스레드 수 |
| 이상 | JVM 메모리 분석 (WAS) | 애플리케이션 | WAS 인스턴스의 힙과 활성 스레드 |
같은 이름이 두 번 나옵니다
이 목록에는 이름이 같은 시나리오가 네 쌍 있습니다.
응답 지연 원인 분석 · 리소스 사용량 예측 · 서비스 이상 징후 탐지 · JVM 메모리 분석
고르는 대상이 다릅니다.
| 하나는 | 다른 하나는 | |
|---|---|---|
| 보는 것 | 쿠버네티스 컨테이너 지표 | Web 서버·WAS 지표 |
| 예 | container_cpu_usage | Web 서버 응답시간, WAS 힙 |
설명 문구로 가릅니다. 목록에서 시나리오를 고르기 전에 이름 아래 한 줄 설명을 읽으십시오. "컨테이너" 가 나오면 앞쪽, "Web 서버" 나 "WAS" 가 나오면 뒤쪽입니다.
컨테이너로 실행한 앱이면 앞쪽, 가상머신이나 물리 장비의 WAS 면 뒤쪽을 고릅니다.
대상이 둘로 갈립니다 — 애플리케이션과 노드
시나리오마다 고를 수 있는 대상이 정해져 있습니다.
- 애플리케이션 — 서비스·앱 단위. 대부분의 시나리오가 여기 속합니다.
- 노드 — 서버·호스트 단위.
노드 상태 예측·디스크 고갈 예측·호스트 자원 예측.
노드 시나리오를 골랐는데 앱 이름이 안 보인다면 잘못된 것이 아닙니다. 대상이 다른 것입니다.
단계가 하나 더 있는 시나리오
일부 시나리 오는 고른 뒤 "어떤 상황인가"를 한 번 더 묻습니다. 상관 분석에 많습니다.
예를 들어 응답 지연 원인 분석 을 고르면 이렇게 되묻습니다.
- 앱 하나 안에서 비교할 것인가
- 앱과 앱 사이를 비교할 것인가
무엇을 비교하느냐에 따라 필요한 대상이 달라지기 때문입니다. 이 되묻는 화면이 위저드 모드이고, 자세한 것은 위저드 모드에서 다룹니다.
다음으로
- 갈래별 자세한 설명 — 상관 분석 · 예측 분석 · 이상 탐지
- 고른 뒤 무엇을 하나 — 위저드 모드
- 결과의 숫자를 어떻게 읽나 — 부록: 결과를 읽는 법