모니터링 솔루션 개발 완료

모니터링 솔루션 개발이 완료가 되었다.
Multi-thread pattern을 사용하여 한번에 수백개의 쓰레드가 동시에 사용되어 데이터 수집 및 경고를 할 수 있는 시스템을 만들었다.
시스템쪽에서 바라보는 시스템 모니터링을 넘어서서, 웹 어플리케이션 개념에서 접근한 모니터링 솔루션이라 할 수 있겠다. 

1. 요구사항
(1) 수집할 모든 프로젝트의 정보를 한 번에 볼 수 있도록 한다.
웹 어플리케이션의 상태를 One Page Monitoring 이라 하는 상황판에서 볼 수 있도록 하는 것이다. 이것만 있으면, Restart, Warning, Error에 대해서 상황 파악이 가능하다

(2) 수집 정보
시스템, Apache, Tomcat, DB, 정보 이렇게 나눌 수 있다.
-- 시스템 정보는 아주 세부적이지는 않다. 예를 들어 cpu의 경우는 io나 nice 값은 보여주지 않는다. idle 값을 100에서 뺀 값으로 보여준다. 간단한 수치만 보여준다. 그래야 사용자들이 판단할 수 있었다.
 loadavg, cpu, io, network, 파일 정보등을 보여준다. 이 떄 모든 명령어는 /proc 데이터를 활용한다.
-- Tomcat
메모리, 쓰레드 정보, 톰캣내 부하 정보를 보여준다. 참조용이라 할 수 있겠다. Outofmemory 정보를 위한 것이다. 사실 JMX 를 통해서 보다 높은 수준의 메모리 쓰레드 정보를 볼 수 있지만, 장애 때를 제외하고는 특별히 수집해도 의미가 없다. 어차피 장애나 튜닝은 특별한 시점에 하기 떄문에 General하게 쓰일 모니터링 솔루션에서는 쓰이지 않을 것이다.
-- Apache 정보
Apche의 server-status 정보를 보고, 정보를 저장하도록 한다.
쓰레드 개수, 초당 요청량을 보면서 deadlock 이나 부하 측정이 가능하다. 하지만 역시 참조용..
-- DB
원했던 방향은 SQL Query가 얼마나 속도가 걸리는지 지금 어떤 SQL을 날리는지 보는 것이었으나, 부하 및 개발 시간이 있어서 간단하게 사용.
웹 서버가 리스타트해서 얼마나 많은 SQL query를 날렸는지 count와 시간만을 group by 해서 보여준다.


2. 동작
(1) 수집이 가능한 서버에 대해서 빠르고 정확하게 정보를 수집한다. RMI 기반인 JMX의 Event-Listener 개념을 사용했다. 부하를 최대한 쓰지 않는 구조이다. Connection은 한번만 그리고, 그 Connection은 오직 리스타트나 종료일 때만 끊어진다. 그리고, 데이터 수집 정보는 Policy에 따라서 알려주도록 한다.
모니터링 솔루션은 웹 서버에 몇분마다 이런 정보를 원한다라는 Policy(정책)을 알려주고 웹 서버는 그 정보를 모니터링 솔루션으로 그 정보를 보내주도록 한다.

(2) 동작여부를 확인한다.
L7 체크를 하고 있는 터라 이 부분은 시스템 담당자와 대화할 수 있는 먼가가 필요했다.
그리고, 톰캣은 현재 물리적인 서버에 cpu갯수만큼 띄워져 있다. cpu가 2개이면 2개의 톰캣 인스턴스가..
cpu가 8개이면 8개의 톰캣 인스터를 띄워서 잘 동작시키고 있어서 단순한 설정으로 할 수 없었기에 Customizing이 되도록 하였다.
그리고, 많은 서버, 약2000대 정보의 상태 모니터링을 체크를 할 수 있도록 개발되었다.

(3) 경고 시스템 개발
정보를 통해서 장애가 생기기전 약 5~10분 정도 그 예후를 판별할 수 있고, 사람이 장애라 확인할 때까지 15분정도 소요되는 것에 비해서 빠르게 알아낼 수 있음을 발견했고, 그 부분을 추가했다.
실제, 웹서버가 장애가 나기 전에 어떤 특정 값을 넘어서면, 경고를 알려줄 수 있도록 했다.
이 부분은 아차피, 톰캣, 시스템, DB 수집 정보를 기간으로 판단할 수 있다.

(4) Customized UI 및 One Page Monitoring
웹 개발자는 자신이 원하는 정보를 얻고 싶어하지 자신과 관계없는 프로젝트는 보지 않는다. 따라서 사용자가 미리 수집중인 웹 서버들을 선택해서 그 정보만 볼 수 있게 했다. 그 때 uptime 정보, Restart 여부 정보를 여러 세부 지표와 함께 보여줌으로서 본인위주의 UI를 넣도록 했다.
또한, 시스템 담당자및 관리자는 현재 서비스의 장애상황을 신속히 볼 수 있기 때문에 적절한 판단을 내릴 수 UI가 필요했다. 바로 한페이지 모니터링 UI이다. 한 화면에 모든 웹 서버들을 볼 수 있고, 상황을 표시해 주도록 되어 있다. 그 정보를 선택하면, 수집해 놓은 수집정보를 Refresh 없이 볼 수 있도록 처리했다.

3. 좀더 해야할 일
더 해야할 일은 가용성, 쓰루풋부분이었다.
가용성은 간단하게 말하면, 얼마나 서비스가 잘 response를 보내주었는지 백분율로 나타내준 것으로서, 어떤 서비스가 1월 1일부터 지금까지 한번도 장애가 안났으면 100%로 해서 성과로 보여줄 수 있도록 하는 것이다.
이 가용성을 근거로 서비스의 안정성을 수치로 나타낼 수 있는데, 이는 개발이 되어 있지만, UI로 만들지 않았다. 기존 개발자들이 힘들것 같다..

성능 부분으로는 java instrument를 이용하여 실시간 정보를 바탕으로 성능 저하 및 병목 부분을 발견하도록 하는 부분이었다. 이를 통해서 어느 코드나 어느 쿼리에서 병목인지 확인하고 보려고 했었다.
하지만, 시간상... 이 부분은 나중에 개발할 예정이다. 바빠서... 이유도 있지만.
그리고, JDk7 이 나오면, 훨씬 잘 디자인된 JVM Tool interface와 instrument로 개발이 용이해지기 때문이다.
사라질 api로 개발하는 것은 무리일 것이라 생각된다.


4. 서버
웹 서버 1대, DB 2대 이렇게 구성한 상태이다. DB는 replication 때문에 한 거구.
웹 서버는 부하를 테스트 해보고 싶었다. 현재 약 500대 돌리고 있는데, cpu 5%정도이다. 아직 한참 돌려도 된다. 멀티 쓰레드는 정말 활용할 만한 가치가 있었다..