HestiaCP सह Apache2 वारंवार क्रॅश होत आहे का? Monit स्वयंचलित मॉनिटरिंग आणि समस्यानिवारण मार्गदर्शिका (संपूर्ण कॉन्फिगरेशनसह)

HestiaCP एनवायरनमेंटमध्ये Apache2 वारंवार क्रॅश होत आहे किंवा Monit ऑटो-रीस्टार्ट अयशस्वी होत आहे का? हा लेख Monit वापरून Apache2 चे मॉनिटरिंग करताना येणाऱ्या सामान्य चुका टाळण्यासाठी एक व्यावहारिक मार्गदर्शन करतो, PID पाथ मिसअलाइनमेंट आणि परमिशन ब्लॉकिंग यांसारख्या सामान्य समस्यांचे सखोल विश्लेषण करतो आणि प्रोडक्शन-ग्रेड Monit ऑटोमेशन कॉन्फिगरेशन फाइल्स सादर करतो. आताच हाय-अव्हेलेबिलिटी सर्व्हर मेंटेनन्स तंत्रात प्राविण्य मिळवा आणि अयशस्वी झाल्यास दुसऱ्या स्तरावरील स्वयंचलित रिकव्हरी मिळवा!

Apache2 चे निरीक्षण करण्यासाठी Monit वापरताना मला आलेल्या अडचणी

गेल्या शुक्रवारी, सर्वरने मला मध्यरात्री एक मॉनिट अलर्ट दिला.

मी भांबावलेल्या अवस्थेत पॅनलकडे नजर टाकली, आणि 'apache2 status' कॉलममध्ये लाल रंगाचा 'Timeout' दिसत होता.

मी थोडा वेळ विचार केला. मी दिवसा सर्वरवर मॉनिट मॉनिटरिंग सुरू केलं आहे आणि एका ऑनलाइन ट्युटोरियलमधून कॉन्फिगरेशन कॉपी-पेस्ट केलं आहे. काही अडचण यायला नको, बरोबर ना?

दुसऱ्या दिवशी सकाळी, ते पुन्हा टाइम आउट झाले. तिसऱ्यांदा असे झाल्यावर, मॉनिटरने काम करणे सोडून दिले आणि पॅनलवर "निरीक्षण केले जात नाही" असे दिसू लागले.

मी...

मी कबूल करतो, सुरुवातीला मी ते गांभीर्याने घेतले नाही. अपाचे२ मॉनिटरिंग? तुम्हाला ऑनलाइन असंख्य टेम्पलेट कॉन्फिगरेशन्स मिळतील, फक्त कॉपी-पेस्ट करायचे. पण त्या पेस्ट करण्याच्या प्रक्रियेमुळे मला खरंच प्रचंड राग आला होता.

HestiaCP च्या डीफॉल्ट आर्किटेक्चर आणि Monit पोर्ट्समधील संघर्षाचे मूळ कारण

ज्या कॉन्फिगरेशनमुळे मला खूप त्रास झाला, ते मी तुम्हाला आधी दाखवतो, म्हणजे तुम्ही पाहिलेल्या आवृत्तीशी ते तंतोतंत जुळते की नाही हे तुम्हाला पाहता येईल.

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

हे ठीक वाटतंय, बरोबर? ते पोर्ट ८० तपासते आणि क्रॅश झाल्यास, पुन्हा सुरू होते. ५ वेळा पुन्हा सुरू करूनही क्रॅश झाल्यास, टाइम आउट होतो.

समस्या अशी आहे की, तुमचा Apache2 पोर्ट 80 वर चालूच नाहीये.

ही HestiaCP ची एक अडचण आहे, आणि अनेक लोक त्यात अडकण्याचे हेच मूळ कारण आहे. HestiaCP चे डीफॉल्ट आर्किटेक्चर हे Nginx + Apache2 चे रिव्हर्स प्रॉक्सी आहे, ज्यामध्ये Nginx समोर पोर्ट 80 आणि 443 वापरतो, आणि Apache2 मागे स्थानिक पोर्ट 8081 वर चालतो.

जर तुम्ही मॉनिटला पोर्ट ८० वर अपाचे२ (Apache2) चालू आहे की नाही हे तपासायला सांगितले, तर ते मॅकडोनाल्डमध्ये जाऊन केएफसी (KFC) शोधण्यासारखे आहे. सर्व्हर तुमच्याकडे रिकाम्या नजरेने पाहतो आणि तुम्ही दोघे एकमेकांकडे बघत राहता. शेवटी, मॉनिटला कळते की सर्व्हर बंद आहे आणि तो वेगाने पुन्हा सुरू करू लागतो.

पुन्हा सुरू केल्यानंतर, पोर्ट ८०८१ च राहतो. मग मॉनिट पोर्ट ८० तपासण्याचा प्रयत्न करतो, जो देखील अयशस्वी होतो, त्यामुळे ते पुन्हा सुरू होते. जोपर्यंत मॉनिटला हे दुरुस्त करण्यापलीकडे आहे असे वाटत नाही आणि तो टाइम आउट होत नाही, तोपर्यंत हे चक्र पुन्हा पुन्हा चालू राहते.

जेव्हा मला हे पहिल्यांदा आढळले, तेव्हा मी खरोखरच थक्क झालो. मला ऑनलाइन सापडलेल्या दहापैकी नऊ ट्यूटोरियल्समध्ये पोर्ट ८० चा वापर केला होता. जर तुम्ही त्यांचे अनुसरण केले असेल, तर समस्या तुमच्यात नव्हती, तर माहितीच्या स्रोतामध्येच होती.

एका दूषित Apache2 PID फाईलमुळे Monit ने चुकून त्या प्रक्रियेला अस्तित्वात नाही असे ओळखले.

पोर्ट 80 वरून 8081 वर बदलल्यानंतर, मॉनिटने सैद्धांतिकदृष्ट्या ते शोधले पाहिजे, बरोबर?

मात्र, प्रत्यक्षात, ते अजूनही अधूनमधून "अंमलबजावणी अयशस्वी झाली " असा अहवाल देते.

बराच वेळ धडपडल्यानंतर, मला शेवटी कारण सापडले: PID फाईल खराब झाली होती.

विचार करा, मॉनिट वेड्यासारखा अपाचे२ (Apache2) पुन्हा सुरू करत होता, प्रत्येक वेळी त्याला जबरदस्तीने बंद करून पुन्हा सुरू करत होता, अशी अनेक वेळा मागे-पुढे क्रिया करत होता. या प्रक्रियेदरम्यान, /var/run/apache2/apache2.pid या फाईलचा आकार ० बाईट्सचा झाला असेल.

दुसऱ्या शब्दांत सांगायचे तर, फाईल अजूनही तिथेच आहे, पण ती रिकामी आहे.

जेव्हा मॉनिट ही फाईल वाचतो, तेव्हा त्याला काहीही सापडत नाही. तुमचा Apache2 बॅकग्राउंडमध्ये अगदी व्यवस्थित चालू असला तरी, तो त्याला ओळखत नाही; मॉनिटला वाटते की ती प्रोसेस अस्तित्वात नाही.

जेव्हा मी हे पाहिले, तेव्हा मी क्षणभर निःशब्द झालो.

ही एक डेडलॉकची स्थिती आहे. मॉनिटला अपाचे २ इन्स्टन्स सापडत नाही, ते अपाचे २ रीस्टार्ट करते, रीस्टार्ट प्रक्रियेदरम्यान पीआयडी फाईल खराब करते, पुढील डिटेक्शन अयशस्वी होते आणि पुन्हा रीस्टार्ट होते. जोपर्यंत टाइमआउट होत नाही तोपर्यंत हे चक्र सुरू राहते.

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

सर्वप्रथम, तुम्ही काम करत असताना व्यत्यय येऊ नये म्हणून मॉनिट मॉनिटरिंग थांबवा. त्यानंतर, एक नवीन PID पुन्हा लिहिण्यासाठी Apache2 रीस्टार्ट करा. शेवटी, फाईलची सामग्री तपासण्यासाठी `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 हल्ले टाळण्यासाठी प्रोसेस दोन सलग सायकलनंतर पुन्हा सुरू होईल, पण ही मर्यादा फार कठोर नाही.

अपयश ओळखण्याच्या तर्कप्रणालीत बदल करून '२ चक्रांसाठी' (for 2 cycles) पद्धतीचा वापर करण्यात आला आहे. याचा अर्थ, सलग दोन अपयशानंतरच पुनरारंभ (restart) होतो, ज्यामुळे चुकीचे सकारात्मक निष्कर्ष (false positives) कमी होतात. पूर्वीची रचना, ज्यात केवळ एकदा अपयश आढळल्यावर पुनरारंभ होत असे, ती खरे पाहता थोडी जास्तच संवेदनशील होती.

अंतिम टाइमआउट मर्यादा १० सायकलमध्ये ५ रीस्टार्टपर्यंत शिथिल करण्यात आली आहे, ज्यामुळे पुरेशी फॉल्ट टॉलरन्स शिल्लक राहते.

HestiaCP निरीक्षण निरीक्षणकॉन्फिगरेशन समस्यानिवारण सारांश आणि अनुभव सामायिकरण

कॉन्फिगरेशनमध्ये बदल केल्यानंतर, मी apache2 चे निरीक्षण केले आणि शेवटी पॅनलवर हिरवा "OK" इंडिकेटर दिसला.

त्यावेळच्या माझ्या भावना कशा सांगाव्यात? जणू काही दोन दिवस एका बगशी झगडल्यानंतर, शेवटी कळालं की त्याचं कारण कॉन्फिगरेशनची एक चुकीची ओळ होती. ते निराशाजनक आणि हास्यास्पद दोन्ही होतं.

मॉनिट (Monit) ही स्वतःच एक चांगली गोष्ट आहे, आणि प्रत्येक सर्व्हरने डेमन्सचे निरीक्षण केले पाहिजे. पण अडचण अशी आहे की, अनेक ऑनलाइन ट्युटोरियल्स 'Apache2 केवळ पोर्ट 80 वापरतो' या गृहितकावर आधारित आहेत, तर HestiaCP रिव्हर्स प्रॉक्सी वापरते, याचा अर्थ हे गृहितक खरे ठरत नाही.

जर तुम्ही सूचनांचे पालन केले, तर समस्या तुमच्यात नाही; समस्या ही आहे की हे ट्युटोरियल तुमच्या परिस्थितीपेक्षा वेगळ्या परिस्थितीसाठी लागू आहे.

त्यामुळे, जर तुम्ही सुद्धा HestiaCP वापरत असाल आणि Apache2 मॉनिटर करण्यासाठी Monit मध्ये काही बदल करत असाल, तर फक्त दोन गोष्टी लक्षात ठेवा: पोर्ट ८०८१ वर बदला, आणि ते थांबवण्यासाठी `killall -9` ऐवजी `systemctl` कमांड वापरा. ​​तुम्ही या दोन गोष्टी केल्यास, तुम्ही पुढील कोणत्याही समस्या टाळू शकाल.

तुम्ही इथपर्यंत वाचले आहे, आणि जर तुम्हाला हे उपयुक्त वाटले असेल, तर कृपया लाईक आणि शेअर करा. जर तुम्हाला सर्वात आधी अपडेट्स मिळवायचे असतील, तर तुम्ही मला फॉलो देखील करू शकता!

माझा लेख वाचल्याबद्दल धन्यवाद. पुढच्या वेळी भेटूया.