Gereelde ineenstortings van Apache2 met HestiaCP? Monit outomatiese monitering en probleemoplossingsgids (met volledige konfigurasie)

Gereelde Apache2-ineenstortings of Monit-outomatiese herbeginfoute in HestiaCP- omgewings? Hierdie artikel bied 'n praktiese gids om algemene slaggate te vermy wanneer Apache2 met Monit gemonitor word, diepgaande ontleding van algemene probleme soos PID-padwanbelyning en toestemmingsblokkering, en die aanbied van produksiegraadse Monit-outomatiseringskonfigurasielêers. Bemeester nou hoëbeskikbaarheidsbedieneronderhoudstegnieke en bereik tweedevlak-outomatiese herstel van foute!

Die slaggate wat ek teëgekom het terwyl ek Monit gebruik het om Apache2 te monitor

Verlede Vrydag het die bediener my 'n Monit-waarskuwing in die middel van die nag gegee.

Ek het verdwaas na die paneel gekyk, en in die apache2-statuskolom was daar 'n rooi Time-out.

Ek het 'n bietjie daaroor nagedink. Ek het sopas Monit-monitering gedurende die dag by die bediener gevoeg, en ek het die konfigurasie van 'n aanlyn tutoriaal gekopieer en geplak. Daar behoort geen probleme te wees nie, reg?

Die volgende oggend het dit weer uitgetel. Na die derde keer het Monitor eenvoudig moed opgegee, en die paneel het "Nie gemonitor nie" vertoon.

Ek...

Ek erken, ek het dit aanvanklik nie ernstig opgeneem nie. Apache2-monitering? Jy kan tonne sjabloonkonfigurasies aanlyn vind, kopieer en plak net. Maar daardie plakproses het my regtig woedend gemaak.

Die oorsaak van die konflik tussen HestiaCP se standaardargitektuur en Monit-poorte

Laat ek jou eers die konfigurasie wys wat my soveel probleme veroorsaak het, sodat jy kan sien of dit presies dieselfde is as die weergawe wat jy gesien het.

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

Dit lyk goed, reg? Dit kontroleer poort 80, en as dit vasval, herbegin dit. As dit steeds vasval na 5 herbeginnings, kry dit 'n tyd-oorskryding.

Die probleem is, jou Apache2 loop nie eers op poort 80 nie.

Dit is 'n valkuil van HestiaCP, en die oorsaak waarom baie mense daarin val. HestiaCP se standaardargitektuur is 'n omgekeerde proxy van Nginx + Apache2, met Nginx wat poorte 80 en 443 voor beset, en Apache2 wat op die plaaslike poort 8081 agter loop.

As jy Monit vra om die lewendigheid van Apache2 op poort 80 te ondersoek, is dit soos om na McDonald's te gaan om KFC te soek. Die kelner kyk jou leeg aan, en julle twee staar na mekaar. Uiteindelik bepaal Monit dat julle af is en begin paniekerig herbegin.

Na herbegin is die poort steeds 8081. Monit probeer dan poort 80 ondersoek, wat ook misluk, so dit herbegin weer. Hierdie siklus herhaal totdat Monit besluit dat dit onherstelbaar is en 'n tyd-oorskryding bereik.

Toe ek dit die eerste keer teëgekom het, was ek werklik verstom. Nege uit tien tutoriale wat ek aanlyn gevind het, het poort 80 gebruik. As jy hulle gevolg het, was die probleem nie by jou nie, maar by die bron van die inligting self.

'n Korrupte Apache2 PID-lêer het veroorsaak dat Monit die proses verkeerdelik as nie-bestaande geïdentifiseer het.

Nadat die poort van 80 na 8081 verander is, behoort Monit dit teoreties te kan opspoor, reg?

In werklikheid rapporteer dit egter steeds af en toe "Uitvoering het misluk ".

Nadat ek lank gesukkel het, het ek uiteindelik ontdek dat die rede eenvoudig was: die PID-lêer was korrup.

Dink daaraan, Monit het Apache2 paniekerig herbegin, elke keer met geweld doodgemaak en herbegin, en verskeie kere heen en weer gegaan. Gedurende hierdie proses kan die lêer /var/run/apache2/apache2.pid 0 grepe word.

Met ander woorde, die lêer is steeds daar, maar dit is leeg.

Wanneer Monit hierdie lêer lees, vind dit niks. Dit herken nie jou Apache2 nie, selfs al loop jou Apache2 perfek in die agtergrond; Monit dink nie die proses bestaan ​​nie.

Toe ek dit sien, was ek vir 'n oomblik sprakeloos.

Dit is 'n dooiepunt. Monit slaag nie daarin om die Apache 2-instansie op te spoor nie, herbegin Apache2, beskadig die PID-lêer tydens die herbeginproses, misluk die volgende opsporing en herbegin weer. Hierdie siklus duur voort totdat die tydsberekening plaasvind.

Probleemoplossing en herstelstappe vir Apache2-monitering in die HestiaCP-omgewing

Om eerlik te wees, die ondersoekproses is nie ingewikkeld nie, maar jy moet weet watter rigting om te ondersoek.

Die eerste stap is om te bepaal op watter poort jou Apache2 luister. Tik eenvoudig 'n opdrag in die terminaal.

netstat -tulpn | grep apache2

Alternatiewelik kan jy die `ss`-opdrag gebruik; die effek is dieselfde.

ss -tulpn | grep apache2

Jy sal soortgelyke uitset sien.

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

Dit is bevestig as 8081, nie 80 nie. Dis die wortel van die probleem.

Die tweede stap is om die korrupte PID-lêer te herstel. Dit is eenvoudiger.

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

Eerstens, onderbreek Monit-monitering om te verhoed dat dit inmeng terwyl jy dinge regstel. Herbegin dan Apache2 om dit toe te laat om 'n skoon PID te herskryf. Laastens, gebruik `cat` om die lêerinhoud na te gaan; dit moet 'n string getalle bevat, nie 'n leë string nie.

Sodra hierdie stap voltooi is, is die probleem basies opgelos.

Vergelykende Analise van Monit Tradisionele Aanpasbare en Aggressiewe Beskermende Konfigurasies

Aanlyn tutoriale oor die konfigurasie van Apache2 met Monit val gewoonlik in twee kategorieë.

Een tipe is die "tradisionele aanpassingstipe", wat die `diens`-opdrag gebruik om dienste te bestuur en plaaslike poorte na te gaan sonder om te veel ingewikkelde beperkings by te voeg. Hierdie konfigurasie kan op HestiaCP gebruik word deur eenvoudig die poort te verander, en dit is relatief stabiel.

Nog 'n benadering is die "aggressiewe beskerming"-metode, wat systemctl gebruik om dienste te bestuur, kinderprosesbeperkings byvoeg en strenger opsporingslogika gebruik. Dit lyk goed, maar dit het 'n fatale fout: die stopopdrag wat gebruik word, is `killall -9`.

Wat beteken `killall -9`? Dit beteken om die toestel met geweld dood te maak, ongeag wat dit doen. Hierdie brute-force-operasie kan maklik korrupte PID-lêers agterlaat, wat die probleem is wat ek so pas genoem het.

My persoonlike ervaring is dat die beperking van die aantal kinderprosesse in 'n aggressiewe konfigurasie inderdaad nuttig is. Wanneer jou Apache2 oorweldig word deur 'n CC-aanval, kan die beperking van die aantal kinderprosesse verhoed dat die bediener geheue opraak. Die `killall -9`-benadering is egter werklik onbruikbaar.

So uiteindelik het ek 'n kompromis aangegaan en die voordele van beide konfigurasies gekombineer.

HestiaCP Apache2 Monit Beste Praktyk Konfigurasie

Wysig die lêer /etc/monit/conf.d/apache2 met die 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 ek kortliks die logika agter hierdie paar konfigurasielyne verduidelik.

Skryf poort 8081 om presies ooreen te stem met HestiaCP se omgekeerde proxy-argitektuur; hou op om dwaaslik poort 80 te skryf.

Gebruik die `systemctl stop`-opdrag in plaas van `killall -9` om die PID-lêer te stop, sodat dit nie beskadig word nie.

'n Kinderproseslimiet is bygevoeg: as die aantal kinders 120 oorskry, sal die proses na twee opeenvolgende siklusse herbegin om CC-aanvalle te voorkom, maar dit is nie te aggressief nie.

Die logika vir die opsporing van mislukkings is aangepas om 'n "vir 2 siklusse"-benadering te gebruik, wat beteken dat 'n herbegin slegs na twee opeenvolgende mislukkings geaktiveer word, wat vals positiewe verminder. Die vorige konfigurasie, wat na slegs een opsporing herbegin het, was eerlikwaar 'n bietjie oorsensitief.

Die finale tydsbeperkingsdrempel word verslap na 5 herbeginnings binne 10 siklusse, wat voldoende fouttoleransie laat.

HestiaCP Monit moniteringOpsomming van konfigurasieprobleme en ervaringsdeling

Nadat ek die konfigurasieveranderinge aangebring het, het ek apache2 gemonitor, en die paneel het uiteindelik 'n groen "OK" aanwyser gewys.

Hoe beskryf ek my gevoelens destyds? Dit was soos om twee dae lank met 'n fout te sukkel, net om uit te vind dat die oorsaak 'n enkele reël konfigurasie verkeerd was. Dit was beide frustrerend en lagwekkend.

Monit is op sigself 'n goeie ding, en die monitering van daemone is iets wat elke bediener behoort te doen. Maar die probleem is dat baie aanlyn tutoriale gebaseer is op die aanname dat "Apache2 uitsluitlik poort 80 gebruik," terwyl HestiaCP 'n omgekeerde instaanbediener gebruik, wat beteken dat hierdie aanname nie waar is nie.

As jy die instruksies volg, is die probleem nie jy nie; dit is dat die tutoriaal van toepassing is op 'n ander scenario as joune.

So as jy ook HestiaCP gebruik en met Monit peuter om Apache2 te monitor, onthou net twee dinge: Verander die poort na 8081, en gebruik die `systemctl`-opdrag om dit te stop, nie `killall -9` nie. As jy hierdie twee dinge doen, behoort jy enige verdere probleme te kan vermy.

Aangesien jy tot hier gelees het, as jy dit nuttig gevind het, like en deel dit asseblief. As jy eerste opdaterings wil ontvang, kan jy my ook volg!

Dankie dat jy my artikel gelees het. Sien jou volgende keer.