Oc Pasm Monitor. Wprowadzenie Wczesne dostrzeganie problemów zagraŜających całej infrastrukturze informatycznej firmy, wymaga niezawodnego narzędzia monitorującego jakim z pewnością

XV Konferencja PLOUG Kościelisko Październik 2009

Oc Pasm Monitor

Andrzej Rydzanicz Opitz Consulting Kraków Sp.z o.o.

[email protected] Abstrakt. Celem prezentacji jest przedstawienie platformy PASM Monitor (Pro-Active-System-Management) bazującej na produkcie Nagios (Open Source) oraz OC-AGENT – aplikacji Java napisanej na potrzeby naszego projektu celem zwiększenia wydajności oraz niezawodności naszych usług. Zaprezentowany zostanie całościowy zakres moŜliwości systemu monitoringu szerokiej gamy produków firmy ORACLE oraz uŜyte technologie (Nagios, shell scripting, Java, OSGi, Oracle Database oraz Oracle APEX).Wykład oparty jest o praktyczne doświadczenia z projektów.

Oc Pasm Monitor 133

1. Wprowadzenie

Wczesne dostrzeganie problemów zagraŜających całej infrastrukturze informatycznej firmy, wymaga niezawodnego narzędzia monitorującego jakim z pewnością jest Nagios (oprogramowa-nie Open Source mające szeroki wachlarz zastosowań, jeŜeli chodzi o nadzór Infrastruktury IT). Zaprojektowany z myślą o uŜytkownikach końcowych (administratorzy), nagios swą skalowalno-ścią oraz elastycznoscią daje pewność, iŜ krytyczne procesy biznesowe nie zostaną przerwane przez nieznane problemy natury technicznej. Nagios jest potęŜnym narzędziem dającym moŜli-wość śledzenia procesów biznesowych w czasie rzeczywistym, co pozwala wykryć a następnie usunąć usterki w infrastrukturze IT, tak aby uŜytkownik końcowy nie był świadom zaistaniałych problemów.

2. Czym jest OC PASM ?

OC PASM – Opitz Consulting Pro-Active-System-Managment. Naszym celem jest dostarcze-nie wysoko wyspecjalizowanego systemu charakteryzującego się 24 godzinną dostępnością przez 7 dni w tygodniu. W skład tego systemu wchodzą następujace komponenty:

2.1. Monitoring

2.2. Administracja

2.3. Stały kontakt telefoniczny (24h przez 7 dni w tygodniu)

OC PASM (Opitz Consulting ProActiveSystemManagment) jest zunifikowanym, dostosowa-nym do potrzeb klienta, kompleksowym systemem zarządzania oraz nadzoru baz danych Oracle. Wszystkie działania wykonywane są zgodnie z tzw. SLA (Servive Level Agreements). Admini-stracja odbywa się w oparciu o komponent monitorujący (Nagios). Precyzyjnie wytyczone drogi eskalacji mają na celu zapewnienie jesczcze większej niezawodności. Podstawowym komponen-tem tego systemu jest wyŜej wspomniany Nagios. Główną ideą monitoringu baz danych, jest szybkie wykrywanie sytuacji konfliktowych, które mogą przerodzić się w szeroko rozumiane prze-rwy w dostawie usług bazodanowych. Naszym celem było zbudowanie systemu monitoringu, któ-ry byłby uniwersalny do tego stopnia, aby mógł działać na róŜnych platformach oraz nadzorować róŜnego typu rozproszone środowiska klientów. Z załoŜenia system musiałbyć w stanie monitoro-wać rozproszone systemy klienta zbierając istotne informacje statusowe oraz statystyczne a na-stępnie wysyłać powiadomienia do odpowiednich grup odpowiedzialnych za dany komponent, sieć lub system. Przetestowaliśmy róŜnego rodzaju narzędzia, ale najbardziej odpowiednim i nie-zawodnym okazał sie właśnie Nagios. System ten oferuje równieŜ prosty w uŜyciu (wręcz intu-icyjny) interfejs uŜytkownika. Szczególną cechą tego narzędzia okazała sie bardzo łatwa integracja z naszym systemem ticket-owym (aplikacja Pasm) co doprowadziło do powstania wyŜej wymie-nionej juz platformy OC PASM MONITOR.

3. Czym jest Nagios?

Oryginalnie Nagios powstał pod roboczą nazwą NetSaint. Został napisany oraz jest wspierany przez Ethan Galstad oraz grupę programistów, którzy aktywnie uczestniczą w rozwoju tego narzę-dzia jak rownieŜ wielu dodatków/wtyczek (plugins). Istotnym atutem Nagiosa jest fakt, iŜ jest to narzędzie całkowicie opensourcowe (GNU GPL). Po co wydawać setki tysięcy złotych na opro-gramowanie komercyjne (np. Enterprise Manager), gdy nie płacąc ani złotówki moŜemy uzyskać tą samą funkcjonalność. Nagios to system monitorowania hostów i usług w sieci komputerowej dający moŜliwość sprawdzania ich stanu w zaplanowanym czasie przy uŜyciu wtyczek. Nagios ma

134 Andrzej Rydzanicz

moŜliwość sprawdzania rownocześnie wielu usług, oferując przy tym zcentralizowany interfejs uŜytkownika, dający moŜliwość skupienia się na komponentach, które nas interesują. Generalna zasada monitoringu przy pomocy Nagiosa brzmi: mogę monitorować wszystko, co da sie monito-rować przy pomocy wtyczki (dostarczonej standardowo, bądź napisanej własnoręcznie). KaŜdy wykryty błąd lub usterka jest natychmiast komunikowana naleŜnym grupom administratorów, które rownieŜ moŜemy zdefiniować w zaleŜności od monitorowanego komponentu. Komunikacja moŜe odbywać sie na wiele sposobow (E-Mail, pager, sms lub inny zdefiniowany przez uŜytkow-nika sposób). Narzędzie oferuje takŜe moŜliwość określenia stopnia ostrzeŜeń dla poszczególnych grup uŜytkowników (stany: Uknown, Warning, Critical) jak rowniez tzw. „tłumienia” wysyłania komunikatów na określony czas. Ogólna architektura narzędzia prezentuje się następująco:

Rys. 1. Ogólna architektura Nagiosa

Nagios regularnie czyta plik z komendami oraz pozwala modyfikować proces monitorowania i wysyłania komunikatów podczas działania narzędzia. Nagios daje rownieŜ moŜliwość interakcji z aplikacją z zewnątrz poprzez tzw. plik „External Comand File”. PoniŜej przedstawiona jest ar-chitektura owego rozwiązania.

Oc Pasm Monitor 135

Rys. 2. Architektura pracy Nagiosa

Takowa interakcja daje moŜliwość wprowadzania komend (np. przez apikacje zewnętrzną) do pliku, które następnie zostaną przez proces Nagios wykonane w zadanym czasie. Nagios oferuje dwa rodzaje metod sprawdzania usług sieciowych: aktywne oraz pasywne. Monitoring aktywny to synchroniczne oraz planowane przez proces Nagiosa wykonania komend, mających na celu uzy-skanie statusu danej usługi w zadanym czasie. Monitorowanie pasywne polega zaś na analizowa-niu wyników dostarczonych przez zewnętrzne aplikacje (w sposób asynchroniczny). Przetwarza-nie danych odbywa sie w ten sam sposób jak w monitoringu aktywnym.

4. Czym jest platforma PASM MONITOR?

Poprzez lata doświadczeń oraz testów udało nam się zaimplementować nowatorską platformę OC PASM Monitor. Jej ogólna architektura przedstawia sie nastepujaco:


Rys. 3. Architektura Platformy OC PASM MONITOR

Jak widać na powyŜszej grafice, cała infrastruktura monitorująca podzielona jest na dwie czę-ści. Pierwsza to maszyna PMS (pasywny monitoring – Pasm Monitoring Systen) oraz PAS (ak-tywny monitoring). KaŜda z maszyn PAS podłączana jest do infrastruktury sieciowej klienta gdzie wykonywane są aktywne odpytania statusów poszczególnych usług sieciowych. Maszyna PMS jest tylko jedna – tutaj przekazywane są zbiorcze statusy usług sieciowych zebranych przez ak-tywny monitoring realizowany przez serwery PAS, rezydujące u poszczególnych klientów. To właśnie PMS udostępnia interfejs uŜytkownika dający moŜliwość generowania grafik dla poszcze-gólnych usług sieciowych (obrazujących ich dostępność w przeciągu określonego czasu itd.) tzw. grafik modułu PNP. PoniŜsza grafika prezentuje przykładowe średnie czasy odpowiedzi oraz ilość utraconych pakietów ICMP oraz aktualne zuŜycie procesora.

Oc Pasm Monitor 137

Rys. 4. Grafiki PNP (PING oraz zuŜycie CPU)

Następna grafika odnosi sie bezpośrednio do bazy danych i prezentuje aktualną liczbę sesji oraz procesów uŜytkowników.


Rys. 5. Grafiki PNP (Aktualna liczba sesji oraz liczba procesów oraclowych)

W zaleŜności od interesujących nas statystyk, mamy do dyspozycji następujące ramy czasowe:

• 4 godziny,

• 24 godziny,

• 1 tydzień,

• 1 miesiąc

• 1 rok.

5. OC-AGENT i jego zadania

Kolejnym nieodzownym elementem platformy jest komponent pośredniczący między maszy-nami PAS oraz PMS noszący nazwę OC-AGENT. Jest to aplikacja Java napisana specjalnie na potrzeby platformy. Stanowi swoisty pomost w przekazywaniu informacji do centralnego kompo-nentu platformy (serwera PMS). Wszystkie informacje zebrane przez aktywny monitoring na temat odpytywanych usług gromadzone są w dwóch plikach: service-perfdata.$TIME$ oraz host-perfdata.$TIME$ (makro $TIMES$ oznacza czas w formacie uniksowym – ilość sekund od roku 1970).

Oto przykładowa zawartość jednego z plików:

1252424919 ServerB PING 0 PING OK - Packet loss = 0%, RTA = 0.31 ms|rta=0.308000ms;500.000000;2000.000000;0.000000 pl=0%;20;60;0

1252424919 ServerA PING 0 PING OK - Packet loss = 0%, RTA = 0.25 ms|rta=0.255000ms;500.000000;2000.000000;0.000000 pl=0%;20;60;0

1252424919 ServerB ICIP: tablespace IMAGE 0 ICIP : IMAGE OK - 0% used [ 1 / 500 MB used ]|used=1MB;85;92;0;500

Oc Pasm Monitor 139

1252424919 ServerB Swap Usage 0 SWAP OK: 87% free (26504 MB out of 30464 MB)|swap=26503MB;0;0;0;3046

Na pierwszym miejscu widzimy liczbę, która reprezentuje uniksowy format czasu oznaczający ilość sekund od roku 1970. Przykładowo:

Liczba 1252424971 oznacza date

Di 8. Sep 17:49:31 CEST 2009 (date -d @1252424971)

Następnie widzimy nazwę hosta do którego odnosi sie check oraz zwróconą wartość. Charakte-rystyczną cechą tego wyniku jest pionowa kreska (pipe), która dzieli wynik na dwie czesci:

1252424919 ServerA DB: tablespace IMAGE 0 DB : IMAGE OK - 0% used [ 1 / 500 MB used ] |used=1MB;85;92;0;500

Pierwsza część (powyŜej) reprezentuje faktyczny string, który ujrzymy później w interfejsie uŜytkownika jako wynik wykonanego checku, druga zaś (poniŜej), stanowi dane dla modułu PNP odpowiedzialnego za kreślenie wykresów:

|used=1MB;85;92;0;500

1MB – aktualna zajetosc

85 – wartosc w procentach okreslajaca poziom warning

92 – wartosc w procentach okreslajaca poziom critical

0 – wartosc min.

500 – wartosc max.

Jak juŜ wspomniano wyniki poszczególnych check-ów zapisywane są do dwóch plików, które są systematycznie przetwarzane przez OC-AGENT-a tzn. wyniki są zbierane i przekazywane dalej do modułu centralnego. Takie rozwiązanie ma jedną zasadniczą zaletę, w razie wystąpienia pro-blemów natury sieciowej w komunikacji między modułem centralnym (PMS) i lokalnym (PAS) OC-AGENT jest w stanie „odłoŜyć dane ” i przekazać je w późniejszym terminie, gdy problemy zostaną usunięte. Naszym celem jest szczególna dbałość o dane klienta, tak więc cała komunikacja między centralnym komponentem a maszyną PAS odbywa sie przy uŜyciu protokołu https. PoniŜ-sza grafika przedstawia proces przetwarzania plików wynikowych przez proces OC-AGENT. Jak widać w początkowej fazie ilość plików wynikowych wzrasta, ale po chwili znowu spada do zera – co wskazuje na to, iŜ pliki zostały zebrane przez proces OC-AGENT i przekazane dalej do mo-dułu centralnego. Proces ten odbywa sie cyklicznie.


Rys. 6. Proces przesyłu plików wynikowych do modułu centralnego

OC-AGENT to bardzo elastyczny, modułowy komponent, sterowany centralnie. Mamy moŜli-wość ustalania czasu próbkowania (z jaką czestotliwością OC-AGENT ma przekazywać pliki). Istnieje rownieŜ moŜliwość, aby OC-AGENT uaktualnił swoją konfigurację. PoniŜej przedstawio-no przykład startu agenta:

| 2009/02/09 13:54:13 | /opt/oc_agent/./load/wsclient-0.10.jar

| 2009/02/09 13:54:13 | /opt/oc_agent/./load/servicelayer-0.10.jar

| 2009/02/09 13:54:13 | /opt/oc_agent/./load/checkuploader-0.20.jar

| 2009/02/09 13:54:13 | /opt/oc_agent/./load/configupdater-0.20.jar

| 2009/02/09 13:54:14 | Installed /opt/oc_agent/load/checkuploader-0.20.jar: null

| 2009/02/09 13:54:14 | Installed /opt/oc_agent/load/wsclient-0.10.jar: null

| 2009/02/09 13:54:14 | Installed /opt/oc_agent/load/servicelayer-0.10.jar: null

| 2009/02/09 13:54:14 | Installed /opt/oc_agent/load/configupdater-0.20.jar: null

| 2009/02/09 13:55:15 | Service-Layer started

| 2009/02/09 13:55:25 | Service-Layer: Initially started ConfigUpdater

| 2009/02/09 13:55:25 | ServiceLayer: Config still null

Oc Pasm Monitor 141

| 2009/02/09 13:55:25 | Config-Updater: Bearbeite Host pas403 und Plugin OCAgentServiceLayer

| 2009/02/09 13:55:26 | Bearbeite Config...

| 2009/02/09 13:55:26 | Service-Layer: Config injected!

| 2009/02/09 13:55:26 | Config-Updater: Bearbeite Host pas403 und Plugin OCA-gentConfigUpdater


| 2009/02/09 13:55:26 | Config-Updater: Bearbeite Host pas403 und Plugin OCA-gentCheckUploader


| 2009/02/09 13:55:27 | Schleifenlauf

| 2009/02/09 13:55:27 | OC Agent - Service Layer 0.10

| 2009/02/09 13:55:27 | OC-Agent Config-Updater Version 0.11

| 2009/02/09 13:55:27 | ist gestartet

| 2009/02/09 13:55:27 | OC-Agent Check-Uploader Version 0.20

| 2009/02/09 13:55:27 | wurde gestartet

| 2009/02/09 13:55:27 | CheckUploader RUN

| 2009/02/09 13:55:27 | Check-Uploader: Process file service-perfdata.1234182810



| 2009/02/09 13:55:27 | Check-Uploader: Process file host-perfdata.1234183470


Tekst pogrubiony prezentuje 4 zasadnicze komponenty:

WSCLIENT, SERVICELAYER, CHECKUPLOADER, CONFIGUPDATER

NajwaŜniejszym z nich jest WSCLIENT, który odpowiada za właściwą komunikację z modu-łem centralnym. CONFIGUPDATER zajmuje się aktualizacją konfiguracji, zaś CHECKUPLOA-DER przesyłem plików wynikowych (sprawdza czy istnieją, jeŜeli tak, to inicjonowana jest trans-misja przez komponent wsclient). Następnie moŜna zauwaŜyć jak OC-AGENT zainstalował po-szczególne moduły (tekst oznaczony kolorem zielonym). Tekst oznaczony kolorem niebieskim pokazuje, jak poszczególne pliki są uploadowane przez moduł CHECKUPLOADER.

6. Monitorowanie baz danych ORACLE

Nagios nie narzuca ograniczeń na elementy, jakie chcemy monitorować. Zasada monitoringu przy pomocy wtyczek daje adminstratorom szeroki wachlarz zastosowań. Wystarczy prosty skrypt schell-owy (bash, ksh ..) aby móc monitorować stan bazy danych i jej nierozłącznych komponen-tów. Check_oracle.sh skypt składający sie z wielu procedur odnoszących sie do konkretnego ele-mentu, bedącego przedmiotem monitoringu.

Przykładowe wykonanie skryptu moŜe wygladąć następująco: (naleŜy przy tym pamiętać, iŜ skrypt wykonywany jest aktywnie a rezultaty jego odpytań będą przekazane dalej do centralnego systemu PMS poprzez OC AGENT-a).

Wykonanie z poziomu systemu operacyjnego (maszyna aktywnie monitorujacą – serwer PAS):

Usage:

check_oracle.sh --tablespace <USER> <PASS> <INST> <TABLESPACE> <CRITICAL> <WARN-ING>

pas350:/usr/local/nagios/libexec # ./check_oracle.sh --tablespace nagios xxx sid SYSTEM 90 70

fors : SYSTEM OK - 1% used [ 439 / 32767 MB used ]|'used'=439MB;70;90;0;32767


Podgląd graficznego interfejsu wykonania tego checku – serwer PMS:

Oczywiście cała komunikacja z bazą danych odbywa sie przy pomocy protokołu SQL.NET. Zaprezentowany wyŜej rodzaj checku jest tylko jednym z wielu, który opracowaliśmy aby w spo-sób rzeczowy i ciągły (zgodnie z SLA), monitorować systemy bazodanowe naszych klientów.

Oto przykład interfejsu graficzengo, który ukazuje moŜliwości Nagiosa, jako nieodzownego komponentu OC PASM MONITOR. PoniŜsza grafika przedstawia aktualne statusy komponentów danego hosta. Widać tu podstawowe usługi jakie moŜna monitorować aby dostatecznie szybko wykrywać i zapobiegać błędom systemu operacyjnego. Dodatkowo monitorowana jest tu baza standby, która w tym przypadku znajduje sie na serwerze.

Rys. 7. Interfejs uŜytkownika (statusy hosta)

Jak widać powyŜej, do dyspozyji mamy metryki takie jak: bierzące obciaŜenie systemu, ilość zalogowanych uŜytkowników, dostępność hosta (PING), dostepność demona SSH, zajętość po-szczególnych filesystemów, dostępność bazy standby oraz jej opóźnienie względem bazy produk-cyjnej.

Kolejna grafika przedstawia nie tylko statusy hosta ale równieŜ rezydującą na nim produkcyjną bazę danych Oracle. Sprawdzane są róŜnorodne komponenty, waŜne z punktu widzenia niezawod-ności systemu jako całości. MoŜemy wyszczególnić w obrębie monitoringu bazy następujące me-tryki: sprawdzanie zajętości przestrzeni tabel, aktualną liczbę sesji oraz liczbę procesów, czas od ostatniego backup-u bazy, sprawdzanie nowych wpisów (ORA-) w pliku alert.log jak równieŜ dostepność listenera i samej bazy danych (tnsping, dblogin).

Rys. 8. Statusy bazy

Oc Pasm Monitor 143

Grafika poniŜej przedstawia z kolei monitoring samego hosta, na którym zainstalowany jest Nagios. Aby uniknąć systuacji, w której to monitoring z przyczyn bliŜej nieznanych uległ uszko-dzeniu, zaimplementowaliśmy sprawdzanie maszyny nagiosowej oraz krytycznych dla jej prawi-dłowego działania komponentów.

Rys. 9. Statusy hosta maszyny nagiosowej (PAS)

Ciekawym rodzajem checku jest sprawdzanie samego procesu Nagiosa a dokładniej sprawdza-nie statusowego logu deamona Nagiosa pod kątem wieku. Jeśli okaŜe sie, Ŝe log nie był uaktual-niony dostatecznie długo, pojawi się alarm świadczący o tym, Ŝe proces Nagiosa nie działa lub działa nieprawidłowo.

Jak juŜ wspomniałem wcześniej, Nagios oferuje szeroki wachlarz moŜliowści, jeŜeli chodzi o monitoring środowisk róŜnego typu. Jesteśmy w stanie nadzorować nie tylko pojedyńcze bazy danych (single instance) ale równieŜ róŜnego rodzaju konstelacje bazodanowe typu RAC czy Fail-Over Cluster. PoniŜsza grafika przedstawia nadzór RAC-a.

Rys. 10. Monitoring środowiska typu RAC

Jak moŜna łatwo zauwaŜyć nadzorowanie takiego środowiska nie róŜni się zbytnio od poprzed-niego sposobu ale co moŜna zauwaŜyć na pierwszy rzut oka, to nowe pluginy – kontrolujące zaję-tość grup dyskowych jak równieŜ samych dysków ASM. TakŜe pluginy typu dblogin i alert.log check zostaly rozdzielone na dwie osobne instancje RAC-a. Znaczącym aspektem z punktu widze-nia bezpieczeństwa i niezawodności są bazy standby oraz ich monitoring. PoniŜszy przykład pre-zentuje plugin monitorujący opóznienie bazy standby względem produkcji jak równieŜ reprezenta-cję graficzna tego zestawienia (moduł PNP):

Rys. 11. Opóźnienie bazy standby względem produkcji

Wzkres poniŜej prezentuje graficzną reprezentację powyŜszego check-u z wykorzystaniem modułu PNP. Jesteśmy w stanie dokładnie powiedzieć jak kształtowały sie wyniki opóźnienia bazy standby w zaleŜności od godziny. Poziom ostrzegawczy to w tym przypadku 45 minut, zaś 60 minut to poziom krytyczny.


Rys. 12. Graficzna reprezentacja powyŜszego checku

Często zdaŜa się, Ŝe potrzebujemy „wyciągnać” interesujący nas raport z bazy wprowadzając ją w tryb read only. Jak widać na poniŜszym przykładzie sprawdzany jest czas, jak długo baza znaj-duje się w tym trybie. W razie przekroczenia krytycznej granicy generowany jest ticket:

Rys. 13. Sprawdzanie czasu „Read Only State”- aktualny status ok

Rys. 14. Sprawdzanie czasu „Read Only State”- aktualny status critical

Nagios to bardzo praktyczne i elastyczne narzędzie. Jesteśmy w stanie monitorować nie tylko aktualny stan naszej bazy, ale równieŜ zmiany jakie zaszły w jej konfiguracji mam tu na myśli np. dodanie lub usunięcie tablespace-ów. Narzędzie to daje szeroki zakres zastosowań równieŜ w mo-nitoring serwera aplikacji.

Rys. 15. Nadzór serwera aplikacji

Wielu klientów dysponuje równieŜ konstelacją typu fail-over-cluster co skłoniło nas do podję-cia wyzwania i opracowania monitoringu dla tego typu rozwiązania:

Oc Pasm Monitor 145

Rys. 16. Nadzór klastra typu fail-over

Monitorujemy tu przede wszystkim zasoby CRS.

7. Aplikacja PASM

Dzięki integracji narzędzia Nagios z naszym systemem zgłoszeniowym, powstała platforma OC PASM MONITOR. KaŜdy problem w środowisku IT klienta jest natychmiast rejestrowany przez modul monitorujący (Nagios) i przekazywany dalej do aplikacji Pasm. To właśnie na po-ziomie naszego systemu ticketowego odbywa sie kategoryzacja klienta jego systemów, komponen-tów oraz piorytetów z jakim ma być otwarty ticket. Wszystkie te informacje zawarte są w nowo powstałym tickecie tak aby dostarczyć precyzyjnych informacji na temat zaistniałego problemu. Na poziomie aplikacji mamy teŜ moŜliwość ignorowania błedów. Nie znaczy to, Ŝe zdarzenia te nie bedą raportowane, wręcz przeciwnie, bedą widoczne w systemie w postaci eventu ale nigdy nie powstanie z nich ticket. Mamy równieŜ moŜliwość zdefiniowania czasu w którym klient prze-prowadzać będzie zabiegi techniczne bazy, bądz serwera, następstwem czego jest ignorowanie wszelkich błędów odnoszących się do odpowiedniego komponentu.

8. Podsumowanie

Nagios to program działający jako daemon w systemie Linux do monitorowania sieci, urządzeń sieciowych, aplikacji, baz danych oraz serwerów rozpowszechnianym na podstawie licencji open source. MoŜe monitorować hosty oraz usługi według określonych ustawień, dzięki czemu jest moŜliwe dostosowanie go do swoich potrzeb. W razie wykrycia problemu Nagios moŜe wysłać E-Mail, wiadomość na pager lub SMS do administratora systemu z informacją o problemie. Jest nie-zwykle stabilnym oraz wszechstronnym narzędziem. Dzięki integracji z aplikacją PASM udało się nam stworzyć platformę OC PASM MONITOR, która specjalizuje się w nadzorowaniu wszelkie-go rodzaju konfiguracji bazodanowych Oracle. Jej modułowość i prostota zapewnia wręcz nie-ograniczone moŜliwości zastosowań. Bezpieczeństwo i niezawodność to kolejny aspekt przema-wiający na korzyść naszego rozwiązania, dający nam pozycję lidera wśród konkurencyjnych firm i rozwiązań na rynku niemieckim.

Bibliografia

http://www.nagios.org/

Documents

Oc Pasm Monitor. Wprowadzenie Wczesne dostrzeganie problemów zagraŜających całej infrastrukturze informatycznej firmy, wymaga niezawodnego narzędzia monitorującego jakim z pewnością