Monit 모니터링 구성과 PHP-FPM 간의 불일치로 인해 발생하는 "해당 파일 또는 디렉터리가 없습니다" 오류를 해결합니다.

소켓 경로로 인해 발생한 유혈 사태

이야기는 다음과 같습니다.

제 친구네 서버가 지난달에 또 다운됐어요.

그는 내게 와서 monit가 php-fpm 소켓 파일을 찾을 수 없다는 오류를 계속 보고하고, 그 후 서비스가 빈번하게 재시작되고 부하가 급증한다고 말했습니다. 새벽 3시에 그는 서버 문제를 해결해 달라는 긴급 호출을 받았습니다.

당황하지 말고 모니터링 로그를 보여달라고 했잖아요.

자세히 보니, 와, 이런 종류의 오류로 가득 차 있더군요.

오류: Unix 소켓 /run/php/php8.4-fpm.sock 연결 오류 — 해당 파일 또는 디렉터리가 없습니다. 오류: 'php8.4-fpm' fai/run/php/php8.4-fpm.sock에서 led 프로토콜 테스트 [DEFAULT] 오류 발생 — /run/php/php8.4-fpm.sock에 대한 유닉스 소켓을 생성할 수 없습니다.

나는 그에게 "소켓 파일이 지금 어디에 있나요?"라고 물었다.

그는 모른다고 해서 기본 설정으로 설치했어요.

기다리라고 했잖아요, 제가 확인해 볼게요.

그런 다음 SSH로 접속해서 그의 실제 소켓 파일 이름이 무엇인지 확인해 봤습니다... /run/php/php8.4-fpm-etufo.org.sock.

내가 말했지, "친구, 네 소켓 경로는 완전히 다른 두 가지야. 둘이 통신할 수 있다면 기적일 거야."

오늘은 이 문제를 자세히 분석하고 해결책도 제시해 드리겠습니다.

당신은 감시가 당신을 보호해준다고 생각하지만, 실제로는 당신에게 해를 끼치고 있습니다.

먼저 monit 로그에서 가장 흔하게 나타나는 오류 유형에 대해 이야기해 보겠습니다.

이것을 보면:

오류: Unix 소켓 /run/php/php8.4-fpm.sock 연결 오류 — 해당 파일 또는 디렉터리가 없습니다.

이는 monit가 이 소켓을 통해 php-fpm 서비스를 감지하려고 시도하지만 파일을 찾을 수 없음을 나타냅니다.

그다음에는 monit가 서비스를 재시작하려고 시도하고 로그에는 다음과 같은 내용이 표시됩니다.

정보: 'php8.4-fpm' 재시작 시도 중 정보: 'php8.4-fpm' 중지: '/usr/sbin/service php8.4-fpm stop' 정보: 'php8.4-fpm' 시작: '/usr/sbin/service php8.4-fpm start'

꽤 똑똑해 보이죠? 자동으로 수리도 되잖아요.

하지만 진짜 문제는 이렇게 자주 재시작되는 것이 바로 재앙이라는 점입니다.

다음과 같은 상황을 상상해 보세요. php-fpm이 재시작될 때, 현재 처리 중인 모든 요청이 중단되고, 모든 세션이 손실될 수 있으며, 모든 연결을 다시 설정해야 합니다. 만약 php-fpm이 짧은 시간 내에 반복적으로 재시작되고 실패한다면, 서버 부하가 순식간에 급증할 것입니다.

로그에는 다음과 같은 추가 정보도 나와 있습니다.

오류: 'etUFO.org' 로드 평균(15분) 8.8이 리소스 제한과 일치합니다[로드 평균(15분) > 8.0] 오류: 'etUFO.org 도메인의 CPU 시스템 사용률 33.9%가 리소스 제한(CPU 시스템 사용률 > 30.0%)을 충족합니다.

서버는 이미 과부하 상태였는데도 모니터링 시스템은 계속해서 서비스를 재시작하고 있었다. 이는 불을 끄는 것이 아니라 불에 기름을 붓는 격이었다.

문제의 핵심은 열쇠와 자물쇠가 맞지 않는다는 것입니다.

자세히 분석해 보면, 문제는 사실 아주 간단합니다.

monit 설정 파일에 지정된 소켓 경로는 다음과 같습니다./run/php/php8.4-fpm.sock

하지만 php-fpm이 실제로 실행되는 소켓 경로는 다음과 같습니다./run/php/php8.4-fpm-etufo.org.sock

한 함수가 파일 A를 감지하도록 설계되었는데 다른 함수가 실제로는 파일 B라면, 감지는 당연히 실패할 것입니다.

이건 마치 뭔가 같아요.

열쇠는 있는데, 다른 방에 잠겨 있어요.

당신은 매일 열쇠로 문을 열지만, 매번 문이 열리지 않아 자물쇠가 고장 났다고 말합니다.

사실 자물쇠가 고장난 건 아니에요. 단지 열쇠가 자물쇠에 맞지 않는 것뿐이에요.

풀다모니터링 모니터링PHP-FPM과 구성이 일치하지 않습니다.

옵션 1: monit 설정을 변경합니다.

php-fpm의 기존 소켓 설정을 유지하려면 monit 설정을 수정하십시오.

monit 설정 파일을 찾아서 다음 내용을 수정하십시오.

if failed unixsocket /run/php/php8.4-fpm.sock then restart

로 변경:

if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart

그런 다음 새로 고침을 수행하십시오.

sudo monit reload

그게 다예요.

옵션 2: php-fpm 설정을 변경합니다.

기본 경로를 사용하려면 php-fpm의 풀 구성을 변경하십시오.

꼰다. /etc/php/8.4/fpm/pool.d/chenweiliang.com.conflisten 명령어를 다음과 같이 변경하세요:

listen = /run/php/php8.4-fpm.sock

그런 다음 php-fpm을 다시 시작하십시오.

sudo systemctl restart php8.4-fpm

그게 다예요.

두 가지 해결책 모두 문제를 해결할 수 있지만, 어떤 것을 선택할지는 구체적인 상황에 따라 다릅니다.

서버에 호스팅된 사이트는 몇 개입니까? 각 사이트마다 독립적인 소켓이 있습니까? 사이트가 하나만 있는 경우 기본 경로가 더 간단해집니다.

진심을 담아 말씀드리겠습니다.

저는 이러한 유형의 설정 문제가 가장 쉽게 간과되지만 유지보수 중 서버 안정성에 가장 큰 영향을 미친다고 진심으로 믿습니다.

소켓 경로가 잘못 기록되면 겉으로는 아무 문제 없어 보일 수 있지만, 실제로는 모니터링 시스템에서 오경보가 계속 발생하고, 서비스가 무작위로 재시작되며, 부하가 설명할 수 없이 급증하는 현상이 나타납니다.

서버가 너무 오래되어 업그레이드가 필요하다고 생각할 수도 있지만, 실제로는 구성 파일의 경로가 잘못되었을 가능성이 있습니다.

한 선배 동료가 말했듯이, "모니터링의 정확성은 서비스 안정성을 보장하는 첫 번째 방어선입니다."

성공과 실패는 세부 사항에 달려 있으며, 이는 서버 환경에서 절대적으로 사실입니다.

오늘부터 모니터링 구성을 확인하세요. 이 사소해 보이는 문제가 서버를 다운시키지 않도록 하세요.

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