Časté pády Apache2 s HestiaCP? Sprievodca automatizovaným monitorovaním a riešením problémov Monit (s kompletnou konfiguráciou)

Časté pády Apache2 alebo zlyhania automatického reštartu Monitu v prostrediach HestiaCP ? Tento článok poskytuje praktický návod, ako sa vyhnúť bežným nástrahám pri monitorovaní Apache2 pomocou Monitu, podrobne analyzuje bežné problémy, ako je nesprávne zarovnanie cesty PID a blokovanie oprávnení, a ponúka konfiguračné súbory automatizácie Monitu na produkčnej úrovni. Zvládnite techniky údržby serverov s vysokou dostupnosťou a dosiahnite automatickú obnovu po zlyhaniach druhej úrovne!

Úskalia, s ktorými som sa stretol pri používaní Monitu na monitorovanie Apache2

Minulý piatok mi server uprostred noci poslal upozornenie Monit.

Omámene som pozrel na panel a v stĺpci stavu apache2 sa zobrazila červená nápis „Časový limit“.

Chvíľu som o tom premýšľal. Práve som počas dňa pridal na server monitoring Monit a skopíroval a vložil konfiguráciu z online tutoriálu. Nemali by byť žiadne problémy, však?

Nasledujúce ráno opäť vypršal časový limit. Po treťom pokuse sa Monitor jednoducho vzdal a panel zobrazil „Nemonitorované“.

Ja...

Priznávam, že som to najprv nebral vážne. Monitorovanie Apache2? Online nájdete množstvo konfigurácií šablón, stačí ich skopírovať a vložiť. Ale ten proces vkladania ma naozaj rozzúril.

Hlavná príčina konfliktu medzi predvolenou architektúrou HestiaCP a portami Monit

Najprv vám ukážem konfiguráciu, ktorá mi spôsobila toľko problémov, aby ste zistili, či je úplne rovnaká ako verzia, ktorú ste videli.

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

Zdá sa, že je to v poriadku, však? Skontroluje port 80 a ak zlyhá, reštartuje. Ak zlyhá aj po 5 reštartoch, časový limit vyprší.

Problém je, že váš Apache2 nebeží ani na porte 80.

Toto je úskalie HestiaCP a hlavná príčina, prečo sa doňho mnohí ľudia púšťajú. Predvolená architektúra HestiaCP je reverzná proxy Nginx + Apache2, pričom Nginx obsadzuje porty 80 a 443 vpredu a Apache2 beží na lokálnom porte 8081 vzadu.

Ak požiadate Monita, aby preskúmal aktivitu Apache2 na porte 80, je to ako ísť do McDonaldu hľadať KFC. Obsluha sa na vás nechápavo pozrie a vy dvaja sa na seba pozeráte. Nakoniec Monit zistí, že ste mimo prevádzky a začne zúfalo reštartovať.

Po reštarte je port stále 8081. Monit sa potom pokúša otestovať port 80, čo tiež zlyhá, takže sa reštartuje znova. Tento cyklus sa opakuje, kým Monit nerozhodne, že je neopraviteľný a nevyprší časový limit.

Keď som sa s tým prvýkrát stretol, bol som úprimne ohromený. Deväť z desiatich návodov, ktoré som našiel online, používalo port 80. Ak ste ich dodržali, problém nebol vo vás, ale v samotnom zdroji informácií.

Poškodený súbor Apache2 PID spôsobil, že Monit mylne identifikoval proces ako neexistujúci.

Po zmene portu z 80 na 8081 by ho Monit teoreticky mal vedieť detekovať, však?

V skutočnosti však stále občas hlási „Vykonanie zlyhalo “.

Po dlhom trápení som konečne zistil, že dôvod je jednoduchý: súbor PID bol poškodený.

Zamyslite sa nad tým, Monit zúfalo reštartoval Apache2, zakaždým ho násilne ukončil a reštartoval, niekoľkokrát prepínal tam a späť. Počas tohto procesu mohol súbor /var/run/apache2/apache2.pid zostať veľký 0 bajtov.

Inými slovami, súbor je stále tam, ale je prázdny.

Keď Monit prečíta tento súbor, nič nenájde. Nerozpozná váš Apache2, aj keď váš Apache2 beží na pozadí úplne bez problémov; Monit si nemyslí, že proces existuje.

Keď som to uvidel, na chvíľu som onemel.

Toto je zablokovanie. Monit nedokáže zistiť inštanciu Apache 2, reštartuje Apache 2, počas procesu reštartu poškodí súbor PID, zlyhá pri ďalšej detekcii a znova reštartuje. Tento cyklus pokračuje, kým nedôjde k uplynutiu časového limitu.

Kroky na riešenie problémov a opravu monitorovania Apache2 v prostredí HestiaCP

Úprimne povedané, proces vyšetrovania nie je zložitý, ale musíte vedieť, ktorým smerom sa uberať.

Prvým krokom je určiť, na ktorom porte počúva váš Apache2. Jednoducho zadajte príkaz do terminálu.

netstat -tulpn | grep apache2

Prípadne môžete použiť príkaz `ss`; efekt je rovnaký.

ss -tulpn | grep apache2

Uvidíte výstup podobný tomuto.

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

Je potvrdené, že ide o 8081, nie 80. To je koreň problému.

Druhým krokom je oprava poškodeného súboru PID. Toto je jednoduchšie.

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

Najprv pozastavte monitorovanie Monitu, aby ste zabránili jeho zasahovaniu počas opravovania problémov. Potom reštartujte Apache2, aby ste mu umožnili prepísať čistý PID. Nakoniec použite príkaz `cat` na kontrolu obsahu súboru; mal by obsahovať reťazec čísel, nie prázdny reťazec.

Po dokončení tohto kroku je problém v podstate vyriešený.

Porovnávacia analýza tradičných adaptívnych a agresívnych ochranných konfigurácií spoločnosti Monit

Online návody na konfiguráciu Apache2 pomocou Monitu sa vo všeobecnosti delia do dvoch kategórií.

Jeden typ je „tradičný typ adaptácie“, ktorý používa príkaz `service` na správu služieb a kontrolu lokálnych portov bez pridania príliš veľa zložitých obmedzení. Túto konfiguráciu je možné použiť na HestiaCP jednoduchou zmenou portu a je relatívne stabilná.

Ďalším prístupom je metóda „agresívnej ochrany“, ktorá používa systemctl na správu služieb, pridáva obmedzenia pre podprocesy a používa prísnejšiu logiku detekcie. Vyzerá to skvele, ale má to fatálnu chybu: použitý príkaz na zastavenie je `killall -9`.

Čo znamená `killall -9`? Znamená to násilné ukončenie zariadenia bez ohľadu na to, čo robí. Táto operácia hrubou silou môže ľahko zanechať poškodené súbory PID, čo je problém, ktorý som práve spomenul.

Moja osobná skúsenosť je, že obmedzenie počtu podradených procesov v agresívnej konfigurácii je skutočne užitočné. Keď je váš Apache2 zahltený útokom CC, obmedzenie počtu podradených procesov môže zabrániť serveru v nedostatku pamäte. Prístup `killall -9` je však skutočne nepoužiteľný.

Takže nakoniec som urobil kompromis a skombinoval výhody oboch konfigurácií.

Konfigurácia osvedčených postupov pre monitorovanie HestiaCP Apache2

Upravte súbor /etc/monit/conf.d/apache2 s nasledujúcim obsahom.

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

Dovoľte mi stručne vysvetliť logiku, ktorá sa skrýva za týmito niekoľkými konfiguračnými riadkami.

Napíšte port 8081 tak, aby presne zodpovedal architektúre reverznej proxy HestiaCP; prestaňte hlúpo zapisovať port 80.

Na zastavenie súboru PID použite príkaz `systemctl stop` namiesto príkazu `killall -9`, aby ste ho nepoškodili.

Bol pridaný limit pre podradené procesy: ak počet podradených procesov presiahne 120, proces sa po dvoch po sebe nasledujúcich cykloch reštartuje, aby sa zabránilo útokom CC, ale nie je to príliš agresívne.

Logika detekcie porúch bola upravená tak, aby používala prístup „počas 2 cyklov“, čo znamená, že reštart sa spustí až po dvoch po sebe nasledujúcich poruchách, čím sa znižuje počet falošne pozitívnych výsledkov. Predchádzajúca konfigurácia, ktorá reštartovala už po jednej detekcii, bola úprimne povedané trochu príliš citlivá.

Konečný prah časového limitu je uvoľnený na 5 reštartov v rámci 10 cyklov, čím sa zachová dostatočná odolnosť voči chybám.

HestiaCP Monitorovanie monitorovaniaSúhrn problémov s konfiguráciou a zdieľanie skúseností

Po vykonaní zmien konfigurácie som monitoroval apache2 a panel nakoniec zobrazil zelený indikátor „OK“.

Ako by som opísal svoje vtedy pocity? Bolo to ako stráviť dva dni zápasením s chybou a zistiť, že príčinou bol jediný nesprávny riadok konfigurácie. Bolo to frustrujúce aj smiešne zároveň.

Monit je sám o sebe dobrá vec a monitorovanie démonov je niečo, čo by mal robiť každý server. Problém je však v tom, že mnohé online návody sú založené na predpoklade, že „Apache2 používa výhradne port 80“, zatiaľ čo HestiaCP používa reverznú proxy, čo znamená, že tento predpoklad neplatí.

Ak budete postupovať podľa pokynov, problém nie je vo vás; problém je v tom, že návod je použiteľný v inom scenári ako je ten váš.

Takže ak používate aj HestiaCP a experimentujete s Monitom na monitorovanie Apache2, nezabudnite na dve veci: Zmeňte port na 8081 a na jeho zastavenie použite príkaz `systemctl`, nie `killall -9`. Ak urobíte tieto dve veci, mali by ste sa vyhnúť ďalším problémom.

Keďže ste sa dočítali až sem, ak vám to pomohlo, dajte to lajk a zdieľajte. Ak chcete dostávať novinky ako prví, môžete ma tiež sledovať!

Ďakujem za prečítanie môjho článku. Dovidenia nabudúce.