HestiaCP ഉപയോഗിച്ചുള്ള Apache2 ന്റെ പതിവ് ക്രാഷുകൾ? മോണിറ്റ് ഓട്ടോമേറ്റഡ് മോണിറ്ററിംഗ്, ട്രബിൾഷൂട്ടിംഗ് ഗൈഡ് (പൂർണ്ണ കോൺഫിഗറേഷനോടെ)

HestiaCP പരിതസ്ഥിതികളിൽ Apache2 ക്രാഷുകളോ മോണിറ്റ് ഓട്ടോ-റീസ്റ്റാർട്ട് പരാജയങ്ങളോ പതിവായി സംഭവിക്കുന്നുണ്ടോ? മോണിറ്റിനൊപ്പം Apache2 നിരീക്ഷിക്കുമ്പോഴും PID പാത്ത് തെറ്റായ ക്രമീകരണം, അനുമതി തടയൽ തുടങ്ങിയ സാധാരണ പ്രശ്‌നങ്ങൾ ആഴത്തിൽ വിശകലനം ചെയ്യുമ്പോഴും പ്രൊഡക്ഷൻ-ഗ്രേഡ് മോണിറ്റ് ഓട്ടോമേഷൻ കോൺഫിഗറേഷൻ ഫയലുകൾ വാഗ്ദാനം ചെയ്യുമ്പോഴും സാധാരണ പിഴവുകൾ ഒഴിവാക്കുന്നതിനുള്ള ഒരു പ്രായോഗിക ഗൈഡ് ഈ ലേഖനം നൽകുന്നു. ഉയർന്ന ലഭ്യതയുള്ള സെർവർ പരിപാലന സാങ്കേതിക വിദ്യകൾ ഇപ്പോൾ മാസ്റ്റർ ചെയ്യുക, പരാജയങ്ങളിൽ നിന്ന് രണ്ടാം ലെവൽ ഓട്ടോമാറ്റിക് വീണ്ടെടുക്കൽ നേടുക!

Apache2 നിരീക്ഷിക്കാൻ മോണിറ്റ് ഉപയോഗിക്കുമ്പോൾ ഞാൻ നേരിട്ട അപകടങ്ങൾ

കഴിഞ്ഞ വെള്ളിയാഴ്ച, അർദ്ധരാത്രിയിൽ സെർവർ എനിക്ക് ഒരു മോണിറ്റ് അലേർട്ട് നൽകി.

ഞാൻ സ്തബ്ധനായി പാനലിലേക്ക് നോക്കി, അപ്പോഴാണ് apache2 സ്റ്റാറ്റസ് കോളത്തിൽ ഒരു ചുവന്ന ടൈംഔട്ട് കണ്ടത്.

ഞാൻ കുറച്ചു നേരം ആലോചിച്ചു. പകൽ സമയത്ത് സെർവറിൽ മോണിറ്റ് മോണിറ്ററിംഗ് ചേർത്തു, ഒരു ഓൺലൈൻ ട്യൂട്ടോറിയലിൽ നിന്ന് കോൺഫിഗറേഷൻ പകർത്തി ഒട്ടിച്ചു. ഒരു പ്രശ്‌നവും ഉണ്ടാകരുത്, അല്ലേ?

പിറ്റേന്ന് രാവിലെ, അത് വീണ്ടും സമയപരിധി കഴിഞ്ഞു. മൂന്നാം തവണയും മോണിറ്റർ നിർത്തി, പാനൽ "നിരീക്ഷിക്കപ്പെടുന്നില്ല" എന്ന് പ്രദർശിപ്പിച്ചു.

ഞാൻ...

ആദ്യം ഞാൻ അത് ഗൗരവമായി എടുത്തില്ല എന്ന് സമ്മതിക്കുന്നു. Apache2 നിരീക്ഷണമാണോ? നിങ്ങൾക്ക് ഓൺലൈനിൽ ടൺ കണക്കിന് ടെംപ്ലേറ്റ് കോൺഫിഗറേഷനുകൾ കണ്ടെത്താൻ കഴിയും, പകർത്തി ഒട്ടിക്കുക. പക്ഷേ ആ പേസ്റ്റിംഗ് പ്രക്രിയ എന്നെ ശരിക്കും ദേഷ്യം പിടിപ്പിച്ചു.

ഹെസ്റ്റിയാസിപിയുടെ ഡിഫോൾട്ട് ആർക്കിടെക്ചറും മോണിറ്റ് പോർട്ടുകളും തമ്മിലുള്ള സംഘർഷത്തിന്റെ മൂലകാരണം

ആദ്യം എനിക്ക് ഇത്രയധികം പ്രശ്‌നമുണ്ടാക്കിയ കോൺഫിഗറേഷൻ കാണിച്ചുതരാം, അതുവഴി നിങ്ങൾ കണ്ട പതിപ്പിന് സമാനമാണോ ഇത് എന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും.

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 ൽ പ്രവർത്തിക്കുന്നു.

പോർട്ട് 80 ൽ Apache2 ന്റെ പ്രവർത്തനക്ഷമത പരിശോധിക്കാൻ മോണിറ്റിനോട് ആവശ്യപ്പെട്ടാൽ, KFC കണ്ടെത്താൻ മക്ഡൊണാൾഡ്‌സിൽ പോകുന്നത് പോലെയാണ്. സെർവർ നിങ്ങളെ ശൂന്യമായി നോക്കുന്നു, നിങ്ങൾ രണ്ടുപേരും പരസ്പരം തുറിച്ചുനോക്കുന്നു. അവസാനം, നിങ്ങൾ ഡൗൺ ആണെന്ന് മോണിറ്റ് മനസ്സിലാക്കുകയും ഭ്രാന്തമായി റീബൂട്ട് ചെയ്യാൻ തുടങ്ങുകയും ചെയ്യുന്നു.

പുനരാരംഭിച്ചതിനുശേഷവും പോർട്ട് 8081 തന്നെയാണ്. തുടർന്ന് മോണിറ്റ് പോർട്ട് 80 പരിശോധിക്കാൻ ശ്രമിക്കുന്നു, അതും പരാജയപ്പെടുന്നു, അതിനാൽ അത് വീണ്ടും ആരംഭിക്കുന്നു. മോണിറ്റ് ഇത് നന്നാക്കാൻ കഴിയില്ലെന്ന് തീരുമാനിക്കുകയും സമയം കഴിയുകയും ചെയ്യുന്നതുവരെ ഈ ചക്രം ആവർത്തിക്കുന്നു.

ഇത് ആദ്യമായി നേരിട്ടപ്പോൾ ഞാൻ ശരിക്കും സ്തബ്ധനായിപ്പോയി. ഓൺലൈനിൽ കണ്ടെത്തിയ പത്തിൽ ഒമ്പത് ട്യൂട്ടോറിയലുകളും പോർട്ട് 80 ഉപയോഗിച്ചിരുന്നു. നിങ്ങൾ അവ പിന്തുടർന്നാൽ, പ്രശ്നം നിങ്ങളുടേതല്ല, മറിച്ച് വിവരങ്ങളുടെ ഉറവിടത്തിലാണ്.

കേടായ ഒരു Apache2 PID ഫയൽ കാരണം മോണിറ്റ് ആ പ്രക്രിയ നിലവിലില്ലെന്ന് തെറ്റായി തിരിച്ചറിഞ്ഞു.

പോർട്ട് 80 ൽ നിന്ന് 8081 ലേക്ക് മാറ്റിയ ശേഷം, മോണിറ്റിന് അത് സൈദ്ധാന്തികമായി കണ്ടെത്താൻ കഴിയണം, അല്ലേ?

എന്നിരുന്നാലും, വാസ്തവത്തിൽ, അത് ഇപ്പോഴും ഇടയ്ക്കിടെ "നിർവ്വഹണം പരാജയപ്പെട്ടു " എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു.

വളരെ നേരം കഷ്ടപ്പെട്ടതിനു ശേഷം, ഒടുവിൽ കാരണം ലളിതമായിരുന്നുവെന്ന് ഞാൻ കണ്ടെത്തി: PID ഫയൽ കേടായി.

ഒന്നാലോചിച്ചു നോക്കൂ, മോണിറ്റ് അപ്പാച്ചെ2 ഭ്രാന്തമായി റീസ്റ്റാർട്ട് ചെയ്യുകയായിരുന്നു, ഓരോ തവണയും അത് നിർബന്ധിച്ച് ഇല്ലാതാക്കുകയും റീസ്റ്റാർട്ട് ചെയ്യുകയും ചെയ്തു, പലതവണ മുന്നോട്ടും പിന്നോട്ടും പോയി. ഈ പ്രക്രിയയിൽ, /var/run/apache2/apache2.pid ഫയൽ 0 ബൈറ്റുകളായി മാറിയേക്കാം.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഫയൽ ഇപ്പോഴും അവിടെയുണ്ട്, പക്ഷേ അത് ശൂന്യമാണ്.

മോണിറ്റ് ഈ ഫയൽ വായിക്കുമ്പോൾ, അത് ഒന്നും കണ്ടെത്തുന്നില്ല. നിങ്ങളുടെ അപ്പാച്ചെ2 പശ്ചാത്തലത്തിൽ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ പോലും, അത് നിങ്ങളുടെ അപ്പാച്ചെ2 തിരിച്ചറിയുന്നില്ല; മോണിറ്റ് ഈ പ്രക്രിയ നിലവിലുണ്ടെന്ന് കരുതുന്നില്ല.

ഇത് കണ്ടപ്പോൾ ഒരു നിമിഷം എനിക്ക് ഒന്നും മിണ്ടിയില്ല.

ഇതൊരു ഡെഡ്‌ലോക്കാണ്. മോണിറ്റ് അപ്പാച്ചെ 2 ഇൻസ്റ്റൻസ് കണ്ടെത്തുന്നതിൽ പരാജയപ്പെടുന്നു, അപ്പാച്ചെ 2 പുനരാരംഭിക്കുന്നു, പുനരാരംഭിക്കുന്ന പ്രക്രിയയിൽ 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

ആദ്യം, നിങ്ങൾ കാര്യങ്ങൾ ശരിയാക്കുമ്പോൾ മോണിറ്റ് ഇടപെടുന്നത് തടയാൻ മോണിറ്റ് മോണിറ്ററിംഗ് താൽക്കാലികമായി നിർത്തുക. തുടർന്ന്, ഒരു വൃത്തിയുള്ള PID മാറ്റിയെഴുതാൻ അനുവദിക്കുന്നതിന് Apache2 പുനരാരംഭിക്കുക. അവസാനമായി, ഫയലിന്റെ ഉള്ളടക്കം പരിശോധിക്കാൻ `cat` ഉപയോഗിക്കുക; അതിൽ ശൂന്യമായ ഒരു സ്ട്രിംഗ് അല്ല, അക്കങ്ങളുടെ ഒരു സ്ട്രിംഗ് അടങ്ങിയിരിക്കണം.

ഈ ഘട്ടം പൂർത്തിയായിക്കഴിഞ്ഞാൽ, പ്രശ്നം അടിസ്ഥാനപരമായി പരിഹരിക്കപ്പെടും.

മോണിറ്റ് ട്രഡീഷണൽ അഡാപ്റ്റീവ്, അഗ്രസീവ് പ്രൊട്ടക്റ്റീവ് കോൺഫിഗറേഷനുകളുടെ താരതമ്യ വിശകലനം

മോണിറ്റിനൊപ്പം Apache2 കോൺഫിഗർ ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ഓൺലൈൻ ട്യൂട്ടോറിയലുകൾ സാധാരണയായി രണ്ട് വിഭാഗങ്ങളിലാണ് വരുന്നത്.

ഒരു തരം "പരമ്പരാഗത അഡാപ്റ്റേഷൻ തരം" ആണ്, ഇത് സേവനങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനും വളരെയധികം സങ്കീർണ്ണമായ നിയന്ത്രണങ്ങൾ ചേർക്കാതെ ലോക്കൽ പോർട്ടുകൾ പരിശോധിക്കുന്നതിനും `service` കമാൻഡ് ഉപയോഗിക്കുന്നു. പോർട്ട് മാറ്റുന്നതിലൂടെ ഈ കോൺഫിഗറേഷൻ HestiaCP-യിൽ ഉപയോഗിക്കാൻ കഴിയും, കൂടാതെ ഇത് താരതമ്യേന സ്ഥിരതയുള്ളതുമാണ്.

മറ്റൊരു സമീപനം "അഗ്രസീവ് പ്രൊട്ടക്ഷൻ" രീതിയാണ്, ഇത് സേവനങ്ങൾ കൈകാര്യം ചെയ്യാൻ systemctl ഉപയോഗിക്കുന്നു, ചൈൽഡ് പ്രോസസ്സ് നിയന്ത്രണങ്ങൾ ചേർക്കുന്നു, കൂടാതെ കർശനമായ കണ്ടെത്തൽ ലോജിക്കും ഉപയോഗിക്കുന്നു. ഇത് മികച്ചതായി കാണപ്പെടുന്നു, പക്ഷേ ഇതിന് ഒരു മാരകമായ പോരായ്മയുണ്ട്: ഉപയോഗിച്ചിരിക്കുന്ന സ്റ്റോപ്പ് കമാൻഡ് `killall -9` ആണ്.

`killall -9` എന്നതിന്റെ അർത്ഥമെന്താണ്? ഉപകരണം എന്തുതന്നെ ചെയ്താലും അത് ബലമായി ഇല്ലാതാക്കുക എന്നാണ് ഇതിനർത്ഥം. ഈ ക്രൂരമായ പ്രവർത്തനം എളുപ്പത്തിൽ കേടായ PID ഫയലുകൾ അവശേഷിപ്പിക്കും, അതാണ് ഞാൻ ഇപ്പോൾ സൂചിപ്പിച്ച പ്രശ്നം.

എന്റെ വ്യക്തിപരമായ അനുഭവം, ഒരു ആക്രമണാത്മക കോൺഫിഗറേഷനിൽ ചൈൽഡ് പ്രോസസ്സുകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നത് തീർച്ചയായും ഉപയോഗപ്രദമാണ് എന്നതാണ്. നിങ്ങളുടെ Apache2 ഒരു CC ആക്രമണത്താൽ വലയം ചെയ്യപ്പെടുമ്പോൾ, ചൈൽഡ് പ്രോസസ്സുകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നത് സെർവറിന്റെ മെമ്മറി തീർന്നുപോകുന്നത് തടയാൻ കഴിയും. എന്നിരുന്നാലും, `killall -9` സമീപനം യഥാർത്ഥത്തിൽ ഉപയോഗശൂന്യമാണ്.

അങ്ങനെ അവസാനം ഞാൻ വിട്ടുവീഴ്ച ചെയ്യുകയും രണ്ട് കോൺഫിഗറേഷനുകളുടെയും ഗുണങ്ങൾ സംയോജിപ്പിക്കുകയും ചെയ്തു.

ഹെസ്റ്റിയസിപി അപ്പാച്ചെ2 മോണിറ്റ് ബെസ്റ്റ് പ്രാക്ടീസ് കോൺഫിഗറേഷൻ

താഴെ പറയുന്ന ഉള്ളടക്കം ഉപയോഗിച്ച് /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` കമാൻഡ് ഉപയോഗിക്കുക.

ഒരു ചൈൽഡ് പ്രോസസ് പരിധി ചേർത്തിട്ടുണ്ട്: കുട്ടികളുടെ എണ്ണം 120 കവിയുന്നുവെങ്കിൽ, CC ആക്രമണങ്ങൾ തടയുന്നതിന് തുടർച്ചയായ രണ്ട് സൈക്കിളുകൾക്ക് ശേഷം പ്രക്രിയ പുനരാരംഭിക്കും, പക്ഷേ ഇത് വളരെ ആക്രമണാത്മകമല്ല.

പരാജയങ്ങൾ കണ്ടെത്തുന്നതിനുള്ള യുക്തി "രണ്ട് സൈക്കിളുകൾക്ക്" എന്ന സമീപനം ഉപയോഗിക്കുന്നതിനായി പരിഷ്കരിച്ചിരിക്കുന്നു, അതായത് തുടർച്ചയായ രണ്ട് പരാജയങ്ങൾക്ക് ശേഷം മാത്രമേ പുനരാരംഭിക്കുകയുള്ളൂ, ഇത് തെറ്റായ പോസിറ്റീവുകൾ കുറയ്ക്കുന്നു. ഒരു കണ്ടെത്തലിന് ശേഷം പുനരാരംഭിച്ച മുൻ കോൺഫിഗറേഷൻ, തുറന്നുപറയുമ്പോൾ അൽപ്പം അമിതമായി സെൻസിറ്റീവ് ആയിരുന്നു.

അവസാന സമയപരിധി 10 സൈക്കിളുകൾക്കുള്ളിൽ 5 പുനരാരംഭങ്ങളായി ഇളവ് ചെയ്‌തിരിക്കുന്നു, ഇത് മതിയായ തെറ്റ് സഹിഷ്ണുത നിലനിർത്തുന്നു.

ഹെസ്റ്റിയസിപി നിരീക്ഷണം നിരീക്ഷിക്കുകകോൺഫിഗറേഷൻ ട്രബിൾഷൂട്ടിംഗ് സംഗ്രഹവും അനുഭവ പങ്കിടലും

കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ വരുത്തിയ ശേഷം, ഞാൻ apache2 നിരീക്ഷിച്ചു, പാനൽ ഒടുവിൽ ഒരു പച്ച "ശരി" സൂചകം കാണിച്ചു.

ആ സമയത്തെ എന്റെ വികാരങ്ങൾ എങ്ങനെ വിവരിക്കും? രണ്ട് ദിവസം ഒരു പ്രാണിയുമായി മല്ലിടുന്നത് പോലെയായിരുന്നു അത്, പക്ഷേ ഒരു വരിയിലെ കോൺഫിഗറേഷൻ തെറ്റാണെന്ന് കണ്ടെത്തിയപ്പോൾ അത് നിരാശാജനകവും ചിരിക്കാവുന്നതുമായിരുന്നു.

മോണിറ്റ് തന്നെ ഒരു നല്ല കാര്യമാണ്, ഡെമണുകളെ നിരീക്ഷിക്കുന്നത് എല്ലാ സെർവറുകളും ചെയ്യേണ്ട ഒന്നാണ്. എന്നാൽ പ്രശ്നം എന്തെന്നാൽ, പല ഓൺലൈൻ ട്യൂട്ടോറിയലുകളും "Apache2 പോർട്ട് 80 മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ" എന്ന അനുമാനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, അതേസമയം HestiaCP ഒരു റിവേഴ്സ് പ്രോക്സി ഉപയോഗിക്കുന്നു, അതായത് ഈ അനുമാനം ശരിയല്ല.

നിങ്ങൾ നിർദ്ദേശങ്ങൾ പാലിക്കുകയാണെങ്കിൽ, പ്രശ്നം നിങ്ങളുടേതല്ല; ട്യൂട്ടോറിയൽ നിങ്ങളുടേതിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു സാഹചര്യത്തിൽ ബാധകമാണ് എന്നതാണ്.

അതിനാൽ നിങ്ങൾ HestiaCP ഉപയോഗിക്കുകയും Apache2 നിരീക്ഷിക്കാൻ Monit-മായി ഇടപഴകുകയും ചെയ്യുന്നുവെങ്കിൽ, രണ്ട് കാര്യങ്ങൾ ഓർമ്മിക്കുക: പോർട്ട് 8081 ലേക്ക് മാറ്റുക, അത് നിർത്താൻ `killall -9` എന്നതിന് പകരം `systemctl` കമാൻഡ് ഉപയോഗിക്കുക. ഈ രണ്ട് കാര്യങ്ങളും ചെയ്താൽ, നിങ്ങൾക്ക് കൂടുതൽ പ്രശ്നങ്ങൾ ഒഴിവാക്കാൻ കഴിയും.

ഇത്രയും ദൂരം വായിച്ചതിനാൽ, ഇത് സഹായകരമാണെന്ന് തോന്നിയാൽ ദയവായി ലൈക്ക് ചെയ്യുകയും ഷെയർ ചെയ്യുകയും ചെയ്യുക. ആദ്യം അപ്‌ഡേറ്റുകൾ ലഭിക്കണമെങ്കിൽ, നിങ്ങൾക്ക് എന്നെ പിന്തുടരാനും കഴിയും!

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