Hyppige nedbrud af Apache2 med HestiaCP? Monit automatiseret overvågnings- og fejlfindingsguide (med komplet konfiguration)

Hyppige Apache2-nedbrud eller automatisk genstart af Monit i HestiaCP- miljøer? Denne artikel giver en praktisk guide til at undgå almindelige faldgruber, når du overvåger Apache2 med Monit, analyserer dybt almindelige problemer såsom PID-stiforskydning og blokering af tilladelser og tilbyder konfigurationsfiler til automatisering af Monit i produktionskvalitet. Mestrer vedligeholdelsesteknikker til servere med høj tilgængelighed nu, og opnå automatisk gendannelse på andet niveau efter fejl!

De faldgruber jeg stødte på, da jeg brugte Monit til at overvåge Apache2

Sidste fredag ​​gav serveren mig en Monit-alarm midt om natten.

Jeg kastede et blik på panelet i en døs, og i apache2-statuskolonnen var der en rød Timeout.

Jeg tænkte lidt over det. Jeg tilføjede lige Monit-overvågning til serveren i løbet af dagen, og jeg kopierede og indsatte konfigurationen fra en online tutorial. Der burde ikke være nogen problemer, vel?

Næste morgen gik den ud igen. Efter tredje gang gav Monitoren simpelthen op, og panelet viste "Ikke overvåget".

JEG...

Jeg indrømmer, jeg tog det ikke alvorligt i starten. Apache2-overvågning? Du kan finde tonsvis af skabelonkonfigurationer online, bare kopier og indsæt. Men den indsætningsproces gjorde mig virkelig rasende.

Grundårsagen til konflikten mellem HestiaCPs standardarkitektur og Monit-porte

Lad mig først vise dig den konfiguration, der forårsagede mig så mange problemer, så du kan se, om den er præcis den samme som den version, du har set.

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

Det ser fint ud, ikke? Den tjekker port 80, og hvis den går ned, genstarter den. Hvis den stadig går ned efter 5 genstarter, får den timeout.

Problemet er, at din Apache2 ikke engang kører på port 80.

Dette er en faldgrube ved HestiaCP, og roden til, at mange falder i den. HestiaCPs standardarkitektur er en reverse proxy af Nginx + Apache2, hvor Nginx optager port 80 og 443 foran, og Apache2 kører på den lokale port 8081 bagved.

Hvis du beder Monit om at undersøge Apache2's live-funktion på port 80, er det som at gå på McDonald's for at finde KFC. Tjeneren ser tomt på dig, og I to stirrer på hinanden. Til sidst konstaterer Monit, at I er nede, og begynder febrilsk at genstarte.

Efter genstart er porten stadig 8081. Monit forsøger derefter at undersøge port 80, hvilket også fejler, så den genstarter igen. Denne cyklus gentages, indtil Monit beslutter, at den ikke kan repareres, og der opstår timeout.

Da jeg først stødte på dette, var jeg oprigtigt lamslået. Ni ud af ti tutorials, jeg fandt online, brugte port 80. Hvis du fulgte dem, lå problemet ikke hos dig, men hos selve informationskilden.

En beskadiget Apache2 PID-fil fik Monit til fejlagtigt at identificere processen som ikke-eksisterende.

Efter at have ændret porten fra 80 til 8081, burde Monit teoretisk set være i stand til at registrere den, ikke?

Men i virkeligheden rapporterer den stadig lejlighedsvis "Udførelsen mislykkedes ".

Efter lang tids kæmpen opdagede jeg endelig, at årsagen var enkel: PID-filen var beskadiget.

Tænk over det, Monit genstartede febrilsk Apache2, hver gang med magt lukkede og genstartede den, frem og tilbage flere gange. Under denne proces kunne filen /var/run/apache2/apache2.pid blive 0 bytes.

Med andre ord, filen er der stadig, men den er tom.

Når Monit læser denne fil, finder den ingenting. Den genkender ikke din Apache2, selvom din Apache2 kører helt fint i baggrunden; Monit tror ikke, at processen eksisterer.

Da jeg så dette, var jeg målløs et øjeblik.

Dette er en fastlåst situation. Monit kan ikke registrere Apache 2-instansen, genstarter Apache2, beskadiger PID-filen under genstartsprocessen, mislykkes med den næste registrering og genstarter igen. Denne cyklus fortsætter, indtil timeout indtræffer.

Fejlfindings- og reparationstrin for Apache2-overvågning i HestiaCP-miljøet

For at være ærlig er undersøgelsesprocessen ikke kompliceret, men du er nødt til at vide, hvilken retning du skal undersøge.

Det første trin er at finde ud af, hvilken port din Apache2 lytter på. Du skal blot skrive en kommando i terminalen.

netstat -tulpn | grep apache2

Alternativt kan du bruge kommandoen `ss`; effekten er den samme.

ss -tulpn | grep apache2

Du vil se output svarende til dette.

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

Det er bekræftet at det er 8081, ikke 80. Det er roden til problemet.

Det andet trin er at reparere den beskadigede PID-fil. Dette er enklere.

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

Først skal du sætte Monit-overvågningen på pause for at forhindre den i at forstyrre, mens du retter ting. Genstart derefter Apache2 for at give den mulighed for at omskrive en ren PID. Brug til sidst `cat` til at kontrollere filindholdet; den skal indeholde en talstreng, ikke en tom streng.

Når dette trin er gennemført, er problemet stort set løst.

Sammenlignende analyse af Monits traditionelle adaptive og aggressive beskyttelseskonfigurationer

Online tutorials om konfiguration af Apache2 med Monit falder generelt i to kategorier.

En type er den "traditionelle tilpasningstype", som bruger `service`-kommandoen til at administrere tjenester og kontrollere lokale porte uden at tilføje for mange komplicerede begrænsninger. Denne konfiguration kan bruges på HestiaCP ved blot at ændre porten, og den er relativt stabil.

En anden tilgang er metoden "aggressiv beskyttelse", som bruger systemctl til at administrere tjenester, tilføjer begrænsninger for underordnede processer og anvender strengere detektionslogik. Det ser godt ud, men det har en fatal fejl: den anvendte stopkommando er `killall -9`.

Hvad betyder `killall -9`? Det betyder at tvangsafbryde enheden, uanset hvad den foretager sig. Denne brute-force-operation kan nemt efterlade ødelagte PID-filer, hvilket er det problem, jeg lige nævnte.

Min personlige erfaring er, at det er nyttigt at begrænse antallet af underprocesser i en aggressiv konfiguration. Når din Apache2 overvældes af et CC-angreb, kan begrænsning af antallet af underprocesser forhindre serveren i at løbe tør for hukommelse. Tilgangen `killall -9` er dog virkelig ubrugelig.

Så til sidst gik jeg på kompromis og kombinerede fordelene ved begge konfigurationer.

HestiaCP Apache2 Monit Bedste Praksis Konfiguration

Rediger filen /etc/monit/conf.d/apache2 med følgende indhold.

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

Lad mig kort forklare logikken bag disse få konfigurationslinjer.

Skriv port 8081, så den præcist matcher HestiaCPs reverse proxy-arkitektur; stop med at dumme dig ud i at skrive port 80.

Brug kommandoen `systemctl stop` i stedet for `killall -9` til at stoppe PID-filen og dermed undgå at beskadige den.

Der er tilføjet en grænse for underordnede processer: hvis antallet af underordnede processer overstiger 120, genstartes processen efter to på hinanden følgende cyklusser for at forhindre CC-angreb, men den er ikke for aggressiv.

Logikken til at detektere fejl er blevet ændret til at bruge en "i 2 cyklusser"-tilgang, hvilket betyder, at en genstart kun udløses efter to på hinanden følgende fejl, hvilket reducerer falske positiver. Den tidligere konfiguration, som genstartede efter kun én detektion, var ærligt talt lidt for følsom.

Den endelige timeout-tærskel er lempet til 5 genstarter inden for 10 cyklusser, hvilket giver tilstrækkelig fejltolerance.

HestiaCP Monit overvågningOpsummering af fejlfinding af konfiguration og erfaringsdeling

Efter at have foretaget konfigurationsændringerne overvågede jeg apache2, og panelet viste endelig en grøn "OK"-indikator.

Hvordan skal jeg beskrive mine følelser dengang? Det var som at bruge to dage på at kæmpe med en fejl, kun for at opdage, at årsagen var en enkelt konfigurationslinje, der var forkert. Det var både frustrerende og latterligt.

Monit er en god ting i sig selv, og overvågning af dæmoner er noget, som alle servere bør gøre. Men problemet er, at mange online tutorials er baseret på antagelsen om, at "Apache2 udelukkende bruger port 80", mens HestiaCP bruger en reverse proxy, hvilket betyder, at denne antagelse ikke holder stik.

Hvis du følger instruktionerne, er problemet ikke dig; det er, at vejledningen gælder for et andet scenarie end dit.

Så hvis du også bruger HestiaCP og eksperimenterer med Monit til at overvåge Apache2, skal du huske to ting: Skift porten til 8081, og brug kommandoen `systemctl` til at stoppe den, ikke `killall -9`. Hvis du gør disse to ting, burde du kunne undgå yderligere problemer.

Nu du har læst så langt, så synes du meget godt om og del det, hvis du fandt det nyttigt. Hvis du vil modtage opdateringer først, kan du også følge mig!

Tak fordi du læste min artikel. Vi ses næste gang.