<시스템 Live Check 모니터링에 대한 조언을 구했더니, 미국에서 Bobby가 보내온 내용을 블로깅합니다>
우선 개요부터 말씀드리자면, 어플리케인션을 모니터링하는 방법은 여러가지가 있습니다.
1. 포트(port)를 모니터링하는 경우:
서버 기반의 어플리케이션들은 통신을 위해 포트(service port, a.k.a listen port, ...)를 열어놓습니다. 대표적으로 HTTP는 80번 포트를, Telnet은 23, FTP 서버는 21번을 이용합니다.
따라서 포트가 열려있지 않으면, 서버가 실행되지 않다고 봐도 무방합니다. 하지만, 서버 기반의 어플리케이션이 아닌 경우 (예를 들면, microsoft word)는 포트를 이용하지 않기 때문에 포트 체크를 통해서 어플리케이션의 활성화/정상동작 여부를 확인할 수 없습니다.
2. 어플리케이션을 모니터링하는 경우:
포트가 없는 어플리케이션은 대게 어플리케이션이 실행되었는지/아닌지를 체크하여 어플리케이션을 모니터링할 수 있는데요..
윈도우즈의 '작업 관리자'나 Mac의 Activity monitor (Application/Utilites/Activity monitor.app)을 실행하면 현재 동작 중인 어플리케이션을 확인할 수 있습니다. 이와 같은 방법으로 모니터링 소프트웨어가 어플리케이션이 실행 중인지를 체크할 수 있습니다.
3. 어플리케이션의 '동작 상태'를 모니터링하는 경우:
어플리케이션이 정상적으로 실행되었다 하더라도 (그리고, 서버 어플리케이션의 경우 포트가 정상적으로 열렸다 하더라도), 어플리케이션이 정상적으로 '동작'하는지를 보증할 수 없습니다.
예를 들면, 좀비 프로세스 (zombie process)의 경우가 그렇습니다. http://en.wikipedia.org/wiki/Zombie_process
혹은, 환경 설정의 오류로 어플리케이션이 정상적으로 동작하지 않기도 합니다. 예를 들면, live 시스템이 개발용 DB를 이용하는 경우..
이와 같은 경우는 00님께서 말씀하신 두 번째 방법- Live Check bit(1bit)외에 Heart beat count를 병기 - 으로 체크할 수 있습니다. (DB를 이용하는 어플리케이션에 한해서요..)
4. 리소스 모니터링
모든 상태가 정상이라 하더라도, 시스템의 메모리나 CPU, 하드 디스크 등의 리소스들이 고갈되어 장애가 나는 경우가 있습니다.
2번의 기법과 같은 메커니즘으로 시스템 리소스(보통 메모리, CPU, 하드 디스크)를 모니터해야 합니다. 시스템마다 설정이 다를 수 있겠지만, 보통 시스템 리소스 사용율이 60%를 넘으면 하드웨어를 업그레이드하거나 서버를 증설 (scale out)합니다. - 각각을 vertical/horizontal scaling이라 부릅니다.
5. 네트웍 연결 상태를 모니터링하는 경우:
보통의 시스템은 독자적인 어플리케이션으로 서비스 되는 것이 아니라, 여러 서버들의 협업으로 동작됩니다. 이를 multi-tier architecture라고 부르는데요.. 예를 들면,
(1) 사용자가 웹서버에게 로그인을 요청을 하면,
(2) 웹서버는 간단한 입력값 체크를 한 후에, backend 서버에게 실제 작업을 요청합니다.
(3) backend 서버는 DB에 사용자 정보를 확인한 후 결과값을 리턴합니다.
간혹, network configuration 문제나 networking 장애로 각 서버간의 통신이 안 되는 경우가 있습니다. 이와 같은 경우, remote 커넥션 체크를 해야 합니다. 예를 들면, 웹서버에서 backend server로 잘 접속되는지 체크, backend server에서 DB server로의 커넥션 체크...
1,2,4,5번의 경우는 많은 모니터링 도구들이 있습니다. 하지만, 3번의 경우는 직접 모니터링 어플리케이션을 작성하여 체크해야 합니다.
아래 말씀하신 2번 모니터링 방법의 경우, DB를 사용하지 않는 어플리케이션의 경우 사용할 수 없습니다.
이런 경우, (1) 로그 파일을 lookup한다 던가, (2) 서버 어플리케이션의 경우, 모의 리퀘스트 메시지를 보내어 의도한 응답이 오는지를 확인할 수 있습니다. 예를 들면, 로그인 어플리케이션이라 할 경우 ID/Password를 요청 메시지로 보내고, 응답값으로 상응하는 UserId, UserName 메시지
요즘 많은 모니터링 자동화 도구들이 나와 있습니다.
3번의 해당하는 모니터링 방식도, 단순한 체크라면, 자동화 도구 설정으로 해결 할 수 있습니다. 아래 참고 페이지를 한번 살펴봐 주세요..
Comparison of network monitoring systems - Wikipedia
http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
Monitoring Software ReviewProduct Comparisons 2014
http://monitoring-software-review.toptenreviews.com/
참고로, 저는 Zabbix ( http://www.zabbix.com/ ) 라는 서버를 사용하고 있습니다. 이유는 무료이기 때문이구요.. ^^;
저희도 아주 복잡한 모니터링을 하지 않는지라, 이정도의 기능 스펙으로도 충분히 서비스를 운영하는데 지장이 없습니다.
위에 설명 드린 내용은 아주 개론적인 내용이면 어플리케이션 모니터링에 대한 주요 이슈를 설명드렸습니다.
솔직히 파고들면 한도 끝도 없는 게 이쪽 분야인데요, 그러니까, 각각의 전문가들로 회사가 운영되는 것이겠지요.., 네트워크/시스템/서비스 운영팀과 상의하시면 더 많은 정보와 적합한 솔루션을 찾으실 수 있을 겁니다.
그럼, 오늘 하루도 좋은 일들 많이 만드시기 바랍니다.