이번 주제는 조금 길어질 듯하여 1, 2부로 나누었다.
1부에서는 Built-in Plugin의 개념과 개발하기 위한 필수 요구사항에 대해 분석하고,
2부에서는 실제로 빌트인 플러그인(.jar)을 제작해보도록 하겠다.

본 게시글을 이해하기 위해서는 Java Reflect의 개념에 대해 조금 알고 있어야 한다.

목차는 아래와 같다.
1. Plugin의 개념
  1-1. Scripting Plugin VS Built-in Plugin
2. Built-in Plugin 개발 요구사항
  2-1. 요구사항 요약
  2-2. 소스코드 분석
3. 결론

스카우터는 시스템 모니터링한 정보를 클라이언트에서 확인하는 방법을 제외하고도 다양한 방식으로 모니터링 데이터를 활용하도록 해준다.
예를 들면 Email 전송이나, 슬랙 알림등이 있는데, 이 때 사용되는 것이 Plugin이다.

Plugin은 Scripting Plugin과 Built-in Plugin으로 나뉜다.

1. Scripting Plugin은 Java를 이용하는 스크립트로, 전처리와 같은 단순한 작업을 지원한다. 
이는 코드 변경이 동적으로 이뤄져서 Server가 돌아가는 중에 수정을 해도 바로 변경사항이 적용된다. 
그러나 어디까지나 단순 작업용이므로 기능적 한계가 있다.
스크립트 플러그인 파일은 server 내부의 plugin 폴더에 위치한다.
플러그인의 이름은 아래와 같이 지어야 하며, 이름 변경을 할 수 없다.

내부는 자바 메서드로 이뤄져 있으며 아래와 같은 형식으로 작성하면 된다.

2. Built-in Plugin은 독립된 Java Project로 이메일 전송 등의 좀더 고차원의 많은 기능을 지원한다.
스크립트와 다르게 변경사항 등을 적용하려면 Server의 재 시작이 필요하다.
빌트인 플러그인 파일은 server 내부의 lib 폴더에 위치하며, 요구사항에 맞춰 생성된 jar파일이다.

본 게시글에서는 Built-in Plugin의 요구사항 부분에 집중하도록 하겠다.

무엇을 충족해야 하는지 결론만 알고 싶은 사람들을 위해 결론부터 적어보면 다음과 같다.

1. 스카우터의 스케쥴러에 올릴 메서드는 public 이어야 하며, 반드시 아래의 6개 Annotation중 하나는 가져야 한다.

2. 또한 메서드의 파라미터로는 Pack 인터페이스 또는 이를 구현한 하위 클래스 1개를 받아야 한다.

3. 위의 메서드가 담긴 클래스는 반드시 public class여야 한다.
4. 위의 public class는 반드시 scouter.plugin.server 패키지 하위에 있어야 한다.
  ex) scouter.plugin.server.mypackage.yolo (O)
        mypackage.yolo (X)
5. Dependency로 scouter.server와 scouter.common을 갖는다.
  (1) server plugin 이기 때문에 scouter.server가 필요하고
  (2) annotation 및 기타 유틸이 scouter.common 에 있기 때문이다.


이를 다 충족시킨 예시는 아래와 같다.

제일 먼저 Main 클래스를 보면 56번 라인에서 Built-in Plugin이 호출되는 것을 알 수 있다.

이를 따라서 BuiltInPluginManager로 가보면 아래와 같다.

위에서부터 차근차근 분석해보도록 하겠다.

먼저 18번 라인의 HashMap을 보면 key로 String을, value로는 List를 갖는 것을 알 수 있다.

이 HashMap은 스카우터 플러그인들을 모두 담아놓은 컬렉션으로, 각 어노테이션 별로 플러그인을 모아 관리한다. 다음과 같이 나타낼 수 있다.

(나중에 설명하겠지만 모든 플러그인을 불러온 뒤, key값을 가지고 각 플러그인들을 호출하여 실행시킨다.)


다음으로 21번 라인을 보면 scouter.plugin.server 패키지 내부의 모든 클래스를 뽑아서 Set에 담아놓은 것을 볼 수 있다. 이 때문에 반드시 scouter.plugin.server 패키지 하위에 코드를 작성해야 하는 것이다.

그 다음으로 Iteration을 하는 while 내부의 27 ~ 29번 라인을 보면, 추출한 class들 중에서 public class만 처리하는 것을 확인할 수 있다. 이러한 이유로 반드시 스케쥴러에서 불러올 클래스는 public class여야 한다.

그 다음 부분으로 넘어가서 메서드를 불러오는 31 ~ 46번 라인을 살펴보자
이 부분에서 왜 public 메서드여야 되는지, 지정된 annotation이 꼭 필요한지가 나온다.

마지막으로 62번 라인의 invokeAllPlugins()을 살펴보자.
이 메서드는 말 그대로 pluginPoint 종류에 해당하는 모든 플러그인들을 실행시키는 메서드이다.

이 invokeAllPlugins()는 스카우터가 실행되며 내부의 Scala에서 호출되는데, 너무 복잡하여 생략하도록 하겠다.
단지 요구사항을 모두 만족시키는 메서드에 한해서 invokeAllPlugins()에서 호출되어 실행된다는 것만 알면 된다.


정상 실행 결과를 보면 아래와 같이 로그가 찍힌다.

위의 소스코드 분석 과정을 통해 어떤 요구사항을 충족해야 하는지에 대해 알아보았다.

마지막으로 최종적으로 정리하면 아래의 요구사항을 충족해야 한다고 말할 수 있다.

여기까지 하여 스카우터의 Built-in Plugin의 필수 요구사항에 대해 알아보았다.
다음 챕터에선 이 조건을 가지고 어떻게 진짜로 빌트인 플러그인을 제작할 수 있는지에 대해 알아보도록 하겠다.