HestiaCP에서 Apache2가 자주 충돌하나요? Monit 자동 모니터링 및 문제 해결 가이드(완벽한 설정 포함)

HestiaCP 환경에서 Apache2가 자주 충돌하거나 Monit 자동 재시작이 실패합니까? 이 문서에서는 Monit을 사용하여 Apache2를 모니터링할 때 흔히 발생하는 문제점을 피하는 실용적인 가이드를 제공합니다. PID 경로 불일치 및 권한 차단과 같은 일반적인 문제를 심층적으로 분석하고, 실제 운영 환경에서 사용할 수 있는 Monit 자동화 구성 파일을 제공합니다. 지금 바로 고가용성 서버 유지 관리 기술을 익히고 장애 발생 시 2단계 자동 복구를 구현하세요!

Monit을 사용하여 Apache2를 모니터링하면서 겪었던 문제점들

지난 금요일 밤, 서버에서 Monit 알림이 왔습니다.

나는 멍한 상태로 패널을 흘끗 보았는데, apache2 상태 열에 빨간색 타임아웃 표시가 있었다.

잠시 생각해 봤어요. 오늘 막 서버에 Monit 모니터링을 추가했는데, 온라인 튜토리얼에서 설정 방법을 복사해서 붙여넣기만 했거든요. 문제없겠죠?

다음날 아침, 또다시 시간 초과 오류가 발생했습니다. 세 번째 시도 후, 모니터는 결국 작동을 멈추고 패널에 "모니터링되지 않음"이라고 표시했습니다.

나...

솔직히 처음에는 심각하게 생각하지 않았습니다. Apache2 모니터링이라니? 인터넷에 템플릿 설정 파일이 넘쳐나는데, 그냥 복사해서 붙여넣기만 하면 되잖아요. 하지만 그 붙여넣기 과정이 정말 화가 났습니다.

HestiaCP의 기본 아키텍처와 Monit 포트 간의 충돌의 근본 원인

먼저 제가 그토록 애를 먹었던 설정값을 보여드리겠습니다. 그래야 여러분이 보셨던 버전과 정확히 같은지 확인할 수 있습니다.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

괜찮아 보이죠? 80번 포트를 확인하고, 오류가 발생하면 재시작합니다. 5번 재시작 후에도 오류가 계속 발생하면 타임아웃됩니다.

문제는 Apache2가 80번 포트에서 실행되고 있지 않다는 것입니다.

이것은 HestiaCP의 함정이며, 많은 사람들이 이 함정에 빠지는 근본적인 원인입니다. HestiaCP의 기본 아키텍처는 Nginx + Apache2의 리버스 프록시이며, Nginx는 프런트에서 80번 포트와 443번 포트를 사용하고, Apache2는 백에서 로컬 포트 ​​8081번으로 실행됩니다.

Monit에게 80번 포트에서 Apache2의 활성 상태를 확인하도록 요청하는 것은 마치 맥도날드에 가서 KFC를 찾는 것과 같습니다. 서버는 멍하니 당신을 바라보고, 당신과 서버는 서로를 응시합니다. 결국 Monit은 서버가 다운되었다고 판단하고는 정신없이 재시작을 시작합니다.

재시작 후에도 포트는 여전히 8081입니다. 그러면 Monit는 80번 포트를 탐색하려고 시도하지만 실패하고 다시 재시작합니다. 이 과정이 반복되다가 Monit가 복구 불가능하다고 판단하고 시간 초과됩니다.

처음에 이 문제를 접했을 때 정말 깜짝 놀랐습니다. 온라인에서 찾은 튜토리얼 열 개 중 아홉 개가 80번 포트를 사용했거든요. 그 튜토리얼을 그대로 따라 했다면 문제는 당신이 아니라 정보 출처 자체에 있었던 겁니다.

손상된 Apache2 PID 파일로 인해 Monit이 해당 프로세스를 존재하지 않는 것으로 잘못 식별했습니다.

포트를 80에서 8081로 변경하면 Monit이 이론적으로 이를 감지할 수 있어야 하지 않을까요?

하지만 실제로는 여전히 간혹 "실행 실패 "라는 메시지가 표시됩니다.

오랜 시간 애쓴 끝에 마침내 원인을 알아냈습니다. 바로 PID 파일이 손상되었던 것입니다.

생각해 보세요. Monit은 Apache2를 미친 듯이 재시작했는데, 매번 강제로 종료하고 다시 시작하는 과정을 여러 번 반복했습니다. 이 과정에서 /var/run/apache2/apache2.pid 파일의 크기가 0바이트가 될 수도 있습니다.

즉, 파일은 여전히 ​​존재하지만 내용은 비어 있다는 뜻입니다.

Monit이 이 파일을 읽으면 아무것도 찾지 못합니다. Apache2가 백그라운드에서 완벽하게 실행 중이더라도 Monit은 Apache2를 인식하지 못합니다. Monit은 해당 프로세스가 존재하지 않는다고 판단하는 것입니다.

이것을 봤을 때, 나는 잠시 말문이 막혔다.

이것은 교착 상태입니다. Monit이 Apache 2 인스턴스를 감지하지 못하고 Apache2를 재시작하지만, 재시작 과정에서 PID 파일이 손상되고, 다음 감지에도 실패한 후 다시 재시작됩니다. 이 과정이 타임아웃이 발생할 때까지 계속됩니다.

HestiaCP 환경에서 Apache2 모니터링 관련 문제 해결 및 복구 단계

솔직히 말해서 조사 과정 자체는 복잡하지 않지만, 어떤 방향으로 조사해야 할지 알아야 합니다.

첫 번째 단계는 Apache2가 수신 대기 중인 포트를 확인하는 것입니다. 터미널에 명령어를 입력하기만 하면 됩니다.

netstat -tulpn | grep apache2

또는 `ss` 명령어를 사용할 수도 있습니다. 효과는 동일합니다.

ss -tulpn | grep apache2

다음과 유사한 출력이 표시될 것입니다.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

80이 아니라 8081인 것으로 확인되었습니다. 그게 문제의 근본 원인입니다.

두 번째 단계는 손상된 PID 파일을 복구하는 것입니다. 이 단계는 더 간단합니다.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

먼저, 문제를 해결하는 동안 Monit 모니터링이 방해하지 않도록 일시 중지하십시오. 그런 다음 Apache2를 재시작하여 깨끗한 PID를 다시 기록하도록 하십시오. 마지막으로 `cat` 명령어를 사용하여 파일 내용을 확인하십시오. 빈 문자열이 아닌 숫자로 이루어진 문자열이 포함되어 있어야 합니다.

이 단계가 완료되면 문제는 기본적으로 해결됩니다.

Monit의 기존 적응형 및 공격형 보호 구성에 대한 비교 분석

Monit을 사용하여 Apache2를 구성하는 방법에 대한 온라인 튜토리얼은 일반적으로 두 가지 범주로 나뉩니다.

한 가지 유형은 "기존 적응형"으로, 복잡한 제약 조건을 많이 추가하지 않고 `service` 명령어를 사용하여 서비스를 관리하고 로컬 포트를 확인합니다. 이 구성은 포트만 변경하면 HestiaCP에서 사용할 수 있으며 비교적 안정적입니다.

또 다른 접근 방식은 systemctl을 사용하여 서비스를 관리하고, 자식 프로세스 제한을 추가하고, 더 엄격한 탐지 로직을 적용하는 "적극적인 보호" 방법입니다. 좋아 보이지만 치명적인 결함이 있습니다. 바로 사용하는 종료 명령이 `killall -9`라는 점입니다.

`killall -9`는 무슨 뜻인가요? 이는 장치가 현재 어떤 작업을 하고 있든 상관없이 강제로 장치를 종료하라는 뜻입니다. 이렇게 무차별적으로 종료하면 PID 파일이 손상될 수 있는데, 이것이 제가 방금 언급한 문제입니다.

제 개인적인 경험으로는 공격적인 환경에서 자식 프로세스 수를 제한하는 것이 실제로 유용합니다. Apache2가 CC 공격으로 과부하될 때 자식 프로세스 수를 제한하면 서버 메모리 부족 현상을 방지할 수 있습니다. 하지만 `killall -9` 방식은 사실상 실용성이 떨어집니다.

결국 저는 타협하여 두 가지 구성의 장점을 결합했습니다.

HestiaCP Apache2 모니터링 모범 사례 구성

/etc/monit/conf.d/apache2 파일을 다음 내용으로 수정하십시오.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

이 몇 줄의 설정에 담긴 논리를 간략하게 설명드리겠습니다.

HestiaCP의 리버스 프록시 아키텍처와 정확히 일치하도록 포트 8081을 사용하십시오. 더 이상 불필요하게 포트 80을 사용하지 마십시오.

PID 파일이 손상되지 않도록 하려면 `killall -9` 대신 `systemctl stop` 명령을 사용하여 PID 파일을 중지하십시오.

자식 프로세스 제한이 추가되었습니다. 자식 프로세스 수가 120개를 초과하면 CC 공격을 방지하기 위해 두 번의 연속 실행 후 프로세스가 다시 시작되지만, 과도하게 작동하는 것은 아닙니다.

오류 감지 로직이 "2주기" 방식을 사용하도록 수정되었습니다. 즉, 두 번 연속 오류가 발생한 후에만 재시작이 트리거되어 오탐이 줄어듭니다. 이전 구성은 한 번만 오류가 감지되어도 재시작되었는데, 이는 솔직히 지나치게 민감했습니다.

최종 타임아웃 임계값은 10주기 내 5회 재시작으로 완화되어 충분한 내결함성을 확보합니다.

헤스티아CP 모니터링 모니터링구성 문제 해결 요약 및 경험 공유

설정을 변경한 후 Apache2를 모니터링했더니 패널에 녹색 "OK" 표시등이 나타났습니다.

당시 제 심정을 어떻게 표현해야 할까요? 마치 이틀 동안 버그와 씨름했는데, 알고 보니 원인이 잘못된 설정 코드 한 줄 때문이었다는 걸 깨달은 기분이었습니다. 답답하기도 했지만, 어이가 없어서 웃음이 나오기도 했죠.

Monit 자체는 좋은 도구이며, 데몬 모니터링은 모든 서버에서 수행해야 하는 작업입니다. 하지만 문제는 많은 온라인 튜토리얼이 "Apache2는 80번 포트만 사용한다"는 가정에 기반하고 있다는 점입니다. HestiaCP는 리버스 프록시를 사용하므로 이 가정은 사실이 아닙니다.

지시사항을 제대로 따랐다면 문제는 당신이 아니라, 해당 튜토리얼이 당신의 상황과는 다른 시나리오에 적용되는 것일 뿐입니다.

HestiaCP를 사용하고 Monit으로 Apache2를 모니터링하는 경우, 다음 두 가지를 기억하세요. 포트를 8081로 변경하고, `killall -9`가 아닌 `systemctl` 명령어를 사용하여 프로세스를 종료해야 합니다. 이 두 가지를 준수하면 더 이상의 문제를 방지할 수 있을 것입니다.

여기까지 읽어주셔서 감사합니다. 도움이 되셨다면 좋아요와 공유 부탁드립니다. 최신 소식을 가장 먼저 받아보고 싶으시다면 팔로우도 해주세요!

제 글을 읽어주셔서 감사합니다. 다음에 또 뵙겠습니다.