Სარჩევი:

სერვისის მონიტორის სკრიპტი Linux სერვერებისთვის: 4 ნაბიჯი
სერვისის მონიტორის სკრიპტი Linux სერვერებისთვის: 4 ნაბიჯი

ვიდეო: სერვისის მონიტორის სკრიპტი Linux სერვერებისთვის: 4 ნაბიჯი

ვიდეო: სერვისის მონიტორის სკრიპტი Linux სერვერებისთვის: 4 ნაბიჯი
ვიდეო: Delphi Программирование / Android NDK, SDK, Java Machine, JDK, Nox Player, AVD Android Эмулятор 2024, ნოემბერი
Anonim
სერვისის მონიტორის სკრიპტი Linux სერვერებისთვის
სერვისის მონიტორის სკრიპტი Linux სერვერებისთვის

სტაბილური, ყოველთვის გაშვებული სისტემის არსებობა, მაშინაც კი, თუ Linux- ს იყენებთ, შეიძლება რთული ამოცანა იყოს.

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

ნაბიჯი 1: Systemd– ის მიერ მოწოდებული მეთოდების გამოყენება

როგორც უკვე იცით, Linux– ის თანამედროვე ოპერაციული სისტემების უმეტესობა იყენებს systemd.

თუ თქვენ არ იცნობთ systemd- ს, ეს არის ვიკიპედიის მიხედვით:

"… Init სისტემა გამოიყენება Linux დისტრიბუციებში მომხმარებლის სივრცის ჩატვირთვისა და შემდგომ ყველა პროცესის სამართავად, UNIX System V ან Berkeley Software Distribution (BSD) init სისტემების ნაცვლად."

ბევრი კვლავ კამათობს იმაზე, თუ რატომ იყო საჭირო ძველი ძველი სისტემის შეცვლა ამ უფრო რთული პროცესის მართვის სისტემით, მაგრამ შემდეგ ბმულზე შეიძლება ვიპოვოთ კარგი ახსნა:

www.tecmint.com/systemd-replaces-init-in-l…

ყველაზე მნიშვნელოვანი გაუმჯობესება იქნება ის, რომ მას შეუძლია აღზარდოს სისტემა უფრო სწრაფად, ვიდრე init, ჩატვირთვისას პარალელური და პარალელური დამუშავების გამო, ვიდრე init თანმიმდევრული მიდგომის ნაცვლად

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

[ერთეული] აღწერა = განაცხადის აღწერა დოკუმენტაცია = https://wikipedia.org/ შემდეგ = local-fs.target network.target [სერვისი] ტიპი = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/აპლიკაციის გადატვირთვაExecStop =/ usr/sbin/application stopRestart = ყოველთვის [Install] WantedBy = multi-user.target

განათავსეთ ისინი application.service ფაილში/lib/systemd/system საქაღალდეში.

რას აკეთებს თითოეული ეს ვარიანტი განმარტებულია შემდეგ ბმულზე:

access.redhat.com/documentation/en-US/Red_…

თქვენი განაცხადის დასაწყებად, გასცეს შემდეგი ბრძანება:

sudo systemctl პროგრამის დაწყება. მომსახურება

შენიშვნა: სერვისის გაფართოება შეიძლება გამოტოვებული იყოს.

განაცხადის შესაჩერებლად:

sudo systemctl განაცხადის შეწყვეტა. მომსახურება

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

sudo systemctl გადატვირთვის პროგრამა. მომსახურება

განაცხადის გადატვირთვისთვის:

sudo systemctl გადატვირთეთ პროგრამა. მომსახურება

ჩატვირთვისას ავტომატური დაწყების გასააქტიურებლად:

sudo systemctl პროგრამის ჩართვა. მომსახურება

თუ ეს ჩართულია, მაშინ სისტემის პროცესის მენეჯერი შეეცდება პროგრამის გაშვებას სისტემის ფაილის მიერ მოწოდებული პარამეტრების საფუძველზე.

მისი გამორთვისთვის გამოიყენეთ იგივე ბრძანება, როგორც ზემოთ, მაგრამ 'გამორთვის' პარამეტრით.

თუ თქვენ განათავსებთ გადატვირთვას = ყოველთვის სერვისის ფაილში, მაშინ systemd მონიტორინგს გაუწევს პროცესს და თუ ის არ მოიძებნება პროცესის სიაში, ის შეეცდება ავტომატურად გადატვირთოს.

თუ განათავსებთ

გადატვირთვა = 30

გადატვირთვის დირექტივის შემდეგ, ის დაელოდება 30 წამს, სანამ შეეცდება პროცესის განახლებას. ეს შეიძლება სასარგებლო იყოს, რადგან სერვისის/პროგრამის ჩავარდნის უწყვეტმა მცდელობამ შეიძლება გამოიწვიოს სისტემაში მაღალი მოთხოვნა (შეცდომების ჟურნალების წერა და სხვა)

როგორც ხედავთ, systemd უკვე იძლევა პროცესების მონიტორინგის გარკვეულ საშუალებებს. თუმცა, ზოგიერთ შემთხვევაში ეს შეიძლება არ იყოს საკმარისი. რა მოხდება, თუ პროცესი არ გადის (ის კვლავ იქნება პროცესების სიაში), მაგრამ ის შეწყვეტს რეაგირებას. ამ შემთხვევაში, იმის უზრუნველსაყოფად, რომ პროცესი მართლაც დაწყებულია, შეიძლება დაგჭირდეთ დამატებითი შემოწმება.

აქ არის, სადაც ამ სასწავლო სკრიპტები გამოდგება.

ნაბიჯი 2: სერვისის შემოწმების სკრიპტების კონფიგურაცია და გამოყენება

თუ თქვენ გჭირდებათ მეტი კონტროლი თქვენს მიმდინარე პროცესებზე/სერვისებზე, ეს სკრიპტები აუცილებლად გამოგადგებათ.

ვინაიდან კოდი ოდნავ დიდია, ის აიტვირთება github– ში და შეგიძლიათ იხილოთ შემდეგ საცავში:

github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh

მთელი პაკეტის "გული" არის

checkService.sh

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

სკრიპტს შეუძლია გააკონტროლოს რამდენიმე პროცესი და შეასრულოს დამატებითი დავალება, როგორც ეს აღწერილია ქვემოთ:

ის გადის თითოეული სერვისის /საქაღალდის საქაღალდეში, რომელსაც გააჩნია.serv ან.check გაფართოებები და შეამოწმებს არის თუ არა აქტიური პროცესი სახელწოდებით "აპლიკაცია".

თუ პროგრამისთვის არ არის ".შემოწმების" ფაილი, მხოლოდ application.serv ფაილი:

თუ პროცესი აქტიურია, ის პროცესს აქტიურად მიიჩნევს

თუ პროცესი უმოქმედოა, ის განაახლებს სერვისს შემდეგი ბრძანების გაცემით:

systemctl გადატვირთვის პროგრამა

თუ.serv ფაილი ცარიელია!

თუ.serv ფაილი არ არის ცარიელი და აქვს შესრულებადი უფლებები, ის შეეცდება გაუშვას როგორც უბრალო BASH სკრიპტი.

ეს სასარგებლოა, თუ რაიმე დამატებით უნდა გაკეთდეს, გარდა მომსახურების გადატვირთვისა.

მაგალითად, spamd.serv ფაილში, ზემოთ არსებული repo– დან, იმ შემთხვევაში, თუ spamd სერვისი მკვდარია, ამის ნაცვლად spamassassin სერვისის გადატვირთვაა საჭირო, რაც ასევე spamd– ის გადატვირთვასაც მოახდენს. მხოლოდ სპამის გადატვირთვა არ იქნება საკმარისი.

თქვენ შეგიძლიათ შეცვალოთ ასეთი სერვისის ფაილის შინაარსი საჭიროების შესაბამისად.

კიდევ ერთი მაგალითია pcscd.serv ფაილი. ამ შემთხვევაში კიდევ რამდენიმე პროცესი ხელახლა დაიწყო/დაიღუპა.

თუ არის შემოწმების ფაილი, პროცესის გაშვების შემოწმების შემდეგ ის ასევე გაუშვებს ამ სკრიპტის ფაილს დამატებითი შემოწმებების შესასრულებლად.

მაგალითად, oscam სერვისისთვის, ჩვენ შევქმენით შემოწმების ფაილი, რომელიც ცდილობს დაუკავშირდეს მის ვებ ინტერფეისს, რომ ნახოთ წარმატებულია თუ არა. თუ არა, მაშინ, მიუხედავად იმისა, რომ პროცესი აქტიურია, სერვისი არ რეაგირებს და საჭიროებს გადატვირთვას. სერვისის გადატვირთვა უნდა შესრულდეს/დარეკილი იყოს თავად.check ფაილის მიერ.

კიდევ ერთი მაგალითი იქნება მედიატომბ DLNA სერვისი.

ეს არის პატარა სერვერი, რომელიც უზრუნველყოფს ვიდეო/აუდიო შინაარსს DLNA კლიენტებისთვის და მაუწყებლობს თავად ქსელში. ზოგჯერ სერვისი გათიშულია და მისი აღმოჩენა შეუძლებელია, მაგრამ პროცესი კვლავ აქტიური იქნება. იმის შესამოწმებლად, არის თუ არა სერვისი აღმოჩენილი, გამოყენებული იქნა CLI პროგრამა სახელწოდებით gssdp-Discover. მთელი კოდი, რომელიც ამოწმებს DLNA სერვერს, მოთავსებულია mediatomb.check სკრიპტში.

ეს არის მხოლოდ რამდენიმე მაგალითი იმისა, თუ როგორ შეგიძლიათ გამოიყენოთ.serv და.check ფაილები.

ახალი სერვისის მონიტორინგის მიზნით, თქვენ უნდა შექმნათ.serv და საჭიროების შემთხვევაში ასევე შეამოწმოთ ფაილი და ჩაწეროთ შესაბამისი სკრიპტი მათ შიგნით.

თუ საკმარისია მხოლოდ პროცესის არსებობის შემოწმება, მაშინ საკმარისი იქნება ცარიელი.serv ფაილი. თუ დამატებითი შემოწმება უნდა განხორციელდეს, მაშინ.check ფაილი უნდა შეიქმნას და მცირე სკრიპტი უნდა დაიწეროს სამუშაოს შესასრულებლად.

ამრიგად,.sh სკრიპტი პერიოდულად უნდა გაშვებულიყო, ამიტომ მისთვის ასევე უნდა შეიქმნას cron სამუშაო:

#შეამოწმეთ გაშვებული სერვისები ყოველ 5 წუთში */5 * * * * /var/bin/ServiceCheck/checkService.sh>/dev/null

ნაბიჯი 3: საბოლოო აზრები

ვიმედოვნებ, რომ თქვენთვის სასარგებლო იქნება ეს პაკეტი, რადგან მას შეუძლია მნიშვნელოვნად შეაჩეროს Linux პროცესების მონიტორინგი და იმედია შეამცირებს თქვენი მომსახურების ხანგრძლივობას.

მოგერიდებათ ატვირთოთ დამატებითი სკრიპტები github– ში, თუ ახალს შექმნით. უბრალოდ შემატყობინე და მე დაგამატებ, როგორც კონტრიბუტორი.

გირჩევთ: