ការគាំងជាញឹកញាប់របស់ Apache2 ជាមួយ HestiaCP? តាមដានការណែនាំអំពីការត្រួតពិនិត្យ និងដោះស្រាយបញ្ហាដោយស្វ័យប្រវត្តិ (ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធពេញលេញ)

ការគាំង Apache2 ញឹកញាប់ ឬការបរាជ័យក្នុងការចាប់ផ្តើមឡើងវិញដោយស្វ័យប្រវត្តិរបស់ Monit នៅក្នុងបរិស្ថាន HestiaCP ? អត្ថបទនេះផ្តល់នូវការណែនាំជាក់ស្តែងមួយដើម្បីជៀសវាងកំហុសទូទៅនៅពេលត្រួតពិនិត្យ Apache2 ជាមួយ Monit ដោយវិភាគយ៉ាងស៊ីជម្រៅអំពីបញ្ហាទូទៅដូចជាការមិនត្រឹមត្រូវនៃផ្លូវ PID និងការរារាំងការអនុញ្ញាត និងការផ្តល់ជូនឯកសារកំណត់រចនាសម្ព័ន្ធស្វ័យប្រវត្តិកម្ម Monit កម្រិតផលិតកម្ម។ ស្ទាត់ជំនាញបច្ចេកទេសថែទាំម៉ាស៊ីនមេដែលមានភាពអាចរកបានខ្ពស់ឥឡូវនេះ ហើយសម្រេចបាននូវការស្តារឡើងវិញដោយស្វ័យប្រវត្តិកម្រិតទីពីរពីការបរាជ័យ!

ចំណុចខ្វះខាតដែលខ្ញុំបានជួបប្រទះពេលកំពុងប្រើ Monit ដើម្បីត្រួតពិនិត្យ Apache2

កាលពីថ្ងៃសុក្រសប្តាហ៍មុន ម៉ាស៊ីនមេបានផ្តល់ឱ្យខ្ញុំនូវការជូនដំណឹង Monit នៅពាក់កណ្តាលអធ្រាត្រ។

ខ្ញុំបានសម្លឹងមើលបន្ទះដោយងឿងឆ្ងល់ ហើយនៅក្នុងជួរឈរស្ថានភាព apache2 មានសញ្ញា Timeout ពណ៌ក្រហម។

ខ្ញុំបានគិតអំពីវាមួយសន្ទុះ។ ខ្ញុំទើបតែបន្ថែមការត្រួតពិនិត្យ Monit ទៅក្នុងម៉ាស៊ីនមេក្នុងពេលថ្ងៃ ហើយខ្ញុំបានចម្លង និងបិទភ្ជាប់ការកំណត់រចនាសម្ព័ន្ធពីការបង្រៀនតាមអ៊ីនធឺណិត។ មិនគួរមានបញ្ហាអ្វីទេ មែនទេ?

នៅព្រឹកបន្ទាប់ វាអស់ពេលម្តងទៀត។ បន្ទាប់ពីលើកទីបី ម៉ូនីទ័រគ្រាន់តែបោះបង់ ហើយបន្ទះបង្ហាញ "មិនត្រូវបានត្រួតពិនិត្យ"។

ខ្ញុំ...

ខ្ញុំសារភាពថា ដំបូងឡើយខ្ញុំមិនបានយកចិត្តទុកដាក់ចំពោះវាទេ។ ការត្រួតពិនិត្យ Apache2? អ្នកអាចរកឃើញការកំណត់រចនាសម្ព័ន្ធគំរូជាច្រើននៅលើអ៊ីនធឺណិត គ្រាន់តែចម្លងនិងបិទភ្ជាប់។ ប៉ុន្តែដំណើរការបិទភ្ជាប់នោះពិតជាធ្វើឱ្យខ្ញុំខឹងសម្បារយ៉ាងខ្លាំង។

មូលហេតុចម្បងនៃជម្លោះរវាងស្ថាបត្យកម្មលំនាំដើមរបស់ 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

វាហាក់ដូចជាល្អមែនទេ? វាពិនិត្យមើលច្រក 80 ហើយប្រសិនបើវាគាំង វានឹងចាប់ផ្តើមឡើងវិញ។ ប្រសិនបើវានៅតែគាំងបន្ទាប់ពីចាប់ផ្តើមឡើងវិញ 5 ដង វានឹងអស់ពេល។

បញ្ហាគឺថា Apache2 របស់អ្នកមិនដំណើរការលើច្រក 80 ទេ។

នេះ​គឺជា​អន្ទាក់​មួយ​របស់ HestiaCP ហើយ​ក៏​ជា​មូលហេតុ​ចម្បង​ដែល​ធ្វើ​ឲ្យ​មនុស្ស​ជាច្រើន​ធ្លាក់​ចូល​ក្នុង​វា។ ស្ថាបត្យកម្ម​លំនាំដើម​របស់ HestiaCP គឺជា​ប្រូកស៊ី​បញ្ច្រាស​របស់ Nginx + Apache2 ដោយ Nginx កាន់កាប់​ច្រក 80 និង 443 នៅ​ខាងមុខ ហើយ Apache2 ដំណើរការ​លើ​ច្រក​ក្នុងស្រុក 8081 នៅ​ខាងក្រោយ។

ប្រសិនបើអ្នកសុំឱ្យ Monit ស៊ើបអង្កេតភាពរស់រវើករបស់ Apache2 នៅលើច្រក 80 វាដូចជាការទៅ McDonald's ដើម្បីរក KFC។ អ្នកបម្រើមើលមកអ្នកដោយទទេៗ ហើយអ្នកទាំងពីរសម្លឹងមើលគ្នាទៅវិញទៅមក។ នៅទីបញ្ចប់ Monit កំណត់ថាអ្នកកំពុងបិទ ហើយចាប់ផ្តើមឡើងវិញដោយអន្ទះសារ។

បន្ទាប់ពីចាប់ផ្តើមឡើងវិញ ច្រកនៅតែជា 8081។ បន្ទាប់មក Monit ព្យាយាមស៊ើបអង្កេតច្រក 80 ដែលក៏បរាជ័យដែរ ដូច្នេះវាចាប់ផ្តើមឡើងវិញម្តងទៀត។ វដ្តនេះធ្វើម្តងទៀតរហូតដល់ Monit សម្រេចចិត្តថាវាមិនអាចជួសជុលបាន ហើយផុតកំណត់។

ពេលខ្ញុំជួបប្រទះរឿងនេះដំបូង ខ្ញុំពិតជាភ្ញាក់ផ្អើលណាស់។ ក្នុងចំណោមការបង្រៀនទាំងដប់ដែលខ្ញុំបានរកឃើញតាមអ៊ីនធឺណិត មានប្រាំបួនដែលប្រើច្រក 80។ ប្រសិនបើអ្នកធ្វើតាមពួកវា បញ្ហាមិនមែនស្ថិតនៅជាមួយអ្នកទេ ប៉ុន្តែស្ថិតនៅប្រភពព័ត៌មានខ្លួនឯង។

ឯកសារ Apache2 PID ដែលខូចបានបណ្តាលឱ្យ Monit កំណត់អត្តសញ្ញាណដំណើរការដោយច្រឡំថាមិនមាន។

បន្ទាប់ពីផ្លាស់ប្តូរច្រកពី 80 ទៅ 8081 តាមទ្រឹស្តី Monit គួរតែអាចរកឃើញវាបាន មែនទេ?

ទោះយ៉ាងណាក៏ដោយ តាមពិតទៅ វានៅតែរាយការណ៍ម្តងម្កាលថា "ការប្រតិបត្តិ បរាជ័យ "។

បន្ទាប់ពីតស៊ូអស់រយៈពេលយូរ ទីបំផុតខ្ញុំបានរកឃើញថាមូលហេតុគឺសាមញ្ញ៖ ឯកសារ PID ខូច។

សូមគិតអំពីវា Monit កំពុងចាប់ផ្តើម Apache2 ឡើងវិញដោយអន្ទះសារ រាល់ពេលវាបង្ខំឱ្យបិទ និងចាប់ផ្តើមវាឡើងវិញ ដោយធ្វើឡើងវិញច្រើនដង។ ក្នុងអំឡុងពេលដំណើរការនេះ ឯកសារ /var/run/apache2/apache2.pid អាចក្លាយជា 0 បៃ។

ម្យ៉ាង​ទៀត ឯកសារ​នៅ​តែ​មាន ប៉ុន្តែ​វា​ទទេ។

នៅពេលដែល Monit អានឯកសារនេះ វារកមិនឃើញអ្វីទាំងអស់។ វាមិនស្គាល់ Apache2 របស់អ្នកទេ ទោះបីជា Apache2 របស់អ្នកដំណើរការល្អឥតខ្ចោះនៅផ្ទៃខាងក្រោយក៏ដោយ។ Monit មិនគិតថាដំណើរការនេះមានទេ។

ពេលខ្ញុំឃើញបែបនេះ ខ្ញុំក៏និយាយមិនចេញមួយសន្ទុះ។

នេះគឺជាការជាប់គាំង។ Monit បរាជ័យក្នុងការរកឃើញឧទាហរណ៍ Apache 2 ចាប់ផ្តើម Apache2 ឡើងវិញ ធ្វើឱ្យខូចឯកសារ PID ក្នុងអំឡុងពេលដំណើរការចាប់ផ្តើមឡើងវិញ បរាជ័យក្នុងការរកឃើញលើកក្រោយ ហើយចាប់ផ្តើមឡើងវិញម្តងទៀត។ វដ្តនេះបន្តរហូតដល់ការអស់ពេលកើតឡើង។

ជំហានដោះស្រាយបញ្ហា និងជួសជុលសម្រាប់ការត្រួតពិនិត្យ Apache2 នៅក្នុងបរិស្ថាន HestiaCP

និយាយឱ្យត្រង់ទៅ ដំណើរការស៊ើបអង្កេតមិនស្មុគស្មាញទេ ប៉ុន្តែអ្នកត្រូវដឹងថាត្រូវស៊ើបអង្កេតទិសដៅណា។

ជំហានដំបូងគឺត្រូវកំណត់ថាច្រកណាដែល 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 ទេ។ នោះជាឫសគល់នៃបញ្ហា។

ជំហានទីពីរគឺជួសជុលឯកសារ PID ដែលខូច។ វិធីនេះសាមញ្ញជាង។

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

ដំបូង សូមផ្អាកការត្រួតពិនិត្យ Monit ដើម្បីការពារវាពីការជ្រៀតជ្រែក ខណៈពេលដែលអ្នកកំពុងជួសជុលវា។ បន្ទាប់មក ចាប់ផ្តើម Apache2 ឡើងវិញ ដើម្បីអនុញ្ញាតឱ្យវាសរសេរ PID ស្អាតឡើងវិញ។ ជាចុងក្រោយ សូមប្រើ `cat` ដើម្បីពិនិត្យមើលខ្លឹមសារឯកសារ។ វាគួរតែមានខ្សែអក្សរលេខ មិនមែនខ្សែអក្សរទទេទេ។

នៅពេលដែលជំហាននេះត្រូវបានបញ្ចប់ បញ្ហាត្រូវបានដោះស្រាយជាទូទៅ។

ការវិភាគប្រៀបធៀបនៃការកំណត់រចនាសម្ព័ន្ធការពារបែបប្រពៃណីរបស់ Monit ដែលសម្របខ្លួន និងការពារបែបឈ្លានពាន

ការបង្រៀនតាមអ៊ីនធឺណិតអំពីការកំណត់រចនាសម្ព័ន្ធ Apache2 ជាមួយ Monit ជាទូទៅត្រូវបានបែងចែកជាពីរប្រភេទ។

ប្រភេទមួយគឺ "ប្រភេទសម្របខ្លួនបែបប្រពៃណី" ដែលប្រើពាក្យបញ្ជា `service` ដើម្បីគ្រប់គ្រងសេវាកម្ម និងពិនិត្យមើលច្រកក្នុងស្រុកដោយមិនចាំបាច់បន្ថែមការរឹតបន្តឹងស្មុគស្មាញច្រើនពេក។ ការកំណត់រចនាសម្ព័ន្ធនេះអាចត្រូវបានប្រើនៅលើ HestiaCP ដោយគ្រាន់តែផ្លាស់ប្តូរច្រក ហើយវាមានស្ថេរភាព។

វិធីសាស្រ្តមួយទៀតគឺវិធីសាស្រ្ត "ការការពារយ៉ាងសកម្ម" ដែលប្រើ systemctl ដើម្បីគ្រប់គ្រងសេវាកម្ម បន្ថែមការរឹតបន្តឹងដំណើរការកុមារ និងប្រើប្រាស់តក្កវិជ្ជារកឃើញដ៏តឹងរ៉ឹងជាងមុន។ វាមើលទៅអស្ចារ្យណាស់ ប៉ុន្តែវាមានគុណវិបត្តិធ្ងន់ធ្ងរ៖ ពាក្យបញ្ជាបញ្ឈប់ដែលប្រើគឺ `killall -9`។

តើ `killall -9` មានន័យដូចម្តេច? វាមានន័យថា បង្ខំឲ្យឧបករណ៍នោះបិទដោយមិនគិតពីអ្វីដែលវាកំពុងធ្វើនោះទេ។ ប្រតិបត្តិការ brute-force នេះអាចបន្សល់ទុកឯកសារ 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

សូម​ឲ្យ​ខ្ញុំ​ពន្យល់​ដោយ​សង្ខេប​អំពី​តក្កវិជ្ជា​នៅ​ពីក្រោយ​បន្ទាត់​កំណត់​រចនាសម្ព័ន្ធ​ទាំងនេះ។

សរសេរ​ច្រក 8081 ដើម្បី​ផ្គូផ្គង​យ៉ាង​ច្បាស់លាស់​នូវ​ស្ថាបត្យកម្ម​ប្រូកស៊ី​បញ្ច្រាស​របស់ HestiaCP; ឈប់​សរសេរ​ច្រក 80 ដោយ​ល្ងង់ខ្លៅ​ទៀត។

ប្រើពាក្យបញ្ជា `systemctl stop` ជំនួសឲ្យពាក្យបញ្ជា `killall -9` ដើម្បីបញ្ឈប់ឯកសារ PID ដើម្បីកុំឲ្យវាខូច។

ដែនកំណត់ដំណើរការកូនត្រូវបានបន្ថែម៖ ប្រសិនបើចំនួនកូនលើសពី 120 ដំណើរការនឹងចាប់ផ្តើមឡើងវិញបន្ទាប់ពីវដ្តជាប់ៗគ្នាពីរ ដើម្បីការពារការវាយប្រហារ CC ប៉ុន្តែវាមិនឈ្លានពានពេកទេ។

តក្កវិជ្ជាសម្រាប់ការរកឃើញការបរាជ័យត្រូវបានកែប្រែដើម្បីប្រើវិធីសាស្រ្ត "សម្រាប់ 2 វដ្ត" មានន័យថាការចាប់ផ្តើមឡើងវិញត្រូវបានបង្កឡើងតែបន្ទាប់ពីការបរាជ័យពីរជាប់ៗគ្នាប៉ុណ្ណោះ ដែលកាត់បន្ថយលទ្ធផលវិជ្ជមានមិនពិត។ ការកំណត់រចនាសម្ព័ន្ធមុន ដែលបានចាប់ផ្តើមឡើងវិញបន្ទាប់ពីការរកឃើញតែមួយដង គឺពិតជាមានភាពរសើបខ្លាំងពេក។

កម្រិត​ពេលវេលា​អស់​ចុងក្រោយ​ត្រូវ​បាន​បន្ធូរបន្ថយ​មក​ត្រឹម 5 ដង​នៃ​ការ​ចាប់ផ្ដើម​ឡើង​វិញ​ក្នុង​រយៈពេល 10 វដ្ត ដោយ​ទុក​ឲ្យ​មាន​ការ​អត់ឱន​ចំពោះ​កំហុស​គ្រប់គ្រាន់។

HestiaCP ការត្រួតពិនិត្យតាមដានសេចក្តីសង្ខេបអំពីការដោះស្រាយបញ្ហាការកំណត់រចនាសម្ព័ន្ធ និងការចែករំលែកបទពិសោធន៍

បន្ទាប់ពីធ្វើការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធរួច ខ្ញុំបានត្រួតពិនិត្យ apache2 ហើយបន្ទះនេះបានបង្ហាញសូចនាករ "យល់ព្រម" ពណ៌បៃតង។

តើ​ខ្ញុំ​ត្រូវ​ពណ៌នា​អំពី​អារម្មណ៍​របស់​ខ្ញុំ​នៅ​ពេល​នោះ​យ៉ាង​ដូចម្តេច? វា​ដូច​ជា​ការ​ចំណាយ​ពេល​ពីរ​ថ្ងៃ​ដើម្បី​តស៊ូ​ជាមួយ​នឹង​កំហុស​មួយ ប៉ុន្តែ​ដើម្បី​ដឹង​ថា​មូលហេតុ​គឺ​ជា​ការ​កំណត់​រចនាសម្ព័ន្ធ​តែ​មួយ​គត់​ដែល​មិន​ត្រឹមត្រូវ។ វា​ទាំង​ធ្វើ​ឲ្យ​ខ្ញុំ​ខកចិត្ត និង​អស់​សំណើច។

Monit គឺជារឿងល្អមួយនៅក្នុងខ្លួនវា ហើយ daemons ត្រួតពិនិត្យគឺជាអ្វីដែលម៉ាស៊ីនមេគ្រប់រូបគួរធ្វើ។ ប៉ុន្តែបញ្ហាគឺថាការបង្រៀនតាមអ៊ីនធឺណិតជាច្រើនគឺផ្អែកលើការសន្មត់ថា "Apache2 ប្រើច្រក 80 ទាំងស្រុង" ខណៈពេលដែល HestiaCP ប្រើប្រូកស៊ីបញ្ច្រាស ដែលមានន័យថាការសន្មត់នេះមិនពិតទេ។

ប្រសិនបើអ្នកធ្វើតាមការណែនាំ បញ្ហាមិនមែនស្ថិតនៅលើអ្នកទេ វាគឺថាការបង្រៀននេះអាចអនុវត្តបានចំពោះសេណារីយ៉ូផ្សេងពីរបស់អ្នក។

ដូច្នេះប្រសិនបើអ្នកកំពុងប្រើ HestiaCP ហើយលេងជាមួយ Monit ដើម្បីត្រួតពិនិត្យ Apache2 សូមចងចាំរឿងពីរយ៉ាង៖ ផ្លាស់ប្តូរច្រកទៅ 8081 ហើយប្រើពាក្យបញ្ជា `systemctl` ដើម្បីបញ្ឈប់វា មិនមែន `killall -9` ទេ។ ប្រសិនបើអ្នកធ្វើរឿងទាំងពីរនេះ អ្នកគួរតែអាចជៀសវាងបញ្ហាបន្ថែមទៀត។

ដោយសារអ្នកបានអានដល់ចំណុចនេះ ប្រសិនបើអ្នកយល់ថាវាមានប្រយោជន៍ សូមចូលចិត្ត និងចែករំលែកវា។ ប្រសិនបើអ្នកចង់ទទួលបានព័ត៌មានថ្មីៗមុនគេ អ្នកក៏អាចតាមដានខ្ញុំបានដែរ!

សូមអរគុណសម្រាប់ការអានអត្ថបទរបស់ខ្ញុំ។ ជួបគ្នាពេលក្រោយ។