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

यो ठीक देखिन्छ, हैन त? यसले पोर्ट ८० जाँच गर्छ, र यदि यो क्र्यास भयो भने, यो पुन: सुरु हुन्छ। यदि यो ५ पटक पुन: सुरु भएपछि पनि क्र्यास भयो भने, यसको समय समाप्त हुन्छ।

समस्या यो हो कि, तपाईंको Apache2 पोर्ट ८० मा पनि चलिरहेको छैन।

यो HestiaCP को एउटा पासो हो, र धेरै मानिसहरू यसमा फस्नुको मूल कारण हो। HestiaCP को पूर्वनिर्धारित वास्तुकला Nginx + Apache2 को रिभर्स प्रोक्सी हो, जसमा Nginx ले अगाडि पोर्ट ८० र ४४३ ओगटेको छ, र Apache2 पछाडि स्थानीय पोर्ट ८०८१ मा चलिरहेको छ।

यदि तपाईंले मोनिटलाई पोर्ट ८० मा Apache2 को जीवन्तता जाँच गर्न भन्नुभयो भने, यो KFC खोज्न म्याकडोनाल्डमा जानु जस्तै हो। सर्भरले तपाईंलाई शून्य नजरले हेर्छ, र तपाईंहरू दुई एकअर्कालाई हेर्नुहुन्छ। अन्तमा, मोनिटले तपाईं डाउन हुनुहुन्छ भनेर निर्धारण गर्छ र पागलपनले पुन: सुरु गर्न थाल्छ।

पुन: सुरु गरेपछि, पोर्ट अझै पनि ८०८१ नै छ। त्यसपछि मोनिटले पोर्ट ८० लाई जाँच गर्ने प्रयास गर्छ, जुन पनि असफल हुन्छ, त्यसैले यो फेरि पुन: सुरु हुन्छ। यो चक्र दोहोरिन्छ जबसम्म मोनिटले यो मर्मत भन्दा बाहिर छ र समय सकिएको छैन भनेर निर्णय गर्दैन।

जब मैले पहिलो पटक यो कुराको सामना गरें, म साँच्चै छक्क परें। दस मध्ये नौ ट्यूटोरियलहरू मैले अनलाइनमा पोर्ट ८० प्रयोग गरेको पाएँ। यदि तपाईंले तिनीहरूलाई पछ्याउनु भएको छ भने, समस्या तपाईंसँग होइन, तर जानकारीको स्रोतसँग नै थियो।

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

पोर्ट ८० बाट ८०८१ मा परिवर्तन गरेपछि, मोनिटले सैद्धान्तिक रूपमा यसलाई पत्ता लगाउन सक्षम हुनुपर्छ, हैन?

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

लामो समयसम्म संघर्ष गरेपछि, मैले अन्ततः कारण सरल थियो भनेर पत्ता लगाएँ: PID फाइल बिग्रिएको थियो।

सोच्नुहोस् त, मोनिटले हताश भएर Apache2 लाई रिस्टार्ट गरिरहेको थियो, प्रत्येक पटक जबरजस्ती मार्दै र रिस्टार्ट गर्दै, धेरै पटक अगाडि र पछाडि गर्दै। यस प्रक्रियाको क्रममा, /var/run/apache2/apache2.pid फाइल ० बाइट हुन सक्छ।

अर्को शब्दमा, फाइल अझै पनि त्यहाँ छ, तर यो खाली छ।

जब मोनिटले यो फाइल पढ्छ, यसले केहि पनि फेला पार्दैन। यसले तपाईंको Apache2 लाई पहिचान गर्दैन, यदि तपाईंको Apache2 पृष्ठभूमिमा पूर्ण रूपमा राम्रोसँग चलिरहेको छ भने पनि; मोनिटलाई प्रक्रिया अवस्थित छ जस्तो लाग्दैन।

यो देखेर, म एकछिनको लागि अवाक भएँ।

यो एउटा गतिरोध हो। Monit ले Apache 2 उदाहरण पत्ता लगाउन असफल हुन्छ, Apache2 पुन: सुरु गर्छ, पुन: सुरु प्रक्रियाको क्रममा 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 अनुगमनलाई रोक्नुहोस्। त्यसपछि, सफा 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 को रिभर्स प्रोक्सी आर्किटेक्चरसँग ठ्याक्कै मिलाउन पोर्ट ८०८१ लेख्नुहोस्; मूर्खतापूर्वक पोर्ट ८० लेख्न बन्द गर्नुहोस्।

PID फाइललाई भ्रष्ट नबनाओस् भनेर रोक्न `killall -9` को सट्टा `systemctl stop` आदेश प्रयोग गर्नुहोस्।

बच्चा प्रक्रिया सीमा थपिएको छ: यदि बच्चाहरूको संख्या १२० भन्दा बढी भयो भने, CC आक्रमणहरू रोक्नको लागि प्रक्रिया लगातार दुई चक्र पछि पुन: सुरु हुनेछ, तर यो धेरै आक्रामक छैन।

असफलता पत्ता लगाउने तर्कलाई "२ चक्रका लागि" दृष्टिकोण प्रयोग गर्न परिमार्जन गरिएको छ, जसको अर्थ लगातार दुई असफलता पछि मात्र पुन: सुरु हुन्छ, जसले गर्दा गलत सकारात्मकताहरू कम हुन्छन्। अघिल्लो कन्फिगरेसन, जुन केवल एक पत्ता लगाएपछि पुन: सुरु भयो, स्पष्ट रूपमा अलि बढी संवेदनशील थियो।

अन्तिम टाइमआउट थ्रेसहोल्डलाई १० चक्र भित्र ५ पटक पुन: सुरु गर्न खुकुलो पारिएको छ, जसले गर्दा पर्याप्त गल्ती सहनशीलता रहन्छ।

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

कन्फिगरेसन परिवर्तन गरेपछि, मैले apache2 निगरानी गरें, र प्यानलले अन्ततः हरियो "OK" सूचक देखायो।

त्यतिबेलाका मेरा भावनाहरू कसरी वर्णन गर्ने? यो दुई दिनसम्म बगसँग संघर्ष गर्नु जस्तै थियो, तर कारण पत्ता लगाउनको लागि एउटा मात्र कन्फिगरेसन गलत थियो। यो निराशाजनक र हाँसोलाग्दो दुवै थियो।

Monit आफैंमा राम्रो कुरा हो, र डेमनहरूको निगरानी गर्नु भनेको हरेक सर्भरले गर्नुपर्ने काम हो। तर समस्या यो हो कि धेरै अनलाइन ट्यूटोरियलहरू "Apache2 ले विशेष रूपमा पोर्ट 80 प्रयोग गर्दछ" भन्ने धारणामा आधारित छन्, जबकि HestiaCP ले रिभर्स प्रोक्सी प्रयोग गर्दछ, जसको अर्थ यो धारणा सत्य होइन।

यदि तपाईंले निर्देशनहरू पालना गर्नुभयो भने, समस्या तपाईं होइन; यो ट्यूटोरियल तपाईंको भन्दा फरक परिदृश्यमा लागू हुन्छ भन्ने हो।

त्यसैले यदि तपाईं पनि HestiaCP प्रयोग गर्दै हुनुहुन्छ र Apache2 निगरानी गर्न Monit सँग खेल्दै हुनुहुन्छ भने, केवल दुई कुराहरू याद राख्नुहोस्: पोर्टलाई 8081 मा परिवर्तन गर्नुहोस्, र यसलाई रोक्न `systemctl` आदेश प्रयोग गर्नुहोस्, `killall -9` होइन। यदि तपाईंले यी दुई कुराहरू गर्नुभयो भने, तपाईं थप समस्याहरूबाट बच्न सक्षम हुनुहुनेछ।

तपाईंले यहाँसम्म पढिसक्नुभएको हुनाले, यदि तपाईंलाई यो उपयोगी लाग्यो भने, कृपया यसलाई लाइक र सेयर गर्नुहोस्। यदि तपाईं पहिले अपडेटहरू प्राप्त गर्न चाहनुहुन्छ भने, तपाईं मलाई फलो पनि गर्न सक्नुहुन्छ!

मेरो लेख पढ्नुभएकोमा धन्यवाद। अर्को पटक भेटौँला।