Adresár článkov
Krvavý kúpeľ spustený cestou socketu
Príbeh ide takto.
Mám kamaráta, ktorému minulý mesiac opäť spadol server.
Prišiel za mnou a povedal, že monit stále hlási chyby, že nevie nájsť socket súbor php-fpm a potom sa služba začala často reštartovať a záťaž stále prudko stúpala. O tretej hodine ráno mu zavolali tiesňové volanie, aby opravil server.
Povedal som ti, aby si nepanikáril a ukázal mi záznamy z monitorovania.
Keď som sa na to pozrel, wow, bolo to plné týchto druhov chýb:
chyba: Chyba pripojenia Unix socketu /run/php/php8.4-fpm.sock — Žiadny takýto súbor alebo adresár chyba: 'php8.4-fpm' faitest protokolu LED [PREDVOĽBENÉ] na /run/php/php8.4-fpm.sock — Nedá sa vytvoriť unixový socket pre /run/php/php8.4-fpm.sock
Spýtal som sa ho: „Kde máš teraz socketový súbor?“
Povedal, že nevie, tak som to jednoducho nainštaloval s predvolenými nastaveniami.
Povedal som ti, aby si počkal, skontrolujem ťa.
Potom som sa prihlásil cez SSH a videl som, že jeho skutočný socketový súbor sa volá... /run/php/php8.4-fpm-etufo.org.sock.
Povedal som, kamarát, tvoja socketová cesta sú dve rôzne veci, bol by zázrak, keby dokázali komunikovať.
Dnes to podrobne rozoberiem a vysvetlím a tiež poskytnem riešenie problému.
Myslíš si, že ťa sledovanie chráni, ale v skutočnosti ti škodí.
Začnime tým, že si povieme o najbežnejšom type chyby v protokoloch monitorovania.
Keď toto uvidíte:
chyba: Chyba pripojenia Unix socketu /run/php/php8.4-fpm.sock — Neexistuje žiadny súbor ani adresár
Toto znamená, že monit sa pokúša zistiť službu php-fpm cez tento socket, ale súbor nemôže nájsť.
Ďalej sa monitor pokúsi reštartovať službu a v protokoloch sa zobrazí:
info: 'php8.4-fpm' pokúša sa o reštart info: 'php8.4-fpm' stop: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' start: '/usr/sbin/service php8.4-fpm start'
Vyzerá to celkom šikovne, však? Opraví sa to automaticky.
Problém je však v tom, že toto časté reštartovanie je skutočnou katastrofou.
Predstavte si toto: keď sa php-fpm reštartuje, všetky aktuálne spracovávané požiadavky sa prerušia, všetky relácie sa môžu stratiť a všetky pripojenia je potrebné obnoviť. Ak sa opakovane reštartuje a zlyháva v krátkom čase, zaťaženie servera sa okamžite zvýši.
V záznamoch sa zobrazia aj ďalšie informácie, ako napríklad:
chyba: 'etUFO.org' loadavg (15min) z 8.8 zodpovedá limitu zdrojov [loadavg (15min) > 8.0] chyba: 'etUFOVyužitie CPU systému domény .org na úrovni 33.9 % zodpovedá limitu zdrojov [využitie CPU systému > 30.0 %]
Server bol už aj tak vysoko zaťažený, ale monitorovací systém stále opakovane reštartoval službu. Toto nehasilo oheň, ale prilievalo olej do ohňa.
Podstata problému: kľúč a zámok sa nezhodujú.
Pri bližšej analýze je problém v skutočnosti dosť jednoduchý.
Cesta k soketu uvedená v konfiguračnom súbore monit je:/run/php/php8.4-fpm.sock
Skutočná cesta k socketu, na ktorej beží php-fpm, je však:/run/php/php8.4-fpm-etufo.org.sock
Ak je jedna funkcia určená na detekciu súboru A, ale druhá je v skutočnosti súbor B, detekcia zjavne zlyhá.
Toto je ako niečo.
Máš kľúč, zamknutý v inej miestnosti.
Každý deň otváraš dvere kľúčom, ale zakaždým zistíš, že sa neotvárajú, a potom povieš, že zámok je pokazený.
V skutočnosti zámok nie je pokazený; len tvoj kľúč k zámku nepasuje.
vyriešiťMonitorovanie monitorovaniaKonfigurácia nie je konzistentná s PHP-FPM

Možnosť 1: Zmeňte konfiguráciu monitora.
Ak chcete zachovať existujúcu konfiguráciu socketu php-fpm, upravte konfiguráciu monit.
Vyhľadajte konfiguračný súbor monit a upravte nasledujúce:
if failed unixsocket /run/php/php8.4-fpm.sock then restart
Zmeňte to na:
if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart
Potom vykonajte opätovné načítanie:
sudo monit reload
To je všetko.
Možnosť 2: Zmeňte konfiguráciu php-fpm.
Ak chcete použiť predvolenú cestu, zmeňte konfiguráciu fondu php-fpm.
编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confZmeňte príkaz listen na:
listen = /run/php/php8.4-fpm.sock
Potom reštartujte php-fpm:
sudo systemctl restart php8.4-fpm
To je všetko.
Obe riešenia môžu problém vyriešiť; to, ktoré si vyberiete, závisí od vašich konkrétnych okolností.
Koľko stránok je hostovaných na vašom serveri? Má každá stránka nezávislý socket? Ak existuje iba jedna stránka, predvolená cesta bude jednoduchšia.
Dovoľte mi hovoriť zo srdca.
Úprimne verím, že tieto typy problémov s konfiguráciou sa najčastejšie prehliadajú, no zároveň majú najväčší vplyv na stabilitu servera počas údržby.
Ak je cesta k soketu zapísaná nesprávne, na povrchu sa môže zdať, že je všetko pokojné, ale v skutočnosti monitorovací systém neustále hlási falošné poplachy, služba sa neustále náhodne reštartuje a záťaž neustále nevysvetliteľne stúpa.
Možno si myslíte, že server je príliš starý a potrebuje aktualizáciu, ale v skutočnosti je možné, že cesta v konfiguračnom súbore je nesprávna.
Ako raz povedal jeden starší kolega: „Presnosť monitorovania je prvou obrannou líniou pre zabezpečenie stability služby.“
Detaily určujú úspech alebo neúspech a to platí absolútne aj v serverovom prostredí.
Od dnešného dňa skontrolujte konfiguráciu monitorovania. Nenechajte tento zdanlivo jednoduchý problém spôsobiť zlyhanie vášho servera.
Ďakujem za prečítanie môjho článku. Dovidenia nabudúce.
Blog Hope Chen Weiliang ( https://www.chenweiliang.com/ Článok „Riešenie chyby „Žiadny takýto súbor alebo adresár“ v konfigurácii monitorovania Monit a PHP-FPM“, ktorý je tu zdieľaný, by vám mohol byť užitočný.
Vitajte pri zdieľaní odkazu na tento článok:https://www.chenweiliang.com/cwl-34000.html
