Apache2 sagedased krahhid HestiaCP-ga? Moniti automatiseeritud jälgimise ja tõrkeotsingu juhend (täieliku konfiguratsiooniga)

Sagedased Apache2 krahhid või Moniti automaatse taaskäivitamise tõrked HestiaCP keskkondades? See artikkel annab praktilise juhendi, kuidas vältida levinud lõkse Apache2 jälgimisel Moniti abil, analüüsides põhjalikult levinud probleeme, nagu PID-tee joondusviga ja lubade blokeerimine, ning pakkudes tootmisklassi Moniti automatiseerimise konfiguratsioonifaile. Õppige kohe selgeks serveri kõrge käideldavusega hooldustehnikad ja saavutage teise taseme automaatne taastumine tõrgetest!

Lõksud, millega Moniti kasutamisel Apache2 jälgimiseks kokku puutusin

Eelmisel reedel andis server mulle keset ööd Moniti hoiatuse.

Heitsin uimaselt pilgu paneelile ja apache2 oleku veerus oli punane ajalõpu kiri.

Mõtlesin selle üle natuke. Lisasin Moniti jälgimise serverile päeva jooksul ja kopeerisin konfiguratsiooni veebijuhendist. Probleeme ei tohiks tekkida, eks?

Järgmisel hommikul aegus see uuesti. Kolmanda korra järel andis Monitor lihtsalt alla ja paneelil kuvati "Ei jälgita".

Mina...

Tunnistan, et alguses ma seda tõsiselt ei võtnud. Apache2 jälgimine? Internetist leiab hulgaliselt konfiguratsioonimalle, lihtsalt kopeeri ja kleebi. Aga see kleepimisprotsess ajas mind tõesti marru.

HestiaCP vaikesätete arhitektuuri ja Moniti portide konflikti algpõhjus

Lubage mul kõigepealt näidata teile konfiguratsiooni, mis mulle nii palju probleeme tekitas, et saaksite näha, kas see on täpselt sama versioon, mida olete näinud.

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

Tundub korras olevat, eks? See kontrollib porti 80 ja kui see kokku jookseb, siis taaskäivitub. Kui see pärast 5 taaskäivitamist ikka kokku jookseb, siis aegub.

Probleem on selles, et teie Apache2 ei tööta isegi pordil 80.

See on HestiaCP lõks ja peamine põhjus, miks paljud inimesed sellesse langevad. HestiaCP vaikearhitektuur on Nginx + Apache2 pöördproksi, kus Nginx hõivab eesmised pordid 80 ja 443 ning Apache2 töötab tagaosas asuval kohalikul pordil 8081.

Kui paluda Monitil kontrollida Apache2 aktiivsust pordil 80, on see nagu McDonald'sis KFC-d otsimine. Teenindaja vaatab sind tühja pilguga ja teie kaks jõllitate teineteist. Lõpuks otsustab Monit, et sa oled maas ja hakkab meeleheitlikult taaskäivitama.

Pärast taaskäivitamist on port endiselt 8081. Seejärel proovib Monit ühendust luua pordiga 80, mis samuti ebaõnnestub, seega taaskäivitub see uuesti. See tsükkel kordub seni, kuni Monit otsustab, et seda pole enam võimalik parandada, ja aegub.

Kui ma sellega esimest korda kokku puutusin, olin siiralt jahmunud. Üheksa kümnest veebist leitud õpetusest kasutasid porti 80. Kui sa neid järgisid, polnud probleem sinus, vaid infoallikas endas.

Rikutud Apache2 PID-faili tõttu tuvastas Monit ekslikult protsessi olematuks.

Pärast pordi 80-lt 8081-le muutmist peaks Monit teoreetiliselt suutma selle tuvastada, eks?

Tegelikkuses annab see siiski aeg-ajalt teada, et "Täitmine ebaõnnestus ".

Pärast pikka vaeva nägemist avastasin lõpuks, et põhjus oli lihtne: PID-fail oli rikutud.

Mõtle sellele, Monit taaskäivitas meeleheitlikult Apache2-e, iga kord jõuga seda tappes ja taaskäivitades, mitu korda edasi-tagasi liikudes. Selle protsessi käigus võis fail /var/run/apache2/apache2.pid muutuda 0 baiti suuruseks.

Teisisõnu, fail on küll alles, aga tühi.

Kui Monit seda faili loeb, ei leia see midagi. See ei tunne teie Apache2 ära, isegi kui see taustal laitmatult töötab; Monit ei arva, et see protsess olemas on.

Kui ma seda nägin, jäin hetkeks sõnatuks.

See on ummikseis. Monitil ei õnnestu Apache 2 eksemplari tuvastada, see taaskäivitab Apache2, rikub taaskäivitamise käigus PID-faili, järgmine tuvastamine ebaõnnestub ja taaskäivitub uuesti. See tsükkel jätkub kuni ajalõpuni.

Apache2 jälgimise tõrkeotsingu ja parandamise sammud HestiaCP keskkonnas

Ausalt öeldes pole uurimisprotsess keeruline, aga peate teadma, millises suunas uurida.

Esimene samm on kindlaks teha, millist porti teie Apache2 kuulab. Lihtsalt sisestage terminalis käsk.

netstat -tulpn | grep apache2

Teise võimalusena võite kasutada käsku `ss`; efekt on sama.

ss -tulpn | grep apache2

Näete sarnast väljundit.

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

On kinnitust leidnud, et see on 8081, mitte 80. See on probleemi juur.

Teine samm on rikutud PID-faili parandamine. See on lihtsam.

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

Esmalt peata Moniti jälgimine, et see ei segaks sind parandamise ajal. Seejärel taaskäivita Apache2, et see saaks puhta PID-i ümber kirjutada. Lõpuks kontrolli faili sisu käsuga `cat`; see peaks sisaldama numbrijada, mitte tühja stringi.

Kui see samm on lõpule viidud, on probleem põhimõtteliselt lahendatud.

Moniti traditsiooniliste adaptiivsete ja agressiivsete kaitsekonfiguratsioonide võrdlev analüüs

Apache2 Monitiga seadistamise veebipõhised õpetused jagunevad üldiselt kahte kategooriasse.

Üks tüüp on "traditsiooniline kohandamise tüüp", mis kasutab teenuste haldamiseks ja kohalike portide kontrollimiseks käsku `service` ilma liiga palju keerulisi piiranguid lisamata. Seda konfiguratsiooni saab HestiaCP-s kasutada lihtsalt porti muutes ja see on suhteliselt stabiilne.

Teine lähenemisviis on "agressiivse kaitse" meetod, mis kasutab teenuste haldamiseks systemctl-i, lisab alamprotsessidele piiranguid ja rakendab rangemat tuvastusloogikat. See näeb hea välja, kuid sellel on saatuslik viga: kasutatav stopp-käsk on `killall -9`.

Mida tähendab käsk `killall -9`? See tähendab seadme sundtappamist olenemata sellest, mida see teeb. See jõuetu toiming võib kergesti jätta rikutud PID-failid maha, mis ongi probleem, mida ma just mainisin.

Minu isiklik kogemus näitab, et agressiivses konfiguratsioonis on lapseprotsesside arvu piiramine tõepoolest kasulik. Kui teie Apache2 on CC-rünnaku poolt ülekoormatud, saab lapseprotsesside arvu piiramisega ära hoida serveri mälu otsa saamise. `killall -9` lähenemisviis on aga täiesti kasutuskõlbmatu.

Seega lõpuks tegin kompromissi ja ühendasin mõlema konfiguratsiooni eelised.

HestiaCP Apache2 Moniti parimate tavade seadistamine

Muutke faili /etc/monit/conf.d/apache2 järgmise sisuga.

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

Lubage mul lühidalt selgitada nende paari konfiguratsioonirea taga olevat loogikat.

Kirjuta port 8081 täpselt nii, et see vastaks HestiaCP pöördproksi arhitektuurile; lõpeta pordi 80 rumal kirjutamine.

PID-faili peatamiseks, et seda mitte rikkuda, kasutage käsu `killall -9` asemel käsku `systemctl stop`.

Lisatud on alamprotsesside piirang: kui alamprotsesside arv ületab 120, taaskäivitub protsess pärast kahte järjestikust tsüklit, et vältida CC-rünnakuid, kuid see pole liiga agressiivne.

Rikete tuvastamise loogikat on muudetud nii, et see kasutab nüüd "2 tsükli" lähenemisviisi, mis tähendab, et taaskäivitamine käivitatakse alles pärast kahte järjestikust tõrget, vähendades valepositiivseid tulemusi. Eelmine konfiguratsioon, mis taaskäivitati juba pärast ühte tuvastamist, oli ausalt öeldes veidi liiga tundlik.

Lõplikku ajalõpu läve vähendatakse 5 taaskäivituseni 10 tsükli jooksul, jättes piisava veataluvuse.

HestiaCP Jälgige jälgimistKonfiguratsiooni tõrkeotsingu kokkuvõte ja kogemuste jagamine

Pärast konfiguratsioonimuudatuste tegemist jälgisin apache2-e ja paneel näitas lõpuks rohelist "OK" indikaatorit.

Kuidas ma oma tolleaegseid tundeid kirjeldada saaksin? See oli nagu kaks päeva veaga maadlemine, mille järel selgus, et põhjuseks oli üksainus vale konfiguratsioonirida. See oli nii frustreeriv kui ka naeruväärne.

Monit on iseenesest hea asi ja deemonite jälgimine on midagi, mida iga server peaks tegema. Probleem on aga selles, et paljud veebipõhised õpetused põhinevad eeldusel, et "Apache2 kasutab ainult porti 80", samas kui HestiaCP kasutab pöördproksit, mis tähendab, et see eeldus ei pea paika.

Kui järgid juhiseid, pole probleem sinus, vaid selles, et õpetust saab rakendada teistsuguses stsenaariumis kui sinu oma.

Seega, kui sa kasutad ka HestiaCP-d ja mässad Monitiga Apache2 jälgimiseks, siis pea meeles kahte asja: muuda port 8081-ks ja kasuta selle peatamiseks käsku `systemctl`, mitte käsku `killall -9`. Kui sa teed neid kahte asja, peaksid sa suutma edaspidiseid probleeme vältida.

Kuna oled siiani lugenud, siis kui see oli sulle kasulik, siis palun laigi ja jaga seda. Kui soovid esimesena uuendusi saada, võid mind ka jälgida!

Tänan teid minu artikli lugemise eest. Näeme järgmine kord.