Madalas bang mag-crash ang Apache2 gamit ang HestiaCP? Gabay sa awtomatikong pagsubaybay at pag-troubleshoot ng Monitor (kasama ang kumpletong configuration)

Madalas bang mag-crash ang Apache2 o mag-auto-restart failure ang Monit sa mga HestiaCP environment? Ang artikulong ito ay nagbibigay ng praktikal na gabay upang maiwasan ang mga karaniwang problema kapag sinusubaybayan ang Apache2 gamit ang Monit, malalim na sinusuri ang mga karaniwang isyu tulad ng PID path misalignment at permission blocking, at nag-aalok ng mga production-grade na configuration file ng Monit automation. Maging dalubhasa sa mga high-availability server maintenance techniques ngayon at makamit ang pangalawang antas ng awtomatikong pagbawi mula sa mga pagkabigo!

Ang mga patibong na aking naranasan habang ginagamit ang Monit para subaybayan ang Apache2

Noong nakaraang Biyernes, binigyan ako ng server ng Monit alert sa kalagitnaan ng gabi.

Natulala akong sumulyap sa panel, at sa column ng status ng apache2, may pulang Timeout.

Pinag-isipan ko ito nang kaunti. Idinagdag ko lang ang Monit monitoring sa server noong araw, at kinopya at ipinaste ko ang configuration mula sa isang online tutorial. Wala naman dapat maging problema, 'di ba?

Kinabukasan, nag-timeout ulit ito. Pagkatapos ng ikatlong beses, sumuko na lang ang Monitor, at lumabas sa panel ang "Not monitored".

ako...

Inaamin ko, hindi ko ito sineryoso noong una. Pagmomonitor ng Apache2? Marami kang makikitang template configuration online, copy and paste lang. Pero talagang ikinagalit ko ang proseso ng pag-paste na iyon.

Ang ugat ng tunggalian sa pagitan ng default na arkitektura ng HestiaCP at mga port ng Monit

Hayaan mo munang ipakita ko sa iyo ang configuration na nagdulot sa akin ng labis na abala, para makita mo kung eksaktong kapareho ito ng bersyong nakita mo.

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

Mukhang ayos naman, 'di ba? Sinusuri nito ang port 80, at kung mag-crash ito, magre-restart ito. Kung mag-crash pa rin ito pagkatapos ng 5 restart, magti-time out ito.

Ang problema, ang iyong Apache2 ay hindi man lang tumatakbo sa port 80.

Ito ay isang patibong ng HestiaCP, at ang ugat ng pagkahulog ng maraming tao dito. Ang default na arkitektura ng HestiaCP ay isang reverse proxy ng Nginx + Apache2, kung saan ang Nginx ay sumasakop sa mga port 80 at 443 sa harap, at ang Apache2 ay tumatakbo sa lokal na port 8081 sa likuran.

Kung hihilingin mo kay Monit na suriin ang sigla ng Apache2 sa port 80, parang pumunta ka sa McDonald's para maghanap ng KFC. Walang ekspresyon ang tingin sa iyo ng server, at nagtitigan kayong dalawa. Sa huli, napagtanto ni Monit na down ka na at agad na nagsimulang mag-restart.

Pagkatapos mag-restart, ang port ay 8081 pa rin. Sinubukan ng Monit na suriin ang port 80, na nabigo rin, kaya nag-restart itong muli. Nauulit ang cycle na ito hanggang sa magdesisyon ang Monit na hindi na ito maaayos at nag-time out na.

Noong una ko itong nasaksihan, talagang natigilan ako. Siyam sa sampung tutorial na nakita ko online ang gumamit ng port 80. Kung sinunod mo ang mga ito, ang problema ay wala sa iyo, kundi sa mismong pinagmulan ng impormasyon.

Isang sirang Apache2 PID file ang naging dahilan upang magkamali si Monit sa pagtukoy sa proseso bilang hindi umiiral.

Matapos palitan ang port mula 80 patungong 8081, dapat ay ma-detect na ito ng Monit sa teorya, tama ba?

Gayunpaman, sa katotohanan, paminsan-minsan ay nag-uulat pa rin ito ng " Nabigo ang pagpapatupad ".

Matapos ang mahabang panahon ng paghihirap, sa wakas ay natuklasan ko na simple lang ang dahilan: corrupted ang PID file.

Isipin mo, paulit-ulit na nire-restart ni Monit ang Apache2, sa bawat pagkakataon ay pilit itong pinapatay at nire-restart, paulit-ulit na nagpapabalik-balik. Sa prosesong ito, ang file na /var/run/apache2/apache2.pid ay maaaring maging 0 bytes.

Sa madaling salita, nandoon pa rin ang file, ngunit walang laman.

Kapag binasa ng Monit ang file na ito, wala itong makita. Hindi nito makikilala ang iyong Apache2, kahit na maayos ang paggana ng iyong Apache2 sa background; sa tingin ng Monit ay wala ang prosesong ito.

Nang makita ko ito, sandali akong nawalan ng malay.

Ito ay isang deadlock. Nabigo ang Monit na matukoy ang Apache 2 instance, muling i-restart ang Apache2, sinisira ang PID file habang nagre-restart, nabigo sa susunod na pagtuklas, at muling nagre-restart. Nagpapatuloy ang cycle na ito hanggang sa mangyari ang timeout.

Mga Hakbang sa Pag-troubleshoot at Pagkukumpuni para sa Pagsubaybay sa Apache2 sa HestiaCP Environment

Sa totoo lang, hindi naman kumplikado ang proseso ng imbestigasyon, pero kailangan mong malaman kung saang direksyon mag-iimbestiga.

Ang unang hakbang ay ang pagtukoy kung saang port nakikinig ang iyong Apache2. Mag-type lamang ng command sa terminal.

netstat -tulpn | grep apache2

Bilang kahalili, maaari mong gamitin ang utos na `ss`; pareho lang ang epekto.

ss -tulpn | grep apache2

Makakakita ka ng output na katulad nito.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

Kumpirmadong 8081 ito, hindi 80. Iyan ang ugat ng problema.

Ang pangalawang hakbang ay ang pag-aayos ng sirang PID file. Mas simple ito.

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

Una, i-pause ang Monit monitoring para maiwasan itong makagambala habang inaayos mo ang mga bagay-bagay. Pagkatapos, i-restart ang Apache2 para makapagsulat muli ito ng malinis na PID. Panghuli, gamitin ang `cat` para suriin ang nilalaman ng file; dapat itong maglaman ng isang string ng mga numero, hindi isang walang laman na string.

Kapag nakumpleto na ang hakbang na ito, ang problema ay karaniwang nalutas na.

Paghahambing na Pagsusuri ng mga Tradisyonal na Adaptive at Agresibong Protective Configuration ng Monit

Ang mga online na tutorial sa pag-configure ng Apache2 gamit ang Monit ay karaniwang nahahati sa dalawang kategorya.

Ang isang uri ay ang "tradisyonal na uri ng adaptasyon," na gumagamit ng utos na `service` upang pamahalaan ang mga serbisyo at suriin ang mga lokal na port nang hindi nagdaragdag ng napakaraming kumplikadong mga paghihigpit. Ang configuration na ito ay maaaring gamitin sa HestiaCP sa pamamagitan lamang ng pagpapalit ng port, at ito ay medyo matatag.

Ang isa pang pamamaraan ay ang pamamaraang "agresibong proteksyon", na gumagamit ng systemctl upang pamahalaan ang mga serbisyo, nagdaragdag ng mga paghihigpit sa proseso ng anak, at gumagamit ng mas mahigpit na lohika ng pagtuklas. Maganda ang hitsura nito, ngunit mayroon itong isang nakamamatay na depekto: ang utos na stop na ginamit ay `killall -9`.

Ano ang ibig sabihin ng `killall -9`? Ang ibig sabihin nito ay sapilitang pagpatay sa device anuman ang ginagawa nito. Ang brute-force operation na ito ay madaling makapag-iwan ng mga sirang PID file, na siyang problemang nabanggit ko lang.

Ang personal kong karanasan ay ang paglimita sa bilang ng mga child process sa isang agresibong configuration ay talagang kapaki-pakinabang. Kapag ang iyong Apache2 ay nalulula sa isang CC attack, ang paglimita sa bilang ng mga child process ay maaaring maiwasan ang pagkaubusan ng memorya ng server. Gayunpaman, ang pamamaraang `killall -9` ay talagang hindi magagamit.

Kaya sa huli ay nakipagkompromiso ako at pinagsama ang mga bentahe ng parehong configuration.

Pag-configure ng Pinakamahusay na Kasanayan sa HestiaCP Apache2 Monitor

Baguhin ang file na /etc/monit/conf.d/apache2 gamit ang sumusunod na nilalaman.

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

Hayaan ninyong ipaliwanag ko nang maikli ang lohika sa likod ng ilang linyang ito ng pagsasaayos.

Isulat ang port 8081 upang eksaktong tumugma sa reverse proxy architecture ng HestiaCP; itigil ang kalokohang pagsusulat ng port 80.

Gamitin ang utos na `systemctl stop` sa halip na `killall -9` upang ihinto ang PID file, nang sa gayon ay hindi ito masira.

Nagdagdag ng limitasyon sa proseso ng anak: kung ang bilang ng mga anak ay lumampas sa 120, ang proseso ay magsisimula muli pagkatapos ng dalawang magkasunod na siklo upang maiwasan ang mga pag-atake ng CC, ngunit hindi ito masyadong agresibo.

Ang lohika para sa pagtukoy ng mga pagkabigo ay binago upang gumamit ng pamamaraang "para sa 2 siklo", ibig sabihin ang pag-restart ay nati-trigger lamang pagkatapos ng dalawang magkasunod na pagkabigo, na binabawasan ang mga maling positibo. Ang nakaraang configuration, na nag-restart pagkatapos lamang ng isang pagtuklas, ay lantaran na medyo masyadong sensitibo.

Ang huling timeout threshold ay niluluwagan sa 5 restart sa loob ng 10 cycle, na nag-iiwan ng sapat na fault tolerance.

HestiaCP Pagsubaybay sa monitorBuod ng Pag-troubleshoot ng Configuration at Pagbabahagi ng Karanasan

Matapos gawin ang mga pagbabago sa configuration, minanmanan ko ang apache2, at sa wakas ay nagpakita ang panel ng berdeng "OK" indicator.

Paano ko ilalarawan ang nararamdaman ko noon? Parang gumugol ako ng dalawang araw sa pakikipaglaban sa isang bug, para lang malaman na ang sanhi ay isang linya ng configuration na mali. Nakakadismaya at nakakatawa.

Mabuti na ang Monit sa ganang sarili nito, at ang pagsubaybay sa mga daemon ay isang bagay na dapat gawin ng bawat server. Ngunit ang problema ay maraming online tutorial ang nakabatay sa palagay na "Ang Apache2 ay eksklusibong gumagamit ng port 80," habang ang HestiaCP ay gumagamit ng reverse proxy, na nangangahulugang ang palagay na ito ay hindi totoo.

Kung susundin mo ang mga tagubilin, ang problema ay hindi ikaw; ito ay ang tutorial ay naaangkop sa ibang senaryo kaysa sa iyo.

Kaya kung gumagamit ka rin ng HestiaCP at ginagamit ang Monit para i-monitor ang Apache2, tandaan lamang ang dalawang bagay: Baguhin ang port sa 8081, at gamitin ang utos na `systemctl` para ihinto ito, hindi ang `killall -9`. Kung gagawin mo ang dalawang bagay na ito, dapat ay maiiwasan mo ang mas maraming problema.

Dahil nabasa mo na ito hanggang dito, kung nakatulong ito sa iyo, paki-like at share naman. Kung gusto mo munang makatanggap ng mga update, puwede mo rin akong sundan!

Salamat sa pagbabasa ng aking artikulo. Sa susunod na lang ulit.