Hyppige krasj av Apache2 med HestiaCP? Monit automatisert overvåkings- og feilsøkingsguide (med fullstendig konfigurasjon)

Hyppige Apache2-krasj eller automatisk omstart av Monit i HestiaCP- miljøer? Denne artikkelen gir en praktisk veiledning for å unngå vanlige fallgruver når du overvåker Apache2 med Monit, analyserer vanlige problemer som feiljustering av PID-banen og blokkering av tillatelser i dybden, og tilbyr konfigurasjonsfiler for automatisering av Monit i produksjonskvalitet. Mestre vedlikeholdsteknikker for servere med høy tilgjengelighet nå og oppnå automatisk gjenoppretting på andre nivå fra feil!

Fallgruvene jeg møtte på da jeg brukte Monit til å overvåke Apache2

Forrige fredag ​​ga serveren meg et Monit-varsel midt på natten.

Jeg kikket forvirret på panelet, og i apache2-statuskolonnen var det en rød Timeout-melding.

Jeg tenkte litt på det. Jeg la nettopp til Monit-overvåking på serveren i løpet av dagen, og jeg kopierte og limte inn konfigurasjonen fra en online veiledning. Det burde ikke være noen problemer, ikke sant?

Neste morgen gikk det ut på nytt. Etter tredje gang ga skjermen rett og slett opp, og panelet viste «Ikke overvåket».

JEG...

Jeg innrømmer at jeg ikke tok det seriøst i starten. Apache2-overvåking? Du kan finne tonnevis av malkonfigurasjoner på nettet, bare kopier og lim inn. Men den limeprosessen gjorde meg virkelig rasende.

Den grunnleggende årsaken til konflikten mellom HestiaCPs standardarkitektur og Monit-porter

La meg først vise deg konfigurasjonen som forårsaket meg så mye problemer, slik at du kan se om den er nøyaktig den samme som versjonen du har sett.

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 virker greit, ikke sant? Den sjekker port 80, og hvis den krasjer, starter den på nytt. Hvis den fortsatt krasjer etter 5 omstarter, får den tidsavbrudd.

Problemet er at Apache2-en din ikke engang kjører på port 80.

Dette er en fallgruve med HestiaCP, og roten til at mange faller i den. HestiaCPs standardarkitektur er en omvendt proxy av Nginx + Apache2, med Nginx som okkuperer portene 80 og 443 foran, og Apache2 som kjører på den lokale porten 8081 bakerst.

Hvis du ber Monit om å undersøke Apache2s aktiverthet på port 80, er det som å gå til McDonald's for å finne KFC. Servitøren ser tomt på deg, og dere to stirrer på hverandre. Til slutt bestemmer Monit seg for at dere er nede og begynner febrilsk å starte på nytt.

Etter omstart er porten fortsatt 8081. Monit prøver deretter å undersøke port 80, noe som også mislykkes, så den starter på nytt. Denne syklusen gjentas til Monit bestemmer at den ikke kan repareres og får tidsavbrudd.

Da jeg først oppdaget dette, ble jeg virkelig sjokkert. Ni av ti veiledninger jeg fant på nettet brukte port 80. Hvis du fulgte dem, lå ikke problemet hos deg, men hos selve informasjonskilden.

En ødelagt Apache2 PID-fil førte til at Monit feilaktig identifiserte prosessen som ikke-eksisterende.

Etter å ha endret porten fra 80 til 8081, burde Monit teoretisk sett kunne oppdage den, ikke sant?

Men i virkeligheten rapporterer den fortsatt av og til "Kjøringen mislyktes ".

Etter å ha slitt lenge, oppdaget jeg endelig at årsaken var enkel: PID-filen var ødelagt.

Tenk på det, Monit startet febrilsk Apache2 på nytt, og tvang det til å avvikle og starte det på nytt hver gang, frem og tilbake flere ganger. I løpet av denne prosessen kan filen /var/run/apache2/apache2.pid bli 0 byte.

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

Når Monit leser denne filen, finner den ingenting. Den gjenkjenner ikke Apache2-filen din, selv om Apache2-filen kjører helt fint i bakgrunnen; Monit tror ikke at prosessen eksisterer.

Da jeg så dette, ble jeg målløs et øyeblikk.

Dette er en vranglås. Monit klarer ikke å oppdage Apache 2-instansen, starter Apache2 på nytt, ødelegger PID-filen under omstartsprosessen, mislykkes ved neste deteksjon og starter på nytt. Denne syklusen fortsetter til tidsavbruddet inntreffer.

Feilsøkings- og reparasjonstrinn for Apache2-overvåking i HestiaCP-miljøet

For å være ærlig, er ikke etterforskningsprosessen komplisert, men du må vite hvilken retning du skal etterforske.

Det første trinnet er å finne ut hvilken port Apache2-en din lytter på. Bare skriv inn en kommando i terminalen.

netstat -tulpn | grep apache2

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

ss -tulpn | grep apache2

Du vil se utdata som ligner på dette.

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

Det er bekreftet at det er 8081, ikke 80. Det er roten til problemet.

Det andre trinnet er å reparere den ødelagte PID-filen. Dette er enklere.

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

Først, sett Monit-overvåkingen på pause for å forhindre at den forstyrrer deg mens du fikser ting. Start deretter Apache2 på nytt for å la den skrive om en ren PID. Til slutt, bruk `cat` for å sjekke filinnholdet; den skal inneholde en tallstreng, ikke en tom streng.

Når dette trinnet er fullført, er problemet i utgangspunktet løst.

Sammenlignende analyse av Monits tradisjonelle adaptive og aggressive beskyttelseskonfigurasjoner

Nettbaserte veiledninger om konfigurasjon av Apache2 med Monit faller vanligvis inn i to kategorier.

En type er den «tradisjonelle tilpasningstypen», som bruker `service`-kommandoen til å administrere tjenester og sjekke lokale porter uten å legge til for mange kompliserte restriksjoner. Denne konfigurasjonen kan brukes på HestiaCP ved ganske enkelt å endre porten, og den er relativt stabil.

En annen tilnærming er metoden «aggressiv beskyttelse», som bruker systemctl til å administrere tjenester, legger til begrensninger for underordnede prosesser og benytter strengere deteksjonslogikk. Den ser flott ut, men den har en fatal feil: stoppkommandoen som brukes er `killall -9`.

Hva betyr `killall -9`? Det betyr å tvangsavslutte enheten uavhengig av hva den gjør. Denne brute-force-operasjonen kan lett etterlate ødelagte PID-filer, som er problemet jeg nettopp nevnte.

Min personlige erfaring er at det er nyttig å begrense antall barneprosesser i en aggressiv konfigurasjon. Når Apache2-serveren din blir overveldet av et CC-angrep, kan det å begrense antall barneprosesser forhindre at serveren går tom for minne. Imidlertid er `killall -9`-tilnærmingen virkelig ubrukelig.

Så til slutt inngikk jeg kompromisser og kombinerte fordelene ved begge konfigurasjonene.

HestiaCP Apache2 Monit Beste praksiskonfigurasjon

Endre filen /etc/monit/conf.d/apache2 med følgende innhold.

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

La meg kort forklare logikken bak disse få konfigurasjonslinjene.

Skriv port 8081 slik at den samsvarer nøyaktig med HestiaCPs reverse proxy-arkitektur; slutt med å skrive port 80 på en tåpelig måte.

Bruk kommandoen `systemctl stop` i stedet for `killall -9` for å stoppe PID-filen, slik at den ikke blir ødelagt.

En grense for barneprosesser er lagt til: hvis antallet barn overstiger 120, vil prosessen starte på nytt etter to påfølgende sykluser for å forhindre CC-angrep, men den er ikke for aggressiv.

Logikken for å oppdage feil er endret til å bruke en "for 2 sykluser"-tilnærming, som betyr at en omstart kun utløses etter to påfølgende feil, noe som reduserer falske positiver. Den forrige konfigurasjonen, som startet på nytt etter bare én deteksjon, var ærlig talt litt for følsom.

Den endelige tidsavbruddsterskelen er redusert til 5 omstarter innen 10 sykluser, noe som gir tilstrekkelig feiltoleranse.

HestiaCP Monit overvåkingSammendrag av feilsøking av konfigurasjon og erfaringsdeling

Etter å ha gjort konfigurasjonsendringene, overvåket jeg apache2, og panelet viste endelig en grønn "OK"-indikator.

Hvordan skal jeg beskrive følelsene mine den gangen? Det var som å bruke to dager på å slite med en feil, bare for å oppdage at årsaken var en enkelt konfigurasjonslinje som var feil. Det var både frustrerende og latterlig.

Monit er en god ting i seg selv, og overvåking av daemoner er noe alle servere burde gjøre. Men problemet er at mange nettbaserte veiledninger er basert på antagelsen om at "Apache2 utelukkende bruker port 80", mens HestiaCP bruker en omvendt proxy, noe som betyr at denne antagelsen ikke stemmer.

Hvis du følger instruksjonene, er ikke problemet deg; det er at veiledningen gjelder for et annet scenario enn ditt.

Så hvis du også bruker HestiaCP og tukler med Monit for å overvåke Apache2, husk to ting: Endre porten til 8081, og bruk `systemctl`-kommandoen for å stoppe den, ikke `killall -9`. Hvis du gjør disse to tingene, bør du kunne unngå flere problemer.

Siden du har lest så langt, så lik og del gjerne hvis du syntes det var nyttig. Hvis du vil motta oppdateringer først, kan du også følge meg!

Takk for at du leste artikkelen min. Vi sees neste gang.