Dažni „Apache2“ gedimai naudojant „HestiaCP“? „Monit“ automatinio stebėjimo ir trikčių šalinimo vadovas (su visa konfigūracija)

Dažni „Apache2“ gedimai arba automatinio „Monit“ paleidimo gedimai „HestiaCP“ aplinkose? Šiame straipsnyje pateikiamas praktinis vadovas, kaip išvengti dažniausiai pasitaikančių „Apache2“ stebėjimo naudojant „Monit“ klaidų, išsamiai analizuojant dažniausiai pasitaikančias problemas, tokias kaip PID kelio nesutapimas ir leidimų blokavimas, bei siūlant gamybinės klasės „Monit“ automatizavimo konfigūracijos failus. Įvaldykite didelio prieinamumo serverių priežiūros metodus dabar ir pasiekite antro lygio automatinį atkūrimą po gedimų!

Spąstai, su kuriais susidūriau naudodamas „Monit“ Apache2 stebėjimui

Praėjusį penktadienį serveris vidury nakties man davė „Monit“ įspėjimą.

Apsvaigęs žvilgtelėjau į skydelį ir „apache2“ būsenos stulpelyje radau raudoną „Timeout“ ženklą.

Šiek tiek pagalvojau. Ką tik dienos metu įdiegiau „Monit“ stebėjimą serveryje ir nukopijavau bei įklijavau konfigūraciją iš internetinio vadovėlio. Neturėtų kilti jokių problemų, tiesa?

Kitą rytą vėl užstringa skirtasis laikas. Po trečio karto „Monitor“ tiesiog pasidavė, o prietaisų skydelyje pasirodė „Not monitored“ (nestebima).

Aš...

Prisipažįstu, iš pradžių į tai nežiūrėjau rimtai. „Apache2“ stebėjimas? Internete galite rasti daugybę konfigūracijų šablonų, tiesiog nukopijuokite ir įklijuokite. Bet tas įklijavimo procesas mane tikrai įsiutino.

Pagrindinė konflikto tarp numatytosios „HestiaCP“ architektūros ir „Monit“ prievadų priežastis

Pirmiausia leiskite man parodyti konfigūraciją, kuri man sukėlė tiek daug problemų, kad galėtumėte pamatyti, ar ji visiškai tokia pati kaip matyta versija.

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

Atrodo viskas gerai, tiesa? Patikrina 80 prievadą ir, jei sugenda, paleidžiamas iš naujo. Jei vis tiek sugenda po 5 paleidimų iš naujo, laikas baigiasi.

Problema ta, kad jūsų „Apache2“ net neveikia 80 prievadu.

Tai yra „HestiaCP“ spąstai ir pagrindinė daugelio žmonių įkyrėjimo priežastis. Numatytoji „HestiaCP“ architektūra yra atvirkštinis „Nginx“ + „Apache2“ tarpinis serveris, kai „Nginx“ užima 80 ir 443 prievadus priekyje, o „Apache2“ veikia vietiniame 8081 prievade gale.

Jei paprašysite Monit patikrinti „Apache2“ serverio gyvumą 80 prievade, tai bus tas pats, kas eiti į „McDonald's“ ieškoti KFC. Padavėjas į jus žiūrės tuščiu žvilgsniu, o jūs abu spoksosite vienas į kitą. Galiausiai Monit nustato, kad neveikiate, ir pradeda beprotiškai paleisti sistemą iš naujo.

Po perkrovimo prievadas vis dar yra 8081. Tada „Monit“ bando patikrinti 80 prievadą, bet tai taip pat nepavyksta, todėl sistema vėl paleidžiama iš naujo. Šis ciklas kartojasi tol, kol „Monit“ nusprendžia, kad gedimo nebeįmanoma išspręsti, ir baigiasi skirtasis laikas.

Kai pirmą kartą su tuo susidūriau, buvau nuoširdžiai apstulbęs. Devyni iš dešimties internete rastų pamokų naudojo 80 prievadą. Jei jų laikydavotės, problema buvo ne jumyse, o pačiame informacijos šaltinyje.

Sugadintas „Apache2“ PID failas privertė „Monit“ klaidingai identifikuoti procesą kaip neegzistuojantį.

Pakeitus prievadą iš 80 į 8081, „Monit“ teoriškai turėtų jį aptikti, ar ne?

Tačiau iš tikrųjų kartais vis dar pranešama apie „Vykdymas nepavyko “.

Ilgai vargęs, pagaliau atradau, kad priežastis paprasta: PID failas buvo sugadintas.

Pagalvokite, „Monit“ beprotiškai perkraudavo „Apache2“, kaskart jį priverstinai uždrausdama ir paleisdama iš naujo, kelis kartus kartodama veiksmus. Šio proceso metu failas /var/run/apache2/apache2.pid galėjo tapti 0 baitų dydžio.

Kitaip tariant, failas vis dar yra, bet jis tuščias.

Kai „Monit“ nuskaito šį failą, ji nieko neranda. Ji neatpažįsta jūsų „Apache2“, net jei jūsų „Apache2“ puikiai veikia fone; „Monit“ nemano, kad šis procesas egzistuoja.

Kai tai pamačiau, akimirką netekau žado.

Tai aklavietė. „Monit“ nepavyksta aptikti „Apache 2“ egzemplioriaus, jis paleidžia „Apache 2“ iš naujo, paleidimo iš naujo metu sugadina PID failą, kitas aptikimas nepavyksta ir sistema vėl paleidžiama iš naujo. Šis ciklas tęsiasi tol, kol pasibaigia skirtasis laikas.

„Apache2“ stebėjimo trikčių šalinimo ir taisymo veiksmai „HestiaCP“ aplinkoje

Tiesą sakant, tyrimo procesas nėra sudėtingas, tačiau reikia žinoti, kuria kryptimi tirti.

Pirmas žingsnis – nustatyti, kuriame prievade jūsų „Apache2“ klausosi. Tiesiog įveskite komandą terminale.

netstat -tulpn | grep apache2

Arba galite naudoti komandą „ss“; efektas yra tas pats.

ss -tulpn | grep apache2

Pamatysite panašų rezultatą.

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

Patvirtinta, kad tai 8081, o ne 80. Tai yra problemos šaknis.

Antras žingsnis – taisyti sugadintą PID failą. Tai paprasčiau.

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

Pirmiausia pristabdykite „Monit“ stebėjimą, kad jis netrukdytų taisyti sistemos. Tada paleiskite „Apache2“ iš naujo, kad jis galėtų perrašyti švarų PID. Galiausiai, naudodami „cat“ patikrinkite failo turinį; jame turėtų būti skaičių eilutė, o ne tuščia eilutė.

Kai šis žingsnis bus atliktas, problema iš esmės bus išspręsta.

„Monit“ tradicinių adaptyviųjų ir agresyviųjų apsaugos konfigūracijų lyginamoji analizė

Internetinės pamokos apie „Apache2“ konfigūravimą su „Monit“ paprastai skirstomos į dvi kategorijas.

Vienas tipas yra „tradicinis adaptacijos tipas“, kuris naudoja komandą „service“ paslaugoms valdyti ir vietiniams prievadams tikrinti nepridedant per daug sudėtingų apribojimų. Ši konfigūracija gali būti naudojama „HestiaCP“ tiesiog pakeičiant prievadą, ir ji yra gana stabili.

Kitas būdas yra „agresyvios apsaugos“ metodas, kuris naudoja „systemctl“ paslaugoms valdyti, prideda apribojimus antriniams procesams ir taiko griežtesnę aptikimo logiką. Jis atrodo puikiai, bet turi esminį trūkumą: naudojama sustabdymo komanda yra `killall -9`.

Ką reiškia „killall -9“? Tai reiškia priverstinai nutraukti įrenginio veikimą, nepriklausomai nuo to, ką jis daro. Ši „brute-force“ operacija gali lengvai sugadinti PID failus, ir tai yra problema, kurią ką tik minėjau.

Mano asmeninė patirtis rodo, kad agresyvioje konfigūracijoje antrinių procesų skaičiaus ribojimas iš tiesų yra naudingas. Kai jūsų „Apache2“ serverį užvaldo CC ataka, antrinių procesų skaičiaus ribojimas gali padėti išvengti serverio atminties pritrūkimo. Tačiau metodas „killall -9“ yra visiškai netinkamas.

Taigi galiausiai padariau kompromisą ir sujungiau abiejų konfigūracijų privalumus.

„HestiaCP Apache2 Monit“ geriausios praktikos konfigūracija

Pakeiskite failą /etc/monit/conf.d/apache2 tokiu turiniu.

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

Leiskite man trumpai paaiškinti šių kelių konfigūracijos eilučių logiką.

Įrašykite 8081 prievadą, kad jis tiksliai atitiktų „HestiaCP“ atvirkštinio tarpinio serverio architektūrą; nustokite kvailai rašyti 80 prievadą.

Norėdami sustabdyti PID failą, kad jo nesugadintumėte, vietoj `killall -9` naudokite komandą `systemctl stop`.

Pridėtas antrinių procesų apribojimas: jei antrinių procesų skaičius viršija 120, procesas bus paleistas iš naujo po dviejų iš eilės einančių ciklų, siekiant išvengti CC atakų, tačiau tai nėra pernelyg agresyvu.

Gedimų aptikimo logika buvo pakeista, kad būtų naudojamas „2 ciklų“ metodas, o tai reiškia, kad perkrovimas suaktyvinamas tik po dviejų iš eilės gedimų, taip sumažinant klaidingai teigiamų rezultatų skaičių. Ankstesnė konfigūracija, kuri buvo perkrovimas po vos vieno aptikimo, buvo, tiesą sakant, šiek tiek pernelyg jautri.

Galutinė skirtojo laiko riba sušvelninama iki 5 paleidimų iš naujo per 10 ciklų, paliekant pakankamą atsparumą gedimams.

HestiaCP Stebėti stebėjimąKonfigūracijos trikčių šalinimo santrauka ir patirties pasidalijimas

Atlikęs konfigūracijos pakeitimus, stebėjau „apache2“ ir galiausiai skydelyje pasirodė žalias „OK“ indikatorius.

Kaip apibūdinti tuo metu savo jausmus? Tai buvo tarsi dvi dienos kovojant su klaida, o tada paaiškėja, kad jos priežastis – viena neteisinga konfigūracijos eilutė. Tai buvo ir erzinanti, ir juokinga.

„Monit“ savaime yra geras dalykas, o demonų stebėjimas yra tai, ką turėtų daryti kiekvienas serveris. Tačiau problema ta, kad daugelis internetinių vadovėlių yra pagrįsti prielaida, kad „Apache2 naudoja tik 80 prievadą“, o „HestiaCP“ naudoja atvirkštinį tarpinį serverį, o tai reiškia, kad ši prielaida nėra teisinga.

Jei vykdysite instrukcijas, problema ne jumyse; problema ta, kad vadovėlis taikomas kitam scenarijui nei jūsų.

Taigi, jei naudojate „HestiaCP“ ir žaidžiate su „Monit“, kad stebėtumėte „Apache2“, tiesiog nepamirškite dviejų dalykų: pakeiskite prievadą į 8081 ir sustabdykite jį naudodami komandą „systemctl“, o ne „killall -9“. Jei atliksite šiuos du dalykus, turėtumėte išvengti daugiau problemų.

Kadangi jau perskaitėte iki šiol, jei manote, kad tai buvo naudinga, prašome paspausti „patinka“ ir pasidalyti. Jei norite gauti naujienas pirmieji, taip pat galite mane sekti!

Ačiū, kad perskaitėte mano straipsnį. Iki kito karto.