Tartalomjegyzék:

Service Monitor Script Linux szerverekhez: 4 lépés
Service Monitor Script Linux szerverekhez: 4 lépés

Videó: Service Monitor Script Linux szerverekhez: 4 lépés

Videó: Service Monitor Script Linux szerverekhez: 4 lépés
Videó: Bulletproofing IT: Secured-core Technology in Windows 11 and Server 2022. 2024, November
Anonim
Service Monitor Script Linux szerverekhez
Service Monitor Script Linux szerverekhez

Nehéz feladat lehet egy stabil, mindig futó rendszer, még akkor is, ha Linuxot használ.

A modern szoftvercsomagok összetettsége és a rossz kódolás miatt elkerülhetetlen, hogy egyes folyamatok időről időre összeomlanak. Ez rossz dolog lehet, ha szervert futtat, és egyesek ezekre a szolgáltatásokra támaszkodnak.

1. lépés: A Systemd által biztosított módszerek használata

Mint talán már tudja, a legtöbb modern Linux operációs rendszer a systemd -t használja.

Ha nem ismered a systemd -t, akkor ez a wikipédia szerint:

"… A Linux disztribúciókban használt init rendszer a felhasználói tér betöltésére és az összes folyamat későbbi kezelésére a UNIX System V vagy a Berkeley Software Distribution (BSD) init rendszerek helyett."

Sokan még mindig azzal vitatkoznak, hogy miért volt szükség a régi jó init rendszer lecserélésére ezzel a bonyolultabb folyamatkezelő rendszerrel, de az alábbi linken jó magyarázatot találhat:

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

A legfontosabb fejlesztés az lenne, hogy gyorsabban képes felhozni a rendszert, mint az init, mivel az init párhuzamos és párhuzamos feldolgozása a rendszerindítás helyett az init szekvenciális megközelítése helyett

Anélkül, hogy belemennénk a systemd mélységeibe, ahhoz, hogy folyamatot adjunk hozzá a systemd -hez, létre kell hoznunk egy szolgáltatásfájlt. Egy ilyen fájl szintaxisa nagyon egyszerűtől egészen bonyolult lehet, és nem részletezzük. Az alapvető.service fájl eléréséhez elegendő a következő bejegyzések használata:

[Unit] Leírás = applicationDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Service] Type = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/application reloadExecStop =/ usr/sbin/application stopRestart = mindig [Telepítés] WantedBy = multi-user.target

Helyezze ezeket az application.service fájlba a/lib/systemd/system mappába.

Ezen lehetőségek mindegyikét az alábbi link ismerteti:

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

Az alkalmazás elindításához adja ki a következő parancsot:

sudo systemctl indítsa el az alkalmazást.szolgáltatás

Megjegyzés: a.service kiterjesztés elhagyható.

Az alkalmazás leállítása:

sudo systemctl állítsa le az alkalmazást.szolgáltatás

Ha a konfigurációs fájl megváltozott, és újra szeretné tölteni a beállításokat:

sudo systemctl reload application.service

Az alkalmazás újraindításához:

sudo systemctl indítsa újra az alkalmazást.szolgáltatás

Az automatikus indítás engedélyezése rendszerindításkor:

sudo systemctl engedélyezze az application.service szolgáltatást

Ha ez engedélyezve van, akkor a systemd folyamatkezelő megpróbálja elindítani az alkalmazást a rendszerfájl által megadott beállítások alapján.

A letiltáshoz ugyanazt a parancsot használja, mint a fentiekben, de a 'disable' paraméterrel.

Ha az újraindítást = mindig a szervizfájlba helyezi, akkor a systemd figyeli a folyamatot, és ha nem található meg a folyamatlistában, akkor automatikusan újraindítja.

Ha elhelyezed

RestartSec = 30

az újraindítási irányelv után 30 másodpercet vár, mielőtt megpróbálja újraindítani a folyamatot. Ez hasznos lehet, mivel a meghibásodott szolgáltatás/alkalmazás folyamatos újraindítási kísérlete nagy igényt okozhat a rendszeren (hibanaplók írása stb.)

Mint látható, a systemd már biztosít bizonyos eszközöket a folyamatok nyomon követésére. Bizonyos esetekben azonban ez nem elegendő. Mi van, ha egy folyamat nem lép ki (továbbra is szerepelni fog a folyamatlistában), de nem válaszol. Ebben az esetben, annak érdekében, hogy megbizonyosodjon arról, hogy egy folyamat valóban működik, szükség lehet további ellenőrzések elvégzésére.

Itt hasznosak lesznek az utasításból származó szkriptek.

2. lépés: A Service Checker szkriptek konfigurálása és használata

Ha jobban kell irányítania a futó folyamatokat/szolgáltatásokat, ezek a szkriptek biztosan hasznosak lesznek.

Mivel a kód kissé nagy, fel van töltve a github -ra, és megtalálható a következő tárhelyen:

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

Az egész csomag „szíve” a

checkService.sh

Használat előtt ki kell cserélnie a szervizmappa teljes elérési útját. Ez megtalálható a forgatókönyv elején.

A szkript több folyamatot figyelhet és további feladatokat hajthat végre, az alábbiak szerint:

Végignézi a.serv vagy.check kiterjesztéssel rendelkező /services almappából származó összes fájlt, és ellenőrzi, hogy létezik -e aktív alkalmazás, az úgynevezett alkalmazás.

Ha egy alkalmazáshoz nincs ".check" fájl, akkor csak application.serv fájl:

Ha a folyamat aktív, akkor a folyamatot aktívnak tekinti

Ha a folyamat inaktív, akkor újraindítja a szolgáltatást a következő parancs kiadásával:

systemctl indítsa újra az alkalmazást

ha a.serv fájl üres!

Ha a.serv fájl nem üres, és végrehajtható jogokkal rendelkezik, akkor megpróbálja futtatni sima BASH -parancsfájlként.

Ez akkor hasznos, ha a szolgáltatás újraindításán kívül még valamit tenni kell.

Például a spamd.serv fájlban, a fenti repóból, ha a spamd szolgáltatás meghalt, akkor a spamassassin szolgáltatást kell újraindítani, ami szintén újraindítja a spam -et. Csak a spam újraindítása nem lenne elegendő.

Egy ilyen szerv fájl tartalmát szükség szerint szerkesztheti.

Egy másik példa a pcscd.serv fájl. Ebben az esetben számos más folyamatot is újraindítottak/megöltek.

Ha van ellenőrző fájl, akkor a folyamat futásának ellenőrzése után a parancsfájlt is futtatja további ellenőrzések végrehajtásához.

Például az oscam szolgáltatáshoz létrehoztunk egy ellenőrző fájlt, amely megpróbál csatlakozni a webes felületéhez, hogy lássa, sikeres -e. Ha nem, akkor annak ellenére, hogy a folyamat aktív, a szolgáltatás nem válaszol, és újra kell indítani. A szolgáltatás újraindítását a.check fájlnak kell végrehajtania/hívnia.

Egy másik példa a mediatomb DLNA szolgáltatás.

Ez egy kicsi szerver, amely video-/audiotartalmat biztosít a DLNA -ügyfeleknek, és közvetíti magát a hálózaton. Néha a szolgáltatás lefagy, és már nem fedezhető fel, de a folyamat továbbra is aktív lesz. Annak ellenőrzésére, hogy a szolgáltatás felderíthető-e, a gssdp-discover nevű CLI segédprogramot használták. A DLNA szervert ellenőrző teljes kódot egy mediatomb.check szkriptben helyezték el.

Ez csak néhány példa a.serv és.check fájlok használatára.

Egy új szolgáltatás megfigyeléséhez létre kell hoznia egy.serv és szükség esetén egy ellenőrző fájlt, és bele kell írnia a megfelelő szkriptet.

Ha elegendő csak a folyamat jelenlétének ellenőrzése, akkor elegendő egy üres.serv fájl. Ha további ellenőrzéseket kell végrehajtani, akkor létre kell hozni egy.check fájlt, és egy kis szkriptet kell írni a feladat elvégzéséhez.

Természetesen a.sh szkriptet rendszeresen futtatni kell, ezért egy cron feladatot is létre kell hozni hozzá:

#ellenőrizze a futó szolgáltatásokat 5 percenként */5 * * *//var/bin/ServiceCheck/checkService.sh>/dev/null

3. lépés: Utolsó gondolatok

Remélem, hasznosnak találja ezt a csomagot, mivel nagymértékben egyszerűen felügyelheti a Linux folyamatait, és remélhetőleg minimálisra csökkenti a szolgáltatások leállását.

Nyugodtan töltsön fel további szkripteket a githubba, ha újakat hoz létre. Csak tudassa velem, és hozzáadom Önt közreműködőnek.

Ajánlott: