Scouter APM 개발환경 구성하기

Scouter 개발 환경을 구성해보자.

사전 준비 사항

먼저 Java 8, Maven 3, Git 이 설치되어 있어야 하며 GitHub 계정이 있어야 한다.
당연히 PC에 Eclipse (Neon)나 IntelliJ 같은 개발 도구도 설치되어 있어야 한다.

1. GitHub에서 Fork 하기

  • Scouter Github 저장소에서 내 저장소로 Fork 한다.
  • 개발환경을 구성하기 위해 좀 전에 Fork한 저장소를 내 PC로 Clone 한다.
    • 필자의 경우는
      •  git clone https://github.com/gunlee01/scouter.git

  • develop branch로 변경한다.
    • git checkout develop


2. Eclipse에 개발환경 구성하기

 여기서는 Eclipse Neon3를 기준으로 설명한다.
 현재 시점 최신버전인 Scouter 1.7.x 의 클라이언트 개발을 위해서는 Eclipse Neon이 필요하다.

(1) Eclipse Neon을 Java 8로 실행한다.

  • 기본 Java가 Java 8 JDK가 아닌경우에는 eclipse.ini에 vm 경로를 PC에 설치되어 있는 java 8 JDK로 설정한다.

(2) git clone 받은 위치의 scouter project 소스를 eclipse로 import 한다.

  • 우리는 이미 local PC에 소스를 받아놓은 상태이므로 "Existing Maven Project"로 import 받는다.


  • 정상적으로 import되면 자동으로 빌드가 수행되는데 scouter.server와 scouter.webapp이 빌드가 되지 않을 수 있다.
    • scouter.webapp은 Lombok이 필요하고 scouter.server는 scala IDE가 필요한데 Eclipse에 이 두가지가 기본으로 포함되어 있지 않기 때문에 빌드 에러가 발생하게 되며 추가적인 설치가 필요하다. 추가 설치는 아래를 참고해서 진행한다.

(3) Lombok이 설치되어 있지 않다면, lombok을 다운로드 받고 설치한다.

  • https://projectlombok.org/downloads/lombok.jar
  • 위 경로에서 다운로드 받은 후 lombok.jar를 실행하면 설치된 IDE를 자동으로 찾아서 설치해 준다. 지시에 따라 설치한 후 eclipse를 재실행 한다.
    • java -jar lombok.jar
  • Eclipse가 재실행되면 scouter.webapp 이 정상적으로 빌드가 되는 것을 확인할 수 있다.
    • 필요한 경우 clean build를 수행한다.

(4) Scala IDE가 설치되어 있지 않다면, 아래 내용을 참고하여 이를 설치한다.

    • Scala IDE 압축파일을 다운로드 받는다.
    • 다운로드 받은 파일의 압축을 푼다. 그리고 Eclipse에서 "Install New Software" 메뉴를 통해 local 경로에서 설치한다.

    • 설치가 완료된 후 Eclipse를 재실행한다.
    • build path를 확인하고, 만약 source 디렉토리에 /src/main/scala 가 포함되지 않았다면, 이를 포함시킨다.

    • scouter.server 프로젝트에 scala nature가 포함되지 않았다면, 이를 프로젝트에 포함시킨다.

    • 필요한 경우 clean build를 실행한다.
    • 이로써 Eclipse에 scouter 개발환경 구성이 완료되었다.
      • scouter client 개발환경 구성은 조금 다른 부분이 있으므로 IntelliJ 개발환경 구성을 설명한 이후에 다시 설명한다.

(5) Scouter Server를 Eclipse IDE 에서 실행해 보기

  • scouter.server.Main 을 java application으로 실행하면 된다.

  • 단 실행시 log 및 database등의 디렉토리와 파일들이 생성되므로 working directory를 소스 경로가 아닌 다른 곳으로 적당히 잡아주는 것이 좋다. 
  • 실행화면



3. IntelliJ에 개발환경 구성하기

IntelliJ 는 scala 관련한 추가 설정이 거의 필요 없어 Eclipse에 비해 개발환경 구성이 좀 더 용이하다.

(1) IntelliJ 설치시 scala 를 설치하지 않았다면 plugin을 검색해서 추가로 설치한다.


(2) scouter project를 import 한다.

  • import는 maven model을 사용한다.
  • import시에 import maven project automatically 및 create module group 옵션을 체크하는게 좀 더 편하게 사용할 수 있다.

(3) lombok plugin을 설치하지 않았다면 설치하고 이를 활성화 한다.

  • plugin > lombok을 검색해서 설치한다.

  • lombok plugin 설치후 intellj를 재실행하고 settings > annotation processors 메뉴에서 annotation processing을 활성화 한다

  • 이로써 IntellJ에 개발환경 구성이 완료되었다.

(4) Scouter Server IntelliJ에서 실행해보기

  • scouter.server.Main 을 실행하면 된다.
  • 단 scouter server 실행시 data file 및 log file 등이 생성되므로 소스 위치와 관련 없는 위치로 working directory를 설정하여 실행하는 것이 좋다.


  • 아래 그림은 scouter server가 실행 된 화면이다.


3. Scouter Client 개발 환경 구성

scouter client는 eclipse RCP로 개발되어 있으므로 당연히 eclipse에 개발환경을 구성하여야 한다. IntelliJ에 빌드가 가능한 환경을 만들 수는 있으나 debugging 및 ide에서 바로 실행등이 지원되지 않으므로 최소한 코딩은 intellij 에서 하더라도 실행과 debugging은 eclipse에서 하여야 한다.

(1) project import

  • scouter.client.build 가 parent project 이므로 이를 existing maven project로 import 한다.
  • import 도중에 maven tycho plugin을 설치할 것인지를 묻는데 client 패키징을 위해 필요하므로 설치한다.

(2) scouter.common 을 mvn packaging

  • scouter.client 프로젝트에 compile error가 발생하였을텐데 이는 zest plugin 과  scouter.common.jar 가 없기 때문이다.
    (현재 scouter.client는 scouter.common은 local library로 직접 참조하게 되어있다.)
  • scouter.common 프로젝트를 mvn package 하면 빌드한 jar 파일을 scouter.client의 lib 디렉토리로 복사하도록 되어 있으므로 scouter.common을 mvn package 하여 빌드한다.
  • scouter.client 프로젝트의 build path에 lib/scouter.common.jar 에 대한 참조가 없다면 이를 추가해 준다.
  • zest plugin을 설치한다.

  • Eclipse를 재기동 한 후 scouter.client를 refresh 하면 정상적으로 빌드되는 것을 확인할 수 있다.

(3) scouter client를 IDE에서 실행하기

scouter.client.product에서 synchronize를 한번 한 후에 launch 버튼을 통해 실행한다.



끝!

댓글

댓글 쓰기

이 블로그의 인기 게시물

Scouter APM 소소한 시리즈 #1 - 설치하기

이미지
Scouter is an APM optimized for developers. Scouter가 " 개발자를 위한 APM "이라는 목적에 맞게 자유도가 높은 반면, 자잘하게 숨겨진 기능이 많은 APM인지라 이 시리즈를 통해 Scouter의 기능을 하나 하나 알아보도록 하겠습니다. 첫번째 내용은 설치하기 입니다. * Scouter 설치 전 반드시 기억해야할 사항 Scouter는 Agent와 Collector Server 그리고 User용 Client 프로그램으로 구성되며, 이들간의 관계를 잘 아는 것이 중요합니다. 각 서버에 설치된 Scouter의 Agent들이 성능 데이터를 Collector로 전송한다. 사용자는 Client 프로그램을 통해 성능 데이터를 본다. Agent  ⇨⇨⇨   [성능 데이터]  ⇨⇨⇨  Collector (Server) Client  ⇦⇦⇦   [성능 데이터]  ⇦⇦⇦  Collector (Server) * Scouter를 처음 사용하신다면 먼저 아래 동영상을 통해 개략적인 모습을 보시기 바랍니다.   -  Scouter APM Overview Scouter 설치 1. Scouter 다운로드 Scouter 릴리즈 페이지에서 최신버전을 다운로드합니다. Scouter Release Page scouter-all-[version].tar.gz Scouter Collector와 Agent를 포함하는 압축파일입니다. scouter.client.product-[os].tar.gz 각 OS별 Client(Viewer) 프로그램입니다. 2. Scouter Server 설치 및 기동 적절한 위치에 scouter-all-[version].tar.gz 의 압축을 풀어줍니다. Scouter Server를 실행합니다. startup.sh 또는 startup.bat 실행 netstat -an | grep 6100 을 해
자세한 내용 보기

Scouter APM 소소한 시리즈 #4 - XLog 활용 - 상세기능

이미지
Scouter is an APM optimized for developers. XLog 활용 Scouter 개발시 가장 중점을 두었던 것 중 하나가 " XLog 차트 안에서 모든 문제를 다 해결할 수 있도록 하자 " 였습니다. 그래서 XLog 차트는 상당히 많은 기능을 가지고 있으며 그중 중요한 기능들에 대해 설명하도록 하겠습니다. 1. XLog의 조작 (1) 키보드를 통한 간편 이동 실시간 XLog 차트에서 키보드를 사용하여 XLog 차트의 시간을 이동시킬수 있습니다. 이를 통해 가까운 과거 시점으로 빠르게 이동이 가능합니다. (큰 시간을 이동하여야 하면 Load History 메뉴를 사용하여야 합니다.) 좌우 화살표 : 한번 누르는 경우 10초를 이동합니다. 상하 화살표 : 한번 누르는 경우 일정한 비율로 Y축의 스케일을 조절합니다. (2) Y축 항목 변경 <그림. XLog Y축 항목 변경> Y축 항목을 응답시간(ElapsedTime)이 아닌 다른 값으로 변경할 수 있습니다. 현재 서비스가 CPU bound인지 혹은 SQL이나 Api call bound인지를 한눈에 파악할때 주로 사용하게 됩니다. 혹은 SQL 호출 회수가 많은 서비스를 골라내거나, 메모리 사용량이 많은 서비스를 골라낼때 사용하기도 합니다. (3) Load History 과거 특정 시점의 XLog 차트를 로드하기 위해 사용합니다. (4) Summary <그림. XLog 통계> 화면에 표현된 XLog 점들에 대한 통계를 바로 확인할 수 있는 기능입니다. 예를 들면 각 서비스에 대한 총 호출 건수 및 총 응답시간, 평균 응답시간, SQL 및 API 호출에 대한 평균 응답시간 등을 확인할 수 있습니다. (5) Filter XLog를 통한 분석시 가장 많이 사용되는 기능중의 하나입니다. 원하는 조건의 XLog 점들만 보여지도록 하는 기
자세한 내용 보기

Java의 동시성 개선을 위한 Project Loom은 reactive streams를 대체할 것인가?

이미지
Project Loom 최신 빌드 얼리 액세스 빌드 제공 ( 2020년 8월 17일) Build 16-loom+105   자바의 동시성 처리 개선을 위해 Ron Pressler의 제안으로 2017년 시작된 Project Loom이 얼마 전 더욱 완성도 높은 형태의 얼리 액세스 빌드로 제공되었다. 개인적으로 관심이 많은 프로젝트이기도 했고 릴리즈가 되면 현재의 비동기 개발 방식에 많은 영향을 미칠 것으로 보이는지라, 올해 개발 세미나 등에서 ( 이전 글- 나는 왜 Reactive streams와 친해지지 않는가? 와 잘 버무려서 )   관련 내용을 다뤄볼까 하는 생각이 있었지만 이놈의 C19 이슈로 거의 모든 개발 세미나가 온라인으로 진행되고 있어 그냥 블로그 글로 남겨본다. 최근 자바 서버 개발에 큰 흐름 중 하나로 등장한 reactive streams라는 어그로(?) 끄는 제목과는 달리 비동기 프로그래밍과 Project Loom 에 대한 글이다. ^^; (물론 여기엔 reactive streams 도 포함된다.) Project Loom 의 동기 Project Loom 제안 Project Loom: Fibers and Continuations for the Java Virtual Machine Project Loom의 동기 자원 사용면에서 효율적이지 못한 스레드 작성하고 디버깅 하기 어려운 비동기 개발 방식 경량 스레드(파이버)를 통한 블로킹 방식의 개발로 이를 해결하기 위함 먼저 Project Loom의 제안  내용 중 프로젝트의 동기 부분만 간단히 살펴 보도록 하자 하나의 서버에서 수백만 개의 소켓을 다룰 수 있지만 OS 스레드를 직접적으로 사용하는 자바에서는 동시에 수천 개 이상의 요청을 효율적으로 다루기 어렵다. 이를 극복하기 위해 최근 수년 간 많은 비동기 라이브러리들이 탄생하였는데 이는 작성하고 이해하고 디버깅하기 편해서가 아니라 단지 자바의 스레드가 성능면에서 효율적이지 못하기 때문 이다. Loom의 목표는 수백만 개를 생성할 수 있는 파이버라고
자세한 내용 보기