Java Agent 1.2
v1.2.8
Custom Leak 추적
custom leak 추적이란 트랜잭션이 수행되는 도중에 open과 close메소드의 짝이 맞는지를 추적하는 기능입니다.
hook_custom_open_patterns="" hook_custom_close_patterns="" profile_custom_leak_enabled=true
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.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
v1.2.0
CPU 과점 쓰레드 덤프
WAS 프로세스의 CPU가 높을때 어떤 쓰레드가 CPU를 많이 사용하는지 찾기 위해 쓰레드 덤프를 연속적으로 수행하는 기능입니다.
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의 장애가 발생하여 액티브트랜잭션이 증가하면 자동으로 전체 쓰레드를 덤프하여 향후 문제 분석에 활용합니다.
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)
웹 요청이 폭주할경우 초과 요청을 다른 페이지로 넘길 수있다. 쓰로틀링에서 특정 타겟팅 페이지만 제어하는 기능이 추가되었다.
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를 사용하여 사용자를 측정하도록 변경하였습니다.
trace_user_using_ip = true
만약 이전처럼 쿠키를 기반으로 사용자를 측정하고자 한다면 위 옵션을 false로 변경해 주어야 한다.
DB 연결 카운팅
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