Biežas Apache2 avārijas ar HestiaCP? Monit automatizētās uzraudzības un problēmu novēršanas rokasgrāmata (ar pilnu konfigurāciju)

Biežas Apache2 avārijas vai Monit automātiskās restartēšanas kļūmes HestiaCP vidēs? Šajā rakstā sniegts praktisks ceļvedis, kā izvairīties no bieži sastopamām kļūmēm, uzraugot Apache2 ar Monit, padziļināti analizējot tādas izplatītas problēmas kā PID ceļa neatbilstība un atļauju bloķēšana, kā arī piedāvājot ražošanas līmeņa Monit automatizācijas konfigurācijas failus. Apgūstiet augstas pieejamības serveru uzturēšanas metodes jau tagad un panākiet otrā līmeņa automātisko atkopšanu pēc kļūmēm!

Kļūdas, ar kurām saskāros, izmantojot Monit Apache2 uzraudzībai

Pagājušajā piektdienā serveris man nakts vidū iedeva Monit brīdinājumu.

Es apmulsis paskatījos uz paneli, un apache2 statusa kolonnā bija sarkans taimauts.

Es par to mazliet padomāju. Es tikko dienas laikā pievienoju Monit uzraudzību serverim un nokopēju un ielīmēju konfigurāciju no tiešsaistes apmācības. Nevajadzētu būt nekādām problēmām, vai ne?

Nākamajā rītā atkal iestājās taimauts. Pēc trešās reizes Monitor vienkārši padevās, un panelī parādījās ziņojums "Nav monitorēts".

Es...

Atzīstu, sākumā neuztvēru to nopietni. Apache2 uzraudzība? Tiešsaistē var atrast milzum daudz veidņu konfigurāciju, vienkārši nokopējiet un ielīmējiet. Bet šis ielīmēšanas process mani tiešām saniknoja.

HestiaCP noklusējuma arhitektūras un Monit portu konflikta pamatcēlonis

Ļaujiet man vispirms parādīt konfigurāciju, kas man sagādāja tik daudz nepatikšanas, lai jūs varētu redzēt, vai tā ir tieši tāda pati kā versija, ko jūs redzējāt.

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

Šķiet, ka viss ir kārtībā, vai ne? Tas pārbauda 80. portu un, ja avarē, restartējas. Ja pēc 5 restartēšanas tas joprojām avarē, iestājas taimauts.

Problēma ir tā, ka jūsu Apache2 pat nedarbojas 80. portā.

Šī ir HestiaCP kļūda un galvenais iemesls, kāpēc daudzi cilvēki tajā iekrīt. HestiaCP noklusējuma arhitektūra ir Nginx + Apache2 apgrieztais starpniekserveris, kur Nginx aizņem 80. un 443. portu priekšā, bet Apache2 darbojas lokālajā 8081. portā aizmugurē.

Ja lūdzat Monit pārbaudīt Apache2 aktivitāti 80. portā, tas ir līdzīgi kā doties uz McDonald's, lai atrastu KFC. Apkalpotājs tukši skatās uz jums, un jūs abi skatāties viens uz otru. Beigās Monit nosaka, ka jūsu serveris nedarbojas, un sāk drudžaini restartēt datoru.

Pēc restartēšanas ports joprojām ir 8081. Pēc tam Monit mēģina pārbaudīt 80. portu, kas arī neizdodas, tāpēc tas atkal tiek restartēts. Šis cikls atkārtojas, līdz Monit nolemj, ka problēmu vairs nevar salabot, un iestājas taimauts.

Kad pirmo reizi ar to saskāros, biju patiesi pārsteigts. Deviņās no desmit pamācībām, ko atradu tiešsaistē, tika izmantots 80. ports. Ja jūs tām sekojāt, problēma nebija jūsos, bet gan pašā informācijas avotā.

Bojāts Apache2 PID fails lika Monit kļūdaini identificēt procesu kā neesošu.

Pēc porta maiņas no 80 uz 8081 Monit teorētiski vajadzētu to noteikt, vai ne?

Tomēr patiesībā tas joprojām laiku pa laikam ziņo "Izpilde neizdevās ".

Pēc ilgstošas ​​cīņas es beidzot atklāju, ka iemesls ir vienkāršs: PID fails ir bojāts.

Padomājiet tikai, Monit neprātīgi restartēja Apache2, katru reizi piespiedu kārtā to izslēdzot un restartējot, vairākas reizes atkārtojot šo procesu. Šī procesa laikā fails /var/run/apache2/apache2.pid varēja kļūt 0 baiti liels.

Citiem vārdiem sakot, fails joprojām ir tur, bet tas ir tukšs.

Kad Monit nolasa šo failu, tas neko neatrod. Tas neatpazīst jūsu Apache2, pat ja jūsu Apache2 fonā darbojas nevainojami; Monit neuzskata, ka šis process pastāv.

Kad es to ieraudzīju, uz brīdi biju bez vārdiem.

Šī ir strupceļa situācija. Monit neizdodas noteikt Apache 2 instanci, restartē Apache2, restartēšanas procesa laikā sabojā PID failu, nākamā noteikšana neizdodas un restartē vēlreiz. Šis cikls turpinās, līdz iestājas taimauts.

Apache2 uzraudzības problēmu novēršanas un labošanas darbības HestiaCP vidē

Godīgi sakot, izmeklēšanas process nav sarežģīts, taču ir jāzina, kurā virzienā izmeklēt.

Pirmais solis ir noteikt, kuru portu jūsu Apache2 klausās. Vienkārši ierakstiet komandu terminālī.

netstat -tulpn | grep apache2

Varat arī izmantot komandu `ss`; efekts ir tāds pats.

ss -tulpn | grep apache2

Jūs redzēsiet līdzīgu izvadi.

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

Ir apstiprināts, ka tas ir 8081, nevis 80. Tā ir problēmas sakne.

Otrais solis ir bojātā PID faila labošana. Tas ir vienkāršāk.

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

Vispirms apturiet Monit uzraudzību, lai novērstu tās traucējumus, kamēr jūs labojat lietas. Pēc tam restartējiet Apache2, lai ļautu tai pārrakstīt tīru PID. Visbeidzot, izmantojiet `cat`, lai pārbaudītu faila saturu; tajā jābūt skaitļu virknei, nevis tukšai virknei.

Kad šis solis ir pabeigts, problēma būtībā ir atrisināta.

Monit tradicionālo adaptīvo un agresīvo aizsardzības konfigurāciju salīdzinošā analīze

Tiešsaistes pamācības par Apache2 konfigurēšanu ar Monit parasti iedalās divās kategorijās.

Viens veids ir "tradicionālais adaptācijas veids", kas izmanto komandu `service`, lai pārvaldītu pakalpojumus un pārbaudītu lokālās pieslēgvietas, nepievienojot pārāk daudz sarežģītu ierobežojumu. Šo konfigurāciju var izmantot HestiaCP, vienkārši mainot pieslēgvietu, un tā ir relatīvi stabila.

Vēl viena pieeja ir "agresīvās aizsardzības" metode, kas pakalpojumu pārvaldībai izmanto systemctl, pievieno bērnprocesu ierobežojumus un izmanto stingrāku noteikšanas loģiku. Tā izskatās lieliski, taču tai ir fatāls trūkums: izmantotā apturēšanas komanda ir `killall -9`.

Ko nozīmē `killall -9`? Tas nozīmē piespiedu kārtā pārtraukt ierīces darbību neatkarīgi no tās darbības. Šī brutālā spēka darbība var viegli atstāt bojātus PID failus, un šī ir problēma, ko tikko pieminēju.

Mana personīgā pieredze liecina, ka agresīvā konfigurācijā bērnu procesu skaita ierobežošana patiešām ir noderīga. Kad jūsu Apache2 serveri pārņem CC uzbrukums, bērnu procesu skaita ierobežošana var novērst servera atmiņas trūkumu. Tomēr pieeja `killall -9` ir pilnībā nelietojama.

Tāpēc galu galā es piekāpos un apvienoju abu konfigurāciju priekšrocības.

HestiaCP Apache2 Monit labākās prakses konfigurācija

Modificējiet failu /etc/monit/conf.d/apache2 ar šādu saturu.

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

Ļaujiet man īsi paskaidrot šo dažu konfigurācijas rindiņu loģiku.

Ierakstiet 8081. portu, lai tas precīzi atbilstu HestiaCP reversā starpniekservera arhitektūrai; beidziet muļķīgi rakstīt 80. portu.

Lai apturētu PID failu un to nesabojātu, izmantojiet komandu `systemctl stop`, nevis `killall -9`.

Ir pievienots bērnu procesu ierobežojums: ja bērnu skaits pārsniedz 120, process tiks restartēts pēc diviem secīgiem cikliem, lai novērstu CC uzbrukumus, taču tas nav pārāk agresīvs.

Kļūmju noteikšanas loģika ir modificēta, lai izmantotu "2 ciklu" pieeju, kas nozīmē, ka restartēšana tiek aktivizēta tikai pēc divām secīgām kļūmēm, tādējādi samazinot viltus pozitīvus rezultātus. Iepriekšējā konfigurācija, kas restartējās jau pēc vienas noteikšanas, atklāti sakot, bija nedaudz pārāk jutīga.

Galīgais taimauta slieksnis ir atvieglots līdz 5 restartēšanas reizēm 10 ciklu laikā, atstājot pietiekamu kļūdu toleranci.

HestiaCP Uzraudzīt uzraudzībuKonfigurācijas problēmu novēršanas kopsavilkums un pieredzes apmaiņa

Pēc konfigurācijas izmaiņu veikšanas es uzraudzīju apache2, un panelī beidzot parādījās zaļš "OK" indikators.

Kā lai raksturoju savas tā brīža sajūtas? Tas bija kā divas dienas, cīnoties ar kļūdu, tikai lai atklātu, ka tās cēlonis ir viena nepareiza konfigurācijas rinda. Tas bija gan nomācoši, gan smieklīgi.

Monit pats par sevi ir laba lieta, un dēmonu uzraudzība ir kaut kas tāds, kas jādara katram serverim. Taču problēma ir tā, ka daudzas tiešsaistes pamācības ir balstītas uz pieņēmumu, ka "Apache2 izmanto tikai 80. portu", savukārt HestiaCP izmanto apgriezto starpniekserveri, kas nozīmē, ka šis pieņēmums nav patiess.

Ja sekojat norādījumiem, problēma nav jūsos; problēma ir tā, ka apmācība ir piemērojama citam scenārijam nekā jūsu.

Tātad, ja jūs arī izmantojat HestiaCP un eksperimentējat ar Monit, lai uzraudzītu Apache2, atcerieties tikai divas lietas: nomainiet portu uz 8081 un izmantojiet komandu `systemctl`, lai to apturētu, nevis `killall -9`. Ja jūs izdarīsiet šīs divas lietas, jums vajadzētu būt iespējai izvairīties no turpmākām problēmām.

Tā kā esi izlasījis līdz šim brīdim, ja tas tev bija noderīgi, lūdzu, atzīmē ar “Patīk” un dalies ar to. Ja vēlies saņemt jaunumus pirmie, vari arī sekot man!

Paldies, ka izlasījāt manu rakstu. Uz tikšanos nākamreiz.