Java Agent 1.2

v1.2.8

Custom Leak 추적

custom leak 추적이란 트랜잭션이 수행되는 도중에 open과 close메소드의 짝이 맞는지를 추적하는 기능입니다.

whatap.conf
hook_custom_open_patterns=""
hook_custom_close_patterns=""
profile_custom_leak_enabled=true
whatap.conf
profile_custom_leak_enabled=true

옵션에 설정한 메소드들이 프로파일에서 호출내역을 보거나 제거할 수 있다.기본값은 true이다.

사용예

hook_custom_open_patterns=leaktest.T.open
hook_custom_close_patterns=leaktest.T.rollback,leaktest.T.commit

T라는 클래스는 open과 commit/rollback 3개의 메소드가 있다. 이때 open이 호출되면 반드시 commit혹은 rollback이 호출되어야 하며 연속으로 2번이상의 open이나 commit이후 rollback이 호출되는 것은 무시된다.

T.open -> T.open -> T.commit  : ok
T.open ->T.commit -> T.open : leak

v1.2.5

Java9지원

java9가 되면서 JDK내부에 클래스 의존성이 많이 수정되었다. 기존 버전을 설치하면 참조오류가 발생한다. v1.2.5부터 java9에서 애플리케이션을 모니터링 할 수있다.

DBCP & WEBLOGIC10 Connection Pool 기본 추적

DBCP와 웹로직10.3의 컨넥션 풀사이즈가 기본적으로 모니터링된다. 관련 기능을 off하려면 아래 옵션 값을 수정하고 WAS를 재기동하면된다.

dbcp_pool_enabled=true
weblogic_pool_enabled=true

v1.2.2

DB Pool 카운터 추적

와탭은 DB Connection Pool에서 Active 카운트와 Idle카운트를 추적하고 상태정보를 조회하는 기능을 제공한다. 데이터를 조회하는 방식에는 크게는 JMX와 BCI 두가지 방식을 가지고 있다. JMX 방식은 기동중에 옵션 변경만으로 적용된다. 하지만 BCI방식은 재기동시 옵션이 변경되어있어야 한다.

JMX방식에는
tomcat_ds_enabled=false
weblogic_ds_enabled=false
BCI방식에는
hikari_pool_enabled=false
dbcp_pool_enabled=false
weblogic_pool_enabled=false

톰켓과 웹로직은 JMX를 통해 데이터를 조회할수 있지만 버전에 따라서 동작하지 않을 수 있다. 현재 테스트 된 버전은 Tomcat7 버전이다. 웹로직은 weblogic10에서 테스트 되었다. DBCP, Hikari, Weblogic10에서는 컨넥션 풀 클래스를 직접 BCI로 접근하여 데이터를 조회할 수있다.

DB Pool 추적 커스터마이징

1.에이전트 옵션에

custom_pool_classes=<id>@<pool class name>

custom_pool_classes=dbcp@org.apache.tomcat.dbcp.dbcp.BasicDataSource

만약 여러가지 풀을 사용하고 있으면 콤마(,)로 구분하여 여러개를 지정할 수있다.

2.플러그인 추가

${WHATAP_HOME}/plugin/CustomPool.x

$result.active(method($pool,"getNumActive"));
$result.idle(method($pool,”getNumIdle"));

전달된 $pool에서 리플렉션으로 조회를 할 것이다. $pool의 실제 클래스는 custom_pool_classes에 설정했던 객체가 전달된다. 만약 2개이상이 설정되어있다면 $id 를 참조하여 구분할 수있다.

실시간 혹은 일자별 차트에서 데이터 확인 가능

v1.2.1

에이전트 로그 조회

에이전트 로그를 조회할 수있다. java agent v1.2.1이상에서만 동작한다.

메뉴
APM(java) > 서버 > 더보기 > 에이전트 로그

화면이 열리면 에이전트에 저장된 로그 리스트가 보인다. 데이터를 확인하고자 하는 로그를 클릭하면 로그를 볼 수 있다.

로그 내용 상단에 [<<] [ < ] [ > ] [>>] 4개의 이동버튼을 통해 로그를 조회한다.

 [ <<] - 로그 시작 부분으로 이동
 [ < ] - 8KB 이전으로 이동
 [ > ] - 8KB 다음으로 이동
 [ >>] - 로그 파일 끝으로 이동

에이전트 덤프 조회

에이전트에서 생성한 쓰레드덤프 혹은 CPU 프로파일 덤프 파일을 조회할 수 있다. > 단) java agent v1.2.1이상에서만 동작한다.

메뉴

APM(java) > 서버 > 더보기 > 에이전트 덤프

화면이 열리면 에이전트에서 생성된 덤프파일 리스트가 보인다. 파일명을 클릭하면 덤프 내용을 확인할 수있습니다.

v1.2.0

CPU 과점 쓰레드 덤프

WAS 프로세스의 CPU가 높을때 어떤 쓰레드가 CPU를 많이 사용하는지 찾기 위해 쓰레드 덤프를 연속적으로 수행하는 기능입니다.

whatap.conf
debug_cpu_enabled = false;
debug_cpu_trigger = 0;
debug_cpu_interval = 10000;
debug_cpu_dump_count=10;
  • debug_cpu_enabled=true 가 되면 본 기능이 활성화됩니다.

  • debug_cpu_trigger값이 변경되면 그때부터 CPU를 가장 많이 사용하는 쓰레드5개를 ${WHATAP_HOME}/whatap-cpu-(pcode)-(oname)-{time]-{num].wdmp 파일에 기록합니다.

  • 덤프 간격은 debug_cpu_interval에 지정됩니다.

  • debug_cpu_dump_count(10) 횟수만큼 덤부를 수행합니다.

덤프내용을 백그라운드 쓰레드를 포함하여 덤프 간격동안 CPU 를 가장 많이 사용하고 있는 쓰레드이고 만약 개별 쓰레드가 사용자 요청(URL)를 처리 중이라면 URL도 같이 로깅한다.

자동 쓰레드 덤프

WAS의 장애가 발생하여 액티브트랜잭션이 증가하면 자동으로 전체 쓰레드를 덤프하여 향후 문제 분석에 활용합니다.

whatap.conf
thread_dump_enabled = true
thread_dump_interval = DateUtil.MILLIS_PER_HOUR
thread_dump_cpu = -1
thread_dump_actx = 300

thread_dump_actx(300)이상의 액티브 서비스갯수가 쌓이거나 thread_dump_cpu(-1:disabled)이상의 CPU사용이 발생할때 JVM내의 모든 쓰레드와 그 스택을 덤프한다. 각 쓰레드가 수행하는 URL정보도 같이 덤프라한다. (값이 -1일때는 동작하지 않는다) 한번 덤프가 발생하면 thread_dimp_interval 이상 시간이 경과되어야 다시 동작합니다.

특정 url 쓰로틀링(Request Throttling)

웹 요청이 폭주할경우 초과 요청을 다른 페이지로 넘길 수있다. 쓰로틀링에서 특정 타겟팅 페이지만 제어하는 기능이 추가되었다.

whatap.conf
throttle_enabled = false;
throttle_limit = 10000;

throttle_target_urls =

throttle_passing_url =
throttle_passing_url_prefix =

throttle_rejected_message = too many request!!
throttle_rejected_forward = <static url>

throttle_blocking_url =
throttle_blocking_ip =
throttle_blocked_message = request blocked!!
throttle_blocked_forward_ok = true

throttle_enabled=true가 설정되면 쓰로틀링 기능이 활성화된다. 현재 요청된 URL이 블럭킹 대상이면 처리가 거부된다. 그다음은 액티브 트랜잭션 갯수가 throttle_limit에 도달했는지를 확인하고 limit를 초과하면 url을 검사한하다. 만약 throttle_target_urls(이번에 추가됨)이 등록되있으면 해당 URL에 등록된경우는 서비스를 거부하고 포함되지 않았다면 정상 처리한다. throttle_target_urls에는 full url path로 설정한다. 여러개를 설정할때는 ,로 구분한다.

사용자 기본 측정방식 변경

와탭은 웹시스템의 사용자를 측정하기 위해 쿠키를 사용합니다. 그런데 모바일이나 일부 장비에서 쿠키를 원할하게 처리하지 못하는 현상이 예상되어 기본을 ip를 사용하여 사용자를 측정하도록 변경하였습니다.

whatap.conf
trace_user_using_ip = true

만약 이전처럼 쿠키를 기반으로 사용자를 측정하고자 한다면 위 옵션을 false로 변경해 주어야 한다.

DB 연결 카운팅

whatap.conf
tomcat_ds_enabled = false
weblogic_ds_enabled = false
hikari_pool_enabled = false
dbcp_pool_enabled = false
weblogic_pool_enabled = false

xx_ds_enabled와 xx_pool_enabled 두가지 옵션이 있다. ds는 DaraSource에서 데이터를 JMX로 추출하고 _pool_은 BCI 를 통해서 데이터를 추출한다.

따라서 운영중에 xx_ds_enabled=true를 적용하면 바로 적용되지만 xx_pool_enabled는 재기동이 필요하다.

톰켓에서 DBCP를 사용하는 시스템의 경우에는 tomcat_db_enbled혹은 dbcp_pool_enabled를 모두 사용할 수있다. 하지만 SpringBoot에서 DBCP를 사용하는 경우에는 dbcp_pool_enabled를 사용해야 한다.

웹로직의 경웨는 Standalone으로 설치된 경우에는 weblogic_ds_enabled와 weblogic_pool_enabled를 모두 사용할 수 있으나 도메인 구성이되어있는 경우에는 weblogic_pool_enabled를 적용해야 데이터가 추출된다.

메소드 호출 건수 추적

특정 메소드의 호출건수를 추적하고 싶을 때 사용한다. .whatap.conf

hook_method_stat_supers
hook_method_stat_interfaces
hook_method_stat_patterns

서버 > 더보기 > Method Perfor Stat에서 확인 할 수 있습니다.

에이전트 메모리에서 카운팅을 하고 메뉴에서 현재 통계 정보를 조회할수 있다.

액티브 스택 최적화

액티브 스택을 수집함에 있어 에이전트 폭주시 영향을 최소화 하기 위해 최적화 옵션이 적용되어있다.

최대 동시 액티브 스택 지정

간혹 시스템에 따라 액티브 트랜잭션이 수천개가 되는 경우들이 있다. 이것은 이미 장애 상황이기 때문에 액티브 스택 수집을 제한하고 있다.

active_stack_count = 100
덤프 interval

TPS가 높은 시스템에서 (인스턴스당 약400정도)에서는 모니터링 오버헤드를 신경써야 한다. 액티스 스택의 수집주기를 늘려줄 필요가 있다.

active_stack_second=10 (단위 초)

약 60정도 적용하면 무난 할 것이다.

스택 depth

액티브 스택의 최대 depth이다. 기본은 최대 스택별 50라인을 수집한다.

trace_active_callstack_depth = 50

트랜잭션별 메모리 할당 추적기능 OFF

트랜잭션별로 메모리 할당 량을 추적하는 기능을을 default로 false되었다.