Risoluzione dell'errore "File o directory non esistente" causato da incongruenze tra la configurazione di monitoraggio di Monit e PHP-FPM.

Un bagno di sangue innescato da un percorso di connessione

La storia è questa.

Ho un amico il cui server è andato di nuovo in crash il mese scorso.

È venuto da me e mi ha detto che Monit continuava a segnalare errori, dicendo che non riusciva a trovare il file socket php-fpm, poi il servizio ha iniziato a riavviarsi frequentemente e il carico è schizzato alle stelle. È stato chiamato d'urgenza alle 3 del mattino per riparare il server.

Ti avevo detto di non farti prendere dal panico e di mostrarmi i registri di monitoraggio.

Quando l'ho guardato, wow, era pieno di errori di questo tipo:

errore: Errore di connessione del socket Unix /run/php/php8.4-fpm.sock — Nessun file o directory di questo tipo errore: 'php8.4-fpm' non è riuscito nel test del protocollo [DEFAULT] in /run/php/php8.4-fpm.sock — Impossibile creare il socket Unix per /run/php/php8.4-fpm.sock

Gli ho chiesto: "Dov'è il tuo file socket adesso?"

Ha detto che non lo sapeva, quindi l'ho installato con le impostazioni predefinite.

Ti avevo detto di aspettare, vado a controllare io.

Poi mi sono connesso tramite SSH e ho visto che il suo file socket effettivo si chiamava... /run/php/php8.4-fpm-etufo.org.sock.

Ho detto, amico, il tuo percorso socket è composto da due cose diverse, sarebbe un miracolo se riuscissero a comunicare.

Oggi analizzerò e spiegherò questo concetto in dettaglio, fornendo anche una soluzione al problema.

Credi che la sorveglianza ti protegga, ma in realtà ti sta danneggiando.

Iniziamo parlando del tipo di errore più comune nei log di monit.

Quando vedi questo:

errore: Errore di connessione del socket Unix /run/php/php8.4-fpm.sock — File o directory non esistente

Ciò indica che monit sta tentando di rilevare il servizio php-fpm tramite questo socket, ma non riesce a trovare il file.

Quello che succede dopo è che monit tenterà di riavviare il servizio e i log mostreranno:

info: 'php8.4-fpm' tentativo di riavvio info: 'php8.4-fpm' stop: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' start: '/usr/sbin/service php8.4-fpm start'

Sembra piuttosto intelligente, vero? Si ripara da solo.

Il problema, però, è che questi frequenti riavvii rappresentano il vero disastro.

Immaginate questa situazione: quando php-fpm si riavvia, tutte le richieste in corso di elaborazione vengono interrotte, tutte le sessioni potrebbero andare perse e tutte le connessioni devono essere ristabilite. Se si riavvia e fallisce ripetutamente in un breve lasso di tempo, il carico del server aumenterà vertiginosamente.

I registri riveleranno anche ulteriori informazioni, come ad esempio questa:

errore: il carico medio (15 min) di 8.8 per 'et ufo .org' corrisponde al limite delle risorse [carico medio (15 min) > 8.0] errore: l'utilizzo della CPU del sistema pari al 33.9% per 'et ufo .org' corrisponde al limite delle risorse [utilizzo della CPU del sistema > 30.0%]

Il server era già sottoposto a un carico elevato, ma il sistema di monitoraggio continuava a riavviare ripetutamente il servizio. Questo non faceva altro che alimentare il problema, non faceva altro che peggiorarlo.

Il nocciolo del problema: la chiave e la serratura non sono compatibili.

A un'analisi più attenta, il problema si rivela in realtà piuttosto semplice.

Il percorso del socket specificato nel file di configurazione di monit è:/run/php/php8.4-fpm.sock

Tuttavia, il percorso effettivo del socket su cui viene eseguito php-fpm è:/run/php/php8.4-fpm-etufo.org.sock

Se una funzione è destinata a rilevare il file A, ma l'altra rileva in realtà il file B, il rilevamento fallirà ovviamente.

È come qualcosa.

Hai una chiave, chiusa a chiave in un'altra stanza.

Ogni giorno usi la chiave per aprire la porta, ma ogni volta scopri che non si apre e quindi dici che la serratura è rotta.

In realtà, la serratura non è rotta; è solo che la tua chiave non è compatibile con la serratura.

risolvereMonitorare il monitoraggioConfigurazione incompatibile con PHP-FPM

Opzione 1: Modificare la configurazione di monit.

Se si desidera mantenere la configurazione socket esistente di php-fpm, è necessario modificare la configurazione di monit.

Individua il file di configurazione di monit e modifica quanto segue:

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

Cambialo in:

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

Quindi esegui un ricaricamento:

sudo monit reload

Questo è tutto.

Opzione 2: Modificare la configurazione di php-fpm.

Se si desidera utilizzare il percorso predefinito, è necessario modificare la configurazione del pool di php-fpm.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confModifica il comando listen in:

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

Quindi riavviare php-fpm:

sudo systemctl restart php8.4-fpm

Questo è tutto.

Entrambe le soluzioni possono risolvere il problema; la scelta dipende dalle circostanze specifiche.

Quanti siti sono ospitati sul tuo server? Ogni sito ha un socket indipendente? Se c'è un solo sito, il percorso predefinito sarà più semplice.

Lasciatemi parlare a cuore aperto.

Credo sinceramente che questo tipo di problemi di configurazione siano i più facili da trascurare, ma al contempo i più influenti sulla stabilità del server durante la manutenzione.

Se il percorso di un socket è scritto in modo errato, la situazione potrebbe sembrare tranquilla in superficie, ma in realtà il sistema di monitoraggio continua a generare falsi allarmi, il servizio continua a riavviarsi in modo casuale e il carico continua a presentare picchi inspiegabili.

Potresti pensare che il server sia troppo vecchio e necessiti di un aggiornamento, ma in realtà potrebbe dipendere dal fatto che il percorso nel file di configurazione è errato.

Come disse una volta un mio collega anziano: "L'accuratezza del monitoraggio è la prima linea di difesa per garantire la stabilità del servizio".

I dettagli determinano il successo o il fallimento, e questo è assolutamente vero in un ambiente server.

A partire da oggi, verificate la configurazione del vostro sistema di monitoraggio. Non lasciate che questo problema apparentemente semplice mandi in crash il vostro server.

Grazie per aver letto il mio articolo. Alla prossima.