Oftaj kraŝoj de Apache2 kun HestiaCP? Gvidilo por aŭtomata monitorado kaj problemsolvado de Monit (kun kompleta agordo)

Oftaj kraŝoj de Apache2 aŭ malsukcesoj de aŭtomata rekomenco de Monit en HestiaCP- medioj? Ĉi tiu artikolo provizas praktikan gvidilon por eviti oftajn kaptilojn dum monitorado de Apache2 per Monit, profunde analizante oftajn problemojn kiel misaranĝo de PID-vojo kaj permesblokado, kaj ofertante produktadnivelajn aŭtomatigajn agordodosierojn de Monit. Majstru nun alt-havebleco-servilajn bontenajn teknikojn kaj atingu duanivelan aŭtomatan reakiron post malsukcesoj!

La kaptiloj, kiujn mi renkontis dum uzado de Monit por monitori Apache2

Pasintan vendredon, la servilo donis al mi Monit-averton meze de la nokto.

Mi konfuzite ekrigardis la panelon, kaj en la statusa kolumno de apache2 estis ruĝa "Tempolimo".

Mi pripensis ĝin iom. Mi ĵus aldonis Monit-monitoradon al la servilo dumtage, kaj mi kopiis kaj algluis la agordon el reta lernilo. Ne devus esti problemoj, ĉu ne?

La sekvan matenon, ĝi denove eksvalidiĝis. Post la tria fojo, Monitor simple rezignis, kaj la panelo montris "Ne monitorata".

Mi...

Mi konfesas, ke mi komence ne prenis ĝin serioze. Apache2-monitorado? Vi povas trovi tunojn da ŝablonagordoj interrete, nur kopiu kaj algluu. Sed tiu algluprocezo vere kolerigis min.

La vera kaŭzo de la konflikto inter la defaŭlta arkitekturo de HestiaCP kaj la pordoj de Monit

Unue mi montros al vi la agordon, kiu kaŭzis al mi tiom da problemoj, por ke vi povu vidi, ĉu ĝi estas precize la sama kiel la versio, kiun vi vidis.

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

Ŝajnas, ke ĝi bone funkcias, ĉu ne? Ĝi kontrolas pordon 80, kaj se ĝi kraŝas, ĝi rekomenciĝas. Se ĝi ankoraŭ kraŝas post 5 rekomencoj, ĝi eksvalidiĝas.

La problemo estas, ke via Apache2 eĉ ne funkcias sur pordo 80.

Jen kaptilo de HestiaCP, kaj la vera kaŭzo de tio, ke multaj homoj falas en ĝin. La defaŭlta arkitekturo de HestiaCP estas inversa prokurilo de Nginx + Apache2, kun Nginx okupanta la pordojn 80 kaj 443 antaŭe, kaj Apache2 funkcianta sur la loka pordo 8081 malantaŭe.

Se vi petas Monit-on esplori la aktivecon de Apache2 ĉe pordo 80, estas kvazaŭ iri al McDonald's por trovi KFC. La servilo rigardas vin senesprime, kaj vi ambaŭ fiksrigardas unu la alian. Fine, Monit decidas, ke vi ne funkcias kaj panike rekomencas.

Post rekomenco, la pordo estas ankoraŭ 8081. Monit tiam provas sondi pordon 80, kiu ankaŭ malsukcesas, do ĝi rekomencas denove. Ĉi tiu ciklo ripetiĝas ĝis Monit decidas, ke ĝi estas neriparebla kaj la tempolimo eksvalidiĝas.

Kiam mi unue renkontis ĉi tion, mi vere miregis. Naŭ el dek lerniloj, kiujn mi trovis interrete, uzis pordon 80. Se vi sekvis ilin, la problemo ne estis ĉe vi, sed ĉe la fonto de la informo mem.

Koruptita Apache2 PID-dosiero igis Monit erare identigi la procezon kiel neekzistantan.

Post ŝanĝo de la pordo de 80 al 8081, Monit teorie devus povi detekti ĝin, ĉu ne?

Tamen, reale, ĝi ankoraŭ foje raportas "Plenumo malsukcesis ".

Post longa luktado, mi fine malkovris, ke la kialo estis simpla: la PID-dosiero estis koruptita.

Pripensu, Monit panike rekomencis Apache2, ĉiufoje perforte mortigante kaj rekomencante ĝin, irante tien kaj reen plurfoje. Dum ĉi tiu procezo, la dosiero /var/run/apache2/apache2.pid eble fariĝos 0 bajtoj.

Alivorte, la dosiero ankoraŭ estas tie, sed ĝi estas malplena.

Kiam Monit legas ĉi tiun dosieron, ĝi trovas nenion. Ĝi ne rekonas vian Apache2, eĉ se via Apache2 funkcias perfekte bone en la fono; Monit ne pensas, ke la procezo ekzistas.

Kiam mi vidis tion, mi restis senvorta por momento.

Jen blokiĝo. Monit malsukcesas detekti la instancon de Apache 2, rekomencas Apache 2, koruptas la PID-dosieron dum la rekomencprocezo, malsukcesas la sekvan detekton, kaj rekomencas denove. Ĉi tiu ciklo daŭras ĝis la tempolimo okazas.

Solvado de problemoj kaj riparaj paŝoj por Apache2-monitorado en HestiaCP-medio

Verdire, la esplorprocezo ne estas komplika, sed vi devas scii, kiun direkton esplori.

La unua paŝo estas determini, sur kiu pordo via Apache2 aŭskultas. Simple tajpu komandon en la terminalo.

netstat -tulpn | grep apache2

Alternative, vi povas uzi la komandon `ss`; la efiko estas la sama.

ss -tulpn | grep apache2

Vi vidos rezulton similan al ĉi tio.

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

Estas konfirmite, ke ĝi estas 8081, ne 80. Tio estas la radiko de la problemo.

La dua paŝo estas ripari la koruptitan PID-dosieron. Tio estas pli simpla.

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

Unue, paŭzu la monitoradon de Monit por malhelpi ĝin interrompi dum vi riparas aferojn. Poste, rekomencu Apache2 por permesi al ĝi reskribi puran PID-on. Fine, uzu `cat` por kontroli la dosierenhavon; ĝi devus enhavi ĉenon de nombroj, ne malplenan ĉenon.

Post kiam ĉi tiu paŝo estas kompletigita, la problemo estas baze solvita.

Kompara Analizo de Tradiciaj Adaptaj kaj Agresemaj Protektaj Konfiguracioj de Monit

Interretaj lerniloj pri agordado de Apache2 per Monit ĝenerale falas en du kategoriojn.

Unu tipo estas la "tradicia adaptiĝa tipo", kiu uzas la komandon `service` por administri servojn kaj kontroli lokajn pordojn sen aldoni tro multajn komplikajn limigojn. Ĉi tiu agordo uzeblas ĉe HestiaCP simple ŝanĝante la pordon, kaj ĝi estas relative stabila.

Alia aliro estas la metodo "agresema protekto", kiu uzas systemctl por administri servojn, aldonas limigojn al infanaj procezoj, kaj uzas pli striktan detektan logikon. Ĝi aspektas bonege, sed ĝi havas mortigan difekton: la uzata haltiga komando estas `killall -9`.

Kion signifas `killall -9`? Ĝi signifas perforte mortigi la aparaton sendepende de tio, kion ĝi faras. Ĉi tiu krudpera operacio povas facile lasi post si koruptitajn PID-dosierojn, kio estas la problemo, kiun mi ĵus menciis.

Mia persona sperto estas, ke limigi la nombron de idoj en agresema konfiguracio estas efektive utila. Kiam via Apache2 estas superfortita de CC-atako, limigi la nombron de idoj povas malhelpi la servilon elĉerpi memoron. Tamen, la metodo `killall -9` estas vere neuzebla.

Do fine mi kompromisis kaj kombinis la avantaĝojn de ambaŭ konfiguracioj.

Plej Bonaj Praktikoj pri Agordo de HestiaCP Apache2 Monit

Modifu la dosieron /etc/monit/conf.d/apache2 per la jena enhavo.

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

Permesu al mi mallonge klarigi la logikon malantaŭ ĉi tiuj kelkaj linioj de konfiguracio.

Skribu pordon 8081 por precize kongrui kun la inversa prokurila arkitekturo de HestiaCP; ĉesu malsaĝe skribi pordon 80.

Uzu la komandon `systemctl stop` anstataŭ `killall -9` por haltigi la PID-dosieron, por ne korupti ĝin.

Aldoniĝis limo por idoj-procezoj: se la nombro de idoj superas 120, la procezo rekomenciĝos post du sinsekvaj cikloj por preventi CC-atakojn, sed ĝi ne estas tro agresema.

La logiko por detekti paneojn estis modifita por uzi metodon "dum 2 cikloj", kio signifas, ke rekomenco estas ekigita nur post du sinsekvaj paneoj, reduktante falsajn pozitivojn. La antaŭa agordo, kiu rekomenciĝis post nur unu detekto, estis sincere iom tro sentema.

La fina tempolimo-sojlo estas malstreĉigita al 5 rekomencoj ene de 10 cikloj, lasante sufiĉan erar-eltenemon.

HestiaCP Monitora monitoradoResumo pri Agordo-Solvado de Problemoj kaj Kunhavigo de Spertoj

Post fari la agordajn ŝanĝojn, mi monitoris apache2, kaj la panelo fine montris verdan indikilon "Bone".

Kiel priskribi miajn sentojn tiam? Estis kvazaŭ pasigi du tagojn luktante kontraŭ cimo, nur por malkovri, ke la kaŭzo estis ununura linio de malĝusta agordo. Estis kaj frustrante kaj ridinde.

Monit estas bona afero en si mem, kaj monitorado de demonoj estas io, kion ĉiu servilo devus fari. Sed la problemo estas, ke multaj interretaj lerniloj baziĝas sur la supozo, ke "Apache2 uzas ekskluzive pordon 80", dum HestiaCP uzas inversan prokurilon, kio signifas, ke ĉi tiu supozo ne validas.

Se vi sekvos la instrukciojn, la problemo ne estas vi; ĝi estas, ke la lernilo aplikeblas al alia scenaro ol la via.

Do, se vi ankaŭ uzas HestiaCP kaj ludas kun Monit por monitori Apache2, nur memoru du aferojn: Ŝanĝu la pordon al 8081, kaj uzu la komandon `systemctl` por haltigi ĝin, ne `killall -9`. Se vi faros ĉi tiujn du aferojn, vi devus povi eviti pluajn problemojn.

Ĉar vi legis ĝis ĉi tie, se vi trovis ĝin utila, bonvolu ŝati kaj dividi ĝin. Se vi volas ricevi ĝisdatigojn unue, vi ankaŭ povas sekvi min!

Dankon pro legado de mia artikolo. Ĝis revido.