Частыя збоі Apache2 з HestiaCP? Кіраўніцтва па аўтаматызаваным маніторынгу і ліквідацыі непаладак Monit (з поўнай канфігурацыяй)

Частыя збоі Apache2 або збоі аўтаматычнага перазапуску Monit у асяроддзях HestiaCP ? Гэты артыкул змяшчае практычнае кіраўніцтва па пазбяганні распаўсюджаных памылак пры маніторынгу Apache2 з дапамогай Monit, глыбока аналізуе распаўсюджаныя праблемы, такія як няправільнае выраўноўванне шляху PID і блакаванне дазволаў, і прапануе файлы канфігурацыі аўтаматызацыі Monit прадукцыйнага ўзроўню. Авалодайце метадамі абслугоўвання высокадаступных сервераў зараз і дасягніце аўтаматычнага аднаўлення другога ўзроўню пасля збояў!

Падводныя камяні, з якімі я сутыкнуўся пры выкарыстанні Monit для маніторынгу Apache2

У мінулую пятніцу сервер пасярод ночы падаў мне папярэджанне Monit.

Я здзіўлена зірнуў на панэль, і ў слупку стану apache2 з'явілася чырвоная надпіс «Тайм-аўт».

Я трохі падумаў. Я толькі што дадаў маніторынг Monit на сервер на працягу дня і скапіяваў і ўставіў канфігурацыю з онлайн-ўрока. Праблем быць не павінна, праўда?

На наступную раніцу зноў скончыўся час чакання. Пасля трэцяга разу Monitor проста здаўся, і на панэлі адлюстравалася «Не кантралюецца».

Я...

Прызнаюся, спачатку я не ўспрыняў гэта сур'ёзна. Маніторынг 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 ззаду.

Калі вы папросіце Моніта праверыць працаздольнасць Apache2 на порце 80, гэта будзе як пайсці ў McDonald's у пошуках KFC. Афіцыянт глядзіць на вас пустым позіркам, а вы ўтаропіцеся адзін на аднаго. У рэшце рэшт, Моніт вызначае, што вы выйшлі з ладу, і пачынае шалёна перазапускаць сістэму.

Пасля перазапуску порт усё яшчэ мае нумар 8081. Monit спрабуе праверыць порт 80, але таксама не атрымліваецца, таму ён перазапускаецца. Гэты цыкл паўтараецца, пакуль Monit не вырашыць, што яго немагчыма выправіць, і не скончыцца час чакання.

Калі я ўпершыню сутыкнуўся з гэтым, я быў шчыра ашаломлены. У дзевяці з дзесяці падручнікаў, якія я знайшоў у інтэрнэце, выкарыстоўваўся порт 80. Калі вы ім прытрымліваліся, праблема была не ў вас, а ў самой крыніцы інфармацыі.

Пашкоджаны PID-файл Apache2 прымусіў Monit памылкова вызначыць працэс як неіснуючы.

Пасля змены порта з 80 на 8081, Monit тэарэтычна павінен яго выявіць, ці не так?

Аднак на самой справе ён усё яшчэ часам паведамляе "Выкананне не атрымалася ".

Пасля доўгіх спроб я нарэшце выявіў, што прычына простая: файл PID быў пашкоджаны.

Падумайце толькі, Моніт шалёна перазапускаў Apache2, кожны раз прымусова забіваючы і перазапускаючы яго, пераключаючыся туды-сюды некалькі разоў. Падчас гэтага працэсу файл /var/run/apache2/apache2.pid мог стаць памерам 0 байт.

Іншымі словамі, файл усё яшчэ існуе, але ён пусты.

Калі Monit чытае гэты файл, ён нічога не знаходзіць. Ён не распазнае ваш Apache2, нават калі ваш Apache2 працуе выдатна ў фонавым рэжыме; Monit лічыць, што працэс не існуе.

Калі я гэта ўбачыў, я на хвіліну страціў дар мовы.

Гэта тупік. Monit не можа выявіць экзэмпляр Apache 2, перазапускае Apache2, пашкоджвае файл PID падчас працэсу перазапуску, не праходзіць наступнае выяўленне і перазапускаецца зноў. Гэты цыкл працягваецца, пакуль не скончыцца тайм-аўт.

Этапы ліквідацыі непаладак і выпраўлення праблем для маніторынгу Apache2 у асяроддзі HestiaCP

Шчыра кажучы, працэс расследавання нескладаны, але трэба ведаць, у якім кірунку рухацца.

Першы крок — вызначыць, які порт праслухоўвае ваш 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

Пацверджана, што гэта 8081, а не 80. У гэтым і заключаецца корань праблемы.

Другі крок — аднавіць пашкоджаны PID-файл. Гэта прасцей.

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

Спачатку прыпыніце маніторынг Monit, каб ён не ўмешваўся ў працэс выпраўлення памылак. Затым перазапусціце Apache2, каб ён мог перапісаць чысты PID. Нарэшце, выкарыстоўвайце `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

Дазвольце мне коратка растлумачыць логіку гэтых некалькіх радкоў канфігурацыі.

Запішыце порт 8081, каб ён дакладна адпавядаў архітэктуры зваротнага проксі-сервера HestiaCP; спыніце неразумна пісаць порт 80.

Каб спыніць PID-файл, замест каманды `killall -9` выкарыстоўвайце каманду `systemctl stop`.

Дададзена абмежаванне на колькасць даччыных працэсаў: калі колькасць даччыных працэсаў перавышае 120, працэс перазапусціцца пасля двух паслядоўных цыклаў, каб прадухіліць атакі з выкарыстаннем CC, але гэта не занадта агрэсіўна.

Логіка выяўлення збояў была зменена для выкарыстання падыходу «на працягу 2 цыклаў», гэта значыць, перазапуск запускаецца толькі пасля двух збояў запар, што памяншае колькасць ілжывых спрацоўванняў. Папярэдняя канфігурацыя, якая прыводзіла да перазапуску пасля ўсяго аднаго выяўлення, была, шчыра кажучы, занадта адчувальнай.

Канчатковы парог тайм-аўту паслаблены да 5 перазапускаў на працягу 10 цыклаў, што пакідае дастатковую адмоўстойлівасць.

HestiaCP МаніторынгЗводка па ліквідацыі непаладак канфігурацыі і абмен вопытам

Пасля ўнясення змяненняў у канфігурацыю я сачыў за apache2, і на панэлі нарэшце загарэўся зялёны індыкатар "ОК".

Як апісаць мае пачуцці ў той момант? Гэта было падобна на тое, як два дні змагацца з памылкай, а потым высветліць, што прычынай быў адзін няправільны радок канфігурацыі. Гэта было адначасова і расчароўвае, і смешна.

Monit — гэта добрая рэч сама па сабе, а маніторынг дэманаў — гэта тое, што павінен рабіць кожны сервер. Але праблема ў тым, што многія анлайн-падручнікі заснаваныя на здагадцы, што «Apache2 выкарыстоўвае выключна порт 80», у той час як HestiaCP выкарыстоўвае зваротны проксі-сервер, што азначае, што гэтае меркаванне няпраўдзівае.

Калі вы будзеце прытрымлівацца інструкцый, праблема не ў вас; праблема ў тым, што падручнік падыходзіць для іншага сцэнарыя, чым ваш.

Такім чынам, калі вы таксама выкарыстоўваеце HestiaCP і гуляецеся з Monit для маніторынгу Apache2, проста памятайце дзве рэчы: зменіце порт на 8081 і выкарыстоўвайце каманду `systemctl` для яго спынення, а не `killall -9`. Калі вы зробіце гэтыя дзве рэчы, вы зможаце пазбегнуць далейшых праблем.

Калі вы дачыталі да гэтага месца, пастаўце лайк і падзяліцеся гэтым артыкулам, калі ласка. Калі вы хочаце атрымліваць абнаўленні першымі, вы таксама можаце падпісацца на мяне!

Дзякуй, што прачыталі мой артыкул. Да сустрэчы ў наступны раз.