글

라벨이 Scouter APM 소소한 시리즈인 게시물 표시

Scouter APM 소소한 시리즈 #5 - 사용자 정의 알림

이미지
Scouter is an APM optimized for developers. 사용자 정의 알림 설정하기  제가 Scouter에 대해 강조하는 것 중 하나가 "scouter는 개발자가 가장 잘 활용 할 수 있는 APM이다" 인데요, 그 이유가 압축 해제만으로 설치가 끝나고 소규모 장비의 일부 자원으로도 잘 돌아간다는 점도 있지만 가장 중요하게 생각하는 부분은 바로 개발자에게 주어진 자유도입니다. 특히 스크립트 방식의 플러그인을 통하면 개발자가 원하는 정보를 소스의 수정없이 scouter의 프로파일이나 xlog에 남길 수 있는데요, 이번 장에서는 이와 유사한 방식으로 스크립트를 통해 자유도 높은 알림 설정할 수 있는 기능을 소개하고자 합니다. (스크립트 방식의 플러그인 활용에 대해서는 다음에 다른 지면을 통해 다뤄보도록 하겠습니다.) 1. 알림 플러그인 설치 Scouter의 알림은 클라이언트 화면에서도 볼 수 있지만 플러그인을 설치하여 이메일이나 메신저로 확인하는 것이 좋습니다. Scouter는 email, slack, line 메신저등의 확장 플러그인을 가지고 있으며 scouter-project의 github 페이지에서 확인할 수 있습니다. 확장 플러그인 설치는 아래 순서로 진행합니다. 플러그인 릴리즈 제공하는 파일들을 모두 다운로드 받는다. 예를 들어 slack 플러그인을 설치하려면 scouter-server-plugin-alert-slack의 릴리즈 페이지에 있는 파일을 모두 다운로드 받는다.  https://github.com/scouter-project/scouter-plugin-server-alert-slack/releases/tag/v1.0.0 scouter collector server가 설치된 디렉토리 아래의 lib 디렉토리로 받은 파일들을 모두 복사한다. scouter collector를 재기동 한다. 설치된 plugin이 제대로 적용되는지는 collector 시작시 남는 로그를
댓글 6개
자세한 내용 보기

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 점들만 보여지도록 하는 기
댓글 6개
자세한 내용 보기

Scouter APM 소소한 시리즈 #3 - Active Service와 XLog

이미지
Scouter is an APM optimized for developers. APM이 다른 모니터링 도구와의 차이점 중 하나는 발생한 문제의 결과가 아닌 원인에 접근할 수 있다는 것입니다. 이를 위해 Scouter에서는 어플리케이션이 지금 어떤 코드를 실행하고 어디서 지연되고 있는지를 파악할 수 있는 "Active Server 모니터링"과 이미 응답한 요청에 대해 상세 분석할 수 있는 Scatter 형식의 차트인 "XLog"를 제공합니다. 1. Active Service 모니터링 "Active service"란 현재 시점에 어플리케이션에서 수행되고 있는 요청을 나타냅니다. 이에 대한 모니터링은 주로 "Active Service EQ" 차트로 하게되는데, 서비스 지연으로 인한 장애를 가장 먼저 발견할 수 있는 차트이기도 합니다. <그림. Active Service EQ> 위 그림은 다섯개의 인스턴스를 모니터링하고 있으며 숫자는 현재 동시에 실행중인 서비스의 개수를 의미합니다. 지연되는 서비스는 3초 이후에는 노란색, 7초 이후에는 빨간색으로 표시가 됩니다. 여기서 실행중인 서비스의 정보를 알고 싶다면 상세히 보고싶은 인스턴스를 더블클릭하면 "Active Service List" 화면이 열리게 됩니다. <그림. Active Service List> 여기서는 호출된 서비스명과 현재까지 수행중인 시간(ms), 요청자 IP, 쿼리나 다른 서비스를 호출하고 대기중이라면 해당 쿼리나 서비스의 이름, Thread의 상태와 이름등이 보여집니다.  Service - 요청한 서비스의 이름 Elapsed - 현재 시점까지 수행중인 시간 Note - 현재 수행중인 쿼리 혹은 원격 호출하고 대기중인 다른 서비스 CPU - Thread가 생성된 후 현재까지 사용한 CPU IP - 요청자 IP State /
댓글 1개
자세한 내용 보기

Scouter APM 소소한 시리즈 #3 - 기본 항목 모니터링(2/2)

이미지
Scouter is an APM optimized for developers. Scouter의 차트의 기본적인 조작방법과 Perspective 관리에 대해 알아보도록 하겠습니다. 1. 차트의 종류 Scouter의 performance counter는 8가지 종류의 차트를 제공하며, 처음에 열리는 차트는 실시간 성능 정보를 제공해주는 "Realtime-Current" 차트입니다. Real Time 차트 : 현재 시점까지의 데이터를 보여주며 실시간 갱신되는 차트 Current  : 최근 5분 간의 데이터를 2초 간격으로 갱신(Default) All : (각 인스턴스별 값을 보여줍니다.) Total : (모든 인스턴스 값의 합계를 보여줍니다.) Today  : 오늘의 0시 부터 현재 까지의 데이터를 보여줍니다. All :  (각 인스턴스별 값을 보여줍니다.)   Total :  (모든 인스턴스 값의 합계를 보여줍니다.) History 차트 : 과거 특정 시점의 데이터를 조회합니다. Daily  : 과거 특정 시점의 1일~수개월 데이터를 5분 통계 로 보여줍니다. All :  (각 인스턴스별 값을 보여줍니다.) Total :  (모든 인스턴스 값의 합계를 보여줍니다.) Past  : 과거 특정 시점의 5분~4시간 의 데이터를 2초 정밀도 로 보여줍니다. All :  (각 인스턴스별 값을 보여줍니다.) Total :  (모든 인스턴스 값의 합계를 보여줍니다.) <그림. Real Time Current> <그림. Real Time Total> <그림. Today Total> "Today Total" 차트에서 어제 데이터는 회색으로 표시됩니다. <그림. Past All> <그림. Daily All> 2. 차트 다루기 2.1 Performance Co
댓글 7개
자세한 내용 보기

Scouter APM 소소한 시리즈 #2 - 기본 항목 모니터링(1/2)

이미지
Scouter is an APM optimized for developers. Scouter APM 소소한 시리즈 2번째 글입니다. 이번 글에서는 Scouter를 이용한 기본적인 모니터링 방법에 대해 알아보도록 하겠습니다. 뭔가 Tip 위주의 연재를 진행하려고 했는데, "설치쪽은 좀 자세히 써야겠다..." 라고 생각하며 쓰다가 거의 매뉴얼 스타일로 글이 진행되는 것 같습니다. 이렇게 된 이상 그냥 이대로 쭉~ 진행하고, 향후에  "진정 소소한 시리즈" 를 다시 연재하던지 아니면 유용한 Tip들을 여기에 어떻게든 잘 녹여보던지 해야 할 것 같습니다. 1. "Performance Counter"와 "Object Request" Scouter에는 모니터링 항목을 크게 두가지로 구분합니다. "Performance Counter", 그리고 "Object Request" 입니다. "Performance Counter"는 시간에 따라 변하는 값을 실시간 차트 형태로 보여주며, "Object Request"는 사용자가 특정 성능 정보를 요청하여 조회하는 기능입니다. 그리고 보통 "Performance Counte"r에 포함하기도 하지만, 그 성격이 전혀 다른 특수한 몇가지 기능이 있습니다. (XLog, Active Service EQ 등) 이러한 기능은 조금 복잡한 부분이 있으므로 다른 포스트에서 다루도록 하겠으며 여기서는 기본적인 모니터링 항목에 대해서 설명하도록 하겠습니다. 이러한 기능들은 상단메뉴에서도 접근이 가능하지만 "Object View"에서 콘텍스트 메뉴에서 접근하는 것이 더 직관적입니다. 1.1 Performance Counter Performance Counter는 시계열 성능메트릭을 의미합니다. Counter View를 Col
댓글 7개
자세한 내용 보기

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 을 해
댓글 25개
자세한 내용 보기

이 블로그의 인기 게시물

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의 목표는 수백만 개를 생성할 수 있는 파이버라고
자세한 내용 보기