Az Apache2 gyakori összeomlásai HestiaCP használata esetén? Monit automatizált monitorozási és hibaelhárítási útmutató (teljes konfigurációval)

Gyakori Apache2 összeomlások vagy Monit automatikus újraindítási hibák HestiaCP környezetekben? Ez a cikk gyakorlati útmutatót nyújt az Apache2 Monittal történő monitorozása során előforduló gyakori buktatók elkerüléséhez, mélyrehatóan elemzi az olyan gyakori problémákat, mint a PID útvonalhiba és az engedélyek blokkolása, valamint éles szintű Monit automatizálási konfigurációs fájlokat kínál. Sajátítsa el a nagy rendelkezésre állású szerverkarbantartási technikákat most, és érjen el második szintű automatikus helyreállítást hibák után!

A buktatók, amelyekkel a Monit használata során találkoztam az Apache2 monitorozásához

Múlt pénteken a szerver Monit riasztást adott nekem az éjszaka közepén.

Kábultan pillantottam a panelre, és az apache2 állapotoszlopában egy piros időtúllépés felirat volt látható.

Gondolkodtam rajta egy kicsit. Épp most adtam hozzá a Monit monitorozást a szerverhez napközben, és egy online oktatóanyagból másoltam be a konfigurációt. Nem szabadna, hogy gondok legyenek, ugye?

Másnap reggel ismét időtúllépés történt. Harmadszorra a Monitor egyszerűen feladta, és az irányítópulton a „Nincs monitorozva” üzenet jelent meg.

ÉN...

Bevallom, először nem vettem komolyan. Apache2 monitorozás? Rengeteg sablonkonfigurációt találhatsz online, csak másold ki és illeszd be. De a beillesztési folyamat nagyon feldühített.

A HestiaCP alapértelmezett architektúrája és a Monit portjai közötti konfliktus kiváltó oka

Először is hadd mutassam meg azt a konfigurációt, ami annyi gondot okozott nekem, hogy lássa, pontosan ugyanaz-e, mint az általad látott verzió.

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

Úgy tűnik, minden rendben van, ugye? Ellenőrzi a 80-as portot, és ha összeomlik, újraindul. Ha 5 újraindítás után is összeomlik, akkor időtúllépést jelez.

A probléma az, hogy az Apache2 nem is a 80-as porton fut.

Ez a HestiaCP egyik buktatója, és egyben sokak ebbe való beleesésének kiváltó oka. A HestiaCP alapértelmezett architektúrája az Nginx + Apache2 fordított proxyja, ahol az Nginx a 80-as és 443-as portokat foglalja el elöl, az Apache2 pedig a 8081-es helyi porton fut hátul.

Ha megkéred Monitot, hogy ellenőrizze az Apache2 élőségét a 80-as porton, az olyan, mintha a McDonald's-ba mennél KFC-t keresni. A pincér üres tekintettel néz rád, te pedig egymásra meredsz. Végül Monit megállapítja, hogy nem működsz, és kétségbeesetten újraindítja a gépet.

Újraindítás után a port továbbra is a 8081-es. A Monit ezután megpróbálja elérni a 80-as portot, de ez is sikertelen, ezért újraindul. Ez a ciklus addig ismétlődik, amíg a Monit úgy nem dönt, hogy a hiba javíthatatlan, és időtúllépést észlel.

Amikor először találkoztam ezzel, őszintén megdöbbentem. Tízből kilenc online oktatóanyag a 80-as portot használta. Ha követted őket, a probléma nem veled volt, hanem magával az információ forrásával.

Egy sérült Apache2 PID fájl miatt a Monit tévesen nem létezőként azonosította a folyamatot.

Miután a portot 80-ról 8081-re változtattam, a Monitnak elméletileg képesnek kellene lennie felismerni, ugye?

A valóságban azonban továbbra is időnként a „Végrehajtás sikertelen ” hibát jelzi.

Sokáig vívódtam, és végül rájöttem, hogy az ok egyszerű: a PID fájl sérült.

Gondolj bele, a Monit kétségbeesetten újraindította az Apache2-t, minden alkalommal erőszakkal leállítva és újraindítva, többször is oda-vissza menve. A folyamat során a /var/run/apache2/apache2.pid fájl 0 bájtossá válhatott.

Más szóval, a fájl még mindig ott van, de üres.

Amikor a Monit beolvassa ezt a fájlt, semmit sem talál. Nem ismeri fel az Apache2-t, még akkor sem, ha az tökéletesen fut a háttérben; a Monit nem hiszi, hogy létezik a folyamat.

Amikor ezt megláttam, egy pillanatra elakadt a szavam.

Ez egy patthelyzet. A Monit nem észleli az Apache 2 példányt, újraindítja az Apache2-t, az újraindítási folyamat során megrongálja a PID fájlt, a következő észlelés sikertelen, majd újraindítja a rendszert. Ez a ciklus addig folytatódik, amíg időtúllépés nem történik.

Hibaelhárítási és javítási lépések az Apache2 monitorozásához HestiaCP környezetben

Őszintén szólva, a nyomozás folyamata nem bonyolult, de tudni kell, melyik irányba kell nyomozni.

Az első lépés annak meghatározása, hogy az Apache2 melyik porton figyel. Egyszerűen írjon be egy parancsot a terminálba.

netstat -tulpn | grep apache2

Alternatív megoldásként használhatod az `ss` parancsot; a hatás ugyanaz.

ss -tulpn | grep apache2

Ehhez hasonló kimenetet fog látni.

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

Megerősítették, hogy 8081, nem 80. Ez a probléma gyökere.

A második lépés a sérült PID fájl javítása. Ez egyszerűbb.

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

Először is, állítsd le a Monit monitorozását, hogy megakadályozd a beavatkozást a javítások során. Ezután indítsd újra az Apache2-t, hogy újraírhassa a tiszta PID-t. Végül használd a `cat` parancsot a fájl tartalmának ellenőrzéséhez; annak számokból álló karakterláncot kell tartalmaznia, nem üres karakterláncot.

Miután ez a lépés befejeződött, a probléma alapvetően megoldódott.

A Monit hagyományos adaptív és agresszív védelmi konfigurációinak összehasonlító elemzése

Az Apache2 és a Monit konfigurálásával kapcsolatos online oktatóanyagok általában két kategóriába sorolhatók.

Az egyik típus a „hagyományos adaptációs típus”, amely a `service` parancsot használja a szolgáltatások kezelésére és a helyi portok ellenőrzésére túl sok bonyolult korlátozás hozzáadása nélkül. Ez a konfiguráció a HestiaCP-n egyszerűen a port megváltoztatásával használható, és viszonylag stabil.

Egy másik megközelítés az „agresszív védelem” metódus, amely a systemctl parancsot használja a szolgáltatások kezelésére, gyermekfolyamat-korlátozásokat ad hozzá, és szigorúbb észlelési logikát alkalmaz. Nagyszerűen néz ki, de van egy végzetes hibája: a használt stop parancs a `killall -9`.

Mit jelent a `killall -9`? Azt jelenti, hogy erőszakkal leállítod az eszközt, függetlenül attól, hogy mit csinál. Ez a nyers erővel végrehajtott művelet könnyen sérült PID fájlokat hagyhat maga után, ami az imént említett probléma.

Személyes tapasztalatom szerint a gyermekfolyamatok számának korlátozása egy agresszív konfigurációban valóban hasznos. Amikor az Apache2 szervert túlterheli egy CC támadás, a gyermekfolyamatok számának korlátozása megakadályozhatja, hogy a szerver elfogyjon a memóriából. A `killall -9` megközelítés azonban valóban használhatatlan.

Így végül kompromisszumot kötöttem, és kombináltam mindkét konfiguráció előnyeit.

HestiaCP Apache2 Monit ajánlott konfiguráció

Módosítsa az /etc/monit/conf.d/apache2 fájlt a következő tartalommal.

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

Hadd magyarázzam el röviden a logikát e néhány sor konfiguráció mögött.

Írd be a 8081-es portot úgy, hogy pontosan megegyezzen a HestiaCP fordított proxy architektúrájával; hagyd abba a 80-as port ostoba írását.

A PID fájl sérülésének elkerülése érdekében a `killall -9` helyett a `systemctl stop` parancsot használd a leállításhoz.

Hozzáadtak egy gyermekfolyamat-korlátot: ha a gyermekek száma meghaladja a 120-at, a folyamat két egymást követő ciklus után újraindul a CC-támadások megelőzése érdekében, de ez nem túl agresszív.

A hibák észlelésének logikáját úgy módosították, hogy „2 cikluson keresztül” megközelítést használjon, ami azt jelenti, hogy az újraindítás csak két egymást követő hiba után történik meg, csökkentve a téves riasztások számát. Az előző konfiguráció, amely már egyetlen hiba észlelése után újraindult, őszintén szólva kissé túlérzékeny volt.

A végső időtúllépési küszöbértéket 10 cikluson belül 5 újraindításra enyhítették, így elegendő hibatűrés maradt.

HestiaCP Monitor monitoringKonfiguráció Hibaelhárítási összefoglaló és tapasztalatmegosztás

A konfigurációs módosítások elvégzése után figyeltem az apache2-t, és a panel végül egy zöld "OK" jelzőt mutatott.

Hogyan is írjam le az akkori érzéseimet? Olyan volt, mintha két napot töltöttem volna egy hibával küzdve, csak hogy aztán kiderüljön, hogy a hiba oka egyetlen hibás konfigurációs sor. Egyszerre volt frusztráló és nevetséges.

A Monit önmagában jó dolog, és a démonok monitorozása olyan dolog, amit minden szervernek meg kellene tennie. A probléma azonban az, hogy sok online oktatóanyag azon a feltételezésen alapul, hogy az "Apache2 kizárólag a 80-as portot használja", míg a HestiaCP fordított proxyt használ, ami azt jelenti, hogy ez a feltételezés nem igaz.

Ha követed az utasításokat, akkor nem veled van a probléma, hanem azzal, hogy a bemutató egy másik forgatókönyvre alkalmazható, mint a tiéd.

Szóval, ha HestiaCP-t is használsz, és a Monittal játszadozol az Apache2 monitorozásához, csak két dologra emlékezz: Váltsd a portot 8081-re, és a `systemctl` parancsot használd a leállításhoz, ne a `killall -9` parancsot. Ha ezt a két dolgot megteszed, elkerülheted a további problémákat.

Mivel idáig elolvastad, ha hasznosnak találtad, kérlek lájkold és oszd meg. Ha elsőként szeretnél értesülni a frissítésekről, követhetsz is!

Köszönöm, hogy elolvastad a cikkemet. Találkozunk legközelebb.