Apache2:n usein kaatumisia HestiaCP:n kanssa? Monitin automaattinen valvonta- ja vianmääritysopas (täydellinen kokoonpano)

Usein esiintyviä Apache2-kaatumisia tai Monitin automaattisen uudelleenkäynnistyksen virheitä HestiaCP- ympäristöissä? Tämä artikkeli tarjoaa käytännön oppaan yleisten sudenkuoppien välttämiseen Apache2:n valvonnassa Monitin avulla. Se analysoi perusteellisesti yleisiä ongelmia, kuten PID-polun virheellistä kohdistusta ja käyttöoikeuksien estoa, ja tarjoaa tuotantotason Monit-automaatiokonfiguraatiotiedostoja. Hallitse korkean käytettävyyden palvelimen ylläpitotekniikat nyt ja saavuta toisen tason automaattinen palautuminen virheistä!

Sudenkuopat, joita kohtasin käyttäessäni Monitia Apache2:n valvontaan

Viime perjantaina palvelin antoi minulle Monit-hälytyksen keskellä yötä.

Vilkaisin paneelia hämmentyneenä, ja apache2:n tilasarakkeessa oli punainen aikakatkaisu.

Mietin asiaa hetken. Lisäsin juuri Monit-valvonnan palvelimelle päivän aikana ja kopioin ja liitin määritykset verkko-opetusohjelmasta. Eihän siinä pitäisi olla mitään ongelmia?

Seuraavana aamuna aikakatkaistiin uudelleen. Kolmannen kerran jälkeen Monitor yksinkertaisesti luovutti, ja paneelissa näkyi "Ei valvottu".

Minä...

Myönnän, etten ottanut sitä aluksi vakavasti. Apache2-valvonta? Löydät verkosta valtavasti malleja konfiguraatioista, kopioi ja liitä ne vain. Mutta tuo liittämisprosessi todella raivostutti minua.

HestiaCP:n oletusarkkitehtuurin ja Monit-porttien välisen ristiriidan perimmäinen syy

Näytänpä ensin sinulle kokoonpanon, joka aiheutti minulle niin paljon ongelmia, jotta näet, onko se täsmälleen sama kuin näkemäsi versio.

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

Näyttää ihan hyvältä, eikö niin? Se tarkistaa portin 80, ja jos se kaatuu, se käynnistyy uudelleen. Jos se kaatuu edelleen viiden uudelleenkäynnistyksen jälkeen, se aikakatkaistaan.

Ongelmana on, että Apache2 ei edes toimi portissa 80.

Tämä on HestiaCP:n sudenkuoppa ja perimmäinen syy siihen, miksi monet ihmiset lankeavat siihen. HestiaCP:n oletusarkkitehtuuri on Nginxin + Apache2:n käänteinen välityspalvelin, jossa Nginx käyttää edessä olevia portteja 80 ja 443 ja Apache2 toimii takana olevassa paikallisessa portissa 8081.

Jos pyydät Monitia tarkistamaan Apache2:n toimivuuden portissa 80, se on kuin menisit McDonald'siin etsimään KFC:tä. Tarjoilija katsoo sinua tyhjästi ja te kaksi tuijotatte toisianne. Lopulta Monit toteaa, että olet kaatunut, ja alkaa vimmatusti käynnistää palvelimesi uudelleen.

Uudelleenkäynnistyksen jälkeen portti on edelleen 8081. Monit yrittää sitten muodostaa yhteyden porttiin 80, mutta sekin epäonnistuu, joten se käynnistyy uudelleen. Tämä sykli toistuu, kunnes Monit päättää, että vikaa ei voida korjata, ja aikakatkaisee sen.

Kun törmäsin tähän ensimmäisen kerran, olin todella ällistynyt. Yhdeksän kymmenestä verkosta löytämästäni opetusohjelmasta käytti porttia 80. Jos noudatit niitä, ongelma ei ollut sinussa, vaan itse tiedonlähteessä.

Vioittunut Apache2 PID -tiedosto sai Monitin virheellisesti tunnistamaan prosessin olemattomaksi.

Vaihdettuani portin 80:stä 8081:een, Monitin pitäisi teoriassa pystyä tunnistamaan se, eikö niin?

Todellisuudessa se kuitenkin ilmoittaa edelleen ajoittain "Suoritus epäonnistui ".

Pitkän pohtimisen jälkeen vihdoin huomasin, että syy oli yksinkertainen: PID-tiedosto oli vioittunut.

Ajattelepa, Monit käynnisti Apache2:n kuumeisesti uudelleen, joka kerta väkisin sammuttaen ja käynnistäen sen uudelleen, edestakaisin useita kertoja. Tänä aikana tiedosto /var/run/apache2/apache2.pid saattoi muuttua 0 tavun kokoiseksi.

Toisin sanoen tiedosto on edelleen olemassa, mutta se on tyhjä.

Kun Monit lukee tätä tiedostoa, se ei löydä mitään. Se ei tunnista Apache2-prosessiasi, vaikka se toimisikin täysin moitteettomasti taustalla; Monit ei usko prosessin olevan olemassa.

Kun näin tämän, olin hetken sanaton.

Tämä on umpikuja. Monit ei tunnista Apache 2 -instanssia, käynnistää Apache2:n uudelleen, vioittaa PID-tiedoston uudelleenkäynnistyksen aikana, epäonnistuu seuraavassa tunnistuksessa ja käynnistyy uudelleen. Tämä sykli jatkuu, kunnes aikakatkaisu tapahtuu.

Apache2-valvonnan vianmääritys- ja korjausvaiheet HestiaCP-ympäristössä

Rehellisesti sanottuna tutkintaprosessi ei ole monimutkainen, mutta sinun on tiedettävä, mihin suuntaan tutkia.

Ensimmäinen vaihe on selvittää, mitä porttia Apache2-palvelimesi kuuntelee. Kirjoita vain komento terminaaliin.

netstat -tulpn | grep apache2

Vaihtoehtoisesti voit käyttää komentoa `ss`; vaikutus on sama.

ss -tulpn | grep apache2

Näet tämänkaltaisen tulosteen.

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

Sen on vahvistettu olevan 8081, ei 80. Se on ongelman ydin.

Toinen vaihe on korjata vioittunut PID-tiedosto. Tämä on yksinkertaisempaa.

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

Keskeytä ensin Monitin valvonta estääksesi sitä häiritsemästä korjauksia. Käynnistä sitten Apache2 uudelleen, jotta se voi kirjoittaa puhtaan PID:n uudelleen. Lopuksi tarkista tiedoston sisältö `cat`-komennolla; sen tulisi sisältää numeromerkkijono, ei tyhjää merkkijonoa.

Kun tämä vaihe on suoritettu, ongelma on periaatteessa ratkaistu.

Monitin perinteisten adaptiivisten ja aggressiivisten suojauskonfiguraatioiden vertaileva analyysi

Apache2:n ja Monitin konfigurointia käsittelevät verkko-oppaat voidaan yleensä jakaa kahteen luokkaan.

Yksi tyyppi on "perinteinen mukautustyyppi", joka käyttää `service`-komentoa palveluiden hallintaan ja paikallisten porttien tarkistamiseen lisäämättä liian monia monimutkaisia ​​rajoituksia. Tätä kokoonpanoa voidaan käyttää HestiaCP:ssä yksinkertaisesti vaihtamalla porttia, ja se on suhteellisen vakaa.

Toinen lähestymistapa on "aggressiivinen suojaus" -menetelmä, joka käyttää systemctl-komentoa palveluiden hallintaan, lisää lapsiprosessien rajoituksia ja soveltaa tiukempaa tunnistuslogiikkaa. Se näyttää hyvältä, mutta siinä on kohtalokas heikkous: käytetty pysäytyskomento on `killall -9`.

Mitä `killall -9` tarkoittaa? Se tarkoittaa laitteen pakotettua sulkemista riippumatta siitä, mitä se tekee. Tämä raa'an voiman operaatio voi helposti vioittua PID-tiedostoissa, mikä on juuri mainitsemani ongelma.

Oma kokemukseni on, että aggressiivisessa kokoonpanossa lapsiprosessien määrän rajoittaminen on todella hyödyllistä. Kun Apache2-palvelimesi ylikuormittuu CC-hyökkäyksen kohteeksi, lapsiprosessien määrän rajoittaminen voi estää palvelimen muistin loppumisen. `killall -9`-lähestymistapa on kuitenkin todella käyttökelvoton.

Joten lopulta tein kompromissin ja yhdistin molempien kokoonpanojen edut.

HestiaCP Apache2 Monitin parhaiden käytäntöjen konfigurointi

Muokkaa tiedostoa /etc/monit/conf.d/apache2 seuraavalla sisällöllä.

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

Selitän lyhyesti näiden muutaman rivin kokoonpanon taustalla olevan logiikan.

Kirjoita portti 8081 vastaamaan täsmälleen HestiaCP:n käänteisen välityspalvelimen arkkitehtuuria; lopeta typerä portin 80 kirjoittaminen.

Käytä komentoa `systemctl stop` komentoa `killall -9`-komennon sijaan pysäyttääksesi PID-tiedoston, jotta se ei vioittuisi.

Lapsiprosessien rajoitus on lisätty: jos lapsiprosessien määrä ylittää 120, prosessi käynnistyy uudelleen kahden peräkkäisen syklin jälkeen CC-hyökkäysten estämiseksi, mutta tämä ei ole liian aggressiivinen.

Vikojen havaitsemislogiikkaa on muokattu käyttämään "kahden syklin ajan" -lähestymistapaa, mikä tarkoittaa, että uudelleenkäynnistys laukaistaan ​​vasta kahden peräkkäisen vian jälkeen, mikä vähentää vääriä positiivisia tuloksia. Aiempi kokoonpano, joka käynnisti uudelleen vain yhden havainnon jälkeen, oli rehellisesti sanottuna hieman liian herkkä.

Lopullista aikakatkaisukynnystä lievennetään viiteen uudelleenkäynnistykseen 10 syklin aikana, mikä jättää riittävän vikasietoisuuden.

HestiaCP Valvo seurantaaKonfiguraation vianmäärityksen yhteenveto ja kokemusten jakaminen

Tehtyäni kokoonpanomuutokset, valvoin apache2:ta, ja paneeli näytti lopulta vihreää "OK"-merkkivaloa.

Kuinka kuvailisin tunteitani silloin? Se oli kuin olisin paininut kahden päivän ajan bugin kanssa ja huomannut, että syynä oli yksi ainoa väärä rivi asetuksissa. Se oli sekä turhauttavaa että naurettavaa.

Monit on itsessään hyvä asia, ja daemonien valvonta on jokaisen palvelimen tehtävä. Ongelmana on kuitenkin se, että monet verkko-oppaat perustuvat oletukseen, että "Apache2 käyttää yksinomaan porttia 80", kun taas HestiaCP käyttää käänteistä välityspalvelinta, mikä tarkoittaa, että tämä oletus ei pidä paikkaansa.

Jos noudatat ohjeita, ongelma ei ole sinussa, vaan siinä, että opetusohjelma soveltuu eri tilanteeseen kuin sinun.

Jos siis käytät myös HestiaCP:tä ja säätät Monitia Apache2:n valvontaan, muista kaksi asiaa: Vaihda portti 8081:een ja käytä komentoa `systemctl` pysäyttääksesi sen, äläkä komentoa `killall -9`. Jos teet nämä kaksi asiaa, sinun pitäisi pystyä välttämään lisäongelmia.

Koska olet lukenut tähän asti, jos pidit siitä hyödyllisenä, tykkää ja jaa se. Jos haluat saada päivityksiä ensimmäisenä, voit myös seurata minua!

Kiitos, että luit artikkelini. Nähdään taas ensi kerralla.