HestiaCP સાથે Apache2 વારંવાર ક્રેશ થાય છે? Monit ઓટોમેટેડ મોનિટરિંગ અને મુશ્કેલીનિવારણ માર્ગદર્શિકા (સંપૂર્ણ રૂપરેખાંકન સાથે)

HestiaCP વાતાવરણમાં વારંવાર Apache2 ક્રેશ થાય છે કે Monit ઓટો-રીસ્ટાર્ટ નિષ્ફળતાઓ થાય છે? આ લેખ Monit સાથે Apache2 નું નિરીક્ષણ કરતી વખતે સામાન્ય મુશ્કેલીઓ ટાળવા, PID પાથ મિસલાઈનમેન્ટ અને પરવાનગી બ્લોકિંગ જેવા સામાન્ય મુદ્દાઓનું ઊંડાણપૂર્વક વિશ્લેષણ કરવા અને ઉત્પાદન-ગ્રેડ Monit ઓટોમેશન રૂપરેખાંકન ફાઇલો ઓફર કરવા માટે વ્યવહારુ માર્ગદર્શિકા પ્રદાન કરે છે. હવે ઉચ્ચ-ઉપલબ્ધતા સર્વર જાળવણી તકનીકોમાં નિપુણતા મેળવો અને નિષ્ફળતાઓમાંથી બીજા-સ્તરની સ્વચાલિત પુનઃપ્રાપ્તિ પ્રાપ્ત કરો!

Apache2 ને મોનિટર કરવા માટે Monit નો ઉપયોગ કરતી વખતે મને જે મુશ્કેલીઓનો સામનો કરવો પડ્યો

ગયા શુક્રવારે, સર્વરે મને મધ્યરાત્રિએ મોનિટ એલર્ટ આપ્યું.

મેં સ્તબ્ધ થઈને પેનલ તરફ જોયું, અને 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 ફાઇલને કારણે Monit ભૂલથી પ્રક્રિયાને અસ્તિત્વમાં નથી તેમ ઓળખી શક્યું.

પોર્ટને 80 થી 8081 માં બદલ્યા પછી, મોનિટ સૈદ્ધાંતિક રીતે તેને શોધી શકશે, ખરું ને?

જોકે, વાસ્તવમાં, તે હજુ પણ ક્યારેક ક્યારેક "એક્ઝીક્યુશન નિષ્ફળ ગયું " નો અહેવાલ આપે છે.

લાંબા સમય સુધી સંઘર્ષ કર્યા પછી, મને આખરે કારણ સરળ લાગ્યું: PID ફાઇલ દૂષિત હતી.

જરા વિચારો, મોનિટ ઉન્માદથી Apache2 ને રીસ્ટાર્ટ કરી રહ્યો હતો, દરેક વખતે તેને બળજબરીથી મારીને રીસ્ટાર્ટ કરી રહ્યો હતો, ઘણી વખત આગળ પાછળ કરી રહ્યો હતો. આ પ્રક્રિયા દરમિયાન, /var/run/apache2/apache2.pid ફાઇલ 0 બાઇટ બની શકે છે.

બીજા શબ્દોમાં કહીએ તો, ફાઇલ હજુ પણ ત્યાં છે, પણ ખાલી છે.

જ્યારે મોનિટ આ ફાઇલ વાંચે છે, ત્યારે તેને કંઈ મળતું નથી. તે તમારા Apache2 ને ઓળખતું નથી, ભલે તમારું Apache2 પૃષ્ઠભૂમિમાં સંપૂર્ણપણે સારી રીતે ચાલી રહ્યું હોય; મોનિટને લાગતું નથી કે આ પ્રક્રિયા અસ્તિત્વમાં છે.

જ્યારે મેં આ જોયું, ત્યારે હું એક ક્ષણ માટે અવાચક થઈ ગયો.

આ એક ડેડલોક છે. મોનિટ અપાચે 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

તે ૮૦ નહીં, પણ ૮૦૮૧ હોવાની પુષ્ટિ થઈ છે. સમસ્યાનું મૂળ એ જ છે.

બીજું પગલું દૂષિત PID ફાઇલને સુધારવાનું છે. આ સરળ છે.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

સૌપ્રથમ, જ્યારે તમે વસ્તુઓ ઠીક કરી રહ્યા હોવ ત્યારે Monit મોનિટરિંગને અટકાવો જેથી તે દખલ ન કરે. પછી, Apache2 ને ફરીથી શરૂ કરો જેથી તે સ્વચ્છ PID ફરીથી લખી શકે. છેલ્લે, ફાઇલ સામગ્રી તપાસવા માટે `cat` નો ઉપયોગ કરો; તેમાં સંખ્યાઓની સ્ટ્રિંગ હોવી જોઈએ, ખાલી સ્ટ્રિંગ નહીં.

એકવાર આ પગલું પૂર્ણ થઈ જાય, પછી સમસ્યા મૂળભૂત રીતે ઉકેલાઈ જાય છે.

મોનિટ પરંપરાગત અનુકૂલનશીલ અને આક્રમક રક્ષણાત્મક રૂપરેખાંકનોનું તુલનાત્મક વિશ્લેષણ

Monit સાથે Apache2 ને ગોઠવવા માટેના ઓનલાઈન ટ્યુટોરિયલ્સ સામાન્ય રીતે બે શ્રેણીઓમાં આવે છે.

એક પ્રકાર "પરંપરાગત અનુકૂલન પ્રકાર" છે, જે સેવાઓનું સંચાલન કરવા અને સ્થાનિક પોર્ટ્સને તપાસવા માટે `service` આદેશનો ઉપયોગ કરે છે, જેમાં ઘણા બધા જટિલ નિયંત્રણો ઉમેર્યા વિના ઉપયોગ થાય છે. આ રૂપરેખાંકનનો ઉપયોગ HestiaCP પર ફક્ત પોર્ટ બદલીને કરી શકાય છે, અને તે પ્રમાણમાં સ્થિર છે.

બીજો અભિગમ "આક્રમક સુરક્ષા" પદ્ધતિ છે, જે સેવાઓનું સંચાલન કરવા માટે systemctl નો ઉપયોગ કરે છે, ચાઇલ્ડ પ્રક્રિયા પ્રતિબંધો ઉમેરે છે, અને કડક શોધ તર્કનો ઉપયોગ કરે છે. તે સરસ દેખાય છે, પરંતુ તેમાં એક ઘાતક ખામી છે: વપરાયેલ સ્ટોપ આદેશ `killall -9` છે.

`killall -9` નો અર્થ શું છે? તેનો અર્થ એ છે કે ઉપકરણ ગમે તે કરી રહ્યું હોય, તેને બળજબરીથી મારી નાખવું. આ બ્રુટ-ફોર્સ ઓપરેશન સરળતાથી દૂષિત PID ફાઇલોને પાછળ છોડી શકે છે, જે સમસ્યાનો મેં હમણાં જ ઉલ્લેખ કર્યો છે.

મારો અંગત અનુભવ એ છે કે આક્રમક રૂપરેખાંકનમાં ચાઇલ્ડ પ્રક્રિયાઓની સંખ્યા મર્યાદિત કરવી ખરેખર ઉપયોગી છે. જ્યારે તમારું Apache2 CC હુમલાથી ભરાઈ જાય છે, ત્યારે ચાઇલ્ડ પ્રક્રિયાઓની સંખ્યા મર્યાદિત કરવાથી સર્વરની મેમરી ખતમ થતી અટકાવી શકાય છે. જોકે, `killall -9` અભિગમ ખરેખર બિનઉપયોગી છે.

તેથી અંતે મેં સમાધાન કર્યું અને બંને રૂપરેખાંકનોના ફાયદાઓને ભેગા કર્યા.

HestiaCP Apache2 Monit શ્રેષ્ઠ પ્રેક્ટિસ રૂપરેખાંકન

નીચેની સામગ્રી સાથે /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` આદેશનો ઉપયોગ કરો, જેથી તે દૂષિત ન થાય.

બાળ પ્રક્રિયા મર્યાદા ઉમેરવામાં આવી છે: જો બાળકોની સંખ્યા ૧૨૦ થી વધુ થાય, તો CC હુમલાઓને રોકવા માટે પ્રક્રિયા સતત બે ચક્ર પછી ફરી શરૂ થશે, પરંતુ તે ખૂબ આક્રમક નથી.

નિષ્ફળતાઓ શોધવા માટેના તર્કને "2 ચક્ર માટે" અભિગમનો ઉપયોગ કરવા માટે સંશોધિત કરવામાં આવ્યો છે, જેનો અર્થ એ થાય કે સતત બે નિષ્ફળતાઓ પછી જ પુનઃપ્રારંભ શરૂ થાય છે, જે ખોટા હકારાત્મકતા ઘટાડે છે. પાછલી ગોઠવણી, જે ફક્ત એક શોધ પછી પુનઃપ્રારંભ થઈ હતી, તે સ્પષ્ટપણે થોડી વધુ પડતી સંવેદનશીલ હતી.

અંતિમ સમયસમાપ્તિ થ્રેશોલ્ડ 10 ચક્રમાં 5 પુનઃપ્રારંભ સુધી હળવો કરવામાં આવે છે, જેનાથી પૂરતી ફોલ્ટ સહિષ્ણુતા રહે છે.

હેસ્ટિયાસીપી મોનીટરીંગરૂપરેખાંકન મુશ્કેલીનિવારણ સારાંશ અને અનુભવ શેરિંગ

રૂપરેખાંકનમાં ફેરફાર કર્યા પછી, મેં apache2 નું નિરીક્ષણ કર્યું, અને પેનલે આખરે લીલો "OK" સૂચક બતાવ્યો.

તે સમયે મારી લાગણીઓનું વર્ણન કેવી રીતે કરવું? તે બે દિવસ એક જંતુ સાથે સંઘર્ષ કરવા જેવું હતું, પરંતુ કારણ શોધવા માટે ફક્ત એક જ વાક્ય ખોટું હતું. તે નિરાશાજનક અને હાસ્યાસ્પદ હતું.

મોનિટ પોતે જ એક સારી બાબત છે, અને ડિમનનું નિરીક્ષણ કરવું એ દરેક સર્વરે કરવું જોઈએ. પરંતુ સમસ્યા એ છે કે ઘણા ઓનલાઈન ટ્યુટોરિયલ્સ એવી ધારણા પર આધારિત છે કે "Apache2 ફક્ત પોર્ટ 80 નો ઉપયોગ કરે છે," જ્યારે HestiaCP રિવર્સ પ્રોક્સીનો ઉપયોગ કરે છે, જેનો અર્થ એ છે કે આ ધારણા સાચી નથી.

જો તમે સૂચનાઓનું પાલન કરો છો, તો સમસ્યા તમારી નથી; સમસ્યા એ છે કે આ ટ્યુટોરીયલ તમારા કરતાં અલગ પરિસ્થિતિને લાગુ પડે છે.

તો જો તમે પણ HestiaCP નો ઉપયોગ કરી રહ્યા છો અને Apache2 ને મોનિટર કરવા માટે Monit સાથે ગડબડ કરી રહ્યા છો, તો ફક્ત બે બાબતો યાદ રાખો: પોર્ટને 8081 માં બદલો, અને તેને રોકવા માટે `systemctl` આદેશનો ઉપયોગ કરો, `killall -9` નહીં. જો તમે આ બે બાબતો કરશો, તો તમે વધુ સમસ્યાઓ ટાળી શકશો.

તમે અત્યાર સુધી વાંચ્યું હોવાથી, જો તમને તે મદદરૂપ લાગ્યું, તો કૃપા કરીને તેને લાઈક અને શેર કરો. જો તમે પહેલા અપડેટ્સ મેળવવા માંગતા હો, તો તમે મને ફોલો પણ કરી શકો છો!

મારો લેખ વાંચવા બદલ આભાર. ફરી મળીશું.