T2. 대시보드로 문제를 발견하고 추적하기
Diátaxis: Tutorial(따라하기) · 대상: 운영자 (처음~중급) ← 목차로 · ← T1 빠른 시작
이 실습을 마치면 WAS 대시보드 한 화면만 보고 "지금 문제가 있나"를 색으로 판단하고, T-Map에서 느린 요청을 드래그해 트랜잭션 상세(패턴)까지 따라갈 수 있게 됩니다. 약 5분입니다.
먼저 알아둘 것
- T1. 5분 빠른 시작을 끝냈다고 가정합니다(로 그인·대상 선택을 할 줄 안다).
- 지표 개념이 궁금하면 E3. 지표의 의미를 옆에 두면 좋습니다(몰라도 따라올 수 있습니다).
여는 법 — 좌측 메뉴 ▸ WAS ▸ 대시보드
대시보드는 TPS·응답시간·APDEX·오류율 · 실시간 요청(Request Velocity·Viewer) · T-Map · JVM·자원을 한 화면에 모아 보여 줍니다. 이 실습은 이 화면만으로 진행합니다.
1단계 — 대시보드 상단 "실시간 요청" 위젯에서 "빨강" 찾기 (요청 뷰어 · 실시간 요청 모니터링)
별도 메뉴로 이동할 필요가 없습니다. 방금 연 WAS 대시보드의 맨 위에 실시간 요청을 보여 주는 위젯 두 개 — 요청 뷰어(Request Viewer)와 실시간 요청 모니터링(Request Velocity) — 이 나란히 있습니다(위 대시보드 캡처의 상단 영역). 이 두 위젯은 색이 곧 신호라, 숫자를 읽기 전에 색부터 봅니다.
| 위젯 (대시보드 상단) | 정상 | 문제 신호 |
|---|---|---|
| 요청 뷰어 (Request Viewer) | 가운데 원형 벽(Wall) 이 작고 차분함 | 벽이 주황/빨강으로 커짐 = 느린 응답 비중↑. 좌측 숫자 = 동시 접속자 수 |
| 실시간 요청 모니터링 (Request Velocity) | 대부분 Satisfying(초록) 구간 | Tolerating(주황)·Frustrating(빨강) 구간이 커짐 = 처리 중 요청이 느려지는 중 |
- 요청 뷰어의 원형 벽이 빨갛게 부풀어 있는지 봅니다.
- 실시간 요청 모니터링의 스택바에서 주황·빨강 구간이 늘고 있는지 봅니다.
결과 — 둘 중 하나라도 빨강이 두드러지면 "지금 느린 요청이 쌓이고 있다" 는 신호입니다.
참고 이 두 위젯은 대시보드의 한 부분입니다. 같은 화면이 좌측 메뉴 ▸ WAS ▸ 실시간 요청 모니터링 에 전용 페이지로도 있지만, 이 실습은 대시보드 위젯만으로 충분합니다. 참고 빨강 = 응답시간이 Frustrating(불만) 구간(APDEX 기준 4T 초과)에 든 요청입니다. 색만으로 "정상/주의/위험"을 즉시 가를 수 있어, 숫자를 일일이 안 봐도 됩니다.
주의 빨강이 보여도 원인은 아직 모릅니다. 느린 쿼리·외부 API 지연·스레드 풀 고갈 등 여러 가능성이 있습니다 — 원인 좁히기는 3~4단계(T-Map)와 T3(AI)에서 이어집니다.
2단계 — 활성 사용자수 읽기 (어떻게 세는가)
대시보드의 액티브 사용자수는 지금 서비스를 실제로 쓰고 있는 사용자 규모입니다. 트래픽 이상(급증·심야의 비정상 트래픽)을 가늠하는 기준선이 됩니다.
어떻게 계산되나 — 정확히 이해하면 값을 오해하지 않습니다.
- 고유(distinct) 사용자 수입니다. 같은 사용자가 여러 번 요청해도 1명으로 셉니다.
- 1분 단위로 수집하고, 기본 5분 범위의 활성 사용자를 집계합니다(범위는 설정 가능).
- 여러 인스턴스에 흩어진 사용자도 합산해 중복 없이 셉니다. 이 "중복 제거 + 합산"은 대용량에서도 빠르도록 HyperLogLog(근사 distinct 계산)로 처리합니다 — 그래서 값은 정확한 정수라기보다 매우 가까운 추정치입니다.
활성 사용자 vs 로그인 사용자 — 이 카드의 차트에는 선이 두 개 그려집니다. "누구를 세는가"가 다 릅니다.
| 지표 | 누구를 세나 | 식별 기준 |
|---|---|---|
| 액티브(활성) 사용자 | 최근 5분간 한 번이라도 요청한 모든 방문자 — 로그인 여부 무관, 익명 포함 | 쿠키(기본)·세션·IP 등 에이전트 설정 |
| 로그인 사용자 | 로그인 ID 기준으로 별도 집계한 인증 사용자 | 로그인 ID (세션·헤더·쿠키에서 추출) |
- 로그인 사용자수는 에이전트의 로그인 추적 설정이 켜져 있을 때만 수집됩니다.
- 두 값의 간격이 크면 익명 방문·봇 등 비인증 트래픽 비중이 크다는 뜻입니다 — 활성 사용자만 치솟고 로그인 사용자는 그대로라면 실제 고객 증가가 아닐 가능성을 의심합니다.
주의 두 지표는 세는 기준이 다릅니다 — 활성 사용자는 기기(쿠키/세션/IP) 단위, 로그인 사용자는 계정(로그인 ID) 단위입니다. 한 기기에서 여러 계정으로 로그인하면 로그인 사용자수가 활성 사용자수보다 클 수도 있습니다. 두 값은 포함 관계가 아니라 서로 다른 차원의 측정값으로 읽으세요.
- 대시보드에서 액티브 사용자수 타일의 값을 봅니다.
- 평소 같은 시간대와 비교합니다 — 절대값보다 평소 대비가 중요합니다.
"평소와 비교"는 카드가 직접 도와줍니다 — 카드 헤더의 차트 아이콘(어제·지난주와 비교)을 누르면 실시간 / 어제와 비교 / 지난주와 비교 메뉴가 열립니다.
어제와 비교(또는 지난주와 비교)를 고르면 같은 시간대의 어제 추이가 겹쳐 그려져, 지금 값이 평소 대비 높은지 한눈에 읽을 수 있습니다.
결과 — "지금 몇 명이 쓰고 있는지"와 그 값이 평소와 어떻게 다른지 읽을 수 있습니다.
참고 비업무 시간에 액티브 사용자수가 비정상적으로 높으면 봇·비정상 트래픽을 의심합니다.
3단계 — 대시보드 T-Map에서 느린 것·오류·패턴 보기
여기서 보는 T-Map(트랜잭션 히트맵)은 토폴로지 맵이 아니라, WAS 대시보드 안에 있는 위젯 ("트랜잭션 히트맵(T-Map)")입니다. 일정 시간 동안의 트랜잭션을 가로=시간 / 세로=응답시간으로 흩뿌린 그림으로, 한 점(셀)이 트 랜잭션 묶음이고 위치로 느림을, 색으로 오류를 나타냅니다.
- 위로 솟은 셀 = 응답시간이 긴 트랜잭션입니다(아래쪽 0~1초 band가 정상).
- 빨간 셀 = HTTP 오류(4xx/5xx)입니다.
결과 — "느린 게 위에, 오류가 빨강으로" 한눈에 보입니다.
T-Map이 패턴을 스스로 감지한다 — 원형 Indicator(●)
위젯 우상단에는 원형 점(●) Indicator가 항상 떠 있습니다. 시스템이 약 10초마다 T-Map을 자동 분석해, 위험한 모양(패턴)이 보이면 그 점의 색을 바꿔 먼저 알려 줍니다. 셀을 일일이 눈으로 읽기 전에, 이 점의 색부터 보면 됩니다.
| 원(●) 색 | 의미 | 대표 패턴 |
|---|---|---|
| 초록 | 정상 — 감지된 패턴 없음 | — |
| 노랑 | 약한 패턴(정보) — 참고만 | 가로줄·응답시간 정체·점진적 P95 상승 |
| 주황 (천천히 깜빡임) | 주의 패턴 — 살펴볼 것 | 세로줄(순간 지연 퍼짐)·4xx 군집·이중 분포 |
| 빨강 (빠르게 깜빡임) | 위험 패턴 — 즉시 확인 | 5xx 군집·트래픽 단절·연쇄 장애 |
점에 마우스를 올리면 지금 감지된 패턴 목록이 심각도(심각·주의·정보) 와 짧은 설명과 함께 뜹니다. 주황·빨강은 깜빡여서 주의를 끕니다(빨강이 더 빠르게).
감지된 패턴을 AI로 분석하기
원이 주황·빨강이면, 위젯 우상단의 AI 버튼(CogentAI)을 누릅니다. 그러면 T-Map의
통계(P50~P99·4xx/5xx 비율)·응답시간 밀도·가장 느린 구간(핫스팟)·감지된 패턴이 함께
AI로 전달되고, AI가 "무엇이·왜 이상하며, 다음에 어디를 보라" 를 자연어로 보고합니다.
위험(빨강)일 때 팝업에 뜨는 "즉시 AI 버튼을 클릭하여 진단" 안내가 이것입니다.
결과 — 색으로 이상 여부를, 팝업으로 무슨 패턴인지를, AI로 원인 가설까지 한 위젯에서 얻습니다.
참고 T-Map 패턴(세로줄·가로줄·5xx 군집·이중 분포·트래픽 단절 등)의 의미와 조치는 H5. T-Map 패턴으로 진단하기, AI 진단 따라하기는 T3. AI로 원인 분석하기에 있습니다. 주의 AI 답은 출발점입니다 — 지목된 지표를 실제 셀·차트로 교차 확인한 뒤 조치를 정합니다.
4단계 — 드래그해서 트랜잭션 상세(패턴) 열기
이제 핵심입니다. 의심 구간을 드래그하면 그 트랜잭션들의 상세로 바로 들어갑니다.
- T-Map에서 느린 셀(위쪽) 또는 빨간 셀(오류) 이 모인 영역을 마우스로 드래그합니다.
- 그 시간 × 응답시간 구간의 트랜잭션 trace 다이얼로그가 열립니다.
- 다이얼로그에서 다음을 확인합니다.
- 느린 trace 목록 — 가장 느린 트랜잭션
- 호출 흐름(워터폴) · 스택 트레이스 — 어디서 시간을 썼는가
- 성능 분석 탭의 "문제 감지" — 시스템이 느린 SQL·SQL 오류·외부 호출·오류 패턴을 먼저 짚어 준 카드
성능 분석 탭의 "문제 감지" — 심각도부터 본다
목록에서 트랜잭션 하나를 고른 뒤 성능 분석 탭을 열면, 시스템이 그 트랜잭션을 자동 분석해 문제 감지 카드로 보여 줍니다. 각 카드에는 심각도가 붙습니다.
| 심각도 | 의미 | 예 |
|---|---|---|
| 정보 | 참고 신호 | 느린 메소드(Wait/IO bound) 등 |
| 경고 | 살펴볼 것 | 느린 SQL 쿼리(성공했지만 느림) 등 |
| 위험 | 즉시 조치 | SQL 오류·DB 연결 실패·락 대기·오류 군집 등 |
아래는 /testapp/db/runtime-error.jsp를 연 예입니다. HTTP 상태는 200이지만, 시스템이
위험 카드로 "SQL 객체 참조 오류"(java.sql.SQLSyntaxErrorException: Unknown column 'bad_column')를 짚어 주고 가능 원인(스키마 마이그레이션 미적용·배포 지연·잘못된 DB 연결)까지
제시합니다. 응답 코드만 보면 정상이라 놓칠 문제를, 성능 분석이 먼저 잡아 준 것입니다.
참고 모니터링할 때는 문제 감지의 심각도부터 봅니다. 위험 카드가 있으면 HTTP 응답이 200이어도 그 트랜잭션부터 파고듭니다. 카드는 SQL/외부호출/오류를 유형별로 묶어 주므로, 워터폴을 일일이 읽기 전에 "무엇이 문제인지"가 먼저 보입니다.
AI 느린 SQL이나 SQL 오류가 잡혔다면, 워터폴에서 그 SQL을 열어 AI 쿼리 진단으로 실행계획·인덱스까지 바로 분석시킬 수 있습니다 → T3 2부. 느린 SQL → AI 쿼리 진단.
호출 흐름이 중간에 끊겨 보일 때 — 에이전트 수집 한도
호출 흐름(워터폴) 마지막 줄 뒤에 경고 아이콘과 함께 안내 문구가 뜰 때가 있습니다.
T-Map 최대 표시 건수 (최대 N줄) 내에서는 모두 출력 되었지만, 에이전트 트랜잭션 트레이스 상세 수집 최대 라인수 (transaction.trace.max.line) 설정으로 인해 이 지점까지만 수집됩니다.
화면이 잘린 것이 아니라, 에이전트가 그 지점까지만 수집한 것입니다. 호출이 아주 깊거나 반복이 많은 트랜잭션에서 나타납니다. 뒤쪽 호출은 아예 기록되지 않았으므로 더보기·페이징으로 가져올 수 없습니다.
- 뒷부분까지 봐야 한다면 에이전트의
transaction.trace.max.line값을 올려야 합니다(관리자). 다만 값을 키우면 수집량과 저장 용량이 함께 늘어납니다. - 표시 한도에 걸린 경우는 이 문구가 뜨지 않습니다 — 그때는 더보기 버튼이나 페이징이 나타나고, 눌러서 나머지를 볼 수 있습니다. 두 상황은 화면에서 이렇게 구분됩니다.
결과 — 대시보드의 빨강에서 출발해 느린 트랜잭션 한 건의 내부(패턴·문제) 까지 따라왔습니다. 이것이 추적의 결론입니다.
참고 패턴이 감지된 T-Map 원이 깜빡이면, 원의 AI 버튼(CogentAI 분석) 을 눌러 그 패턴에 대한 상세 진단을 바로 받을 수도 있습니다 → T3. AI로 원인 분석하기.
완료 — 이제 할 수 있는 것
- 대시보드 상단 요청 뷰어·실시간 요청 모니터링 위젯의 색(빨강) 으로 문제를 즉시 판단한다
- 액티브 사용자수가 어떻게 계산되는지 알고 평소와 비교한다
- T-Map에서 느린 것·오류를 가리고, 드래그로 트랜잭션 상세(패턴) 를 연다
다음 단계
| 더 알고 싶은 것 | 가이드 |
|---|---|
| 느려진 원인을 AI로 분석하기 (CogentAI 진단·SQL 쿼리 진단·스레드 덤프) | T3. AI로 원인 분석하기 |
| 문제 패턴 19종의 의미와 조치 | H6. 느린 트랜잭션 원인 찾기 |
| T-Map 16패턴 으로 진단하기 | H5. T-Map 패턴으로 진단하기 |
| 차트 색·지표의 의미(APDEX·Frustrating) | E3. 지표의 의미 |