Apache2-ის ხშირი კრახი HestiaCP-თან ერთად? Monit-ის ავტომატური მონიტორინგისა და პრობლემების მოგვარების სახელმძღვანელო (სრული კონფიგურაციით)

ხშირია Apache2-ის კრახი ან Monit-ის ავტომატური გადატვირთვის შეცდომები HestiaCP გარემოში? ეს სტატია იძლევა პრაქტიკულ სახელმძღვანელოს Apache2-ის Monit-ით მონიტორინგისას გავრცელებული შეცდომების თავიდან ასაცილებლად, ღრმად აანალიზებს ისეთ გავრცელებულ პრობლემებს, როგორიცაა PID გზის არასწორი განლაგება და ნებართვების დაბლოკვა, და გთავაზობთ წარმოების დონის Monit ავტომატიზაციის კონფიგურაციის ფაილებს. დაეუფლეთ მაღალი ხელმისაწვდომობის სერვერის მოვლა-პატრონობის ტექნიკას ახლავე და მიაღწიეთ მეორე დონის ავტომატურ აღდგენას ჩავარდნების შემდეგ!

Apache2-ის მონიტორინგისთვის Monit-ის გამოყენებისას წავაწყდი ხაფანგებს

გასულ პარასკევს, სერვერმა შუაღამისას 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 პორტზე მუშაობს.

თუ Monit-ს სთხოვთ, რომ Apache2-ის 80-ე პორტზე მუშაობა შეამოწმოს, ეს იგივეა, რაც McDonald's-ში KFC-ის საპოვნელად წასვლა. სერვერი უემოციოდ გიყურებთ და თქვენ ორივე ერთმანეთს უყურებთ. საბოლოოდ, Monit ადგენს, რომ გათიშული ხართ და სასოწარკვეთილად იწყებს გადატვირთვას.

გადატვირთვის შემდეგ პორტი კვლავ 8081-ია. შემდეგ Monit ცდილობს 80 პორტის შემოწმებას, რაც ასევე ვერ ხერხდება, ამიტომ ის ხელახლა გადაიტვირთება. ეს ციკლი მეორდება მანამ, სანამ Monit არ გადაწყვეტს, რომ ის შეკეთებას ვეღარ ახერხებს და ვადა არ ამოიწურება.

როდესაც პირველად წავაწყდი ამას, გულწრფელად გაოგნებული დავრჩი. ინტერნეტში ნაპოვნი ათიდან ცხრა სახელმძღვანელო მე-80 პორტს იყენებდა. თუ მათ მიჰყევით, პრობლემა თქვენში კი არა, თავად ინფორმაციის წყაროში იყო.

დაზიანებული Apache2 PID ფაილის გამო Monit-მა შეცდომით აღიარა პროცესი, როგორც არარსებული.

პორტის 80-დან 8081-ზე შეცვლის შემდეგ, Monit-ს თეორიულად უნდა შეეძლოს მისი აღმოჩენა, არა?

თუმცა, სინამდვილეში, ის მაინც ხანდახან იუწყება შეტყობინებას „შესრულება ვერ მოხერხდა “.

დიდი ხნის წვალების შემდეგ, საბოლოოდ აღმოვაჩინე, რომ მიზეზი მარტივი იყო: PID ფაილი დაზიანებული იყო.

დაფიქრდით, Monit სასოწარკვეთილად რთავდა Apache2-ს, ყოველ ჯერზე იძულებით თიშავდა და ხელახლა რთავდა მას, რამდენჯერმე აგრძელებდა მუშაობას. ამ პროცესის დროს, ფაილი /var/run/apache2/apache2.pid შეიძლება 0 ბაიტი გახდეს.

სხვა სიტყვებით რომ ვთქვათ, ფაილი ისევ არსებობს, მაგრამ ცარიელია.

როდესაც Monit ამ ფაილს კითხულობს, ვერაფერს პოულობს. ის ვერ ცნობს თქვენს 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

დადასტურებულია, რომ ეს არის 80-ის ნაცვლად 8081-ის ნომერი. პრობლემის არსი სწორედ ეს არის.

მეორე ნაბიჯი დაზიანებული PID ფაილის შეკეთებაა. ეს უფრო მარტივია.

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

პირველ რიგში, შეაჩერეთ Monit-ის მონიტორინგი, რათა თავიდან აიცილოთ მისი ჩარევა პრობლემების გამოსწორებისას. შემდეგ გადატვირთეთ Apache2, რათა მას საშუალება მიეცეს გადაწეროს სუფთა PID. და ბოლოს, გამოიყენეთ `cat` ფაილის შინაარსის შესამოწმებლად; ის უნდა შეიცავდეს რიცხვების სტრიქონს და არა ცარიელ სტრიქონს.

ამ ეტაპის დასრულების შემდეგ, პრობლემა ძირითადად მოგვარებულია.

Monit-ის ტრადიციული ადაპტური და აგრესიული დამცავი კონფიგურაციების შედარებითი ანალიზი

Apache2-ის Monit-ით კონფიგურაციის ონლაინ გაკვეთილები ზოგადად ორ კატეგორიად იყოფა.

ერთ-ერთი ტიპია „ტრადიციული ადაპტაციის ტიპი“, რომელიც იყენებს `service` ბრძანებას სერვისების სამართავად და ლოკალური პორტების შესამოწმებლად ძალიან ბევრი რთული შეზღუდვის დამატების გარეშე. ამ კონფიგურაციის გამოყენება HestiaCP-ზე შესაძლებელია უბრალოდ პორტის შეცვლით და ის შედარებით სტაბილურია.

კიდევ ერთი მიდგომაა „აგრესიული დაცვის“ მეთოდი, რომელიც სერვისების სამართავად იყენებს systemctl-ს, ამატებს შვილობილი პროცესების შეზღუდვებს და იყენებს უფრო მკაცრ აღმოჩენის ლოგიკას. ის შესანიშნავად გამოიყურება, მაგრამ აქვს ერთი ფატალური ნაკლი: გამოყენებული stop ბრძანებაა `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 ფაილის შესაჩერებლად, რათა თავიდან აიცილოთ მისი დაზიანება, გამოიყენეთ `systemctl stop` ბრძანება `killall -9`-ის ნაცვლად.

დამატებულია შვილობილი პროცესის ლიმიტი: თუ შვილების რაოდენობა 120-ს გადააჭარბებს, პროცესი ორი ზედიზედ ციკლის შემდეგ გადაიტვირთება CC შეტევების თავიდან ასაცილებლად, თუმცა ეს არ იქნება ძალიან აგრესიული.

შეცდომების აღმოჩენის ლოგიკა შეიცვალა „2 ციკლის“ მიდგომით, რაც ნიშნავს, რომ გადატვირთვა მხოლოდ ორი ზედიზედ შეცდომების შემდეგ აქტიურდება, რაც ამცირებს ცრუ დადებით შედეგებს. წინა კონფიგურაცია, რომელიც მხოლოდ ერთი აღმოჩენის შემდეგ გადაიტვირთებოდა, გულწრფელად რომ ვთქვათ, ცოტა ზედმეტად მგრძნობიარე იყო.

საბოლოო ტაიმაუტის ზღვარი მცირდება 5 გადატვირთვამდე 10 ციკლის განმავლობაში, რაც საკმარისი ხარვეზის ტოლერანტობას ტოვებს.

HestiaCP მონიტორინგის მონიტორინგიკონფიგურაციის პრობლემების მოგვარების შეჯამება და გამოცდილების გაზიარება

კონფიგურაციის ცვლილებების შეტანის შემდეგ, მე ვაკვირდებოდი apache2-ს და პანელზე საბოლოოდ გამოჩნდა მწვანე „OK“ ინდიკატორი.

როგორ აღვწერო ჩემი გრძნობები მაშინ? ეს ისეთი შეგრძნება იყო, თითქოს ორი დღე მწერთან ბრძოლაში ვიყავი და მხოლოდ იმის გარკვევის შემდეგ აღმოვაჩინე, რომ მიზეზი კონფიგურაციის ერთი არასწორი ხაზი იყო. ეს ერთდროულად იმედგაცრუებასაც იწვევდა და სასაცილოსაც.

Monit თავისთავად კარგია და დემონების მონიტორინგი ყველა სერვერის ვალდებულებაა. თუმცა, პრობლემა ის არის, რომ ბევრი ონლაინ სახელმძღვანელო ეფუძნება იმ ვარაუდს, რომ „Apache2 ექსკლუზიურად იყენებს 80 პორტს“, ხოლო HestiaCP იყენებს საპირისპირო პროქსის, რაც იმას ნიშნავს, რომ ეს ვარაუდი სიმართლეს არ შეესაბამება.

თუ ინსტრუქციებს მიჰყვებით, პრობლემა თქვენში არ არის; პრობლემა იმაშია, რომ სახელმძღვანელო თქვენგან განსხვავებულ სცენარზეა გამოსაყენებელი.

ასე რომ, თუ თქვენ ასევე იყენებთ HestiaCP-ს და Apache2-ის მონიტორინგისთვის Monit-ს იყენებთ, უბრალოდ გახსოვდეთ ორი რამ: შეცვალეთ პორტი 8081-ზე და მის შესაჩერებლად გამოიყენეთ `systemctl` ბრძანება და არა `killall -9`. თუ ამ ორ რამეს გააკეთებთ, თავიდან აიცილებთ შემდგომ პრობლემებს.

რადგან აქამდე წაიკითხეთ, თუ სასარგებლოდ მიგაჩნიათ, გთხოვთ, მოიწონოთ და გააზიაროთ. თუ გსურთ, რომ პირველმა მიიღოთ განახლებები, ასევე შეგიძლიათ გამომყვეთ!

გმადლობთ, რომ წაიკითხეთ ჩემი სტატია. შემდეგ ჯერზე შევხვდებით.