HestiaCP के साथ Apache2 बार-बार क्रैश हो रहा है? Monit स्वचालित निगरानी और समस्या निवारण मार्गदर्शिका (संपूर्ण कॉन्फ़िगरेशन सहित)

क्या आप HestiaCP वातावरण में Apache2 के बार-बार क्रैश होने या Monit के ऑटो-रीस्टार्ट में विफलता का सामना कर रहे हैं? यह लेख Monit के साथ Apache2 की निगरानी करते समय आने वाली आम समस्याओं से बचने के लिए एक व्यावहारिक मार्गदर्शिका प्रदान करता है, जिसमें PID पाथ मिसअलाइनमेंट और परमिशन ब्लॉकिंग जैसी सामान्य समस्याओं का गहन विश्लेषण किया गया है, और उत्पादन-स्तरीय Monit ऑटोमेशन कॉन्फ़िगरेशन फ़ाइलें भी दी गई हैं। उच्च उपलब्धता वाले सर्वर रखरखाव तकनीकों में महारत हासिल करें और विफलताओं से द्वितीय-स्तरीय स्वचालित रिकवरी प्राप्त करें!

Apache2 की निगरानी के लिए Monit का उपयोग करते समय मुझे जिन समस्याओं का सामना करना पड़ा

पिछले शुक्रवार को, सर्वर ने मुझे आधी रात में मॉनिट अलर्ट दिया।

मैंने स्तब्धता में पैनल पर एक नजर डाली, और apache2 स्टेटस कॉलम में लाल रंग का टाइमआउट लिखा हुआ था।

मैंने थोड़ी देर सोचा। मैंने अभी दिन के दौरान सर्वर पर मॉनिट मॉनिटरिंग जोड़ी है, और मैंने ऑनलाइन ट्यूटोरियल से कॉन्फ़िगरेशन को कॉपी और पेस्ट किया है। कोई समस्या नहीं होनी चाहिए, है ना?

अगली सुबह, यह फिर से टाइम आउट हो गया। तीसरी बार के बाद, मॉनिटर ने काम करना बंद कर दिया, और डैशबोर्ड पर "निगरानी नहीं की जा रही" प्रदर्शित हुआ।

मैं...

मैं मानता हूँ, मैंने शुरू में इसे गंभीरता से नहीं लिया। अपाचे2 मॉनिटरिंग? आपको ऑनलाइन ढेरों टेम्पलेट कॉन्फ़िगरेशन मिल जाएँगे, बस कॉपी और पेस्ट कर दीजिए। लेकिन उस पेस्ट करने की प्रक्रिया ने मुझे सच में बहुत गुस्सा दिलाया।

हेस्टियासीपी के डिफ़ॉल्ट आर्किटेक्चर और मॉनिट पोर्ट्स के बीच संघर्ष का मूल कारण

सबसे पहले मैं आपको वह कॉन्फ़िगरेशन दिखा देता हूँ जिसकी वजह से मुझे इतनी परेशानी हुई, ताकि आप देख सकें कि क्या यह बिल्कुल उसी संस्करण जैसा है जो आपने देखा है।

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 पर चल ही नहीं रहा है।

यह हेस्टियासीपी की एक खामी है, और कई लोगों के इसके जाल में फंसने का मूल कारण है। हेस्टियासीपी का डिफ़ॉल्ट आर्किटेक्चर Nginx + Apache2 का रिवर्स प्रॉक्सी है, जिसमें Nginx सामने पोर्ट 80 और 443 का उपयोग करता है, और Apache2 पीछे स्थानीय पोर्ट 8081 पर चलता है।

अगर आप Monit से पोर्ट 80 पर Apache2 की सक्रियता की जांच करने को कहें, तो यह McDonald's में KFC ढूंढने जैसा है। सर्वर आपको खाली निगाहों से देखता है, और आप दोनों एक-दूसरे को घूरते रहते हैं। अंत में, Monit यह निष्कर्ष निकालता है कि आपका सर्वर बंद है और तेजी से रीस्टार्ट करना शुरू कर देता है।

रीस्टार्ट करने के बाद भी पोर्ट 8081 ही रहता है। फिर मॉनिट पोर्ट 80 को चेक करने की कोशिश करता है, जो असफल हो जाता है, इसलिए यह दोबारा रीस्टार्ट हो जाता है। यह चक्र तब तक चलता रहता है जब तक मॉनिट यह तय नहीं कर लेता कि अब इसे ठीक नहीं किया जा सकता और टाइम आउट हो जाता है।

जब मैंने पहली बार इसका सामना किया, तो मैं सचमुच हैरान रह गया। ऑनलाइन मिले दस में से नौ ट्यूटोरियल में पोर्ट 80 का इस्तेमाल किया गया था। अगर आपने उनका अनुसरण किया, तो समस्या आपमें नहीं, बल्कि जानकारी के स्रोत में ही थी।

एक दूषित Apache2 PID फ़ाइल के कारण Monit ने गलती से प्रक्रिया को अस्तित्वहीन मान लिया।

पोर्ट को 80 से 8081 में बदलने के बाद, मॉनिट को सैद्धांतिक रूप से इसे पहचानने में सक्षम होना चाहिए, है ना?

हालांकि, वास्तविकता में, यह अभी भी कभी-कभी "निष्पादन विफल " की रिपोर्ट करता है।

काफी संघर्ष के बाद, आखिरकार मुझे पता चला कि इसका कारण बहुत सरल था: पीआईडी ​​फाइल दूषित हो गई थी।

ज़रा सोचिए, मॉनिट लगातार अपाचे2 को रीस्टार्ट कर रहा था, हर बार उसे ज़बरदस्ती बंद करके फिर से चालू कर रहा था, और यह प्रक्रिया कई बार दोहराई जा रही थी। इस दौरान, /var/run/apache2/apache2.pid फ़ाइल का आकार 0 बाइट्स तक गिर सकता था।

दूसरे शब्दों में कहें तो, फाइल अभी भी मौजूद है, लेकिन वह खाली है।

जब मॉनिट इस फ़ाइल को पढ़ता है, तो उसे कुछ नहीं मिलता। यह आपके Apache2 को पहचान नहीं पाता, भले ही आपका Apache2 बैकग्राउंड में पूरी तरह से ठीक से चल रहा हो; मॉनिट को लगता है कि यह प्रोसेस मौजूद ही नहीं है।

जब मैंने यह देखा, तो मैं एक पल के लिए अवाक रह गया।

यह एक गतिरोध है। मॉनिट अपाचे 2 इंस्टेंस का पता लगाने में विफल रहता है, अपाचे 2 को पुनः आरंभ करता है, पुनः आरंभ प्रक्रिया के दौरान पीआईडी ​​फ़ाइल को दूषित कर देता है, अगली बार पता लगाने में विफल रहता है, और फिर से पुनः आरंभ करता है। यह चक्र तब तक चलता रहता है जब तक कि टाइमआउट नहीं हो जाता।

हेस्टियासीपी वातावरण में अपाचे2 मॉनिटरिंग के लिए समस्या निवारण और मरम्मत के चरण

सच कहें तो, जांच प्रक्रिया जटिल नहीं है, लेकिन आपको यह जानना होगा कि किस दिशा में जांच करनी है।

पहला चरण यह निर्धारित करना है कि आपका 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

यह पुष्टि हो चुकी है कि यह 8081 है, 80 नहीं। यही समस्या की जड़ है।

दूसरा चरण दूषित पीआईडी ​​फाइल की मरम्मत करना है। यह सरल है।

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

सबसे पहले, Monit मॉनिटरिंग को रोकें ताकि समस्या ठीक करते समय यह आपके काम में बाधा न डाले। फिर, Apache2 को रीस्टार्ट करें ताकि यह एक नया PID लिख सके। अंत में, फ़ाइल की सामग्री की जाँच करने के लिए `cat` कमांड का उपयोग करें; इसमें संख्याओं की एक स्ट्रिंग होनी चाहिए, खाली स्ट्रिंग नहीं।

एक बार यह चरण पूरा हो जाने पर, समस्या का मूल रूप से समाधान हो जाता है।

मॉनिट की पारंपरिक अनुकूली और आक्रामक सुरक्षात्मक संरचनाओं का तुलनात्मक विश्लेषण

Monit के साथ Apache2 को कॉन्फ़िगर करने पर ऑनलाइन ट्यूटोरियल आम तौर पर दो श्रेणियों में आते हैं।

एक प्रकार "पारंपरिक अनुकूलन प्रकार" है, जो जटिल प्रतिबंधों को जोड़े बिना सेवाओं को प्रबंधित करने और स्थानीय पोर्ट की जांच करने के लिए `service` कमांड का उपयोग करता है। इस कॉन्फ़िगरेशन को पोर्ट बदलकर आसानी से हेस्टियासीपी पर उपयोग किया जा सकता है, और यह अपेक्षाकृत स्थिर है।

एक अन्य तरीका "आक्रामक सुरक्षा" विधि है, जो सेवाओं को प्रबंधित करने के लिए 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

आइए, इन कुछ पंक्तियों के पीछे के तर्क को संक्षेप में समझाते हैं।

पोर्ट 8081 को ठीक उसी तरह लिखें जैसे हेस्टियासीपी का रिवर्स प्रॉक्सी आर्किटेक्चर है; पोर्ट 80 को मूर्खतापूर्ण तरीके से लिखना बंद करें।

पीआईडी ​​फाइल को रोकने के लिए `killall -9` कमांड के बजाय `systemctl stop` कमांड का उपयोग करें, ताकि यह दूषित न हो।

चाइल्ड प्रोसेस की एक सीमा निर्धारित की गई है: यदि बच्चों की संख्या 120 से अधिक हो जाती है, तो CC हमलों को रोकने के लिए प्रक्रिया लगातार दो चक्रों के बाद पुनः आरंभ हो जाएगी, लेकिन यह बहुत आक्रामक नहीं है।

विफलताओं का पता लगाने के लिए इस्तेमाल होने वाले तर्क को संशोधित करके "2 चक्रों के लिए" दृष्टिकोण अपनाया गया है, जिसका अर्थ है कि रीस्टार्ट केवल लगातार दो विफलताओं के बाद ही शुरू होता है, जिससे गलत पहचान की संभावना कम हो जाती है। पिछला कॉन्फ़िगरेशन, जो केवल एक बार विफलता का पता चलने पर ही रीस्टार्ट हो जाता था, वास्तव में थोड़ा ज़्यादा ही संवेदनशील था।

अंतिम टाइमआउट सीमा को 10 चक्रों के भीतर 5 रीस्टार्ट तक कम कर दिया गया है, जिससे पर्याप्त त्रुटि सहनशीलता बनी रहती है।

हेस्टियासीपी निगरानी निगरानीकॉन्फ़िगरेशन संबंधी समस्याओं के निवारण का सारांश और अनुभव साझा करना

कॉन्फ़िगरेशन में बदलाव करने के बाद, मैंने apache2 की निगरानी की, और पैनल पर अंततः एक हरा "ओके" संकेतक दिखाई दिया।

उस समय मेरी भावनाओं को मैं कैसे व्यक्त करूँ? ऐसा लग रहा था जैसे दो दिन किसी बग को ठीक करने में बिताने के बाद पता चला कि उसकी वजह कॉन्फ़िगरेशन की एक ही गलत लाइन थी। यह निराशाजनक और हास्यास्पद दोनों था।

मॉनिट अपने आप में एक अच्छी चीज़ है, और डेमन्स की निगरानी करना हर सर्वर का कर्तव्य है। लेकिन समस्या यह है कि कई ऑनलाइन ट्यूटोरियल इस धारणा पर आधारित हैं कि "Apache2 केवल पोर्ट 80 का उपयोग करता है," जबकि HestiaCP एक रिवर्स प्रॉक्सी का उपयोग करता है, जिसका अर्थ है कि यह धारणा सही नहीं है।

यदि आप निर्देशों का पालन करते हैं, तो समस्या आपमें नहीं है; बल्कि यह है कि ट्यूटोरियल आपके मामले से भिन्न स्थिति के लिए लागू होता है।

तो अगर आप भी HestiaCP का इस्तेमाल कर रहे हैं और Apache2 को मॉनिटर करने के लिए Monit के साथ कुछ प्रयोग कर रहे हैं, तो बस दो बातें याद रखें: पोर्ट को 8081 पर सेट करें और इसे रोकने के लिए `systemctl` कमांड का इस्तेमाल करें, न कि `killall -9` का। अगर आप ये दो काम कर लेते हैं, तो आपको आगे कोई समस्या नहीं आएगी।

आपने यहाँ तक पढ़ लिया है, अगर आपको यह उपयोगी लगा हो तो कृपया इसे लाइक और शेयर करें। अगर आप सबसे पहले अपडेट पाना चाहते हैं तो मुझे फॉलो भी कर सकते हैं!

मेरा लेख पढ़ने के लिए धन्यवाद। फिर मिलेंगे।