아직 적용해 보지는 않았지만 앞으로 해놓을 것을 생각해서 미리 적어놓음.
내가 지금까지 해 왔던 것은 cront과 pid파일을 이용하여 했던 것인데 이런 툴을 이용해서 하는 방법도 괜찮은 것 같다. 그러나 이런 류의 프로그램의 문제는 항상 이 프로그램 자체가 문제가 있는 경우도 대처를 해야된다는 것이다.
이제 조만간에 서버도 준비를 해야되고 시스템도 구축해야되는데 할일이 넘 많네..ㅠ.ㅠ
역시 난 백수가 딱 맞는데 괜히 사서 고생을 하고 있나부다..ㅡ.ㅡ;;;
@취미로 일할 수 있게 돈 많은 여자 좀 소개시켜주삼...ㅡ.ㅡ;;;
@@wiki를 복사해서 그런지 제대로 안 나오네..
monit을 이용한 몽그렐 프로세스 모니터링 3
지난 두 편의 글에서 mongrel을 재시작하는 방법과 Kill -9 이라는 극약 처방에 대해 적었다.
더 노하우가 쌓이면 어떤 상황에서 mongrel 프로세스가 먹통이 되는지에 대해 다루기로 하고, 이 글의 마지막은 monit을 소개하는 것으로 마치려 한다.
무슨 이유에서건 mongrel 프로세스가 서비스를 할 수 없는 상황에 이르게 된다. 현재는 심증만 있고, 물증이 없는 상태라 완벽한 처방은 하지 못하고 있다. 아무튼 서비스를 하려면 이런 프로세스를 최대한 빨리 발견하고 정상화해야 한다. 즉, 주기적인 모니터링과 자동 복구가 필요한 상황이다. 이를 위한 최적의 툴이 바로 monit이다.
monit은 유닉스 시스템에서 프로세스, 파일, 디렉터리를 감시하고 관리하는 유틸리티이다. monit은 자동 관리 및 복구를 가능하게 하므로, 오류가 발생했을 때 시기 적절한 처방을 내릴 수 있다.
설치 과정은 다른 유닉스 프로그램과 크게 다르지 않기 때문에 생략하자. 그 다음 우리가 할 일은 monit에게 mongrel 프로세스를 감시할 수 있는 방법과 처방전을 미리 알려주는 것이 전부이다. 어렵지 않다.
적당한 위치에 monitrc 파일을 만들고(필자는 ~/.monitrc), 다음처럼 적어준다.
check process mongrel_0 with pidfile <SOME-DIR>/shared/log/mongrel.4000.pid
start program = "mongrel_rake.sh start_0"
stop program = "mongrel_rake.sh stop_0"
if totalmem is greater than 100.0 MB for 5 cycles then restart # eating up memory?
if cpu is greater than 50% for 2 cycles then alert # s an email to admin
if cpu is greater than 80% for 3 cycles then restart # hung process?
if loadavg(5min) greater than 10 for 8 cycles then restart # bad, bad, bad
if 3 restarts within 5 cycles then timeout # something is wrong, call the sys-admin
if failed port 4000 protocol http # check for response
with timeout 10 seconds
then restart
group mongrelmongrel.4000.pid라는 파일에는 4000번 포트를 이용하는 몽그렐 프로세스의 아이디가 저장된다. 그리고 자원을 너무 많이 사용하면 재시작해준다. 가장 중요한 부분은 맨 마지막에 4000번 포트를 감시하는 부분이다. 10초안에 접속이 되지 않는 경우 먹통이 된 것으로 판단하고 필요한 조치를 취한다. 여기서는 당연히 재시작이다. 재시작은 stop program과 start program을 하나씩 실행해주는 방법이다. 필자는 지난번에 소개한 우아한 재시작 프로그램을 따로 만들어두고, 이 스크립트를 실행하도록 하였다. 이 부분에 그냥 mongrel_rails를 실행하도록 두어도 된다.
이런 방법으로 클러스터링해둔 프로세스를 모두 감시하도록 monitrc 파일을 작성하면 된다. 반복되지만, 해결할 수 있는 방법은 찾지 못했다.
여기에 덧붙여 이런 내용을 monitrc에 추가한다.
set daemon 60
set logfile monit.log
set pidfile monit.pid
set statefile monit.state
set httpd port 9999
use address localhost
allow username:password60초마다 감시를 하고 필요한 정보(log, pid, state)를 파일로 남기도록 지정한다. 그리고 9999번 포트로 관리툴을 띄운다. 물론 HTTP 인증을 거치도록 설정해둔다.
이 관리툴도 유용한데, 현재 서비스가 잘 이뤄지고 있는지 한 눈에 파악할 수 있는 모니터링 툴이다. 여기서 Stop, Start등 monit 명령어를 수행할 수도 있다.
마지막으로 주의할 점은, 모니터링을 켜두고 몽그렐 클러스터를 재시작하는 경우이다. 재시작은 프로세스를 죽이도 다시 시작한다. 그런데 다시 시작하는 동작이 2번 일어날 수 있다. 물론, 두 번째 프로세스는 이미 포트가 바인드된 상태이므로 큰 문제 없이 실패하겠지만, 그래도 불필요하게 두번 시작하는 것을 막기 위해서라면, 재시작 전에 모니터링을 끄는 것도 방법이다.
monit -g mongrel unmonitor all
-g mongrel을 이용하면 mongrel 그룹으로 지정된 것에 한번에 명령을 내릴 수 있다. 물론, 재시작할 때 mongrel_rails 대신 monit을 이용해도 된다.
monit -g mongrel restart all
이 외에도 monit을 이용해 여러 가지를 감시할 수 있으므로(httpd, ftpd 등), 함께 사용해보면 좋겠다. 더 좋은 설정이 있으면 함께 공유해도 좋을 것 같다.
서비스에 monit을 적용한 이후에, 일단 서비스가 멈추는 일은 없어져서 발 뻗고 잘 수 있게 되었다. 가끔 관리툴에 접속해보면 uptime이 혼자만 짧은 프로세스들이 보이는데, 이 때마다 monit을 설치해두기를 잘했다는 생각이 든다. 이제는 여유롭게 진짜 처방전을 찾아봐야겠다. 뭘까?
관련 링크
Mongrel이 말을 듣지 않으면 Kill -9
Mongrel을 우아하게 재시작하는 법에서 이어서…
mongrel 프로세스를 종료하기 위해 보통 사용하는 명령은 다음과 같다
mongrel_rails stop [options]문제는 온갖 문제로 특정 프로세스가 TERM 시그널을 받고도 죽지 않는 경우이다. TERM 시그널을 보내고 한참을 기다리면 스스로 사라지기도 하지만, 대부분의 경우 그리 느긋하게 기다릴 수만은 없다. 방법은 kill -9를 하는 것이다. 다행인지 mongrel_rails에는 강제 종료 옵션이 있다.
mongrel_rails -f -w 5내가 사용하는 방법은 이렇다. TERM을 보내본다. pid 파일이 아직도 있으면(정상적으로 종료되지 않으면) 강제 종료한다.
def stop(i)
pid = "#{APP_HOME}/shared/log/mongrel.400#{i}.pid"
system "mongrel_rails stop -P #{pid} -c #{APP_HOME}/current"
if File.exists?(pid)
system "mongrel_rails stop -P #{pid} -c #{APP_HOME}/current -w 5 -f"
system "rm #{pid}"
end
end 갑자기 ”When Your Mongrel Misbehaves, Kill -9“이라는 명곡이 생각난다. 킬 대시 나인~~.
