스카우터에서는 성능 모니터링 중 생긴 특정 상황에 대해 얼럿 기능이 들어가 있다.
스카우터 클라이언트의 얼럿항목에서 확인 및 조회가 가능하다.
하지만 항상 보고 있을수는 없는 상황에서, 얼럿을 스카우터 외부에서 받기를 원한다면 어떻게 해야 할까.

스카우터의 커스텀 플러그인으로 해결이 가능하다.
이런 상황에 맞추어 사용자가 직접 플러그인을 개발해서 넣을수 있도록 내부 API를 가지고 있고, 
이를 활용할 수 있는 커스텀 플러그인 구조를 가지고 있다.

우선 스카우터의 플러그인에 대해 알아보도록 하겠다.



스카우터의 플러그인

스카우터의 서버 플러그인은 크게 2가지 종류이다.
스크립트 형식으로 된 스크립팅 플러그인과 java의 jar 파일 형식으로 된 빌트인 플러그인이다.

스크립팅 플러그인은 파일에 java 문법으로 이루어진 스크립트를 넣어서 적용할 수 있다.
빌트인 플러그인의 경우 jar 파일로 이루어진 자바 프로젝트이다.
정해진 형식에 맞게 프로젝트를 만들고 내부 로직은 자유롭게 개발해서 사용할 수 있다.

이번 글에서는 2가지 방식 중 빌트인 플러그인 방식에 대해서 알아보려고 한다.
2가지 방식의 스카우터 플러그인 외에 에이전트에 적용하는 플러그인도 있다. 더 자세한 정보는 아래 링크에서 확인 가능하다.

처음 접하는 입장에서 플러그인을 처음부터 만드는것은 쉽지 않다.
그래서 스카우터를 사용하는 능력자들께서 손수 만드신 플러그인들을 공유하고 있다.
https://github.com/scouter-project 이곳에서 scouter-plugin 으로 시작하는 프로젝트 들이다.

확인해보고 필요한 것이 있다면 학습해보는 것도 좋을것이다.



빌트인 플러그인 적용방법

  1. 플러그인 프로젝트를 jar 파일로 만든다(빌드 방법은 아래에서 다룬다.)
  2. ./server/lib 폴더 아래에 jar 파일을 넣어준다.
  3. 스카우터 수집기 서버를 재기동 한다. (./server.startup.sh)



얼럿 플러그인

얼럿을 외부로 보내기 위한 플러그인은 매체에 따라 구분된다. email, slack, line, telegram, teamup(?) 등이 있다.
매체가 다른 플러그인이지만, 대부분 로직은 비슷하고 발송 단계의 로직만 다르기 때문에 원하는 발송 매체가 있다면 커스터마이징도 가능하다.

이번 글에서는 다양한 발송 매체 중에 슬랙을 이용하는 플러그인을 가지고 설명하려고 한다.
해당 플러그인의 깃헙 주소는 아래와 같다.

이 얼럿 플러그인으로 받을수 있는 알림은 아래와 같다.
  • CPU of Agent (warning / fatal)
  • Memory of Agent (warning / fatal)
  • Disk of Agent (warning / fatal)
  • connected new Agent
  • disconnected Agent
  • reconnect Agent



얼럿 플러그인 적용하기


1.  플러그인 빌드

적용하기 위해서는 얼럿 플러그인 프로젝트의 jar 파일이 필요하다.
클론을 받고, jar 파일로 빌드하자(macos 기준..)
git clone https://github.com/scouter-project/scouter-plugin-server-alert-slack.git
cd scouter-plugin-server-alert-slack/
mvn package

문제없이 빌드가 완료되었다면,
target 디렉토리에 scouter-plugin-server-alert-slack-1.0.1-SNAPSHOT.jar 라는 파일이 생성되어 있을 것이다.
이 파일을 스카우터 수집기 서버 디렉토리 아래 lib 폴더에 복사한다. (스카우터를 설치한 디렉토리에서 ./server/lib 이다)


2. 플러그인 설정

스카우터 수집기 서버의 설정 파일을 수정해야 한다.
별도의 변경이 없다면 경로는 아래와 같다.
./server/conf/scouter.conf
얼럿 플러그인을 사용하기 위해 필요한 설정값은 아래와 같다.
내용을 참고해서 환경에 맞게 내용을 추가해 준다.

ext_plugin_slack_send_alert : 발송기능을 사용할지 여부. true/false
ext_plugin_slack_debug : 메시지를 로깅 할지 여부. true/false
ext_plugin_slack_level : 로깅 레벨. (0=info, 1=warn, 2=error, 3=fatal)
ext_plugin_slack_webhook_url : 슬랙 웹훅 url
ext_plugin_slack_channel : 채널명 (ex. #test1) 혹은 사용자명(ex. @user_id)
ext_plugin_slack_botName : 알림을 보낼 봇 이름
ext_plugin_slack_icon_emoji : 봇 아이콘
ext_plugin_slack_xlog_enabled : xlog 얼럿 활성화 여부 true/false
ext_plugin_elapsed_time_threshold : 응답시간의 임계치. 이 값 보다 큰 응답시간에 반응한다
ext_plugin_gc_time_threshold : gc 시간 임계치. 이 값보다 큰 gc 시간이 걸리면 반응한다
ext_plugin_thread_count_threshold : 쓰레드 갯수 임계치. 쓰레드 갯수가 임계치 보다 커지면 반응한다.

적용해 사용하고 있는 설정은 아래와 같다.
# External Interface (Slack)
ext_plugin_slack_send_alert=true
ext_plugin_slack_debug=true
ext_plugin_slack_level=0
ext_plugin_slack_webhook_url=http://mydonain.com/hooks/1234CCSReKgN23wiw/dtCGozaNPAA41234yiCnhnpcNQCA7BSrkjqmFmsy3nMuKk95
ext_plugin_slack_channel=#alert_channel
ext_plugin_slack_botName=scouter
ext_plugin_slack_icon_emoji=:computer:
ext_plugin_slack_icon_url=https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQnQFLCYQ-rg_iJFXBzazZjUqMXTHPmTQ-AVU_JymsxleUHI1Oe
ext_plugin_slack_xlog_enabled=true
ext_plugin_elapsed_time_threshold=3000
ext_plugin_gc_time_threshold=5000
ext_plugin_thread_count_threshold=300

3. 적용하기

서버를 재기동 하면 적용된다.
./server/startup.sh



플러그인 커스터마이징

얼럿 플러그인을 사용하면서, 기능상 변경이 필요한 상황이 종종 찾아왔다.

예를들어,
스카우터에서 모니터링 하고 있는 서비스 중, 일부 서비스의 요청은 기본 응답시간이 1분이 넘어갈 정도로 오래 걸리게 만들어져 있었다.
응답시간 임계치 보다 크다보니 이 요청이 호출 될 때마다 응답시간 초과로 얼럿이 오게 되었다.
스카우터 전체 응답시간 임계치를 늘리면 기존에 10ms 이내로 처리되는 요청들의 응답이 느려질 때 얼럿을 받지 못하게 되어서 문제가 되었다.

이런식으로 얼럿 조건이 특수한 상황에 맞게 설정 되어야 할 때, 소스를 직접 수정하여 해결 할 수 있다.

대부분의 로직은 SlackPlugin.java 에 있다.

이 클래스의 메소드는 아래와 같은 용도를 가진다.

  • alert : 얼럿 발송
  • object : 에이전트 연결/연결끊김/재연결 얼럿 처리
  • xlog : xlog 에 에러로 표시된 건에 대한 얼럿 처리
  • counter : gc 타임 임계치 값에 대한 얼럿 처리
나의 경우 xlog 에서 응답시간 임계 초과 때 오는 얼럿을 서비스 마다 따로 설정하고 싶었다.
xlog 메소드 쪽에  분기를 추가해서 처리했다. 로직을 만들 때 사용한 내용은 아래와 같다.

  • elapsedThreshold 변수에는 아까 설정한 ext_plugin_elapsed_time_threshold 값이 들어있다. 기본 3초이다.
  • XlogPack 객체로 이루어진 pack 변수에는 xlog의 각 요청을 정보가 들어있다.
  • pack 변수에는 http 요청에 대한 엔드포인트 URL 정보와  지연된 응답시간 정보가 있다.

기존 코드의 264라인 근처에 수정을 하였다.
아래는 특정 엔드포인트에 대해서만 지연 응답시간 기준을 60초로 설정하는  분기를 추가한 코드이다.
try {
      int elapsedThreshold = conf.getInt("ext_plugin_elapsed_time_threshold", 0);
      if (elapsedThreshold != 0 && pack.elapsed > elapsedThreshold) {
         String serviceName = TextRD.getString(DateUtil.yyyymmdd(pack.endTime), TextTypes.SERVICE, pack.service);
         if (
                 AgentManager.getAgentName(pack.objHash).equals("/192.168.123.111/endpoint1")
                 || AgentManager.getAgentName(pack.objHash).equals("/192.168.123.111/endpoint2")
               && pack.elapsed < 60000) {
           //얼럿을 보내지 않음.
         } else {
            AlertPack ap = new AlertPack();
            ap.level = AlertLevel.WARN;
            ap.objHash = pack.objHash;
            ap.title = "Elapsed time exceed a threshold.";
            ap.message = "[" + AgentManager.getAgentName(pack.objHash) + "] "
                  + pack.service + "(" + serviceName + ") "
                  + "elapsed time(" + pack.elapsed + " ms) exceed a threshold.";
            ap.time = System.currentTimeMillis();
            ap.objType = AgentManager.getAgent(pack.objHash).objType;
            alert(ap);
         }
      }

수정을 마치게 되면 위에 설명한 방식으로 빌드를 다시 하고,
스카우터 수집기 서버 lib 폴더에 jar 파일을 덮어쓴 뒤 재기동 하면 바로 적용이 된다.

스카우터에서는 플러그인 개발을 위해 내부 API를 잘 정리하여 공유하고 있다.

자신만의 로직이 필요한 상황이라면 내부 API 문서를 참고하여 기존의 플러그인에 수정을 해서 필요에 맞게 사용할 수 있다.

혹은 새로운 플러그인을 새로 만들 수 있을것이다. 결과가 좋다면 커뮤니티에 공유해서 좋은 피드백도 받을 수도 있지 않을까 한다. 


Posted by panpid

댓글을 달아 주세요

JAVA 기반 서비스에서 운영할수 있는 APM Tool 을 선정하는 과정에서 스카우터를 선택하고 구성을 마친 경험을 다루어 보려고 한다.


1부에서는 선정한 이유와 스카우터 구조, 수집하는 지표 등에 대한 설명을 다룬다.

설치방법이 궁금하다면 공식 GitHub를 참조하자. 친절하게 한글로 설명이 잘 되어있다.


APM Tool 에 대하여

APM은 Application Performance Management 라고 한다. 어플리케이션의 성능을 관리하고 통제하는 도구라고 할 수 있다.
APM Tool은 수많은 종류가 있고 각각의 특징들이 있다.  

이 중에서도 공통적으로 APM 을 사용하는 이유를 내 기준에서 정리해 보았다.
  • 각 서비스 구간 별로 성능을 기록해 병목을 파악하고 미리 대응할 수 있다.
  • 기록에 근거해 현재 서비스에서 수용 가능한 트래픽을 예상해 볼 수 있다.
  • 알람 등 을 이용해 장애상황에 빠르게 대응할 수 있다.
  • 자원 사용률, GC상태 등의 정보를 이용해 잘못된 설계, 메모리 누수 등을 사전에 탐지 할 수 있다.


스카우터를 선택한 이유

오픈소스



한국 기여자 & 한국어 커뮤니티

스카우터는 한국개발자들이 주축으로 개발되는 오픈소스이다. 덕분에 한국어 자료가 많아서 좀 더 쉽게 이해할 수 있다.
가끔 영어 자료도 있지만 읽다보면 한국인이 쓴 영어 느낌이라 쉽게 읽히기도 하는 뜻밖의 장점도..

커뮤니티도 나름 잘 되어있다. 페이스북 그룹의 경우는 스카우터 개발자들이 직접 답글을 달아주기도 한다!..


빠른 버전업

최근에는 버전 업이 자주 있는 편이다. 
버그패치나 기능개선의 내용도 있고, 다양한 종류의 서비스를 지원하기 위한 확장도 있다. 

릴리즈 노트를 통해 활발히 버전업 되고 있다는것을 확인할 수 있다.




스카우터의 구성

스카우터는 크게 3부분으로 나누어져 있다.

에이전트(agent)

HostAgent 와 JavaAgent 로 나뉜다.
  • HostAgent : 단독으로 실행되며 서버 OS 혹은 DB 등에서 자료를 모아 수집기에 전달한다.
  • JavaAgnet : 모니터링하기 원하는 Java 어플리케이션에 포함된 채로 기동이 된다. JVM 수준에서 확인할수 있는 지표들을 수집기로 보낸다.

수집기(Collector)

에이전트에서 받은 지표들을 모아서 저장한다. 대부분의 지표는 UDP 를 이용하여 전송되기 때문에 부담이 적은 편이다.
클라이언트에서 요청하면 수집한 데이터를 내려준다.


클라이언트

수집기를 통해 지표들을 받아서 그래프로 표현해준다. 
JAVA로 만들어진 윈도우와 리눅스, 맥OS 버전이 모두 갖추어져 있다. 
기존의 
특정 조건을 걸어서 얼럿 을 받을 수 있도록 해준다.



지표 소개

스카우터로 모니터링 할 수 있는 지표들을 정리했다.

스카우터를 도입하기 위해 고민할 때, 스카우터에서 어떤 데이터를 제공해주는지 궁금했었다. 
물론 클라이언트-수집기-에이전트 를 구성하고 살펴보면 알수 있지만, 검토 단계에서 구성을 하는게 부담이 된 경험이 있다.
검토단계에서 궁금하신 분들을 위해 기본적인 지표들을 기준으로 정리하였다.

각 지표들을 기준으로 특정 수치를 넘었을 때, 얼럿을 할 수 있도록 세팅이 가능하다. 
얼럿 설정에 대해서는 다음에 다루도록 하겠다.


JVM 가비지 콜렉션 횟수, 시간


JVM 에서 진행항 GC 횟수와 소모시간이다



JVM 힙메모리 사용율


JVM 에서 사용하고 있는 힙메모리 사용율 이다.



자바 프로세스의 CPU 사용율


JVM 프로세스에서 사용중인 CPU 자원 사용량이다.



API Call 기록(XLog)


스카우터에서는 XLog 라고 부른다.
Http 요청 부터 해당 요청의 응답까지를 한 단위로 묶어서 처리시간 별 그래프를 그려준다.
시스템 부하여부를 직관적으로 확인할 수 있고, 한 요청에 딸린 요청들의 응답시간을 추적할 수 있다.


OS 및 JAVA 에러 얼럿


스카우터는 JVM에러, 디스크 사용양, 메모리 사용량 등 다양한 상황에 대한 얼럿을 지원한다. 



TPS


WAS 등에서 측정된 Http 요청을 기반으로 한 초당 처리량이다.



SQL 처리 시간


요청 별로 SQL 처리 시간을 보여준다. 얼럿 조건을 통해 특정 시간 이상 지연이 되면 얼럿을 받을수도 있다.


OS - CPU


Host에서 사용중인 시스템 전체 CPU 사용율이다.



OS - Memory


Host에서 사용중인 시스템 전체 메모리 사용율이다.



OS - DISK Read/Write Byte


Host에서 측정한 디스크 전체의 Read(Write) 사용치이다.



OS - Network Traffic


Host에서 측정한 네트워크 트래픽이다.



OS - Socket Count by status


Host에서 측정한 소켓연결 현황이다. 상태별로 조회가 가능하다.






마치며..

스카우터에서는 지표를 다양하게 제공하고 있지만, 이를 제대로 이해하고 보지 않으면 활용성이 떨어질 수 있다. 
그래서 각 지표에 대한 학습과 그 지표를 제대로 보기위한 설정들이 필요하다. 
또한 얼럿 커스터마이징을 통해 다양한 상황들을 인지하면서 시스템을 장악하는데 도움을 얻을 수 있다.
2부에서는 이들에 대해 다루도록 하겠다.


Posted by panpid
TAG APM, Scouter

댓글을 달아 주세요

  1. 슈기양 2020.03.27 10:46  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 감사합니다
    올려주신 포스팅 잘 볼게요^.^

  2. 늘품아빠 2020.07.10 17:52 신고  댓글주소  수정/삭제  댓글쓰기

    TPS 산정 기준이 궁금합니다. 일단 들오온 요청은 모두 카운트 되는건지, 에러 없이 정상 처리된 트랜잭션만 카운트 하는건지 궁금합니다.