മോണിറ്റ് മോണിറ്ററിംഗ് കോൺഫിഗറേഷനും PHP-FPM-ഉം തമ്മിലുള്ള പൊരുത്തക്കേടുകൾ മൂലമുണ്ടായ "അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല" എന്ന പിശക് പരിഹരിക്കുന്നു.

ഒരു സോക്കറ്റ് പാത മൂലമുണ്ടാകുന്ന ഒരു രക്തച്ചൊരിച്ചിൽ

കഥ ഇങ്ങനെ പോകുന്നു.

കഴിഞ്ഞ മാസം വീണ്ടും സെർവർ തകരാറിലായ ഒരു സുഹൃത്ത് എനിക്കുണ്ട്.

മോണിറ്റ് പിശകുകൾ റിപ്പോർട്ട് ചെയ്തുകൊണ്ടേയിരിക്കുന്നുവെന്നും php-fpm സോക്കറ്റ് ഫയൽ കണ്ടെത്താൻ കഴിയുന്നില്ലെന്നും അദ്ദേഹം എന്റെ അടുത്ത് വന്ന് പറഞ്ഞു. തുടർന്ന് സേവനം ഇടയ്ക്കിടെ പുനരാരംഭിക്കാൻ തുടങ്ങി, ലോഡ് വർദ്ധിച്ചു. സെർവർ ശരിയാക്കാൻ പുലർച്ചെ 3 മണിക്ക് ഒരു അടിയന്തര കോൾ അദ്ദേഹത്തെ വിളിച്ചു.

ഞാൻ പറഞ്ഞതല്ലേ, പരിഭ്രാന്തരാകേണ്ടെന്നും മോണിറ്റ് ലോഗുകൾ കാണിക്കണമെന്നും.

ഞാൻ അതിലേക്ക് നോക്കിയപ്പോൾ, വൗ, അതിൽ നിറയെ ഇത്തരം പിശകുകളായിരുന്നു:

പിശക്: Unix സോക്കറ്റ് /run/php/php8.4-fpm.sock കണക്ഷൻ പിശക് — അത്തരമൊരു ഫയലോ ഡയറക്ടറിയോ ഇല്ല പിശക്: 'php8.4-fpm' f ai led പ്രോട്ടോക്കോൾ ടെസ്റ്റ് [DEFAULT] at /run/php/php8.4-fpm.sock — /run/php/php8.4-fpm.sock-നായി unix സോക്കറ്റ് സൃഷ്ടിക്കാൻ കഴിയില്ല.

ഞാൻ അയാളോട് ചോദിച്ചു, "നിങ്ങളുടെ സോക്കറ്റ് ഫയൽ ഇപ്പോൾ എവിടെയാണ്?"

അയാൾക്ക് അറിയില്ല എന്ന് പറഞ്ഞു, അതുകൊണ്ട് ഞാൻ അത് ഡിഫോൾട്ട് സെറ്റിംഗ്സിൽ ഇൻസ്റ്റാൾ ചെയ്തു.

ഞാൻ നിന്നോട് കാത്തിരിക്കാൻ പറഞ്ഞു, ഞാൻ നോക്കിക്കോളാം.

പിന്നെ ഞാൻ അകത്തു കയറിയപ്പോൾ അവന്റെ യഥാർത്ഥ സോക്കറ്റ് ഫയൽ ... എന്ന് വിളിക്കപ്പെടുന്നത് കണ്ടു. /run/php/php8.4-fpm-etufo.org.sock.

ഞാൻ പറഞ്ഞു, സുഹൃത്തേ, നിങ്ങളുടെ സോക്കറ്റ് പാത രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്, അതിന് ആശയവിനിമയം നടത്താൻ കഴിയുമെങ്കിൽ അത് ഒരു അത്ഭുതമായിരിക്കും.

ഇന്ന് ഞാൻ ഇത് വിശദമായി വിശദീകരിക്കുകയും പ്രശ്നത്തിന് ഒരു പരിഹാരം നൽകുകയും ചെയ്യും.

നിരീക്ഷണം നിങ്ങളെ സംരക്ഷിക്കുന്നുവെന്ന് നിങ്ങൾ കരുതുന്നു, പക്ഷേ യഥാർത്ഥത്തിൽ അത് നിങ്ങൾക്ക് ദോഷം വരുത്തുകയാണ് ചെയ്യുന്നത്.

മോണിറ്റ് ലോഗുകളിലെ ഏറ്റവും സാധാരണമായ പിശകിനെക്കുറിച്ച് സംസാരിച്ചുകൊണ്ട് നമുക്ക് ആരംഭിക്കാം.

ഇത് കാണുമ്പോൾ:

പിശക്: Unix സോക്കറ്റ് /run/php/php8.4-fpm.sock കണക്ഷൻ പിശക് — അത്തരമൊരു ഫയലോ ഡയറക്ടറിയോ ഇല്ല.

ഇത് സൂചിപ്പിക്കുന്നത് മോണിറ്റ് ഈ സോക്കറ്റ് വഴി php-fpm സേവനം കണ്ടെത്താൻ ശ്രമിക്കുന്നുണ്ടെങ്കിലും ഫയൽ കണ്ടെത്താൻ കഴിയുന്നില്ല എന്നാണ്.

അടുത്തതായി സംഭവിക്കുന്നത് മോണിറ്റ് സേവനം പുനരാരംഭിക്കാൻ ശ്രമിക്കും, ലോഗുകൾ കാണിക്കും:

വിവരം: 'php8.4-fpm' പുനരാരംഭിക്കാൻ ശ്രമിക്കുന്ന വിവരം: 'php8.4-fpm' നിർത്തുക: '/usr/sbin/service php8.4-fpm നിർത്തുക' വിവരം: 'php8.4-fpm' ആരംഭിക്കുക: '/usr/sbin/service php8.4-fpm ആരംഭിക്കുക'

ഇത് വളരെ മികച്ചതായി തോന്നുന്നു, അല്ലേ? ഇത് സ്വയം നന്നാക്കുന്നു.

പക്ഷേ പ്രശ്നം എന്തെന്നാൽ, ഈ പതിവ് പുനരാരംഭമാണ് യഥാർത്ഥ ദുരന്തം.

ഇത് സങ്കൽപ്പിക്കുക: php-fpm പുനരാരംഭിക്കുമ്പോൾ, നിലവിൽ പ്രോസസ്സ് ചെയ്യുന്ന എല്ലാ അഭ്യർത്ഥനകളും തടസ്സപ്പെടും, എല്ലാ സെഷനുകളും നഷ്ടപ്പെട്ടേക്കാം, എല്ലാ കണക്ഷനുകളും പുനഃസ്ഥാപിക്കേണ്ടതുണ്ട്. ഇത് ആവർത്തിച്ച് പുനരാരംഭിക്കുകയും ഒരു ചെറിയ കാലയളവിനുള്ളിൽ പരാജയപ്പെടുകയും ചെയ്താൽ, സെർവർ ലോഡ് തൽക്ഷണം വർദ്ധിക്കും.

ലോഗുകൾ കൂടുതൽ വിവരങ്ങൾ വെളിപ്പെടുത്തും, ഉദാഹരണത്തിന്:

പിശക്: 'et ufo .org' loadavg (15 മിനിറ്റ്) 8.8 പൊരുത്തമുള്ള റിസോഴ്‌സ് പരിധി [loadavg (15 മിനിറ്റ്) > 8.0] പിശക്: 'et ufo .org' സിപിയു സിസ്റ്റം ഉപയോഗം 33.9% റിസോഴ്‌സ് പരിധിയുമായി പൊരുത്തപ്പെടുന്നു [cpu സിസ്റ്റം ഉപയോഗം > 30.0%]

സെർവറിൽ ഇതിനകം തന്നെ ഉയർന്ന ലോഡ് ഉണ്ടായിരുന്നു, പക്ഷേ മോണിറ്ററിംഗ് സിസ്റ്റം ഇപ്പോഴും സേവനം ആവർത്തിച്ച് പുനരാരംഭിച്ചുകൊണ്ടിരുന്നു. ഇത് തീ കെടുത്തുകയായിരുന്നില്ല; മറിച്ച് എരിതീയിൽ എണ്ണ ഒഴിക്കുകയായിരുന്നു.

പ്രശ്നത്തിന്റെ സാരം: താക്കോലും പൂട്ടും പൊരുത്തപ്പെടുന്നില്ല.

സൂക്ഷ്മമായി വിശകലനം ചെയ്യുമ്പോൾ, പ്രശ്നം വളരെ ലളിതമാണ്.

മോണിറ്റ് കോൺഫിഗറേഷൻ ഫയലിൽ വ്യക്തമാക്കിയിരിക്കുന്ന സോക്കറ്റ് പാത്ത് ഇതാണ്:/run/php/php8.4-fpm.sock

എന്നിരുന്നാലും, php-fpm പ്രവർത്തിക്കുന്ന യഥാർത്ഥ സോക്കറ്റ് പാത്ത് ഇതാണ്:/run/php/php8.4-fpm-etufo.org.sock

ഒരു ഫംഗ്ഷൻ ഫയൽ എ കണ്ടെത്തുന്നതിന് ഉദ്ദേശിച്ചുള്ളതാണെങ്കിൽ, മറ്റൊന്ന് യഥാർത്ഥത്തിൽ ഫയൽ ബി ആണെങ്കിൽ, കണ്ടെത്തൽ വ്യക്തമായും പരാജയപ്പെടും.

ഇത് എന്തോ പോലെയാണ്.

നിങ്ങളുടെ കൈവശം ഒരു താക്കോൽ ഉണ്ട്, അത് മറ്റൊരു മുറിയിൽ പൂട്ടിയിരിക്കുകയാണ്.

നിങ്ങൾ എല്ലാ ദിവസവും വാതിൽ തുറക്കാൻ നിങ്ങളുടെ താക്കോൽ ഉപയോഗിക്കുന്നു, പക്ഷേ ഓരോ തവണ കണ്ടെത്തുമ്പോഴും അത് തുറക്കുന്നില്ല, എന്നിട്ട് നിങ്ങൾ പറയുന്നു പൂട്ട് പൊട്ടിയിട്ടുണ്ടെന്ന്.

വാസ്തവത്തിൽ, പൂട്ട് പൊട്ടിയിട്ടില്ല; നിങ്ങളുടെ താക്കോൽ പൂട്ടുമായി പൊരുത്തപ്പെടുന്നില്ല എന്നതാണ് കാര്യം.

പരിഹരിക്കുകനിരീക്ഷണം നിരീക്ഷിക്കുകPHP-FPM-മായി പൊരുത്തപ്പെടാത്ത കോൺഫിഗറേഷൻ

ഓപ്ഷൻ 1: മോണിറ്റ് കോൺഫിഗറേഷൻ മാറ്റുക.

നിലവിലുള്ള php-fpm സോക്കറ്റ് കോൺഫിഗറേഷൻ നിലനിർത്തണമെങ്കിൽ, മോണിറ്റ് കോൺഫിഗറേഷൻ പരിഷ്കരിക്കുക.

മോണിറ്റ് കോൺഫിഗറേഷൻ ഫയൽ കണ്ടെത്തി ഇനിപ്പറയുന്നവ പരിഷ്കരിക്കുക:

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

അത്രയേയുള്ളൂ.

രണ്ട് പരിഹാരങ്ങളും പ്രശ്നം പരിഹരിക്കാൻ കഴിയും; ഏതാണ് നിങ്ങൾ തിരഞ്ഞെടുക്കുന്നത് എന്നത് നിങ്ങളുടെ നിർദ്ദിഷ്ട സാഹചര്യങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു.

നിങ്ങളുടെ സെർവറിൽ എത്ര സൈറ്റുകൾ ഹോസ്റ്റ് ചെയ്തിട്ടുണ്ട്? ഓരോ സൈറ്റിനും ഒരു സ്വതന്ത്ര സോക്കറ്റ് ഉണ്ടോ? ഒരു സൈറ്റ് മാത്രമേ ഉള്ളൂവെങ്കിൽ, ഡിഫോൾട്ട് പാത്ത് ലളിതമായിരിക്കും.

ഹൃദയത്തിൽ നിന്ന് ഞാൻ സംസാരിക്കട്ടെ.

ഈ തരത്തിലുള്ള കോൺഫിഗറേഷൻ പ്രശ്നങ്ങൾ ഏറ്റവും എളുപ്പത്തിൽ അവഗണിക്കപ്പെടുന്നവയാണെന്നും എന്നാൽ അറ്റകുറ്റപ്പണി സമയത്ത് സെർവർ സ്ഥിരതയെ ഏറ്റവും സ്വാധീനിക്കുന്നവയാണെന്നും ഞാൻ ആത്മാർത്ഥമായി വിശ്വസിക്കുന്നു.

ഒരു സോക്കറ്റ് പാത്ത് തെറ്റായി എഴുതിയിട്ടുണ്ടെങ്കിൽ, ഉപരിതലത്തിൽ കാര്യങ്ങൾ ശാന്തമായി തോന്നാം, പക്ഷേ വാസ്തവത്തിൽ, മോണിറ്ററിംഗ് സിസ്റ്റം തെറ്റായ അലാറങ്ങൾ നൽകുന്നു, സേവനം ക്രമരഹിതമായി പുനരാരംഭിക്കുന്നു, ലോഡ് വിശദീകരിക്കാനാകാത്തവിധം വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്നു.

സെർവർ വളരെ പഴയതാണെന്നും ഒരു അപ്‌ഗ്രേഡ് ആവശ്യമാണെന്നും നിങ്ങൾ കരുതിയേക്കാം, പക്ഷേ കോൺഫിഗറേഷൻ ഫയലിലെ പാത്ത് തെറ്റായിരിക്കാം.

ഒരു മുതിർന്ന സഹപ്രവർത്തകൻ ഒരിക്കൽ പറഞ്ഞതുപോലെ, "സേവന സ്ഥിരത ഉറപ്പാക്കുന്നതിനുള്ള ആദ്യ പ്രതിരോധ നിരയാണ് നിരീക്ഷണത്തിന്റെ കൃത്യത."

വിശദാംശങ്ങളാണ് വിജയ പരാജയം നിർണ്ണയിക്കുന്നത്, ഇത് ഒരു സെർവർ പരിതസ്ഥിതിയിൽ തികച്ചും സത്യമാണ്.

ഇന്ന് മുതൽ, നിങ്ങളുടെ മോണിറ്ററിംഗ് കോൺഫിഗറേഷൻ പരിശോധിക്കുക. ലളിതമായി തോന്നുന്ന ഈ പ്രശ്നം നിങ്ങളുടെ സെർവറിനെ തകരാറിലാക്കാൻ അനുവദിക്കരുത്.

എന്റെ ലേഖനം വായിച്ചതിന് നന്ദി. അടുത്ത തവണ കാണാം.