HestiaCP ဖြင့် Apache2 မကြာခဏ crash ဖြစ်တတ်ပါသလား။ အလိုအလျောက် စောင့်ကြည့်ခြင်းနှင့် ပြဿနာရှာဖွေခြင်းလမ်းညွှန်ကို စောင့်ကြည့်ပါ (ပြီးပြည့်စုံသော configuration ဖြင့်)

HestiaCP ပတ်ဝန်းကျင်တွင် Apache2 မကြာခဏ ပျက်သွားခြင်း သို့မဟုတ် Monit အလိုအလျောက်ပြန်လည်စတင်မှု ပျက်ကွက်ခြင်းများ ဖြစ်တတ်ပါသလား။ ဤဆောင်းပါးသည် Monit ဖြင့် Apache2 ကို စောင့်ကြည့်သည့်အခါ အဖြစ်များသော အန္တရာယ်များကို ရှောင်ရှားရန်၊ PID လမ်းကြောင်း မညီမျှခြင်းနှင့် ခွင့်ပြုချက်ပိတ်ဆို့ခြင်းကဲ့သို့သော အဖြစ်များသော ပြဿနာများကို နက်နက်နဲနဲ ခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် ထုတ်လုပ်မှုအဆင့် Monit အလိုအလျောက်ဖွဲ့စည်းမှုဖိုင်များကို ပံ့ပိုးပေးခြင်းအတွက် လက်တွေ့ကျသော လမ်းညွှန်ချက်တစ်ခုကို ပေးပါသည်။ ရရှိနိုင်မှုမြင့်မားသော ဆာဗာပြုပြင်ထိန်းသိမ်းမှုနည်းပညာများကို ယခုပင် ကျွမ်းကျင်စွာ အသုံးချပြီး ချို့ယွင်းချက်များမှ ဒုတိယအဆင့် အလိုအလျောက်ပြန်လည်ရယူခြင်းကို ရယူလိုက်ပါ။

Apache2 ကို စောင့်ကြည့်ဖို့ Monit ကိုသုံးနေတုန်း ကျွန်တော်ကြုံတွေ့ခဲ့ရတဲ့ အခက်အခဲတွေ

ပြီးခဲ့တဲ့သောကြာနေ့ညသန်းခေါင်မှာ server က ကျွန်တော့်ကို Monit alert ပေးခဲ့ပါတယ်။

ကျွန်တော် panel ကို ကြောင်အအနဲ့ ကြည့်လိုက်တော့ apache2 status column မှာ အနီရောင် Timeout ပြနေတယ်။

ကျွန်တော် ခဏလောက် စဉ်းစားလိုက်တယ်။ နေ့ခင်းဘက်မှာ Monit monitoring ကို server မှာ ထည့်လိုက်ပြီး online tutorial ကနေ configuration ကို copy ကူးထည့်လိုက်တယ်။ ဘာပြဿနာမှ ရှိမှာမဟုတ်ဘူး မဟုတ်လား။

နောက်တစ်နေ့မနက်မှာ အချိန်ကုန်သွားပြန်တယ်။ တတိယအကြိမ်မှာတော့ Monitor က လက်လျှော့လိုက်ပြီး panel က "စောင့်ကြည့်မထားဘူး" လို့ ပြနေတယ်။

ငါ...

ဝန်ခံပါတယ်၊ အစကတော့ ကျွန်တော် အလေးအနက်မထားမိခဲ့ဘူး။ Apache2 စောင့်ကြည့်ခြင်းလား။ အွန်လိုင်းမှာ template configuration အများကြီး ရှာတွေ့နိုင်ပါတယ်၊ ကူးယူပြီး paste လုပ်လိုက်ရုံပါပဲ။ ဒါပေမယ့် အဲဒီ paste လုပ်တဲ့ လုပ်ငန်းစဉ်က ကျွန်တော့်ကို အရမ်းဒေါသထွက်စေခဲ့တယ်။

HestiaCP ရဲ့ default architecture နဲ့ Monit port တွေကြားက conflict ရဲ့ အရင်းခံအကြောင်းရင်း

ခင်ဗျားမြင်ဖူးတဲ့ ဗားရှင်းနဲ့ တစ်ထပ်တည်းကျရဲ့လားဆိုတာ ကြည့်နိုင်အောင် ကျွန်တော့်ကို အရမ်းဒုက္ခရောက်စေတဲ့ configuration ကို အရင်ပြပါရစေ။

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

အဆင်ပြေပါတယ်၊ မဟုတ်လား။ port 80 ကို စစ်ဆေးပြီး crash ဖြစ်ရင် restart လုပ်ပါတယ်။ restart ၅ ကြိမ်တောင် crash ဖြစ်နေတုန်းပဲဆိုရင် times out လုပ်ပါတယ်။

ပြဿနာက သင့်ရဲ့ Apache2 ဟာ port 80 မှာတောင် အလုပ်မလုပ်ပါဘူး။

ဒါက HestiaCP ရဲ့ အားနည်းချက်တစ်ခုဖြစ်ပြီး လူအတော်များများ ဒီထဲကို ကျရောက်ရတဲ့ အကြောင်းရင်းလည်း ဖြစ်ပါတယ်။ HestiaCP ရဲ့ default architecture က Nginx + Apache2 ရဲ့ reverse proxy တစ်ခုဖြစ်ပြီး Nginx က port 80 နဲ့ 443 တွေကို ရှေ့ကနေယူပြီး Apache2 က နောက်ကနေ local port 8081 မှာ run နေပါတယ်။

port 80 မှာ Apache2 ရဲ့ liveness ကို Monit ကို မေးကြည့်ရင် McDonald's မှာ KFC ရှာဖို့ သွားတာနဲ့ တူပါတယ်။ server က သင်တို့ကို ကြောင်အအနဲ့ ကြည့်နေပြီး ခင်ဗျားတို့နှစ်ယောက် တစ်ယောက်ကိုတစ်ယောက် စိုက်ကြည့်နေကြတယ်။ နောက်ဆုံးမှာတော့ Monit က ခင်ဗျားတို့ down နေပြီဆိုတာ ဆုံးဖြတ်ပြီး အပြင်းအထန် restart လုပ်ပါတယ်။

ပြန်စပြီး ပြန်စရင်တောင် port က 8081 ပဲ ရှိနေတုန်းပဲ။ Monit က port 80 ကို စမ်းသပ်ကြည့်တော့လည်း port 80 က မအောင်မြင်ဘူး။ ဒါကြောင့် ပြန်စတယ်။ ဒီ cycle က Monit က ပြန်ပြင်လို့ မရတော့ဘူးလို့ ဆုံးဖြတ်ပြီး timeout ဖြစ်တဲ့အထိ ပြန်ဖြစ်တတ်တယ်။

ဒါကို ကျွန်တော် ပထမဆုံးတွေ့တုန်းက တကယ်ကို အံ့အားသင့်သွားခဲ့တယ်။ အွန်လိုင်းမှာ ကျွန်တော်တွေ့ခဲ့တဲ့ သင်ခန်းစာ ဆယ်ခုမှာ ကိုးခုက port 80 ကို အသုံးပြုထားပါတယ်။ သင်သာ သူတို့ကို လိုက်နာမယ်ဆိုရင် ပြဿနာက သင့်မှာ မဟုတ်ဘဲ အချက်အလက်ရဲ့ ရင်းမြစ်မှာ ရှိနေတာပါ။

Apache2 PID ဖိုင်ပျက်စီးသွားခြင်းကြောင့် Monit သည် လုပ်ငန်းစဉ်ကို မရှိဟု မှားယွင်းစွာ မှတ်မိခဲ့သည်။

port ကို 80 ကနေ 8081 ကိုပြောင်းပြီးတဲ့နောက်မှာ Monit က သီအိုရီအရ ထောက်လှမ်းနိုင်သင့်တာပေါ့၊ မဟုတ်လား။

သို့သော် အမှန်တကယ်တွင် "အကောင်အထည်ဖော်မှု မအောင်မြင် " ဟု တစ်ခါတစ်ရံတွင် သတင်းပို့နေဆဲဖြစ်သည်။

အချိန်အတော်ကြာ ရုန်းကန်ပြီးနောက်၊ အကြောင်းရင်းက ရိုးရှင်းတယ်ဆိုတာ နောက်ဆုံးတော့ ကျွန်တော် သဘောပေါက်သွားပါတယ်- PID ဖိုင် ပျက်စီးသွားတာပါ။

စဉ်းစားကြည့်ပါ၊ Monit ဟာ Apache2 ကို အလျင်စလို ပြန်လည်စတင်နေပြီး အကြိမ်တိုင်း အတင်းအကြပ် ပိတ်လိုက် ပြန်စတင်လိုက်နဲ့ အကြိမ်ပေါင်းများစွာ ရှေ့တိုးနောက်ငင် လုပ်ဆောင်နေပါတယ်။ ဒီလုပ်ငန်းစဉ်အတွင်းမှာ /var/run/apache2/apache2.pid ဖိုင်ဟာ 0 bytes ဖြစ်သွားနိုင်ပါတယ်။

တစ်နည်းအားဖြင့် ဖိုင်က ရှိနေဆဲဖြစ်သော်လည်း ဗလာဖြစ်သည်။

Monit က ဒီဖိုင်ကို ဖတ်တဲ့အခါ ဘာမှ မတွေ့ပါဘူး။ Apache2 က background မှာ ကောင်းကောင်း run နေရင်တောင် Apache2 ကို မသိပါဘူး။ Monit က ဒီ process ရှိနေတယ်လို့ မထင်ပါဘူး။

ဒါကိုမြင်တော့ ကျွန်တော် ခဏလောက် စကားမပြောနိုင်ဘဲ ငြိမ်သွားတယ်။

ဒါက ပိတ်ဆို့နေတဲ့ အခြေအနေပါ။ Monit က Apache 2 instance ကို မတွေ့ရှိနိုင်ဘဲ Apache2 ကို ပြန်လည်စတင်ပြီး ပြန်လည်စတင်တဲ့ လုပ်ငန်းစဉ်အတွင်းမှာ PID ဖိုင်ကို ပျက်စီးစေပြီး နောက်တစ်ကြိမ် ရှာဖွေတွေ့ရှိမှုမှာ မအောင်မြင်ဘဲ ထပ်မံပြန်လည်စတင်ပါတယ်။ ဒီစက်ဝန်းဟာ timeout မဖြစ်ပေါ်မချင်း ဆက်လက်ဖြစ်ပေါ်နေပါတယ်။

HestiaCP ပတ်ဝန်းကျင်တွင် Apache2 စောင့်ကြည့်ခြင်းအတွက် ပြဿနာရှာဖွေခြင်းနှင့် ပြုပြင်ခြင်းအဆင့်များ

ရိုးရိုးသားသားပြောရရင် စုံစမ်းစစ်ဆေးမှုလုပ်ငန်းစဉ်က ရှုပ်ထွေးတာမဟုတ်ပေမယ့် ဘယ်လမ်းကြောင်းကို စုံစမ်းစစ်ဆေးရမလဲဆိုတာ သိဖို့လိုပါတယ်။

ပထမခြေလှမ်းကတော့ သင့်ရဲ့ Apache2 က ဘယ် port မှာ နားထောင်နေလဲဆိုတာ ဆုံးဖြတ်ဖို့ပါပဲ။ terminal မှာ command တစ်ခု ရိုက်ထည့်လိုက်ရုံပါပဲ။

netstat -tulpn | grep apache2

တနည်းအားဖြင့် `ss` command ကိုသုံးနိုင်သည်။ အကျိုးသက်ရောက်မှုမှာ အတူတူပင်ဖြစ်သည်။

ss -tulpn | grep apache2

ဤကဲ့သို့ အလားတူ output ကို သင်တွေ့ရပါလိမ့်မည်။

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 ရိုးရာအလိုက် လိုက်လျောညီထွေဖြစ်အောင် ပြုလုပ်ထားသော နှင့် ရန်လိုသော အကာအကွယ်ပေးသည့် ဖွဲ့စည်းမှုပုံစံများ၏ နှိုင်းယှဉ် ခွဲခြမ်းစိတ်ဖြာမှု

Monit ဖြင့် Apache2 ကို configure လုပ်ခြင်းဆိုင်ရာ အွန်လိုင်းသင်ခန်းစာများသည် ယေဘုယျအားဖြင့် အမျိုးအစားနှစ်ခု ခွဲခြားနိုင်သည်။

အမျိုးအစားတစ်ခုမှာ "ရိုးရာ adaptation အမျိုးအစား" ဖြစ်ပြီး ရှုပ်ထွေးသော ကန့်သတ်ချက်များစွာ မထည့်ဘဲ ဝန်ဆောင်မှုများကို စီမံခန့်ခွဲရန်နှင့် ဒေသတွင်း port များကို စစ်ဆေးရန် `service` command ကို အသုံးပြုသည်။ ဤ configuration ကို HestiaCP တွင် port ကို ပြောင်းလဲခြင်းဖြင့် အသုံးပြုနိုင်ပြီး တည်ငြိမ်မှု အတော်လေးရှိသည်။

နောက်ထပ်နည်းလမ်းတစ်ခုမှာ "aggressive protection" နည်းလမ်းဖြစ်ပြီး ၎င်းသည် service များကို စီမံခန့်ခွဲရန် systemctl ကိုအသုံးပြုကာ၊ ကလေးလုပ်ငန်းစဉ်ကန့်သတ်ချက်များကို ထည့်သွင်းပြီး ပိုမိုတင်းကျပ်သော ထောက်လှမ်းမှုယုတ္တိဗေဒကို အသုံးပြုသည်။ ၎င်းသည် ကောင်းမွန်ပုံရသော်လည်း အားနည်းချက်တစ်ခုရှိသည်- အသုံးပြုထားသော stop command မှာ `killall -9` ဖြစ်သည်။

`killall -9` ဆိုတာ ဘာကိုဆိုလိုတာလဲ။ စက်က ဘာလုပ်နေလဲဆိုတာကို ဂရုမစိုက်ဘဲ အတင်းပိတ်ပစ်တာကို ဆိုလိုတာပါ။ ဒီ brute-force လုပ်ဆောင်ချက်က ပျက်စီးနေတဲ့ PID ဖိုင်တွေကို အလွယ်တကူ ချန်ထားခဲ့ပြီး ကျွန်တော် ခုနက ပြောခဲ့တဲ့ ပြဿနာပါ။

ကျွန်တော့်ရဲ့ကိုယ်ပိုင်အတွေ့အကြုံအရ ရန်လိုတဲ့ configuration တစ်ခုမှာ child process အရေအတွက်ကို ကန့်သတ်ထားတာက အမှန်တကယ်အသုံးဝင်ပါတယ်။ သင့်ရဲ့ Apache2 ဟာ CC attack ရဲ့လွှမ်းမိုးမှုကို ခံရတဲ့အခါ child process အရေအတွက်ကို ကန့်သတ်ခြင်းအားဖြင့် server ရဲ့ memory ကုန်ဆုံးမှုကို ကာကွယ်ပေးနိုင်ပါတယ်။ ဒါပေမယ့် `killall -9` approach က အမှန်တကယ်အသုံးမဝင်ပါဘူး။

ဒါကြောင့် နောက်ဆုံးမှာ ကျွန်တော် အလျှော့ပေးလိုက်ပြီး ဖွဲ့စည်းပုံနှစ်ခုလုံးရဲ့ အားသာချက်တွေကို ပေါင်းစပ်လိုက်တယ်။

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

ဒီ configuration လိုင်းအနည်းငယ်ရဲ့ နောက်ကွယ်က logic ကို အကျဉ်းချုပ် ရှင်းပြပါရစေ။

HestiaCP ရဲ့ reverse proxy architecture နဲ့ အတိအကျ ကိုက်ညီအောင် port 8081 ကို ရေးပါ။ port 80 ကို မိုက်မဲစွာ ရေးတာ ရပ်လိုက်ပါ။

PID ဖိုင်ကို ရပ်တန့်ရန် `killall -9` အစား `systemctl stop` command ကိုသုံးပါ၊ ထိုသို့ပြုလုပ်ခြင်းဖြင့် ၎င်းကို ပျက်စီးခြင်းမှ ကာကွယ်ပါ။

ကလေးလုပ်ငန်းစဉ်ကန့်သတ်ချက်ကို ထည့်သွင်းထားသည်- ကလေးအရေအတွက် ၁၂၀ ထက်ကျော်လွန်ပါက CC တိုက်ခိုက်မှုများကို ကာကွယ်ရန် လုပ်ငန်းစဉ်ကို ဆက်တိုက်နှစ်ကြိမ်အပြီးတွင် ပြန်လည်စတင်မည်ဖြစ်သော်လည်း အလွန်ပြင်းထန်ခြင်းမရှိပါ။

ချို့ယွင်းချက်များကို ထောက်လှမ်းရန်အတွက် ယုတ္တိဗေဒကို "၂ ကြိမ်အတွက်" ချဉ်းကပ်မှုကို အသုံးပြုရန် ပြင်ဆင်ထားပြီးဖြစ်ပြီး၊ ဆက်တိုက် ချို့ယွင်းမှုနှစ်ခုပြီးမှသာ ပြန်လည်စတင်ခြင်းကို စတင်ပြီး မှားယွင်းသော အပြုသဘောဆောင်သည့် လက္ခဏာများကို လျှော့ချပေးသည်ဟု ဆိုလိုသည်။ တစ်ကြိမ်သာ ထောက်လှမ်းပြီးနောက် ပြန်လည်စတင်ခဲ့သော ယခင်ဖွဲ့စည်းပုံသည် ပွင့်ပွင့်လင်းလင်းပြောရလျှင် အနည်းငယ် အလွန်အမင်း ထိခိုက်လွယ်ပါသည်။

နောက်ဆုံး timeout threshold ကို ၁၀ cycle အတွင်း ၅ ကြိမ် restart ဖြစ်အောင် ဖြေလျှော့ပေးထားပြီး fault tolerance လုံလောက်ပါသည်။

HestiaCP စောင့်ကြည့်စောင့်ကြည့်ဖွဲ့စည်းပုံဆိုင်ရာ ပြဿနာဖြေရှင်းခြင်း အနှစ်ချုပ်နှင့် အတွေ့အကြုံမျှဝေခြင်း

configuration ပြောင်းလဲမှုတွေ လုပ်ပြီးတဲ့နောက် apache2 ကို စောင့်ကြည့်ခဲ့ပြီး panel က နောက်ဆုံးမှာ အစိမ်းရောင် "OK" indicator ပြပါတယ်။

အဲဒီအချိန်တုန်းက ကျွန်တော့်ရဲ့ခံစားချက်တွေကို ဘယ်လိုဖော်ပြရမလဲ။ bug တစ်ခုနဲ့ နှစ်ရက်လောက် ရုန်းကန်နေရသလိုပါပဲ။ configuration လိုင်းတစ်ခုတည်း မှားနေတာကြောင့် ဖြစ်ရတာလို့ပဲ သိလိုက်ရတယ်။ စိတ်ပျက်စရာကောင်းသလို ရယ်စရာကောင်းပါတယ်။

Monit က သူ့အလိုလိုကောင်းတဲ့အရာတစ်ခုဖြစ်ပြီး daemons တွေကို စောင့်ကြည့်တာက server တိုင်းလုပ်သင့်တဲ့အရာပါ။ ဒါပေမယ့် ပြဿနာက အွန်လိုင်းသင်ခန်းစာအများစုဟာ "Apache2 က port 80 ကိုပဲသုံးတယ်" ဆိုတဲ့ယူဆချက်ပေါ်မှာ အခြေခံထားပြီး HestiaCP က reverse proxy ကိုသုံးတယ်၊ ဒါကြောင့် ဒီယူဆချက်က မှန်ကန်မှာမဟုတ်ပါဘူး။

ညွှန်ကြားချက်တွေကို လိုက်နာမယ်ဆိုရင် ပြဿနာက သင်မဟုတ်ဘူး၊ သင်ခန်းစာက သင့်အခြေအနေနဲ့ မတူတဲ့ အခြေအနေမှာ အသုံးချနိုင်တာပါပဲ။

ဒါကြောင့် HestiaCP ကိုလည်းသုံးပြီး Apache2 ကိုစောင့်ကြည့်ဖို့ Monit နဲ့ကစားနေတယ်ဆိုရင် အချက်နှစ်ချက်ကိုသတိရပါ- port ကို 8081 ကိုပြောင်းပြီး `killall -9` ကိုမသုံးဘဲ `systemctl` command ကိုသုံးကာ ရပ်တန့်ပါ။ ဒီနှစ်ခုကိုလုပ်မယ်ဆိုရင် နောက်ထပ်ပြဿနာတွေကို ရှောင်ရှားနိုင်မှာပါ။

ဒီအထိဖတ်ပြီးပြီဆိုတော့ အသုံးဝင်ရင် like လုပ်ပြီး share လုပ်ပေးပါ။ update တွေကို ဦးစွာရယူချင်ရင် ကျွန်တော့်ကို follow လုပ်နိုင်ပါတယ်။

ကျွန်တော့်ရဲ့ဆောင်းပါးကို ဖတ်ရှုပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။ နောက်တစ်ကြိမ်မှာ ပြန်ဆုံကြမယ်။