전에 작성한 글 (http://www.popit.kr/scouter-open-source-apm/) 에서 약속한대로 오늘은 scouter 의 설정에 대해서 알아보자.

이 글을 읽는 분은 적어도 https://github.com/scouter-project/scouter 를 방문하고, 설치를 해 봤기를 바란다. (그렇지 않으면 무슨 말인지 하나도 못알아 들을테니까)

scouter 의 설정파일은 매우 많다. 그런데, 여러분들이 기본적인 기능만을 사용하려면 세개의 설정 파일을 사용하면 된다.

• scouter agent 설정파일 agent 설정 파일은 WAS 가 시작할 때 읽고 JVM 이 시작하게 된다.
• scouter host 설정파일 host 설정 파일은 장비당 1개의 설정하면 된다.
• scouter server 설정파일 server 설정 파일은 데이터를 수집하는 서버를 설정할 때 사용한다.

이 세상에는 여러 종류의 설정파일이 존재하는데, scouter에서는 properties 형태의 설정을 사용한다. 즉,

key=value

의 형식으로 지정하면 된다.

scouter server 설정하기

scouter server 는 scouter 설치위치/server/conf 에서 찾을 수 있다. 그런데, 서버는 별로 설정할게 없다.

1
2
3
4
5
6
7
8
# Agent Control and Service Port(Default : TCP 6100)
net_tcp_listen_port=6100
# UDP Receive Port(Default : 6100)
net_udp_listen_port=6100
# DB directory(Default : ./database)
db_dir=./database
# Log directory(Default : ./logs)
log_dir=./logs

이렇게 4개의 값만 설정해도 정상적으로 동작한다. (그런데 이 값들이 모두 기본 default 값이기 때문에 굳이 명시하지 않고 기본 값으로 사용해도 전혀 문제는 없다.)

scouter 는 에이전트에서 서버로 데이터를 전달할 때 udp 와 tcp port 를 사용한다. 그리고, 두개의 프로토콜은 방식이 다르기 때문에 같은 값으로 지정해도 전혀 문제는 없다. (여기서 6100 으로 지정한 값이다.)

그리고, 데이터를 저장하기 위한 db_dir 도 지정할 수 있는데, 이 디렉터리에는 scouter 를 창조하신 분이 직접 개발한 데이터 타입의 파일들이 저장되어 있다. 이 파일들은 최소한의 공간에 최대한의 데이터가 들어갈 수 있도록 설계 되었으며, 파일을 읽는 속도도 엄청나게 최적화 되어 있다(고 한다.)

마지막 설정은 로그 파일 위치다. (이 파일들은 별로 볼 일은 없다.)

만약 여러분들이 사용하는 수집서버의 디스크 사용량이 매우 높은 상황이라면, scouter 는 데이터를 하루정도밖에 보관하지 않는다. scouter 내에는 다음과 같은 설정이 있다.

1
mgr_purge_disk_usage_pct=80

만약 디스크 사용량이 80%를 넘으면 데이터를 오래된 것 부터 지운다. scouter 때문에 디스크가 full 나지 않도록 설정한 개발자의 배려가 보인다.

여기서 잠깐) 만약 여러가지 이유로 인해서 하나의 수집서버 장비에 여러개의 scouter 서버 인스턴스를 띄울때는 어떻게 해야할까 ? 여기에 명시된 4개의 설정값만 다르게 하는 설정파일이 있으면 전혀 문제 없이 별도의 수집서버를 띄울 수 있다. 그리고, 인스턴스 시작 스크립트인 startup.sh 을 복사하여 java 시작 옵션에 복제한 스크립트의 위치를 지정하면 된다.

1
java ... -Dscouter.config=./conf/server2.conf ...

scouter host 설정하기

서버의 리소스 현황을 모니터링하기 위한 scouter host 를 설정해보자. Scouter설치위치/agent.host/conf 디렉터리에 가보면 scouter.conf 파일을 확인할 수 있다.

host 설정 파일에는 다음과 같이 수집서버의 IP/UDP TCP Port 를 지정하면 기본설정은 끝난다. Server 설정에서 대부분 이야기한 부분이라 추가적인 설명은 필요 없으리라 생각한다.

1
2
3
net_collector_ip=127.0.0.1
net_collector_udp_port=6100
net_collector_tcp_port=6100

그런데, host 설정파일에는 추가적인 설정이 필요할 때도 있다.

다음의 추가 설정들을 보자.

1
2
3
4
5
6
7
8
9
disk_alert_enabled=true
disk_warning_pct=70
disk_fatal_pct=90
cpu_alert_enabled=true
cpu_warning_pct=70
cpu_fatal_pct=90
mem_alert_enabled=false
mem_warning_pct=80
mem_fatal_pct=90

이게 무슨 설정이냐고 ?

바로 알림 설정이다. scouter 는 각종 메신저나 메일등으로 알림을 보낼 수 있는데, disk, cpu, memory 사용량이 높아지면 알림을 보낸다. 만약 여러분들의 운영서버가 매일 CPU 사용량이 70 %가 넘으면 계속 알림을 받게 될 것이다. (알림을 받은 팀장님의 얼굴이 생각나지 않는가 ?) 팀장님의 갈굼을 피하기 위해서는 이 값을 사알짝 올려주는 것이 좋다. (만약 평소 20 % 정도 사용하는데 이 알림 값을 너무 크게 설정할 경우 장애상황에서 알림이 오히려 안올수도 있으니 상황에 맞게 설정하자)

scouter java agent 설정하기

scouter agent 의 기본 설정은 host 설정과 동일하다.

1
2
3
4
5
6
7
# Scouter Name(Default : tomcat1)
obj_name=api1
# Scouter Server IP Address (Default : 127.0.0.1)
net_collector_ip=127.0.0.1
# Scouter Server Port (Default : 6100)
net_collector_udp_port=6100
net_collector_tcp_port=6100

여기서 obj_name 은 scouter모니터링 화면상에서 확인할 수 있는 jvm agent 의 이름이다. 앞서 지정한 host 의 경우 이 이름을 지정하지 않는 것이 좋다. 지정하지 않으면 자동으로 장비의 호스트 이름을 따라가기 때문이다.

그러면 기본 설정만으로 scouter 를 잘 사용한다고 할 수 있을까 ? 그렇다면, 이 글을 쓰지도 않았다.

기본 설정으로 제공 되는 내용은 메모리 / active service / xlog(의 점과 쿼리 정보) 정도다. scouter를 100%, 200% 활용하기 위해서는 agent 에 추가적인 설정을 해야만 한다.

HTTP header 와 parameter 정보 프로파일링에 추가하기

1
2
profile_http_parameter_enabled=true
profile_http_header_enabled=true

scouter 는 http 로 전송되는 각종 값과 헤더 정보를 관리할 수 있다. 예전 버전의 제니퍼도 이런 기능을 제공하지 못했지만, scouter 는 이 기능을 제공함으로써 보다 많은 사용자의 요청이 어떻게 넘어왔는지 확인/분석할 수 있다.

응답속도 낮은 애들 무시하기 !!!

잘 만들어진 시스템은 xlog 상의 응답속도가 대부분 0.3 이하이다.

이런 응답을 보이는 요청의 성능을 분석해봤자 시간 + 수집서버 디스크 낭비만 된다. 그러면 어떻게 해야할까 ?

1
xlog_lower_bound_time_ms=300

이 옵션을 지정하면 300 ms(0.3초) 이하의 응답을 보이는 요청에 대한 프로파일링 정보를 남기지 않는다.

단!!!!! exception 이 발생했거나 오류가 발생한 요청은 300 ms 이하라도 프로파일링 정보를 남기도록 되어 있다.

메소드 프로파일링하기

1
2
hook_method_patterns=com.xxx.controller*.*,com.xxx.service*.*,com.xxx.dao*.*
hook_method_ignore_classes=com.xxx.dto*.*

이제 가장 끝판왕으로 왔다. 메소드 프로파일링이다. 이렇게 여러분들이 운영하는 시스템의 패키지에 맞게 설정을 해 놓으면 메소드 프로파일링이 가능해 진다.

단 !!!!! 이 설정은 변경후 바로 적용되지 않는다. 반드시 서버를 재시작해야만 적용되는 옵션이다.

이 프로파일링 옵션 적용하는 작업은 가장 시간이 많이 소요되고 어려운 작업이다. 프로그램을 직접 작성한 개발자를 옆에 앉혀 두고 설정하는 것을 권장한다.

자바 데몬 모니터링하기

scouter 는 자동으로 Tomcat 기반의 WAS 를 모니터링할 수 있도록 만들어져 있다. 그렇다면 다른 자바 기반의 서버들은 모니터링이 안될까? 대부분 가능하다. 게다가 여러분들이 만든 자바 프로세스까지도 모니터링이 된다.

“나는 잘 안되던데? 무슨 소리야?” 라고 하시는 분들은 그래도 scouter 로 설치 및 설정을 해 보려고 노력한 분들일 것이다 . 다음의 설정을 보자.

1
hook_service_patterns=scala.concurrent.forkjoin.ForkJoinTask.doExec

여러분들이 scala 의 akka 기반 프로그램을 개발했다면, 위와 같이 지정해 보기 바란다. 그러면 아무것도 나오지 않던 xlog에 점(바람개비)가 찍힐 것이다.

갑자기 scala 이야기를 해서 어이없어하는 분들도 있겠지만, 이와 같이hook_service_patterns 값에 패키지.클래스.메소드 이름을 할당하게 되면 데몬도 모니터링이 가능해진다.

무슨 말인지 이해를 못하는 분들을 위해서 다음과 같은 코드가 있다고 생각해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
package thread;
public class ThreadDaemon extends Thread {
   public void run() {
       try {
             while(true) {
                 scouterRun();
                 Thread.sleep(1000);
             }
       } catch(Exception e) {
             e.printStackTrace();;
       }
   }
   private void scouterRun() {
         System.out.println("Boneless chicken monitoring start !!! ");
   }
}

이러한 코드가 있으면, 쓰레드가 시작된 이후에 무슨 일이 벌어지는지 대부분 이해할 것이다. 이 경우에는 다음과 같이 설정하면 된다.

1
hook_service_patterns=thread.ThreadDaemon.scouterRun

즉, 어떤 요청이 들어오거나, 어떤 시간이 도래해서 쓰레드가 작업을 시작하는 시점을 위와 같이 설정하면 scouter 에서는 해당 메소드(여기서는 scouterRun)가 멈출때 까지 프로파일링을 하고, 메소드 수행이 끝나면 scouter 에 점을 찍는다.

지금까지 아주 간단하게 scouter모니터링을 위한 설정에 대해서 알아보았다. 만약 이 글에 대한 호응이 좋다면, 다음에는 스카우터의 하일라이트라고 할 수 있는 플러그인(plugin)에 대해서 알아볼까 한다.