용어 사전
와탭 모니터링을 쓰다 보면 프로젝트, 에이전트, 메트릭스처럼 반복해서 나오는 말을 만납니다. 이 문서는 그 용어들의 뜻을 한곳에 모아 둡니다.
와탭을 처음 도입하거나 다른 제품을 함께 쓰기 시작한 분이 대상입니다. 제품 문서를 읽다 모르는 말이 나오면 이 문서에서 찾으세요.
용어는 셋으로 나눠 두었습니다. 제품과 무관하게 쓰는 와탭 공통 서비스 용어, 와탭 고유는 아니지만 알아야 하는 모니터링 일반 용어, 특정 제품에서만 쓰는 제품별 용어입니다.
용어 사전은 지속적으로 업데이트됩니다.
와탭 공통 서비스 용어
제품과 무관하게 와탭 서비스 전반에서 쓰는 용어입니다.
프로젝트
모니터링의 기본 단 위입니다. 프로젝트 단위로 모니터링 대상을 구분하고 멤버 권한을 관리합니다.
애플리케이션, 서버, 데이터베이스처럼 와탭 제품을 기준으로 만듭니다. 제품이 다르면 프로젝트도 달라집니다. 같은 제품 안에서도 Front, Gateway, API처럼 용도별로 나눌 수 있습니다.
그룹
여러 프로젝트를 하나로 묶어 관리하는 단위입니다. 제품이 서로 다른 프로젝트도 묶을 수 있습니다. 예를 들어 한 팀이 서버, 애플리케이션, 데이터베이스를 함께 사용한다면 세 프로젝트를 한 그룹으로 묶습니다.
그룹에 멤버를 추가하면 그룹 내 모든 프로젝트에 같은 권한이 적용됩니다.
하나의 프로젝트는 하나의 그룹에만 속합니다. 그룹에 속하지 않는 프로젝트도 있을 수 있습니다.
조직
여러 그룹을 하나로 묶어 관리하는 최상위 단위입니다. 대부분은 프로젝트와 그룹만으로 충분합니다.
운영 관리 서비스(MSP) 기업처럼 여러 고객사를 그룹으로 나눠 관리하는 경우에 활용합니다. 각 그룹 멤버에게 권한을 주면 그룹을 독립적으로 운영할 수 있습니다.
에이전트
모니터링 대상에서 데이터를 수집해 와탭 수집 서버로 보내는 프로그램입니다. 와탭 모니터링은 에이전트가 보낸 데이터로 동작하므로, 제품을 사용하려면 먼저 에이전트를 설치해야 합니다.
에이전트는 제품마다 다르고, 설치 위치와 구성도 모니터링 대상에 따라 달라집니다.
| Target | Location |
|---|---|
| 애플리케이션(APM) | 애플리케이션 서버. 애플리케이션과 함께 실행 |
| 서버 | 모니터링할 서버 |
| 데이터베이스 | DB 서버가 아닌 별도 서버. 에이전트가 DB에 접속해 수집 |
| 컨테이너(쿠버네티스) | 클러스터. 마스터 에이전트와 노드 에이전트로 구성 |
하나의 에이전트가 여러 대상을 수집하기도 합니다. 예를 들어 데이터베이스 에이전트는 클러스터의 대표 노드 한 곳에만 설치하면 나머지 노드를 자동으로 찾아 함께 수집합니다.
에이전트 이름은 제품을 따릅니다. Java 에이전트, PHP 에이전트, 서버 에이전트처럼 부릅니다. 데이터베이스만 역할이 다른 에이전트가 셋이라 각각의 이름을 씁니다.
제품별 에이전트 설치 방법은 각 제품의 설치 문서를 참조하세요.
수집 서버 (Collection Server)
프로젝트 생성시 모니터링 데이터를 수집하는 서버를 의미합니다. SaaS형 서비스 사용시 와탭의 수집 서버를 사용하므로 별도로 수집 서버를 구축할 필요가 없습니다.
인스턴스
모니터링의 개별 단위입니다. 무엇을 하나로 세는지는 제품에 따라 다릅니다.
| Product | Instance |
|---|---|
| 애플리케이션(APM) | 에이전트를 붙인 애플리케이션 프로세스 하나. 같은 애플리케이션을 여러 대로 띄우면 각각이 인스턴스 |
| 서버 | 서버 한 대 |
| 데이터베이스 | DB 노드 하나 |
| 컨테이너(쿠버네티스) | 노드 또는 컨테이너 하나 |
메트릭스
모니터링 대상에서 수집한 수치 지표입니다. CPU 사용률, 응답 시간, 토큰 사용량처럼 시간에 따라 변하는 값을 시계열로 저장합니다.
MXQL
와탭이 수집한 데이터를 직접 조회하는 질의 언어입니다. 메트릭스 쿼리 언어라는 뜻입니다.
기본 화면이 제공하지 않는 형태로 데이터를 뽑거나 수집 값을 그대로 확인할 때 씁니다. 문법과 함수는 MXQL 가이드를 참조하세요.
메트릭스 차트 (Metrics Chart)
수집된 데이터를 시계열 차트로 보여줍니다. 시간대를 선택한 후 원하 는 측정 항목을 고르면 결과를 보여줍니다.
대시보드
대시보드를 이용해 시스템 전체 현황을 실시간으로 파악할 수 있습니다. 대시보드에서는 진행 중 트랜잭션 현황, 종료 트랜잭션의 응답시간 분포, 사용자 수, CPU, 메모리 추이 등의 주요 지표를 보여줍니다.
자세한 내용은 다음 문서를 참조하세요.
큐브
와탭이 5분 단위로 모아 둔 통계 데이터입니다. 제품마다 큐브가 있고, 큐브 분석은 이 데이터를 바탕으로 과거 구간을 들여다보는 기능입니다.
실시간 지표가 지금 상태를 보여 준다면, 큐브는 지난 구간을 5분 단위로 되짚어 볼 때 씁니다.
제품별 큐브 화면은 각 제품 문서를 참조하세요. 저장 방식은 큐브 데이터 저장소에 정리돼 있습니다.
위젯
대시보드를 이루는 개별 구성 요소입니다. 차트, 표, 숫자 등 한 가지 지표나 관점을 보여 줍니다. 위젯을 모아 대시보드를 구성합니다.
플렉스 보드
사용자가 원하는 방식으로 커스터마이즈 할 수 있는 대시보드입니다. 애플리케이션, 서버, 데이터베이스, 컨테이너 등 와탭 프로젝트의 데이터를 화면에 자유자재로 배치할 수 있습니다.
자세한 내용은 다음 문서를 참조하세요.
경고 알림
설정한 조건에 해당하는 상황이 생기면 지정한 채널로 알리는 기능입니다. 어떤 상황을 감지할지는 이벤트 설정에서 정합니다.
이벤트
모니터링 대상에서 감지한 특정 상황입니다. 어떤 상황을 이벤트로 볼지는 이벤트 설정에서 조건으로 정하고, 이벤트가 발생하면 경고 알림을 보냅니다.
알림 (Notification)
모니터링 대상에 문제가 생기면 여러 채널로 사용자에게 실시간으로 보내는 소식입니다.
시스템 특성에 맞춰 미리 정의한 알림 규칙을 제공하고, 필요하면 조건을 직접 설정할 수 있습니다.
oname · okind
에이전트를 식별하는 두 값입니다. 짝으로 쓰이지만 가리키는 것이 다릅니다.
| Option | Description |
|---|---|
oname | 에이전트의 오브젝트 이름. 에이전트 하나를 가리키는 고유값 |
okind | 에이전트의 종류. 용도가 같은 에이전트를 묶는 값 |
oname이 이름표라면 okind는 분류표입니다. 예를 들어 모바일 UI 용도로 쓰는 에이전트라면 okind를 mobile_ui로 지정해 같은 용도끼리 묶어 볼 수 있습니다.
-Dwhatap.oname=web-01
-Dwhatap.okind=mobile_ui
모니터링 일반 용어
와탭 고유 용어는 아니지만 모니터링을 이해하는 데 필요한 용어입니다.
로그(Log)
로그는 애플리케이션 실행 중 발생하는 이벤트와 메시지 등을 기록한 파일입니다.
애플리케이션 활동과 발생한 이슈의 원인을 이해하려면 반드시 로그 파일을 들여다봐야 합니다.
모니터링
모니터링(Monitoring)이란 어떤 대상을 감시, 관찰한다는 뜻입니다. IT 서비스 분야에서는 한정된 비용과 리소스를 가지고 서비스를 제공합니다. 때문에 모니터링으로 예기치 못한 상황과 오류를 대비하고 극복해야 합니다.
Observability (옵저버빌리티)
시스템이 내보내는 데이터로 내부에서 무슨 일이 일어나는지 파악할 수 있는 성질입니다.
모니터링이 미리 정해 둔 지표가 정상 범위인지 확인하는 것이라면, 옵저버빌리티는 예상하지 못한 문제가 생겼을 때 원인까지 추적하는 데 초점을 둡니다.
APM (Application Performance Management)
애플리케이션 성능 관리를 뜻합니다. 애플리케이션의 성능은 웹 서비스의 응답 속도로 측정하므로, APM은 트랜잭션을 추적하고 분석합니다.
- Application, 모니터링 대상인 애플리케이션
- Performance, 응답 속도로 측정하는 성능
- Management 또는 Monitoring
와탭에서는 애플리케이션 모니터링 제품이 APM에 해당합니다.
자세한 내용은 다음 문서를 참조하세요.
OpenMetrics
Prometheus 메트릭 형식을 기반으로 하는 시계열 지표 표준입니다. 와탭은 이 형식으로 노출되는 지표를 수집해 조회하고 분석할 수 있습니다.
OpenAgent
Prometheus 및 OpenMetrics 형식을 노출하는 엔드포인트에서 지표를 수집하는 에이전트입니다. Go로 빌드한 정적 바이너리라 별도 런타임을 설치하지 않아도 됩니다.
토폴로지
구성 요소 사이의 호출 관계를 그림으로 나타낸 것입니다. 어느 지점에서 지연이나 오류가 생기는지 흐름으로 파악할 수 있습니다.
트랜잭션 (Transaction)
애플리케이션 모니터링에 있어 트랜잭션이란, 애플리케이션에 유입된 단일 요청(request)이 애플리케이션의 처리 과정을 거쳐 응답(response)이 반환되기까지의 과정을 일컫습니다.
TPS (Transactions Per Second)
초당 처리된 트랜잭션 건수를 의미합니다. 서비스 성능지표 중 기준이 됩니다. 와탭은 프로젝트 전체 TPS를 실시간으로 보여줍니다.
처리량
성능에 있어서 처리량은 '얼마나 많은 요청을 완료할 수 있는가'를 의미합니다. 이 말은 '시스템이 얼마나 많은 트랜잭션을 처리하는가'를 나타냅니다.
처리량은 초 단위 또는 분 단위로 측정합니다. 처리량은 요청량과 다릅니다. 처리량은 마무리된 요청의 양입니다. 초당 요청량(RPS)이 100이지만 초당 처리량(TPS)이 10이라면 90건 요청은 아직도 처리되지 못한 상태입니다.
자세한 내용은 다음 문서를 참조하세요.
평균 응답 시간
애플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간입니다. 와탭의 서비스는 5초 간격으로 트랜잭션의 평균 응답 시간을 계산합니다. 평균 응답 시간은 튜닝 지표로서 의미를 가집니다.
스레드(Thread)
프로세스 내에서의 실행 단위입니다. 모든 프로세스에는 한 개 이상의 스레드가 존재하여 작업을 수행합니다.
그리고 두 개 이상의 스레드를 가지는 프로세스를 멀티스레드 프로세스(multi-thread process)라고 합니다. 각 스레드는 자신의 스택과 레지스터를 가지고 있습니다.
자세한 내용은 다음 문서를 참조하세요.
제품별 용어
특정 제품에서만 쓰는 용어입니다.
애플리케이션 모니터링(APM)
액티브 트랜잭션 (Active Transaction)
진행 중인 트랜잭션을 의미합니다.
자세한 내용은 다음 문서를 참조하세요.
멀티 트 랜잭션
MSA와 같이 여러 애플리케이션의 호출 관계를 추적해야할 경우에 어느 부분에서 문제가 발생했고, 개선이 필요한지 식별할 수 있는 기능입니다.
트랜잭션 트레이스
단일 트랜잭션의 수행과정에서의 일련의 처리 과정을 의미합니다.
트랜잭션 맵
종료된 개별 트랜잭션의 응답 시간 분포도입니다. 히트맵과 동일하게 분포 패턴에 따른 문제점을 발견하고 분석할 수 있습니다.
Hitmap은 5분 시간 단위로 트랜잭션을 그룹화해서 보여주지만, 트랜잭션 맵은 트랜잭션을 개별로 표시합니다.
Apdex (Application Performance Index)
Apdex는 애플리케이션 성능 지표를 의미합니다. Apdex는 응답 시간에 기반하며 전체 요청 중 만족과 허용건 비율로 수치화합니다. Apdex는 사용자 만족도에 대한 지표로 활용할 수 있으며, 0~1 사이의 값을 갖습니다.
자세한 내용은 다음 문서를 참조하세요.
Hitmap(히트맵)
응답 시간 분포 차트입니다. 특정 기간의 응답 시간 분포를 한눈에 파악할 수 있습니다.
트랜잭션 발생 위치에 따라 느린 트랜잭션을 쉽게 찾아낼 수 있습니다. 색상을 통하여 에러 발생 여부에 대해서도 빠르게 찾아낼 수 있습니다.
X축은 트랜잭션의 종료 시간, Y축은 응답 시간을 의미합니다. 히트맵 상의 특정 영역을 드래그하면 트랜잭션 목록을 보여주는 화면으로 이동합니다.
자세한 내용은 다음 문서를 참조하세요.
탑 스택 (Top Stack)
탑 스택은 트랜잭션의 스택 정보를 수집하여 실행중인 메소드의 사용량 통계를 제공합니다.
스택의 최상단의 사용량 통계를 통해 서비스에 가장 많은 영향을 주는 메소드를 확인합니다. 메소드의 호출 빈도를 파악하면 CPU 또는 메모리에 부하가 걸리는 원인을 분석할 수 있습니다.
자세한 내용은 다음 문서를 참조하세요.
유니크 스택 (Unique Stack)
실행된 메소드의 집합이 동일한 경우에 대한 통계 정보입니다. 유니크 스택을 통해 많이 사용되는 스택의 정보를 알 수 있습니다.
유니크 스택에 많이 노출되었다면 통계적으로 빈번한 호출 또는 오랜 시간 동작하는 메소드입니다.
자세한 내용은 다음 문서를 참조하세요.
액티브 스택 (Active Stack)
실행 중인 트랜잭션의 스택 정보를 수집하는 기능입니다. 스택 정보는 10초마다 수집됩니다. 수집된 데이터는 통계로 확인할 수 있습니다.
통계 정보는 긴 시간 실행되는 메소드, 짧은 시간 수행되지만 잦은 빈도로 실행되는 메소드 모두 비율을 통해 식별할 수 있습니다. 트랜잭션이 진행 중 메소드 레벨에서 어느 부분이 지연이 되었는지 확인 가능합니다.
자세한 내용은 다음 문서를 참조하세요.
힙 메모리 (Heap Memory)
JVM(자바 가상머신)은 프로그램을 실행하기 위해 메모리에 데이터 저장 공간을 할당합니다.
메모리 공간은 크게 3가지 영역으로 분류됩니다. Static, Stack, Heap 영역입니다. 객체(인스턴스), 배열 등 주요 데이터는 Heap 메모리 영역에 저장됩니다.
자세한 내용은 다음 문서를 참조하세요.
동시 접속 사용자 (Realtime User)
실시간 브라우저 사용자 수를 보여줍니다. 10초마다 최근 5분 이내에 트랜잭션을 일으킨 사용자를 카운팅 하여 보여줍니다.
사용자는 브라우저의 IP를 기반으로 카운팅 합니다. 에이전트 설정에서 사용자를 구분하기 위해 IP를 사용하거나 쿠키를 사용할 수 있습니다.
애플리케이션 토폴로지
프로젝트 범위에서 포함된 모든 애플리케이션의 관계 정보를 표현합니다.
액티브 스테이터스 (Active Status)
액티브 트랜잭션들을 각 상태별로 갯수를 보여줍니다.
- METHOD : 메소스 수행중인 상태
- SQL : SQL을 수행중인 상태
- HTTPC : 외부 API 호출 상태
- DBC : 트랜잭션이 Connection Pool로 부터 새로운 Connection을 획득(get)하려는 상태
- SOCKET : 외부로 TCP Socket을 연결 중인 상태
자세한 내용은 다음 문서를 참조하세요.
MSA 분석 (Microservices Architecture)
URL을 기준으로 각각의 서비스 간의 호출 관계를 비율로 보여줍니다.
Caller와 Callee
- Caller: 서비스를 호출한 트랜잭션(호출자)을 의미합니다.
- Callee: 서비스를 호출 당한 트랜잭션(피호출자)을 의미합니다.
성능 추이
지정한 시간에 해당하는 성능에 영향을 끼치는 정보들을 조회할 수 있습니다. 또한 전체, 개별 애플리케이션 서버 별로 그래프를 확인할 수 있습니다. 성능에 많은 영향을 끼치는 애플리케이션 서버가 무엇인지 파악 가능합니다.
성능 추이에서 조회할 수 있는 정보는 다음과 같습니다.
- 실시간 사용자
- 트랜잭션/초(합계)
- 응답시간
- CPU
- 힙 메모리
- 액티브 TX
- 많이 처리된 트랜잭션 Top 10
- HTTP Call Top 10
- SQL Top 10
리소스 보드 (Resource Board)
리소스 보드에서 하나의 프로젝트에 등록된 모든 서버를 모니터링할 수 있습니다. 프로젝트 내 모든 서버의 요약 정보와 실시간 자원 사용량의 변화를 확인할 수 있는 CPU Resource Map 맵을 제공합니다.
전체 자원의 규모, CPU, 메모리, 프로세스의 사용률 Top 5를 보여줍니다. 리소스 보드를 통해 장애 상황을 즉시 인지하고 대응할 수 있습니다.
자세한 내용은 다음 문서를 참조하세요.
쿠버네티스 모니터링
마스터 에이전트 · 노드 에이전트
쿠버네티스 모니터링의 에이전트입니다. 둘을 함께 설치합니다.
| Agent | Description |
|---|---|
whatap-master-agent | 클러스터 수준 지표 수집 |
whatap-node-agent | 노드와 컨테이너 수준 지표 수집 |
와탭 오퍼레이터
쿠버네티스에 와탭 에이전트를 설치하고 관리하는 오퍼레이터입니다. WhatapAgent 사용자 정의 리소스(CR)에 원하는 구성을 적으면 오퍼레이터가 그에 맞게 에이전트를 배포합니다.
로그 모니터링
로그 모니터링 (Log Monitoring)
와탭의 로그 모니터링을 통해서 실시간으로 로그를 조회할 수 있습니다. 혹은 특정 시간, 카테고리, 태그 또는 필터를 적용하여 원하는 로그만 선택적으로 볼 수도 있습니다.
자세한 내용은 다음 문서를 참조하세요.
라이브 테일
수집 중인 로그를 실시간으로 흘려보며 확인하는 화면입니다. 저장하지 않는 로그도 로그 필터 설정에서 표시 여부를 켜면 라이브 테일에서 볼 수 있습니다.
로그 탐색
수집한 로그를 조건으로 좁혀 가며 살펴보는 화면입니다. 시간, 카테고리, 태그, 필터를 조합해 원하는 로그만 추립니다.
로그 파서
형태가 일정하지 않은 로그를 쿼리할 수 있는 구조로 바꾸는 기능입니다. 정규 표현식과 GROK 문법을 쓰는 GROK 파서, JSON 로그를 다루는 JSON 파서 두 가지가 있습니다.
빠른 인덱스
로그를 대량으로 수집하는 환경에서 검색 속도를 높이려고 미리 만들어 두는 인덱스입니다.
로그 장기 보관
로그는 용량이 커서 오래 두기 어렵습니다. 장기 보관은 원본 대신 통계 형태로 줄여 오래 남기는 기능입니다.
개인정보 비식별화
로그에 들어 있는 개인정보를 마스킹하거나 안전한 값으로 바꾸는 기능입니다. 지정한 민감 정보는 암호화해 저장합니다.
서버 모니터링
리소스 이퀄라이저
CPU, Memory, Disk I/O, Disk IOPS의 항목에 대해 상위 5개의 서버 목록을 실시간으로 보여줍니다.
CPU 리소스 맵 (CPU Resource Map)
전체 서버들의 CPU 사용량을 나타내는 분포도입니다. 10분 동안의 데이터를 보여주고 10초 주기로 갱신됩니다.
컴파운드 아이
와탭 에이전트가 설치된 각각의 서버를 하나의 눈(Eye)으로 표현합니다. 컴파운드 아이는 서버들을 한곳에 모아서 보여줍니다.
총 5가지의 정보를 제공합니다.
- CPU 사용량
- Memory 사용량
- Disk 사용량
- 네트워크의 Rx (수신량)
- 네트워크의 Tx (송신량)
자세한 내용은 다음 문서를 참조하세요.
DISK I/O
Disk I/O(%) 지표는 디스크 사용률을 보여줍니다. Disk I/O(%)가 80%를 넘으면 시스템 성능에 영향을 줄 수 있습니다.
기본 경고 값은 90%입니다. Disk I/O(%)가 100%라면 디스크가 쉬지 않고 일하고 있다는 의미입니다.
DISK IOPS (Input/Output Operations Per Second)
초당 입력과 출력 작업을 나타내는 측정 단위입니다. 작업은 KiB 단위로 측정됩니다.
기본 드라이브 기술에 따라 볼륨 유형이 단일 I/O로 계산하는 최대 데이터 용량이 결정됩니다. 일반적으로 HDD의 IOPS 범위는 55-180입니다. SSD의 IOPS는 3,000 ~ 40,000입니다.
CPU Steal Time
CPU Steal Time은 하이퍼바이저가 다른 가상 프로세서를 서비스하는 동안 가상 CPU가 실제 CPU를 기다리는 시간을 백분율로 표시한 값입니다.
가상 환경에서 동작하는 VM(Virtual Machine)은 단일 호스트에 있는 다른 인스턴스와 리소스를 공유합니다.
CPU Steal Time을 통해 VM에서 동작하는 CPU가 물리 머신으로부터 자원을 할당받기 위해 얼마나 대기하고 있는지 알 수 있습니다.
데이터베이스 모니터링
DBX · DMX · XOS
데이터베이스 모니터링의 에이전트입니다. 다른 제품은 제품명을 그대로 쓰지만, 데이터베이스는 역할이 다른 에이전트가 셋이라 각각 이름을 붙였습니다.
| Agent | Description |
|---|---|
DBX | DB 에 접속해 지표 수집. DB 서버가 아닌 별도 서버에 설치 |
DMX | Oracle Pro 전용. 별도 제공 |
XOS | DB 서버 자원 추가 수집. 선택 사항 |
Redis 서버
인-메모리 방식의 데이터 저장소입니다. 와탭에선 HTTP 세션을 담는 세션 저장소로 쓰고 있습니다.
LLM Observability
AI Agent
LLM을 이용해 스스로 판단하고 필요한 도구를 호출해 작업을 수행하는 프로그램입니다. 사용자의 요청 하나를 처리하려고 여러 번의 LLM 호출과 도구 실행을 거치기도 합니다.
와탭이 설치하는 에이전트와는 다른 대상입니다. 와탭 에이전트는 데이터를 수집하는 쪽이고, AI Agent는 관측되는 쪽입니다.
LLM Observability는 AI Agent의 실행 흐름과 토큰 사용량, 응답 성능을 관측합니다.
SDK (Software Development Kit)
애플리케이션 코드에서 직접 호출해 계측 구간을 선언하는 라이브러리입니다. whatap.llm의 workflow와 agent로 영역을 감싸면, 그 안에서 일어난 LLM 호출이 하나의 트랜잭션으로 묶입니다.
from whatap.llm import workflow
에이전트와 하는 일이 다릅니다. 에이전트는 코드를 고치지 않고 자동으로 계측하고, SDK는 코드에 직접 넣어 구간의 경계를 정합니다. 자동 계측만으로 원하는 단위가 나오지 않을 때 SDK로 보완합니다.
LLM (Large Language Model)
대량의 텍스트로 학습해 자연어를 이해하고 생성하는 AI 모델입니다. 대규모 언어 모델이라고도 합니다.
호출할 때마다 토큰 단위로 과금되고, 같은 프롬프트를 보내도 매번 다른 응답을 생성합니다. 이 두 가지 때문에 기존 애플리케이션과는 다른 방식으로 비용과 품질을 관측해야 합니다.