Monit ត្រួតពិនិត្យទំព័រថាមវន្តនៃគេហទំព័រ ហើយរកឃើញថាលេខកូដស្ថានភាពមិនមែន 200 ហើយចាប់ផ្តើមឡើងវិញដោយស្វ័យប្រវត្តិ php8.3-fpm

🚀 នៅពេលដែលទំព័រថាមវន្តនៅលើគេហទំព័រមួយស្រាប់តែមានកូដស្ថានភាពមិនមែន 200 តើ PHP8.3-FPM អាចព្យាបាលដោយខ្លួនឯងក្នុងរយៈពេលប៉ុន្មានវិនាទី?​

🔥 ការកំណត់រចនាសម្ព័ន្ធសង្គ្រោះជីវិត PHP90-FPM ដែលប្រតិបត្តិករ 8.3% មិនដឹង! ការបង្រៀនជាក់ស្តែងនៃ Monit dynamic page self-healing system ។

តើអ្នកគិតថាការត្រួតពិនិត្យការរស់រានមានជីវិតនៃដំណើរការ PHP-FPM គឺគ្រប់គ្រាន់ទេ? ខុសទាំងស្រុង!
នៅពេលដែល PHP-FPM នៅលើ server ស្រាប់តែមានដំណើរការខុសប្រក្រតី ដោយគ្រាន់តែក្រឡេកមើលការរស់រានមានជីវិតរបស់ដំណើរការគឺដូចជាការប្រើទែម៉ូម៉ែត្រដើម្បីវាស់មហារីក វាមិនមានបញ្ហាធ្ងន់ធ្ងរដល់ជីវិតនោះទេ។

ខ្ញុំ​បាន​ឃើញ​មនុស្ស​យាម​ច្រើន​ពេក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ប៉ារ៉ាម៉ែត្រគឺជា talismans សង្គ្រោះជីវិតនៅក្នុងសេណារីយ៉ូ CDN/load balancing។ បើគ្មានពួកគេទេ វាដូចជាការស្វែងរកអ្នកប្រយុទ្ធបំបាំងកាយដែលមានវ៉ែនតាពេលយប់ អ្នកមិនអាចចាប់ស្ថានភាពព្យួរដែលបណ្តាលមកពីផ្នែកក្បាលម៉ាស៊ីនដែលបាត់នោះទេ។

• for 3 cyclesការរចនាកំឡុងពេលបណ្ដោះអាសន្ននេះជៀសវាងយ៉ាងល្អឥតខ្ចោះនូវភាពវិជ្ជមានមិនពិតដែលបណ្តាលមកពីការរំខានបណ្តាញ។ វាដូចជាការដំឡើងឧបករណ៍ស្រូបទាញនៅលើប្រព័ន្ធឃ្លាំមើលដើម្បីការពារការញ័រដៃពីការកេះប៊ូតុងនុយក្លេអ៊ែរ។

• ចុងក្រោយexec "/usr/bin/systemctl restart hestia"វាគឺជាចលនាឃាតករចុងក្រោយ។ នៅពេលដែល PHP-FPM បរាជ័យក្នុងការរស់ឡើងវិញចំនួន 5 ដងជាប់ៗគ្នា ខ្ញុំបានត្រឡប់តារាង ហើយចាប់ផ្តើមផ្ទាំងបង្ហោះទាំងមូលឡើងវិញ។ នេះគឺជាល្បិចដែលខ្ញុំបានលួចពីយន្តការបំបែកសៀគ្វីនៃប្រព័ន្ធពាណិជ្ជកម្ម Wall Street ។

🚨 មេរៀនពីការឈឺចាប់ និងទុក្ខ៖ អន្ទាក់ ៣ ដែលអាចធ្វើឲ្យអ្នកបរាជ័យ

1. ការក្លែងបន្លំវិញ្ញាបនបត្រ SSL៖ បន្ទាប់ពីការធ្វើឱ្យប្រសើរឡើងprotocol httpsការ​មិន​សរសេរ​វា​ធ្វើ​ឱ្យ​ការ​ត្រួត​ពិនិត្យ​តែង​តែ​យល់​ខុស​ថា​ជា​រឿង​ធម្មតា។ ក្រោយមកខ្ញុំបានរកឃើញថាកំណែចាស់របស់ Monit មិនបានផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រតាមលំនាំដើម ដែលធ្វើឲ្យខ្ញុំបាត់បង់ប្រាក់រង្វាន់បំណាច់ឆ្នាំរបស់ខ្ញុំ
2. ចូលទំព័រ 401 អន្ទាក់៖ ភ្លេចបន្ថែមនៅពេលត្រួតពិនិត្យទំព័រចូលBasic Authenticationជាលទ្ធផល ការធ្វើតេស្តនីមួយៗចាប់ផ្តើមឡើងវិញ។ វា​ដូចជា​ការ​ស្រោច​ទឹក​សួនច្បារ​ដោយ​ប្រើ​ឧបករណ៍​ពន្លត់​អគ្គីភ័យ - ខ្លាំង​គ្រប់គ្រាន់ ប៉ុន្តែ​ខុស​ទាំងស្រុង
3. Log Black Hole: ម្តង/var/log/monit.logនៅពេលដែលទំហំកើនឡើងដល់ 50G យើងបានរកឃើញថាមនុស្សល្ងង់មួយចំនួនបានកំណត់រយៈពេលនៃការរកឃើញដល់ 1 វិនាទី។ សូមចាំថា កំណត់ហេតុត្រួតពិនិត្យខ្លួនឯង គឺជាវត្ថុដែលត្រូវត្រួតពិនិត្យ!

💡ជំហានផ្ទៀងផ្ទាត់ និងបំបាត់កំហុស

1. ការត្រួតពិនិត្យវាក្យសម្ព័ន្ធកំណត់រចនាសម្ព័ន្ធ៖

   monit -t
   

2. ការកំណត់រចនាសម្ព័ន្ធលើសទម្ងន់៖

   monit reload

ការធ្វើតេស្តចុងក្រោយ

1. តេស្តអត្តឃាត៖ ផ្ទាល់kill -9សម្លាប់ដំណើរការ PHP-FPM ហើយមើលកំណត់ត្រារស់ឡើងវិញនៅក្នុងកំណត់ហេតុត្រួតពិនិត្យ។ មានអារម្មណ៍ថាចង់មើលរឿងខ្មោចឆៅ!
2. ការចាក់ថ្នាំពុល៖ កែប្រែទំព័រចូលដោយចេតនាដើម្បីត្រឡប់លេខកូដស្ថានភាព 503 និងសង្កេតមើលថាតើប្រព័ន្ធត្រួតពិនិត្យអាចវាយប្រហារបានត្រឹមត្រូវ។ ខ្ញុំហៅវិធីសាស្ត្រនេះថា "វ៉ាក់សាំងឌីជីថល" - ការចាក់បញ្ចូលមេរោគក្នុងបរិមាណតិចតួចទៅក្នុងប្រព័ន្ធជាមុន ដើម្បីបង្ខំឱ្យមានការឆ្លើយតបនៃប្រព័ន្ធភាពស៊ាំនៃប្រព័ន្ធត្រួតពិនិត្យ។ នៅពេលដែលសំឡេងរោទិ៍បញ្ចេញឡើងយ៉ាងសាហាវ ហើយសេវាកម្មបានជាសះស្បើយដោយខ្លួនឯង អ្នកនឹងឃើញឆន្ទៈដ៏សិចស៊ីបំផុតក្នុងការរស់រានមានជីវិតនៅក្នុងពិភពកូដដែលកំពុងឆេះ!