HestiaCP менен Apache2 тез-тез бузулуп жатабы? Монитордук автоматташтырылган мониторинг жана мүчүлүштүктөрдү оңдоо боюнча колдонмо (толук конфигурациясы менен)

HestiaCP чөйрөлөрүндө Apache2 тез-тез бузулуп же Monit автоматтык түрдө кайра жүктөлүп жатканда мүчүлүштүктөр болуп жатабы? Бул макалада Apache2ди Monit менен көзөмөлдөөдө кеңири таралган тузактардан качуу, PID жолунун туура эмес жайгашуусу жана уруксаттарды бөгөттөө сыяктуу кеңири таралган көйгөйлөрдү терең талдоо жана өндүрүштүк деңгээлдеги Monit автоматташтыруу конфигурация файлдарын сунуштоо боюнча практикалык көрсөтмө берилет. Азыр жогорку деңгээлдеги серверди тейлөө ыкмаларын өздөштүрүңүз жана мүчүлүштүктөрдөн кийин экинчи деңгээлдеги автоматтык түрдө калыбына келтириңиз!

Apache2'ни көзөмөлдөө үчүн Monit'ти колдонууда мен туш болгон кыйынчылыктар

Өткөн жума күнү официант мага түн ортосунда Монит эскертүүсүн берди.

Мен панелге таң калып карадым, apache2 статус тилкесинде кызыл тайм-аут деген жазуу пайда болду.

Мен бир аз ойлонуп көрдүм. Күндүз серверге Monit мониторингин коштум, ал эми конфигурацияны онлайн окуу куралынан көчүрүп чаптадым. Эч кандай көйгөй болбошу керек, туурабы?

Эртеси эртең менен ал кайрадан убакыт бүттү. Үчүнчү жолу иштегенден кийин, Монитор жөн гана иштебей калды, ал эми панелде "Көзөмөлдөнгөн эмес" деген жазуу көрсөтүлдү.

мен...

Моюнга алам, башында мен муну олуттуу кабыл алган жокмун. Apache2 мониторингиби? Интернеттен көптөгөн шаблон конфигурацияларын таба аласыз, жөн гана көчүрүп, чаптаңыз. Бирок ал чаптоо процесси мени чындап ачуулантты.

HestiaCPтин демейки архитектурасы менен Monit портторунун ортосундагы карама-каршылыктын негизги себеби

Алгач мага көп кыйынчылык жараткан конфигурацияны көрсөтөйүн, ошондо ал сиз көргөн версия менен дал келерин көрө аласыз.

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

Жакшы эле окшойт, туурабы? Ал 80-портту текшерет, эгер ал бузулуп калса, кайра жүктөлөт. Эгер 5 жолу кайра жүктөгөндөн кийин дагы эле бузулуп калса, анын иштөө убактысы бүтөт.

Маселе, сиздин Apache2 80-портто да иштебей жатат.

Бул HestiaCPтин тузактары жана көптөгөн адамдардын ага түшүп калышынын негизги себеби. HestiaCPтин демейки архитектурасы Nginx + Apache2нин тескери проксиси болуп саналат, Nginx алдыңкы жагында 80 жана 443 портторун ээлейт, ал эми Apache2 арткы жагында жергиликтүү 8081 портунда иштейт.

Эгер сиз Мониттен 80-портто Apache2нин жандуулугун текшерүүнү сурансаңыз, бул McDonald'sка барып KFC тапкандай болот. Сервер сизге эч нерсе түшүнбөй карап турат, ал эми силер бири-бириңерди тиктеп каласыңар. Акырында, Монит сиздин иштебей калганыңызды аныктап, шашылыш түрдө кайра жүктөй баштайт.

Кайра иштетилгенден кийин, порт дагы эле 8081 бойдон калууда. Андан кийин Monit 80-портту текшерүүгө аракет кылат, ал дагы иштебей калат, ошондуктан ал кайрадан башталат. Бул цикл Monit оңдоого мүмкүн эмес деп чечип, убактысы бүткөнгө чейин кайталанат.

Мен муну биринчи жолу көргөндө чындап таң калдым. Интернеттен тапкан он окуу куралынын тогузу 80-портту колдонгон. Эгер сиз аларды аткарсаңыз, көйгөй сизде эмес, маалыматтын булагында болгон.

Бузулган Apache2 PID файлы Monitтин бул процессти жок деп жаңылыштык менен аныкташына алып келген.

Портту 80ден 8081ге өзгөрткөндөн кийин, Monit аны теориялык жактан аныктай алышы керек, туурабы?

Бирок, чындыгында, ал дагы эле кээде "Аткарылбай калды" деген кабарларды берет.

Көпкө кыйналгандан кийин, акыры себеби жөнөкөй экенин билдим: PID файлы бузулган.

Ойлонуп көрсөңүз, Монит Apache2'ни шашылыш түрдө кайра жүктөгөн, ар бир жолу аны күч менен өчүрүп, кайра жүктөгөн, бир нече жолу кайра-кайра кайталап. Бул процесстин жүрүшүндө /var/run/apache2/apache2.pid файлы 0 байт болуп калышы мүмкүн.

Башкача айтканда, файл дагы эле бар, бирок ал бош.

Monit бул файлды окуганда эч нерсе таппайт. Ал сиздин Apache2 түзмөгүңүздү тааныбайт, ал тургай Apache2 түзмөгүңүз фондо жакшы иштеп жатса да; Monit бул процесстин бар экенине ишенбейт.

Муну көргөндө бир азга сөз таппай калдым.

Бул туюкка кептелүү. Monit Apache 2 инстанциясын аныктай албай, Apache2'ни кайра иштетет, кайра иштетүү процессинде PID файлын бузуп, кийинки аныктоодо ийгиликсиз болуп, кайра башталат. Бул цикл тайм-аут пайда болгонго чейин уланат.

HestiaCP чөйрөсүндөгү Apache2 мониторинги үчүн көйгөйлөрдү чечүү жана оңдоо кадамдары

Чынын айтканда, тергөө процесси татаал эмес, бирок кайсы багытты иликтөө керектигин билишиңиз керек.

Биринчи кадам - ​​Apache2 кайсы портту угуп жатканын аныктоо. Жөн гана терминалга буйрук териңиз.

netstat -tulpn | grep apache2

Же болбосо, сиз `ss` буйругун колдоно аласыз; натыйжасы ошол эле.

ss -tulpn | grep apache2

Сиз ушуга окшош чыгарылышты көрөсүз.

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

Анын 80 эмес, 8081 экени тастыкталды. Көйгөйдүн тамыры ушунда.

Экинчи кадам - ​​бузулган PID файлын оңдоо. Бул жөнөкөйүрөөк.

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

Алгач, сиз оңдоп жатканда тоскоолдук жаратпашы үчүн, Мониторду көзөмөлдөөнү токтотуңуз. Андан кийин, таза PIDди кайра жазуу үчүн Apache2'ни өчүрүп-күйгүзүңүз. Акырында, файлдын мазмунун текшерүү үчүн `cat` буйругун колдонуңуз; анда бош сап эмес, сандар сабы камтылышы керек.

Бул кадам аяктагандан кийин, көйгөй негизинен чечилет.

Monit салттуу адаптивдүү жана агрессивдүү коргоочу конфигурацияларынын салыштырмалуу анализи

Apache2ди Monit менен конфигурациялоо боюнча онлайн окуу куралдары, адатта, эки категорияга бөлүнөт.

Бир түрү - "салттуу адаптация түрү", ал кызматтарды башкаруу жана өтө көп татаал чектөөлөрдү кошпостон жергиликтүү портторду текшерүү үчүн `service` буйругун колдонот. Бул конфигурацияны HestiaCPде жөн гана портту өзгөртүү менен колдонсо болот жана ал салыштырмалуу туруктуу.

Дагы бир ыкма - бул "агрессивдүү коргоо" ыкмасы, ал кызматтарды башкаруу үчүн systemctlди колдонот, бала процесстерине чектөөлөрдү кошот жана катуураак аныктоо логикасын колдонот. Ал сонун көрүнөт, бирок анын олуттуу кемчилиги бар: колдонулган токтотуу буйругу `killall -9`.

`killall -9` эмнени билдирет? Бул түзмөк эмне кылып жатканына карабастан, аны күч менен жок кылуу дегенди билдирет. Бул катаал күч колдонуу операциясы PID файлдарын оңой эле бузуп коюшу мүмкүн, бул мен жогоруда айтып өткөн көйгөй.

Менин жеке тажрыйбам көрсөткөндөй, агрессивдүү конфигурацияда бала процесстеринин санын чектөө чындыгында пайдалуу. Apache2 CC чабуулуна кабылганда, бала процесстеринин санын чектөө сервердин эс тутумунун түгөнүп калышына жол бербейт. Бирок, `killall -9` ыкмасы чындап эле колдонууга жараксыз.

Ошентип, акыры мен эки конфигурациянын тең артыкчылыктарын айкалыштырып, келишим түздүм.

HestiaCP Apache2 Monit Эң мыкты тажрыйба конфигурациясы

/etc/monit/conf.d/apache2 файлын төмөнкү мазмун менен өзгөртүңүз.

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

Конфигурациянын ушул бир нече саптарынын артындагы логиканы кыскача түшүндүрүп берейин.

HestiaCP'тин тескери прокси архитектурасына так дал келгидей кылып 8081 портун жазыңыз; 80-портту акылсыздык менен жазууну токтотуңуз.

PID файлын бузуп албаш үчүн, аны токтотуу үчүн `killall -9` буйругунун ордуна `systemctl stop` буйругун колдонуңуз.

Бала процессинин чеги кошулду: эгер балдардын саны 120дан ашса, CC чабуулдарынын алдын алуу үчүн процесс эки удаалаш циклден кийин кайра башталат, бирок ал өтө агрессивдүү эмес.

Каталарды аныктоо логикасы "2 цикл үчүн" ыкмасын колдонуу үчүн өзгөртүлдү, башкача айтканда, кайра иштетүү эки катары менен ката кеткенден кийин гана ишке киргизилет, бул жалган оң натыйжаларды азайтат. Бир гана жолу аныкталгандан кийин кайра иштетилген мурунку конфигурация, чынын айтканда, бир аз өтө сезимтал болгон.

Акыркы тайм-аут босогосу 10 циклдин ичинде 5 жолу кайра жүктөөгө чейин жумшартылып, катага туруктуулук жетиштүү бойдон калат.

HestiaCP МониторингКонфигурациянын көйгөйлөрүн чечүүнүн кыскача баяндамасы жана тажрыйба алмашуу

Конфигурацияны өзгөрткөндөн кийин, мен apache2'ни көзөмөлдөдүм, жана панелде акыры жашыл "OK" индикатору көрсөтүлдү.

Ал кездеги сезимдеримди кантип сүрөттөсөм болот? Бул эки күн бою бир курт-кумурска менен күрөшүп, бирок анын себебин бир гана туура эмес конфигурация экенин билгендей болду. Бул бир жагынан капалантты, бир жагынан күлкүлүү болду.

Monit өзүнчө жакшы нерсе, ал эми демондорду көзөмөлдөө ар бир сервер жасашы керек болгон нерсе. Бирок көйгөй көптөгөн онлайн окуу куралдары "Apache2 жалаң гана 80-портту колдонот" деген божомолго негизделген, ал эми HestiaCP тескери прокси колдонот, демек, бул божомол чындыкка дал келбейт.

Эгер сиз көрсөтмөлөрдү аткарсаңыз, көйгөй сизде эмес; көйгөй окуу куралы сиздикинен башка сценарийге тиешелүү экендигинде.

Андыктан, эгер сиз HestiaCP колдонуп, Apache2'ни көзөмөлдөө үчүн Monit менен алектенип жатсаңыз, эки нерсени эсиңизден чыгарбаңыз: портту 8081ге өзгөртүңүз жана аны токтотуу үчүн `killall -9` эмес, `systemctl` буйругун колдонуңуз. Эгер сиз ушул эки нерсени жасасаңыз, башка көйгөйлөрдөн кача аласыз.

Ушул жерге чейин окугандан кийин, эгер сизге пайдалуу болсо, жактырып, бөлүшүңүз. Эгер жаңылыктарды биринчилерден болуп алгыңыз келсе, мени ээрчисеңиз болот!

Макаланы окуганыңыз үчүн рахмат. Кийинки жолу көрүшкөнчө.