Kraschar Apache2 ofta med HestiaCP? Monit automatiserad övervaknings- och felsökningsguide (med fullständig konfiguration)

Frekventa Apache2-krascher eller automatisk omstart av Monit i HestiaCP- miljöer? Den här artikeln ger en praktisk guide till att undvika vanliga fallgropar när du övervakar Apache2 med Monit, analyserar djupt vanliga problem som feljustering av PID-sökvägar och behörighetsblockering, och erbjuder konfigurationsfiler för automatisering av Monit i produktionsklass. Bemästra tekniker för serverunderhåll med hög tillgänglighet nu och uppnå automatisk återställning på andra nivån från fel!

Fallgroparna jag stötte på när jag använde Monit för att övervaka Apache2

Förra fredagen gav servern mig en Monit-varning mitt i natten.

Jag tittade omtöcknad på panelen, och i apache2-statuskolumnen fanns det en röd Timeout.

Jag funderade lite på det. Jag lade precis till Monit-övervakning på servern under dagen, och jag kopierade och klistrade in konfigurationen från en online-handledning. Det borde väl inte vara några problem?

Nästa morgon gick den ut igen. Efter tredje gången gav Monitorn helt enkelt upp, och panelen visade "Inte övervakad".

Jag...

Jag erkänner att jag inte tog det på allvar först. Apache2-övervakning? Du kan hitta massor av mallkonfigurationer online, bara kopiera och klistra in. Men den inklistringsprocessen gjorde mig verkligen rasande.

Grundorsaken till konflikten mellan HestiaCPs standardarkitektur och Monit-portar

Låt mig först visa dig konfigurationen som orsakade mig så mycket problem, så att du kan se om det är exakt samma version som den 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 verkar bra, eller hur? Den kontrollerar port 80, och om den kraschar startar den om. Om den fortfarande kraschar efter 5 omstarter får den timeout.

Problemet är att din Apache2 inte ens körs på port 80.

Detta är en fallgrop med HestiaCP, och grundorsaken till att många faller för den. HestiaCPs standardarkitektur är en omvänd proxy av Nginx + Apache2, där Nginx upptar portarna 80 och 443 längst fram, och Apache2 körs på den lokala porten 8081 längst bak.

Om du ber Monit att undersöka Apache2:s aktiva läge på port 80, är ​​det som att gå till McDonald's för att hitta KFC. Servitören tittar tomt på dig, och ni två stirrar på varandra. Till slut konstaterar Monit att ni är nere och börjar frenetiskt starta om.

Efter omstart är porten fortfarande 8081. Monit försöker sedan undersöka port 80, vilket också misslyckas, så den startar om igen. Denna cykel upprepas tills Monit bestämmer att den inte kan repareras och tidsgränsen överskrids.

När jag först stötte på detta blev jag genuint chockad. Nio av tio handledningar jag hittade online använde port 80. Om du följde dem låg problemet inte hos dig, utan hos själva informationskällan.

En skadad Apache2 PID-fil fick Monit att felaktigt identifiera processen som icke-existerande.

Efter att ha ändrat porten från 80 till 8081 borde Monit teoretiskt sett kunna upptäcka den, eller hur?

Men i verkligheten rapporterar den fortfarande ibland "Körningen misslyckades ".

Efter att ha kämpat länge upptäckte jag äntligen att orsaken var enkel: PID-filen var skadad.

Tänk på det, Monit startade frenetiskt om Apache2, och varje gång tvångsmässigt avslutade och startade om det, fram och tillbaka flera gånger. Under denna process kan filen /var/run/apache2/apache2.pid bli 0 byte.

Med andra ord, filen finns fortfarande kvar, men den är tom.

När Monit läser den här filen hittar den ingenting. Den känner inte igen din Apache2, även om din Apache2 körs perfekt i bakgrunden; Monit tror inte att processen existerar.

När jag såg detta blev jag mållös för ett ögonblick.

Detta är ett dödläge. Monit misslyckas med att upptäcka Apache 2-instansen, startar om Apache2, korrumperar PID-filen under omstartsprocessen, misslyckas med nästa detektering och startar om igen. Denna cykel fortsätter tills timeout inträffar.

Felsöknings- och reparationssteg för Apache2-övervakning i HestiaCP-miljön

Ärligt talat är utredningsprocessen inte komplicerad, men du måste veta vilken riktning du ska undersöka.

Det första steget är att avgöra vilken port din Apache2 lyssnar på. Skriv helt enkelt ett kommando i terminalen.

netstat -tulpn | grep apache2

Alternativt kan du använda kommandot `ss`; effekten är densamma.

ss -tulpn | grep apache2

Du kommer att se utdata som liknar detta.

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

Det är bekräftat att det är 8081, inte 80. Det är roten till problemet.

Det andra steget är att reparera den skadade PID-filen. Detta är enklare.

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

Pausa först Monit-övervakningen för att förhindra att den stör medan du fixar saker. Starta sedan om Apache2 för att låta den skriva om en ren PID. Använd slutligen `cat` för att kontrollera filinnehållet; den ska innehålla en siffersträng, inte en tom sträng.

När detta steg är slutfört är problemet i princip löst.

Jämförande analys av Monits traditionella adaptiva och aggressiva skyddskonfigurationer

Online-handledningar om hur man konfigurerar Apache2 med Monit delas vanligtvis in i två kategorier.

En typ är den "traditionella anpassningstypen", som använder kommandot `service` för att hantera tjänster och kontrollera lokala portar utan att lägga till för många komplicerade begränsningar. Denna konfiguration kan användas på HestiaCP genom att helt enkelt ändra porten, och den är relativt stabil.

En annan metod är metoden "aggressivt skydd", som använder systemctl för att hantera tjänster, lägger till begränsningar för underordnade processer och använder striktare detekteringslogik. Det ser bra ut, men det har en allvarlig brist: stoppkommandot som används är `killall -9`.

Vad betyder `killall -9`? Det betyder att tvångsavstänga enheten oavsett vad den gör. Denna brute-force-operation kan lätt lämna kvar korrupta PID-filer, vilket är problemet jag just nämnde.

Min personliga erfarenhet är att det är mycket användbart att begränsa antalet underprocesser i en aggressiv konfiguration. När din Apache2 överväldigas av en CC-attack kan en begränsning av antalet underprocesser förhindra att servern får slut på minne. Metoden `killall -9` är dock helt oanvändbar.

Så till slut kompromissade jag och kombinerade fördelarna med båda konfigurationerna.

HestiaCP Apache2 Monitor Bästa praxiskonfiguration

Ändra filen /etc/monit/conf.d/apache2 med följande innehåll.

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

Låt mig kortfattat förklara logiken bakom dessa få konfigurationsrader.

Skriv port 8081 så att den exakt matchar HestiaCPs omvända proxyarkitektur; sluta skriva port 80 på ett dumt sätt.

Använd kommandot `systemctl stop` istället för `killall -9` för att stoppa PID-filen, så att den inte skadas.

En gräns för underprocesser har lagts till: om antalet underprocesser överstiger 120 startas processen om efter två på varandra följande cykler för att förhindra CC-attacker, men den är inte för aggressiv.

Logiken för att upptäcka fel har modifierats för att använda en metod som kallas "för 2 cykler", vilket innebär att en omstart endast utlöses efter två fel i rad, vilket minskar antalet falska positiva resultat. Den tidigare konfigurationen, som startade om efter bara en detektering, var ärligt talat lite överkänslig.

Den slutliga timeout-tröskeln mildras till 5 omstarter inom 10 cykler, vilket lämnar tillräcklig feltolerans.

HestiaCP Monit övervakningSammanfattning av felsökning av konfiguration och erfarenhetsdelning

Efter att ha gjort konfigurationsändringarna övervakade jag apache2, och panelen visade äntligen en grön "OK"-indikator.

Hur ska jag beskriva mina känslor då? Det var som att tillbringa två dagar med att kämpa med en bugg, bara för att upptäcka att orsaken var en enda felaktig konfigurationsrad. Det var både frustrerande och skrattretande.

Monit är en bra sak i sig, och att övervaka daemoner är något som alla servrar borde göra. Men problemet är att många online-handledningar bygger på antagandet att "Apache2 uteslutande använder port 80", medan HestiaCP använder en omvänd proxy, vilket innebär att detta antagande inte stämmer.

Om du följer instruktionerna är problemet inte du; det är att handledningen är tillämplig på ett annat scenario än ditt.

Så om du också använder HestiaCP och experimenterar med Monit för att övervaka Apache2, kom ihåg två saker: Ändra porten till 8081 och använd kommandot `systemctl` för att stoppa det, inte `killall -9`. Om du gör dessa två saker borde du kunna undvika ytterligare problem.

Eftersom du har läst så här långt, om du tyckte att det var hjälpsamt, gilla och dela det gärna. Om du vill få uppdateringar först kan du också följa mig!

Tack för att du läste min artikel. Vi ses nästa gång.