APM을 통한 서버 장애 대응 방법
서비스가 느려질 때 분석 방법
서비스가 느려질 때는 스레드 덤프를 통해서 원인을 파악할 수 있다. 서비스가 느려지는 상황이 되면, APM의 지표들을 통해 상황을 파악할 수 있다.
- 사용자 만족도 지수(APDEX)의 값이 점점 낮아진다.
- TPS 값은 낮아지며, Average Response Time값은 커진다.
- Request Velocity의 Pending Request들이 쌓인다.
- Transaction Heatmap(T-Map)의 상단에 점들이 표시된다.
스레드 덤프 분석 방법




이 때는 스레드 덤프를 받아 분석하는 것이 장애 원인 파악에 도움이 된다.
스레드 덤프는 JVM의 스냅샷을 받는 것이기 때문에, 스레드 덤프는 3~5초 간격으로 5회 정도 받아 놓는 것이 좋다.
대시보드에서 Pending Request가 쌓이는 인스턴스가 있으면, 해당 인스턴스의 Pending Request Bar를 클릭하면 바로 스레드 덤프를 분석하는 페이지로 이동한다.
- 스레드 덤프 요청 방법

- 스레드 덤프 선택

- 스레드 덤프 분석 버튼 클릭

- Active Thread는 현재 Request를 처리 중인 스레드
Active Thread는 APM에서 스레드 덤프가 실행되는 시점에 현재 처리중인 Request 정보를 스레드 덤프의 부가 정보로 추가한 것이다.
스레드를 Active Thread로 정렬하면, 현재 수행중인 URL 정보, 스레드 덤프 시점까지 애플리케이션의 CPU 사용량, 수행시간 정보를 확인할 수 있다.
좌측 하단의 스레드 덤프 테이블에서 해당 행을 클릭하면, 우측 하단의 스레드 덤프 상의 해당 라인으로 이동하여, 해당 스레드가 현재 실행 중인 애플리케이션의 Stack 정보를 확인할 수 있다.

스레드 덤프에 표시되는 스레드의 상태

Lock 관계 분석
서버가 느려지는 경우 중 여러 스레드가 하나의 변수나 메소드를 공유할 경우, Java의 문법 중 synchronized를 사용하여 동시에 접근하지 못하도록 막는다. 스레드 덤프 상 에 BLOCKED가 이런 경우에는 Lock을 잡은 스레드가 Lock을 해제할 때 까지 기다리게 되어 시스템이 느려질 가능성이 있다.

APM의 스레드 덤프 분석화면에서는 다음과 같이 BLOCKED로 표시되며, 해당 열을 클릭하면, waiting to lock <0x0000….>과 같이 대기하는 Lock 정보가 출력된다.
여기서, Lock 번호를 클릭하면, 해당 번호의 Lock을 잡은 스레드로 이동하여 확인할 수 있다.
다음 절차대로 분석하면 된다.


개발중인 애플리케이션의 실행 속도가 궁금한 메소드를 Trace에 표시하려면?
개발중인 애플리케이션의 운영환경에서 실행 속도가 궁금할 때, 코드에 간단히 @TraceMethod 어노테이션만 추가하면 APM의 Transaction Trace 항목에 추가되어 메소드의 실행 시간을 확인할 수 있다.
- APM API를 다운로드, 컴파일
$ git clone https://github.com/opennaru-dev/khan-monitoring-api
$ mvn install
혹은, 다음 URL에서 컴파일된 JAR를 다운로드 할 수 있다.
https://github.com/opennaru-dev/khan-monitoring-api/blob/master/dist/khan-monitoring-api.jar
- pom.xml 파일에 dependency 추가
다음과 같이 dependency를 추가한다.
<dependency>
<groupId>com.opennaru.khan</groupId>
<artifactId>khan-monitoring-api</artifactId>
<version>1.3.0</version>
</dependency>
- @TraceMethod 어노테이션 사용법
아래와 같이 JAX-RS의 메소드에서 Test라는 클래스를 호출한다.
package com.opennaru.rest;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Response;
@Path("/users")
public class UserRestService {
@GET
public Response getUser() throws Exception {
Thread.sleep(1000);
Test test = new Test();
test.test();
Thread.sleep(1000);
Test2 test2 = new Test2();
test2.test();
Thread.sleep(1000);
return Response.status(200).entity("getUser is called").build();
}
}
- Test 클래스의 test() 메소드에 @TraceMethod 어노테이션 추가
package com.opennaru.rest;
import com.opennaru.khan.agent.instrument.TraceMethod;
public class Test {
public Test() {
}
@TraceMethod
public void test() {
try {
System.out.println("start test");
Thread.sleep(1000);
new Test2().test();
System.out.println("end test");
} catch(Exception e) {
e.printStackTrace();
}
}
}
- Transaction Trace항목에 다음과 같이 @TraceMethod 어노테이션이 추가된 Test.test() 메소드의 수행시간이 표시된다.
===========================================================================
[Num.][ Start Time |Elapsed| % | B-Gab|Exclusi| A-Gab| CPUTime] Method Call
---------------------------------------------------------------------------
[ 1][18:25:09.342| 6,327| 100| 0| 5| 0| 0.0]+ org.apache.catalina.connector.CoyoteAdapter.service()
[ 2][18:25:09.346| 6,322| 100| 0| 237| 6,085| 0.0] + org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service()
[ 3][18:25:09.557| 6,085| 96| 0| 3,080| 3,005| 0.0] + @GET com.opennaru.rest.UserRestService.getUser()
[ 4][18:25:10.634| 2,004| 32| 0| 1,003| 1,001| 0.0] + @TraceMethod com.opennaru.rest.Test.test()
[ 5][18:25:11.636| 1,001| 16| 0| 1,001| 0| 0.0] + @TraceMethod com.opennaru.rest.Test2.test()
[ 6][18:25:13.638| 1,001| 16| 0| 1,001| 0| 0.0] + @TraceMethod com.opennaru.rest.Test2.test()
CPU를 많이 사용하는 애플리케이션 분석 방법
처리가 끝난 애플리케이션에 대해서는 Transaction Heatmap(T-Map)의 항목중 CPU 사용량 항목을 통해 CPU 사용량을 확인할 수 있다.
현재 실행중인 애플리케이션 중에서 CPU 사용량이 많은 애플리케이션을 분석하려면, APM의 스레드 덤프 기능을 사용하면 된다.

404/JSP 컴파일 오류가 많이 발생할 때
- Transaction Heatmap(T-Map)에서 빨간색으로 표시된다.

- T-Map을 마우스로 드래그하면 해당 트랜잭션을 표시한다.
- Status로 정렬하면 404, 500 오류를 확인할 수 있다.

- JSP 컴파일 오류일 경우 오류 메시지를 표시한다.

Too many open files 오류가 발생할 때 분석 방법
Java 애플리케이션에서 파일을 많이 열어 문제가 발생하는 경우, WAS의 로그에는 ‘Too many open Files’ 오류가 발생한다. 이런 상황이면, JVM이 어떤 파일을 많이 열었는지를 확인하면 문제의 원인을 쉽게 확인할 수 있을 것이다.



TCP TIME_WAIT, FIN_WAIT가 많을 때 분석 방법
TCP 소켓이 갑자기 많아지면, System > IP_Address > 네트워크 상태 분석을 통해서 어떤 IP, Port를 많이 사용하는지 확인할 수 있다. WAS > Instances > 네트워크 상태 분석에서는 해당 WAS 인스턴스가 사용하는 네트워크 소켓 정보만 표시한다(Linux 계열 운영체제만 가능).

