Ervaart u regelmatig crashes van Apache2 met HestiaCP? Monit biedt een geautomatiseerde monitoring- en probleemoplossingshandleiding (inclusief volledige configuratie).

Ervaart u regelmatig Apache2-crashes of problemen met het automatisch herstarten van Monit in HestiaCP- omgevingen? Dit artikel biedt een praktische handleiding om veelvoorkomende valkuilen bij het monitoren van Apache2 met Monit te vermijden. Het analyseert diepgaand veelvoorkomende problemen zoals onjuiste PID-paden en geblokkeerde machtigingen, en biedt configuratiebestanden voor Monit-automatisering van productieniveau. Beheers nu de technieken voor serveronderhoud met hoge beschikbaarheid en bereik automatisch herstel op het tweede niveau na storingen!

De valkuilen die ik tegenkwam tijdens het gebruik van Monit om Apache2 te monitoren.

Afgelopen vrijdag gaf de server me midden in de nacht een Monit-melding.

Ik wierp een verdwaasde blik op het paneel en zag in de kolom 'apache2 status' een rode 'Timeout' staan.

Ik heb er even over nagedacht. Ik heb Monit-monitoring aan de server toegevoegd voor overdag en de configuratie gekopieerd uit een online handleiding. Er zouden geen problemen moeten zijn, toch?

De volgende ochtend liep het weer vast. Na de derde keer gaf Monitor het gewoon op en verscheen er 'Niet bewaakt' op het scherm.

I...

Ik geef toe, ik nam het eerst niet serieus. Apache2-monitoring? Je kunt online talloze sjabloonconfiguraties vinden, gewoon kopiëren en plakken. Maar dat plakken maakte me echt woedend.

De hoofdoorzaak van het conflict tussen de standaardarchitectuur van HestiaCP en de Monit-poorten.

Laat me je eerst de configuratie laten zien die me zoveel problemen heeft bezorgd, zodat je kunt controleren of die precies hetzelfde is als de versie die je hebt gezien.

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

Het lijkt in orde, toch? Het controleert poort 80 en als het vastloopt, start het opnieuw op. Als het na 5 herstarts nog steeds vastloopt, treedt er een time-out op.

Het probleem is dat je Apache2 niet eens op poort 80 draait.

Dit is een valkuil van HestiaCP en de hoofdoorzaak waardoor veel mensen erin trappen. De standaardarchitectuur van HestiaCP is een reverse proxy van Nginx + Apache2, waarbij Nginx poorten 80 en 443 bezet en Apache2 op de lokale poort 8081 draait.

Als je Monit vraagt ​​om de beschikbaarheid van Apache2 op poort 80 te controleren, is het alsof je naar McDonald's gaat en KFC aantreft. De server kijkt je glazig aan en jullie staren elkaar aan. Uiteindelijk concludeert Monit dat de server offline is en begint hij halsoverkop opnieuw op te starten.

Na de herstart blijft poort 8081. Monit probeert vervolgens poort 80 te testen, wat ook mislukt, waarna het opnieuw opstart. Deze cyclus herhaalt zich totdat Monit besluit dat het niet meer te repareren is en een time-out geeft.

Toen ik dit voor het eerst tegenkwam, was ik echt verbijsterd. Negen van de tien tutorials die ik online vond, gebruikten poort 80. Als je die tutorials volgde, lag het probleem niet bij jou, maar bij de bron van de informatie zelf.

Een beschadigd Apache2 PID-bestand zorgde ervoor dat Monit het proces ten onrechte als niet-bestaand identificeerde.

Na het wijzigen van de poort van 80 naar 8081 zou Monit het apparaat theoretisch moeten kunnen detecteren, toch?

In werkelijkheid geeft het echter nog steeds af en toe de melding "Uitvoering mislukt ".

Na lang zoeken ontdekte ik eindelijk dat de oorzaak simpel was: het PID-bestand was beschadigd.

Bedenk eens, Monit was constant bezig Apache2 opnieuw op te starten, waarbij het proces telkens geforceerd werd beëindigd en opnieuw gestart, en dit meerdere keren herhaalde. Tijdens dit proces kon het bestand /var/run/apache2/apache2.pid wel eens 0 bytes groot worden.

Met andere woorden: het bestand bestaat nog steeds, maar het is leeg.

Wanneer Monit dit bestand leest, vindt het niets. Het herkent uw Apache2 niet, zelfs niet als uw Apache2 perfect op de achtergrond draait; Monit denkt dat het proces niet bestaat.

Toen ik dit zag, was ik even sprakeloos.

Dit is een impasse. Monit detecteert de Apache 2-instantie niet, herstart Apache2, beschadigt het PID-bestand tijdens het herstartproces, mislukt bij de volgende detectie en herstart opnieuw. Deze cyclus herhaalt zich totdat er een time-out optreedt.

Stappen voor probleemoplossing en reparatie voor Apache2-monitoring in een HestiaCP-omgeving

Eerlijk gezegd is het onderzoeksproces niet ingewikkeld, maar je moet wel weten in welke richting je moet onderzoeken.

De eerste stap is om te bepalen op welke poort uw Apache2 luistert. Typ hiervoor simpelweg een commando in de terminal.

netstat -tulpn | grep apache2

Als alternatief kunt u het commando `ss` gebruiken; het effect is hetzelfde.

ss -tulpn | grep apache2

Je krijgt een uitvoer te zien die hierop lijkt.

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

Het is bevestigd dat het 8081 is, niet 80. Dat is de kern van het probleem.

De tweede stap is het repareren van het beschadigde PID-bestand. Dat is eenvoudiger.

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

Pauzeer eerst de Monit-monitoring om te voorkomen dat deze problemen veroorzaakt tijdens het oplossen van de problemen. Start vervolgens Apache2 opnieuw op zodat deze een schone PID kan genereren. Controleer tot slot de inhoud van het bestand met `cat`; het bestand moet een reeks getallen bevatten, geen lege tekenreeks.

Zodra deze stap is voltooid, is het probleem in principe opgelost.

Vergelijkende analyse van traditionele adaptieve en agressieve beschermingsconfiguraties van Monit

Online handleidingen voor het configureren van Apache2 met Monit vallen over het algemeen in twee categorieën.

Een van de typen is het "traditionele aanpassingstype", dat de `service`-opdracht gebruikt om services te beheren en lokale poorten te controleren zonder al te veel ingewikkelde beperkingen toe te voegen. Deze configuratie kan op HestiaCP worden gebruikt door simpelweg de poort te wijzigen en is relatief stabiel.

Een andere aanpak is de "agressieve beschermingsmethode", die systemctl gebruikt om services te beheren, beperkingen oplegt aan onderliggende processen en een strengere detectielogica hanteert. Het ziet er goed uit, maar het heeft een fatale fout: het gebruikte stopcommando is `killall -9`.

Wat betekent `killall -9`? Het betekent dat het apparaat geforceerd wordt afgesloten, ongeacht wat het aan het doen is. Deze brute-force-bewerking kan gemakkelijk beschadigde PID-bestanden achterlaten, wat het probleem is dat ik zojuist noemde.

Mijn persoonlijke ervaring is dat het beperken van het aantal child-processen in een agressieve configuratie wel degelijk nuttig is. Wanneer uw Apache2 overbelast raakt door een CC-aanval, kan het beperken van het aantal child-processen voorkomen dat de server zonder geheugen komt te zitten. De `killall -9`-aanpak is echter volstrekt onbruikbaar.

Uiteindelijk heb ik dus een compromis gesloten en de voordelen van beide configuraties gecombineerd.

HestiaCP Apache2 Monit Best Practice-configuratie

Wijzig het bestand /etc/monit/conf.d/apache2 met de volgende inhoud.

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

Laat me de logica achter deze paar configuratieregels kort toelichten.

Schrijf poort 8081 zo dat deze exact overeenkomt met de reverse proxy-architectuur van HestiaCP; stop met het onverstandig schrijven van poort 80.

Gebruik de opdracht `systemctl stop` in plaats van `killall -9` om het PID-bestand te stoppen, zodat het niet beschadigd raakt.

Er is een limiet toegevoegd voor het aantal child-processen: als het aantal child-processen de 120 overschrijdt, zal het proces na twee opeenvolgende cycli opnieuw opstarten om CC-aanvallen te voorkomen, maar deze limiet is niet al te streng.

De logica voor het detecteren van storingen is aangepast naar een "voor 2 cycli"-aanpak, wat betekent dat een herstart pas wordt geactiveerd na twee opeenvolgende storingen, waardoor het aantal valse positieven wordt verminderd. De vorige configuratie, die al na één detectie een herstart inluidde, was eerlijk gezegd iets te gevoelig.

De uiteindelijke time-outdrempel wordt versoepeld naar 5 herstarts binnen 10 cycli, waardoor er voldoende fouttolerantie overblijft.

HestiaCP Monitor monitoringSamenvatting van configuratieproblemen en ervaringen delen

Na het doorvoeren van de configuratiewijzigingen heb ik apache2 gemonitord en het paneel toonde eindelijk een groene "OK"-indicator.

Hoe kan ik mijn gevoelens van toen beschrijven? Het was alsof ik twee dagen aan het worstelen was met een bug, om er vervolgens achter te komen dat de oorzaak een enkele foute configuratieregel was. Het was zowel frustrerend als lachwekkend.

Monit is op zich een goede zaak, en het monitoren van daemons is iets wat elke server zou moeten doen. Het probleem is echter dat veel online handleidingen uitgaan van de aanname dat "Apache2 uitsluitend poort 80 gebruikt", terwijl HestiaCP een reverse proxy gebruikt, wat betekent dat deze aanname niet klopt.

Als je de instructies volgt, ligt het probleem niet bij jou, maar bij het feit dat de handleiding van toepassing is op een andere situatie dan die van jou.

Als je HestiaCP gebruikt en Monit inzet om Apache2 te monitoren, onthoud dan twee dingen: wijzig de poort naar 8081 en gebruik het commando `systemctl` om het te stoppen, niet `killall -9`. Als je deze twee dingen doet, zou je verdere problemen moeten kunnen voorkomen.

Aangezien je tot hier hebt gelezen, en je het nuttig vond, geef het dan een like en deel het. Wil je als eerste op de hoogte blijven van de laatste ontwikkelingen, volg me dan!

Bedankt voor het lezen van mijn artikel. Tot de volgende keer.