5.5 Szerver események

A PVSR bizonyos moduljai, mint például az alkalmazás manager modul (vagy modulok, ha a másodlagos alkalmazás manager-t is beállítottuk) peridódikusan különböző ellenőrzéseket végeznek a PVSR rendszerrel kapcsolatban.

Ezen menüpont alatt az ilyen ellenőrzéseknek az eredményét illetve a különböző modulok indulásakor és leállításakor keletkező bejegyzéseket lehet megtekinteni. Az eseményekről e-mail értesítés is megy az ADMIN_EMAIL_ADDRESSES konfigurációs paraméter beállításának megfelelően. Ha be van állítva az ADMIN_SNMP_TRAP_ADDRESSES paraméter, akkor SNMP trap-et is küld az eseményekről az alkalmazás. A rendszer megjegyzi azt is, hogy az adott felhasználó látta-e már a kérdéses üzenetet, és azokat, amelyeket még nem tekintett meg egy sárga csillaggal jelzi:

17. ábra Szerver események

Amennyiben a PVSR érzékeli azt, hogy új üzenet keletkezett azóta, hogy a felhasználó utoljára megnyitotta a Szerver események oldalt, úgy ezt az alkalmazás fejlécében a riasztás összegzés mellett egy ikonnal jelzi. Az ikon szine piros, ha a legutóbbi oldal megtekintése óta keletkezett új hiba üzenet, narancssárga, hogyha nem hiba szintű üzenet keletkezett. Az egeret az ikon fölé tartva azt is megmutatja, hogy a legutóbbi oldal megtekintés óta hány új üzenet keletkezett, illetve az ikonra klikkelve azonnal meg is nyitja a Szerver események menüpontot.

Az események fordított időrendben jelennek meg lapozható táblázatban. Az egyes sorok színezése három féle lehet:

• Normál: szerver státusz változása elindítás vagy leállítás után. Ha a szerver státusza Ismeretlenné válik, úgy az piros színnel mint hiba jelenik meg
• Piros: hiba jelenség
• Narancs: figyelmeztetés szintű üzenet vagy olyan hibajelenség, ami már lezáródott, ilyen esetben megjelenik a lezáró üzenet is. Fontos megjegyezni, hogy egyrészt nem minden típusú üzenetnek van lezáró párja, másrészt az, hogy lezárásra került még nem jelenti feltétlenül azt, hogy a hiba megszűnt. Például ha az alkalmazás manager jelez egy hibát majd újraindításra kerül, akkor az újraindítás lezárja az általa jegyzett hibákat, de az indítás utáni első ellenőrzés során újra előjöhetnek. Természetesen az ilyen tranziens állapotok csak pár percig állhatnak fent
• Zöld: hiba jelenség megszűnése

Az alkalmazás manager a következő ellenőrzéseket végzi:

• Mindegyik gépen lévő mindegyik PVSR könyvtárból megpróbál az ottani beállításokkal belépni az Oracle adatbázisba
• Mindegyik gépen lévő mindegyik PVSR könyvtár alatt megvizsgálja a logs, tmp, tmp/done, tmp/sftp illetve a gép root (/) könyvtárát és jelez, ha valamelyik könyvtárhoz tartozó diszk partíción lévő szabad hely kisebb mint 1000MB. A figyelést mindegyik szerver mindegyik partíciójára ki lehet külön kapcsolni a DISABLE_LOW_DISK_SPACE_ERROR CONFIG_INI.pm-ben található paraméterrel, például:

$DISABLE_LOW_DISK_SPACE_ERROR{localhost}{/opt}=1;

• Az adatbetöltő (SQLLDR) komponenst futtató gépen megnézi, hogy a tmp/done könyvtárban lévő file-ok száma nem haladja-e meg az alkalmazás manager komponensnél beállított értéket (lásd szerver konfiguráció)
• Az adatbetöltő (SQLLDR) komponenst futtató gépen megnézi, hogy az sqlldr program elérhető-e
• Az adatbetöltő (SQLLDR) komponens log file-ában Oracle hibaüzeneteket keres
• A szerverek közötti időeltérést vizsgálja, és jelez, ha az nagyobb, mint 10 másodperc
• A PVSR által használt táblaterek telítettségét vizsgálja, és jelez, ha valamelyik nagyobb, mint 95%. A figyelést mindegyik táblatérre külön ki lehet kapcsolni a DISABLE_LOW_TABLESPACE_SPACE_ERROR CONFIG_INI.pm-ben lévő paraméterrel, például:

$DISABLE_LOW_TABLESPACE_SPACE_ERROR{PVSR_DATA}=1;

Ha értéknek nem 1-et, hanem 2-őt adunk meg, akkor a PVSR a szabad helyet nem az aktuális táblatér mérethez viszonyítja, hanem a lehetséges maximális mérethez, figyelembe véve a táblatér automatikus extendálási lehetőséget.

Egységesen az összes táblatérre kikapcsolható, hogyha az __all__ kulcsot használjuk, ilyenkor a PVSR nem is próbálja meg lekérdezni a táblatér kihasználtságokat, azaz a PVSR Oracle felhasználójának nincs is szüksége a SELECT_CATALOG_ROLE jogosultságra:

$DISABLE_LOW_TABLESPACE_SPACE_ERROR{__all__ }=1;

• Amennyiben az alkalmazás manager-t futtató gépen fut az Oracle adatbázis kezelő is, és a PVSR-nél az ORACLE_HOME-nak az adatbázis szerver könyvtára lett megadva, úgy leellenőrzi, hogy nem túl nagy-e az Oracle szerver SQL*Net log file-ja. Amennyiben az túl nagy és riasztást küld, úgy ajánlott az Oracle Listener leállítása és a log file elmozgatása vagy törlése, majd az Oracle Listener újraindítása
• Amennyiben az SQLLDR, a threshold, a riport feldolgozó vagy az adatmozgató ugyanazon a gépen fut, mint az alkalmazás manager, úgy ellenőrzi, hogy az adott modul log file-ja módosítva volt-e az elmúlt két órában
• Ellenőrzi a gyors kiértékelésű threshold modul – adatgyűjtő modul kapcsolatokat

Az adatmozgató modul a következő ellenőrzéseket végzi:

• Történt-e bármilyen Oracle hiba az adatmozgatás során

Az adatbetöltő (SQLLDR) modul a következő ellenőrzéseket végzi:

• Minden futó adatgyűjtő esetében az általa végzett minden mérés ciklusnál megvizsgálja, hogy:
• Keletkezett-e új mérési értékeket tartalmazó file: ha a szerver paraméterezésnek megfelelően a betöltő nem várhat tovább a file-ra, úgy riasztást generál
• A file tartalmaz-e legalább az elvártnak megfelelő számú sikeres mérést (lásd a REQUIRED_SUCCESSFUL_MEASUREMENTS paramétert)
• Riaszt akkor is, ha egy mérési file kimaradt. Erre például akkor lehet példa, ha egy 1 perces mérési ciklus mindig 1 perc 10 másodpercig tart, mivel ilyenkor előbb-utóbb át fog ugrani a rendszer egy mérési ciklust
• Amennyiben egy betöltési ciklus egymás után kétszer is hosszabb ideig tart mint a konfigurációban (lásd 5.3) megadott idő
• Amennyiben az alkalmazás manager (ha kettő is van, akkor az elsődleges) ugyanazon a gépen fut, mint az adatbetöltő, úgy ellenőrzi, hogy a log file-ja módosítva volt-e az elmúlt két órában
• A modul minden mérés file-ra megvizsgálja, hogy az hány sort tartalmaz. Ehhez egy külön parancssori alkalmazást (a wc parancsot) használja. Amennyiben ez nem ad vissza helyes eredményt, úgy üzenetet küld majd újraindítja magát. A modul saját automatikus újraindítása elméletileg megoldja a problémát, azonban ha továbbra is fennáll, úgy szükséges lehet a modul kézzel történő leállítására és újraindítására

A riasztás kiértékelő modul a következő ellenőrzéseket végzi:

·       Figyeli, hogy volt-e kimaradás a gyors kiértékelésű adatok fogadásában. Tipikusan UDP használata esetén fordulhat ilyen elő.