Częste awarie Apache2 z HestiaCP? Przewodnik automatycznego monitorowania i rozwiązywania problemów Monit (z pełną konfiguracją)

Częste awarie Apache2 lub błędy automatycznego restartu Monit w środowiskach HestiaCP ? Ten artykuł zawiera praktyczny przewodnik, jak unikać typowych pułapek podczas monitorowania Apache2 za pomocą Monit, dogłębnie analizując typowe problemy, takie jak niezgodność ścieżek PID i blokowanie uprawnień, a także oferując pliki konfiguracyjne automatyzacji Monit klasy produkcyjnej. Opanuj techniki konserwacji serwerów o wysokiej dostępności już teraz i uzyskaj automatyczne odzyskiwanie danych po awariach na drugim poziomie!

Pułapki, na które natrafiłem podczas monitorowania Apache2 za pomocą Monit

W zeszły piątek serwer wysłał mi alert Monit w środku nocy.

Oszołomiony spojrzałem na panel i zobaczyłem, że w kolumnie stanu Apache2 widnieje czerwony napis Timeout.

Myślałem o tym chwilę. Dodałem monitorowanie Monit do serwera w ciągu dnia i skopiowałem i wkleiłem konfigurację z samouczka online. Nie powinno być żadnych problemów, prawda?

Następnego ranka ponownie nastąpiła przerwa w działaniu systemu. Po trzecim razie Monitor po prostu się poddał, a na panelu pojawił się komunikat „Nie monitorowano”.

I...

Przyznaję, że na początku nie traktowałem tego poważnie. Monitorowanie Apache2? W sieci można znaleźć mnóstwo konfiguracji szablonów, wystarczy skopiować i wkleić. Ale ten proces wklejania naprawdę mnie wkurzył.

Podstawowa przyczyna konfliktu pomiędzy domyślną architekturą HestiaCP a portami Monit

Najpierw pokażę Ci konfigurację, która sprawiła mi tyle kłopotów, tak abyś mógł sprawdzić, czy jest dokładnie taka sama, jak wersja, którą widziałeś.

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

Wygląda dobrze, prawda? Sprawdza port 80 i jeśli wystąpi awaria, uruchamia się ponownie. Jeśli awaria nadal występuje po 5 restartach, następuje przekroczenie limitu czasu.

Problem polega na tym, że Twój Apache2 nie działa nawet na porcie 80.

To pułapka HestiaCP i główna przyczyna, dla której wiele osób wpada w tę pułapkę. Domyślna architektura HestiaCP to odwrotny serwer proxy Nginx + Apache2, gdzie Nginx zajmuje porty 80 i 443 z przodu, a Apache2 działa na porcie lokalnym 8081 z tyłu.

Jeśli poprosisz Monita o sprawdzenie działania Apache2 na porcie 80, to jak pójście do McDonalda w poszukiwaniu KFC. Kelner patrzy na ciebie pustym wzrokiem, a wy dwaj wpatrujecie się w siebie. W końcu Monit stwierdza, że ​​nie masz połączenia i zaczyna gorączkowo restartować komputer.

Po ponownym uruchomieniu port nadal ma numer 8081. Monit próbuje następnie sprawdzić port 80, który również kończy się niepowodzeniem, więc uruchamia się ponownie. Cykl powtarza się, aż Monit uzna, że ​​nie da się go naprawić i przekroczy limit czasu.

Kiedy pierwszy raz się z tym zetknąłem, byłem autentycznie oszołomiony. Dziewięć na dziesięć poradników, które znalazłem w internecie, korzystało z portu 80. Jeśli się do nich zastosowałeś, problem nie leżał w Tobie, ale w samym źródle informacji.

Uszkodzony plik PID Apache2 spowodował, że Monit błędnie zidentyfikował proces jako nieistniejący.

Po zmianie portu z 80 na 8081, Monit teoretycznie powinien być w stanie go wykryć, prawda?

Jednak w rzeczywistości czasami nadal pojawia się komunikat „Wykonanie nieudane ”.

Po długiej walce w końcu odkryłem, że przyczyna jest prosta: plik PID był uszkodzony.

Pomyślcie tylko, Monit gorączkowo restartował Apache2, za każdym razem wymuszonym wyłączaniem i restartowaniem, kilkakrotnie przechodząc w tę i z powrotem. Podczas tego procesu plik /var/run/apache2/apache2.pid mógł osiągnąć rozmiar 0 bajtów.

Innymi słowy, plik nadal tam jest, ale jest pusty.

Kiedy Monit odczytuje ten plik, nic nie znajduje. Nie rozpoznaje serwera Apache2, nawet jeśli działa on bez zarzutu w tle; Monit nie uważa, że ​​proces istnieje.

Kiedy to zobaczyłem, na chwilę zaniemówiłem.

To jest impas. Monit nie wykrywa instancji Apache 2, restartuje Apache 2, uszkadza plik PID podczas restartu, nie wykrywa kolejnego i restartuje się ponownie. Ten cykl powtarza się aż do przekroczenia limitu czasu.

Rozwiązywanie problemów i kroki naprawcze dla monitorowania Apache2 w środowisku HestiaCP

Szczerze mówiąc, proces dochodzenia nie jest skomplikowany, ale trzeba wiedzieć, w jakim kierunku iść.

Pierwszym krokiem jest ustalenie portu, na którym nasłuchuje Apache2. Wystarczy wpisać polecenie w terminalu.

netstat -tulpn | grep apache2

Alternatywnie możesz użyć polecenia `ss`; efekt będzie ten sam.

ss -tulpn | grep apache2

Zobaczysz wynik podobny do tego.

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

Potwierdzono, że jest to liczba 8081, a nie 80. To jest sedno problemu.

Drugim krokiem jest naprawa uszkodzonego pliku PID. To prostsze.

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

Najpierw wstrzymaj monitorowanie Monit, aby zapobiec jego zakłóceniom podczas naprawy. Następnie uruchom ponownie Apache2, aby umożliwić mu zapisanie czystego PID. Na koniec użyj `cat` do sprawdzenia zawartości pliku; powinien on zawierać ciąg liczb, a nie pusty ciąg.

Po wykonaniu tego kroku problem jest zasadniczo rozwiązany.

Analiza porównawcza tradycyjnych adaptacyjnych i agresywnych konfiguracji ochronnych Monit

Samouczki online dotyczące konfiguracji Apache2 z Monitem generalnie dzielą się na dwie kategorie.

Jednym z typów jest „tradycyjny typ adaptacji”, który używa polecenia „service” do zarządzania usługami i sprawdzania portów lokalnych bez wprowadzania zbyt wielu skomplikowanych ograniczeń. Tę konfigurację można zastosować na platformie HestiaCP, po prostu zmieniając port, i jest ona stosunkowo stabilna.

Innym podejściem jest metoda „agresywnej ochrony”, która wykorzystuje systemctl do zarządzania usługami, dodaje ograniczenia dla procesów potomnych i stosuje bardziej rygorystyczną logikę wykrywania. Wygląda świetnie, ale ma poważną wadę: używane polecenie stop to `killall -9`.

Co oznacza `killall -9`? Oznacza to wymuszone zamknięcie urządzenia niezależnie od tego, co robi. Ta operacja siłowa może łatwo pozostawić uszkodzone pliki PID, co jest problemem, o którym właśnie wspomniałem.

Z mojego doświadczenia wynika, że ​​ograniczenie liczby procesów potomnych w konfiguracji agresywnej jest rzeczywiście przydatne. Gdy serwer Apache2 zostanie zaatakowany atakiem CC, ograniczenie liczby procesów potomnych może zapobiec wyczerpaniu się pamięci serwera. Jednak podejście `killall -9` jest całkowicie bezużyteczne.

Więc ostatecznie poszedłem na kompromis i połączyłem zalety obu konfiguracji.

Konfiguracja najlepszych praktyk HestiaCP Apache2 Monitor

Zmodyfikuj plik /etc/monit/conf.d/apache2, wprowadzając następującą zawartość.

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

Pozwólcie, że pokrótce wyjaśnię logikę stojącą za tymi kilkoma linijkami konfiguracji.

Zapisz port 8081 tak, aby dokładnie odpowiadał architekturze odwrotnego proxy HestiaCP; przestań bezsensownie zapisywać port 80.

Użyj polecenia `systemctl stop` zamiast `killall -9`, aby zatrzymać plik PID i nie uszkodzić go.

Dodano limit procesów potomnych: jeśli liczba procesów potomnych przekroczy 120, proces zostanie uruchomiony ponownie po dwóch kolejnych cyklach, aby zapobiec atakom CC. Nie jest to jednak zbyt agresywne.

Logika wykrywania awarii została zmodyfikowana i wykorzystuje podejście „przez 2 cykle”, co oznacza, że ​​restart jest aktywowany dopiero po dwóch kolejnych awariach, co zmniejsza liczbę fałszywych alarmów. Poprzednia konfiguracja, która restartowała się już po jednym wykryciu, była, szczerze mówiąc, nieco zbyt czuła.

Ostateczny próg limitu czasu został złagodzony do 5 ponownych uruchomień w ciągu 10 cykli, co zapewnia wystarczającą tolerancję błędów.

HestiaCP Monitoruj monitorowaniePodsumowanie rozwiązywania problemów z konfiguracją i dzielenie się doświadczeniami

Po wprowadzeniu zmian w konfiguracji monitorowałem Apache2 i na panelu w końcu pojawił się zielony wskaźnik „OK”.

Jak opisać moje ówczesne odczucia? To było jak dwa dni walki z błędem, po których okazało się, że przyczyną była pojedyncza błędna linia konfiguracji. Było to zarówno frustrujące, jak i śmieszne.

Monit sam w sobie jest dobry, a demony monitorujące to coś, co każdy serwer powinien robić. Problem polega jednak na tym, że wiele samouczków online opiera się na założeniu, że „Apache2 korzysta wyłącznie z portu 80”, podczas gdy HestiaCP korzysta z odwrotnego proxy, co oznacza, że ​​to założenie nie jest prawdziwe.

Jeśli postępujesz zgodnie z instrukcjami, problem nie leży w Tobie. Problem polega na tym, że poradnik dotyczy innego scenariusza niż Twój.

Jeśli więc używasz HestiaCP i bawisz się Monitem do monitorowania Apache2, pamiętaj o dwóch rzeczach: zmień port na 8081 i użyj polecenia `systemctl`, aby go zatrzymać, a nie `killall -9`. Wykonanie tych dwóch czynności powinno pomóc uniknąć dalszych problemów.

Skoro dotarłeś aż tutaj, jeśli uznałeś to za pomocne, polub i udostępnij. Jeśli chcesz otrzymywać aktualizacje jako pierwszy, możesz mnie też obserwować!

Dziękuję za przeczytanie mojego artykułu. Do zobaczenia następnym razem.