Časté pády Apache2 s HestiaCP? Průvodce automatizovaným monitorováním a řešením problémů Monit (s kompletní konfigurací)

Časté pády Apache2 nebo selhání automatického restartu Monitu v prostředí HestiaCP ? Tento článek poskytuje praktického průvodce, jak se vyhnout běžným úskalím při monitorování Apache2 pomocí Monitu, podrobně analyzuje běžné problémy, jako je nesprávné zarovnání cesty PID a blokování oprávnění, a nabízí konfigurační soubory automatizace Monitu na produkční úrovni. Zvládněte techniky údržby serverů s vysokou dostupností a dosáhněte automatické obnovy po selhání druhé úrovně!

Úskalí, na která jsem narazil při používání Monitu k monitorování Apache2

Minulý pátek mi server uprostřed noci poslal upozornění Monit.

Omámeně jsem pohlédl na panel a ve sloupci stavu apache2 se objevil červený Timeout.

Chvíli jsem o tom přemýšlel. Zrovna jsem během dne přidal na server monitoring Monitu a konfiguraci jsem zkopíroval a vložil z online tutoriálu. Neměl by s tím být žádný problém, že?

Druhý den ráno časový limit opět vypršel. Po třetím pokusu se Monitor jednoduše vzdal a panel zobrazil „Není monitorováno“.

Já...

Přiznávám, že jsem to zpočátku nebral vážně. Monitorování Apache2? Na internetu najdete spoustu konfigurací šablon, stačí je zkopírovat a vložit. Ale ten proces vkládání mě opravdu rozzuřil.

Hlavní příčina konfliktu mezi výchozí architekturou HestiaCP a porty Monit

Nejprve vám ukážu konfiguraci, která mi způsobila tolik problémů, abyste si mohli ověřit, jestli je úplně stejná jako verze, kterou jste viděli.

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á se to v pořádku, že? Kontroluje port 80 a pokud dojde k chybě, restartuje se. Pokud dojde k chybě i po 5 restartech, vyprší časový limit.

Problém je, že váš Apache2 ani neběží na portu 80.

Toto je úskalí HestiaCP a hlavní příčina, proč do něj mnoho lidí upadá. Výchozí architektura HestiaCP je reverzní proxy Nginx + Apache2, kde Nginx obsazuje porty 80 a 443 vpředu a Apache2 běží na lokálním portu 8081 vzadu.

Pokud požádáte Monita, aby prozkoumal aktivitu Apache2 na portu 80, je to jako jít do McDonaldu hledat KFC. Obsluha se na vás nechápavě podívá a vy dva se na sebe díváte. Nakonec Monit zjistí, že jste mimo provoz, a začne horečně restartovat.

Po restartu je port stále 8081. Monit se poté pokusí otestovat port 80, což také selže, takže se znovu restartuje. Tento cyklus se opakuje, dokud Monit nerozhodne, že je neopravitelný, a nevyprší časový limit.

Když jsem se s tím poprvé setkal, byl jsem opravdu ohromen. Devět z deseti tutoriálů, které jsem našel online, používalo port 80. Pokud jste se jimi řídili, problém nebyl ve vás, ale ve samotném zdroji informací.

Poškozený soubor Apache2 PID způsobil, že Monit mylně identifikoval proces jako neexistující.

Po změně portu z 80 na 8081 by ho Monit teoreticky měl detekovat, že?

Ve skutečnosti se však stále občas zobrazí zpráva „Spuštění se nezdařilo “.

Po dlouhém boji jsem konečně zjistil, že důvod je jednoduchý: soubor PID byl poškozen.

Zamyslete se nad tím, Monit horečně restartoval Apache2, pokaždé ho násilně ukončoval a restartoval, několikrát se opakoval tam a zpět. Během tohoto procesu mohl soubor /var/run/apache2/apache2.pid dosáhnout velikosti 0 bajtů.

Jinými slovy, soubor tam stále je, ale je prázdný.

Když Monit tento soubor čte, nic nenajde. Nerozpozná váš Apache2, i když váš Apache2 běží na pozadí naprosto v pořádku; Monit si nemyslí, že proces existuje.

Když jsem tohle viděl, na chvíli jsem oněměl.

Toto je zablokování. Monit nedokáže detekovat instanci Apache 2, restartuje Apache 2, během restartu poškodí soubor PID, další detekce selže a restartuje znovu. Tento cyklus pokračuje, dokud nedojde k vypršení časového limitu.

Kroky pro odstraňování problémů a opravu monitorování Apache2 v prostředí HestiaCP

Upřímně řečeno, proces vyšetřování není složitý, ale je potřeba vědět, kterým směrem se vydat.

Prvním krokem je zjistit, na kterém portu váš Apache2 naslouchá. Jednoduše zadejte příkaz do terminálu.

netstat -tulpn | grep apache2

Alternativně můžete použít příkaz `ss`; efekt je stejný.

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 potvrzeno, že se jedná o 8081, ne o 80. To je kořen problému.

Druhým krokem je oprava poškozeného souboru PID. To je jednodušší.

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

Nejprve pozastavte monitorování Monitu, abyste zabránili jeho zasahování do opravy. Poté restartujte Apache2, abyste mu umožnili přepsat čistý PID. Nakonec použijte příkaz `cat` ke kontrole obsahu souboru; měl by obsahovat řetězec čísel, nikoli prázdný řetězec.

Jakmile je tento krok dokončen, problém je v podstatě vyřešen.

Srovnávací analýza tradičních adaptivních a agresivních ochranných konfigurací Monitu

Online návody na konfiguraci Apache2 pomocí Monitu se obecně dělí do dvou kategorií.

Jedním typem je „tradiční typ adaptace“, který používá příkaz `service` ke správě služeb a kontrole lokálních portů bez přidání příliš mnoha složitých omezení. Tuto konfiguraci lze použít na HestiaCP pouhou změnou portu a je relativně stabilní.

Dalším přístupem je metoda „agresivní ochrany“, která používá systemctl ke správě služeb, přidává omezení pro podřízené procesy a používá přísnější logiku detekce. Vypadá to skvěle, ale má to fatální chybu: použitý příkaz pro zastavení je `killall -9`.

Co znamená `killall -9`? Znamená to násilné ukončení zařízení bez ohledu na to, co dělá. Tato operace hrubou silou může snadno zanechat poškozené soubory PID, což je problém, který jsem právě zmínil.

Moje osobní zkušenost je, že omezení počtu podřízených procesů v agresivní konfiguraci je skutečně užitečné. Pokud je váš Apache2 zahlcen útokem CC, omezení počtu podřízených procesů může zabránit tomu, aby serveru došlo místo paměti. Přístup `killall -9` je však skutečně nepoužitelný.

Takže jsem nakonec udělal kompromis a zkombinoval výhody obou konfigurací.

Konfigurace osvědčených postupů pro monitorování HestiaCP Apache2

Upravte soubor /etc/monit/conf.d/apache2 s následujícím obsahem.

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

Dovolte mi stručně vysvětlit logiku, která se skrývá za těmito několika řádky konfigurace.

Zapište port 8081 tak, aby přesně odpovídal architektuře reverzní proxy serveru HestiaCP; přestaňte hloupě zapisovat port 80.

Pro zastavení souboru PID použijte příkaz `systemctl stop` namísto `killall -9`, abyste jej nepoškodili.

Byl přidán limit pro podřízené procesy: pokud počet podřízených procesů překročí 120, proces se po dvou po sobě jdoucích cyklech restartuje, aby se zabránilo útokům CC, ale není to příliš agresivní.

Logika pro detekci chyb byla upravena tak, aby používala přístup „po dobu 2 cyklů“, což znamená, že restart se spustí až po dvou po sobě jdoucích chybách, čímž se snižuje počet falešně pozitivních výsledků. Předchozí konfigurace, která restartovala systém už po jedné detekci, byla upřímně řečeno trochu moc citlivá.

Konečný práh časového limitu je uvolněn na 5 restartů během 10 cyklů, což ponechává dostatečnou odolnost proti chybám.

HestiaCP MonitorováníSouhrn řešení problémů s konfigurací a sdílení zkušeností

Po provedení změn konfigurace jsem monitoroval apache2 a panel nakonec ukázal zelený indikátor „OK“.

Jak popsat mé tehdejší pocity? Bylo to, jako bych dva dny bojoval s chybou a zjistil, že příčinou byl jediný špatný řádek konfigurace. Bylo to frustrující i směšné zároveň.

Monit je sám o sobě dobrá věc a monitorování démonů je něco, co by měl dělat každý server. Problém je ale v tom, že mnoho online tutoriálů je založeno na předpokladu, že „Apache2 používá výhradně port 80“, zatímco HestiaCP používá reverzní proxy, což znamená, že tento předpoklad neplatí.

Pokud se budete řídit pokyny, problém není ve vás; problém je v tom, že tutoriál je použitelný pro jiný scénář než ten váš.

Takže pokud používáte HestiaCP a hrajete si s Monitem pro monitorování Apache2, nezapomeňte na dvě věci: Změňte port na 8081 a k jeho zastavení použijte příkaz `systemctl`, nikoli `killall -9`. Pokud tyto dvě věci uděláte, měli byste se vyhnout dalším problémům.

Jelikož jste to dočetli až sem, pokud vám to pomohlo, dejte to prosím like a sdílejte. Pokud chcete dostávat novinky jako první, můžete mě také sledovat!

Děkuji za přečtení mého článku. Uvidíme se příště.