मोनिट वेबसाइट के गतिशील पृष्ठों की निगरानी करता है और पता लगाता है कि स्थिति कोड 200 नहीं है, और स्वचालित रूप से php8.3-fpm को पुनरारंभ करता है

🚀 जब किसी वेबसाइट पर एक डायनामिक पेज में अचानक नॉन-200 स्टेटस कोड होता है, तो PHP8.3-FPM सेकंड में स्वयं को कैसे ठीक कर सकता है?​​

​​🔥 PHP90-FPM जीवन रक्षक कॉन्फ़िगरेशन जिसे 8.3% ऑपरेटर नहीं जानते हैं! मोनिट डायनेमिक पेज सेल्फ हीलिंग सिस्टम का व्यावहारिक शिक्षण।

क्या आपको लगता है कि PHP-FPM प्रक्रिया की उत्तरजीविता की निगरानी पर्याप्त है? बिलकुल ग़लत!
जब किसी सर्वर पर PHP-FPM अचानक गड़बड़ा जाता है, तो केवल प्रक्रिया की उत्तरजीविता को देखना कैंसर को मापने के लिए थर्मामीटर का उपयोग करने जैसा है - यह घातक समस्या को बिल्कुल भी नहीं पकड़ता है।

मैंने बहुत से लोगों को पहरा देते देखा हैphp-fpm.sockनिगरानी में लापरवाही बरती गई और परिणामस्वरूप, वेबसाइट लंबे समय से 404 कब्रिस्तान बन गई है। आज मैं इस परिचालन और रखरखाव के भ्रम को तोड़ना चाहता हूं और आपको सच्चाई दिखाना चाहता हूं: एक जीवंत प्रक्रिया = एक सामान्य सेवा।

🌪️ विनाशकारी परिदृश्य: सॉकेट कनेक्ट है, लेकिन वेबसाइट मृत है

कुछबिजली आपूर्तिकर्तावेबसाइट की निगरानी से पता चला कि PHP-FPM प्रक्रिया सामान्य रूप से चल रही थी, लेकिन उपयोगकर्ता भुगतान विफलताओं के बारे में शिकायत कर रहे थे।

लंबी खोज के बाद, मुझे पता चला कि तीसरे पक्ष की लाइब्रेरी में मेमोरी लीक के कारण PHP प्रक्रिया चालू थी, लेकिन अनुरोधों को संसाधित करने में पूरी तरह असमर्थ थी।

इस समय, केवल सॉकेट डिटेक्शन पर निर्भर रहना ज़ोंबी की नब्ज जांचने जैसा है - आप मस्तिष्क को बिल्कुल भी नहीं ढूंढ सकते死亡.

💥 एक डबल-किल मॉनिटरिंग समाधान जो संज्ञान को नष्ट कर देता है

उन पुरानी एक-आयामी निगरानी को फेंक दें! सभी श्रेष्ठ विशेषज्ञ प्रक्रिया परत + व्यवसाय परत की दोहरी रणनीति का उपयोग करते हैं।

निम्नलिखित कॉन्फ़िगरेशन आपके सर्वर को स्वयं को इतनी तेजी से ठीक करने की अनुमति देगा कि समस्या उत्पन्न होने पर संचालन और रखरखाव कर्मचारी भी बिस्तर से उठ नहीं पाएंगे:

check process php8.3-fpm with pidfile /run/php/php8.3-fpm.pid
    start program = "/usr/sbin/service php8.3-fpm start"
    stop program  = "/usr/sbin/service php8.3-fpm stop"
    if failed unixsocket /run/php/php8.3-fpm.sock then restart
    if failed 
        host www.chenweiliang.com 
        port 443
        protocol https
        request "/wp-login.php"
        status = 200
        hostheader www.chenweiliang.com
        for 3 cycles
    then restart
    if 5 restarts within 5 cycles then exec "/usr/bin/systemctl restart hestia"

🔍 मापदंडों में छिपे घातक विवरण

• hostheaderसीडीएन/लोड संतुलन परिदृश्यों में पैरामीटर जीवन रक्षक ताबीज हैं। उनके बिना, यह रात्रि दृष्टि चश्मे के साथ एक गुप्त लड़ाकू विमान की तलाश करने जैसा है - आप गुम हुए होस्ट हेडर के कारण उत्पन्न निलंबित स्थिति को नहीं पकड़ सकते।

• for 3 cyclesयह बफर अवधि डिजाइन नेटवर्क घबराहट के कारण होने वाले झूठे सकारात्मक परिणामों से पूरी तरह से बचाता है। यह निगरानी प्रणाली पर शॉक एब्जॉर्बर लगाने जैसा है, ताकि हाथ के हिलने से परमाणु बटन दबाने से रोका जा सके।

• अंतिमexec "/usr/bin/systemctl restart hestia"यह परम घातक चाल है। जब PHP-FPM लगातार 5 बार पुनर्जीवित होने में विफल रहा, तो मैंने टेबल को पलट दिया और पूरे होस्टिंग पैनल को पुनः प्रारंभ किया। यह एक तरकीब है जो मैंने वॉल स्ट्रीट ट्रेडिंग सिस्टम के सर्किट ब्रेकर तंत्र से चुराई है।

🚨 दर्द और पीड़ा से सीखे गए सबक: 3 जाल जो आपको असफल बना सकते हैं

1. एसएसएल प्रमाणपत्र धोखाधड़ी: अपग्रेड के बाद,protocol httpsइसे न लिखने से मॉनिटरिंग हमेशा इसे सामान्य मान लेती है। बाद में मुझे पता चला कि मोनिट का पुराना संस्करण डिफ़ॉल्ट रूप से प्रमाणपत्र को सत्यापित नहीं करता था, जिसके कारण मुझे अपना साल के अंत का बोनस खोना पड़ा
2. लॉगिन पेज 401 ट्रैप: लॉगिन पेज की निगरानी करते समय जोड़ना भूल जाएंBasic Authenticationपरिणामस्वरूप, प्रत्येक परीक्षण पुनः आरंभ होता है। यह एक बगीचे को अग्निशामक नल से सींचने जैसा है - काफी शक्तिशाली लेकिन पूरी तरह से गलत
3. लॉग ब्लैक होल: एक बार/var/log/monit.logजब आकार बढ़कर 50G तक पहुंच गया, तो हमें पता चला कि किसी बेवकूफ ने पता लगाने की अवधि 1 सेकंड निर्धारित कर दी थी। याद रखें, मॉनिटरिंग लॉग ही वह वस्तु है जिस पर नजर रखने की जरूरत है!

💡 सत्यापन और डिबगिंग चरण

1. कॉन्फ़िगरेशन सिंटैक्स जाँच:

   monit -t
   

2. अधिभार विन्यास:

   monit reload

अंतिम परीक्षण

1. आत्महत्या परीक्षण: प्रत्यक्षkill -9PHP-FPM प्रक्रिया को समाप्त करें और मॉनिटरिंग लॉग में पुनरुत्थान रिकॉर्ड देखें। ऐसा लगता है जैसे कोई ज़ॉम्बी फिल्म देख रहे हों!
2. ज़हर इंजेक्शन: 503 स्थिति कोड लौटाने के लिए लॉगिन पृष्ठ को जानबूझकर संशोधित करें और देखें कि क्या निगरानी प्रणाली सटीक रूप से हमला कर सकती है। मैं इस विधि को "डिजिटल वैक्सीन" कहता हूं - निगरानी प्रणाली की प्रतिरक्षा प्रतिक्रिया को बाहर करने के लिए सिस्टम में पहले से थोड़ी मात्रा में वायरस को इंजेक्ट करना। जब अलार्म तेजी से चमकेंगे और सेवाएं स्वयं ठीक हो जाएंगी, तो आप कोड की दुनिया में जीवित रहने की सबसे कामुक इच्छा को जलते हुए देखेंगे!