Dlaczego Nagios? Przede wszystkim dlatego, że jest łatwy we wdrożeniu i darmowy (nie zapomnijcie wpłacić symboliczną kwotę, jeśli będziecie używać Nagiosa! - w ten sposób można podziękować twórcom za kawał dobrej roboty). Co więcej, można go instalować zarówno na *nixie, jak i na platformie Windows.

Przechodząc dalej, zakładam że:

• W2k8r2 jest zainstalowany.
• Centos jest zainstalowany.
• Czytelnik umie zarządzać linuxem w stopniu podstawowym.

Instalacja, konfigurowanie i uruchamianie Nagiosa

Pobieramy paczkę Nagiosa. Niestety nie ma wersji dla dystrybucji Centos, ale ta dla Fedory działa bez problemów. Gdy piszę artykuł, Nagios dostępny jest w wersji 3.2.1. Zanim jednak przystąpimy do instalacji, musimy zainstalować niezbędne komponenty systemu, takie jak: serwer www (httpd), interpreter języka skryptowego php (php), kompilator (gcc) oraz biblioteka graficzna (gd).

wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz
yum install httpd php
yum install gcc glibc glibc-common
yum install gd gd-devel

W dalszej kolejności tworzymy grupę 'nagcmd' i użytkownika 'nagios', dla którego hasłem jest 'nagios'. Dodajemy go, a także użytkownika 'apache' (wykorzytywany jest, aby właściwie działały uprawnienia do pewnych czynności, które będziemy wykonywać w Nagiosie, np. dodawania powiadomień przy wyłączaniu usług lub całych serwerów) do nowo powstałej grupy 'nagcmd'.

usermod -a -G nagcmd nagiosf
usermod -a -G nagcmd apache

Gdy skonfigurowaliśmy już w/w komponenty systemu, przechodzimy do instalacji Nagiosa, którego paczkę pobraliśmy wcześniej. Po jej rozpakowaniu wykonujemy konfigurację i kompilację:

./configure --with-command-group=nagcmd
make all
make install
make install-init
make install-config
make install-commandmode
make install-webconf

Tworzymy użytkownika 'nagiosadmin' do autoryzacji http. Nie chcemy przecież, by ktoś niepowołany miał dostęp do systemu.

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Część instalacji "szkieletu" Nagiosa mamy już za sobą. Możemy teraz podać adres e-mail, na który będą przychodziły alerty. Robimy to w pliku:

w linii:

email      nagsio@localhost

nagios@localhost zastępujemy nowym adresem. W wielu organizacjach maile z powiadomieniami przekazywane są do bramek sms.

Aby Nagiosa mógł działać w pełni, należy doinstalować dodatki rozszerzające jego funckjonalność. Po ich pobraniu rozpakowujemy, konfigurujemy i kompilujemy:

./configure --with-nagios-user=nagios --with-nagios-group=nagcmd
make
make install

Możemy teraz uruchomić proces Nagiosa. Jednak zanim to zrobimy, zweryfikujmy, czy plik konfiguracyjny jest poprawny:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Plików konfiguracyjnych Nagiosa jest dużo. Warto więc zawsze sprawdzać konfigurację, ponieważ informacje o źródłach błędu są bardzo precyzyjne.

Uruchamiamy usługę Nagiosa

service nagios start

Teraz sprawdzamy czy interfejs webowy działa, poprzez wpisanie w przeglądarkę http://adres_IP_lub_nazwa_serwera/nagios. Pojawi się okno autoryzacji http, w którym podajemy poświadczenia dla uprzednio utworzonego użytkownika 'nagiosadmin'. Naszym oczom ukazuje się piękna strona Nagiosa. Super!

W przypadku, gdy po kliknięciu w dowolny link pojawi się błąd wewnętrzny serwera, należy sprawdzić, czy został wyłączony system bezpieczeństwa SELinux. Wyłącza się go wpisując w linię komend:

lub, permanentnie, uruchamiając przewodnika konfiguracji komendą 'setup', wybierając pozycję 'Firewall configuration' i zaznaczając 'security level' na 'disabled' oraz 'Selinux' na 'disable'. Wyłączanie systemu SELinux może jednak znacznie zmniejszyć bezpieczeństwo linuxa, polecam więc zapoznanie się z konfiguracją tego systemu. W naszym przypadku konfiguracja sprowadza się do wykonania następujących komend:

chcon -R -t httpd_sys_content_t /usr/local/nagios/sbin/

Po skonfigurowaniu SELinuxa linki Nagiosa zaczynają działać. Żeby sprawdzić monitorowane usługi klikamy na link 'Services'. Domyślnie, po zainstalowaniu Nagiosa, skonfigurowane jest monitorowanie systemu lokalnego 'localhost':

Mamy więc namiastkę tego, co nas czeka po dodaniu usług dla w2k8r2. Zanim jednak to się stanie, należy edytować kilka plików konfiguracyjnych oraz dodać agenta do w2k8r2.

Zacznijmy od skonfigurowania w2k8r2. Do komunikacji z Nagiosem w w2k8r2 niezbędny będzie agent NSClient++ (http://sourceforge.net/projects/nscplus/files/). Pobieramy paczkę i instalujemy na w2k8r2. Na dzień 05-09-2010 NSClient++ jest w wersji 0.3.8 dla 64bit. Paczka ma format msi więc łatwo można będzie ją wdrożyć przez GPO w naszym środowisku.

Po zainstalowaniu w systemie pojawi się nowa usługa 'NSClient ++ (x64)':

A w programach:

Aby móc korzystać z NSClienta należy edytować plik NCS.ini, który znajduje się w katalogu 'C:\Program Files\NSClient++'. W segmencie '[NSClient]' usuwamy komentarz przy pozycji 'port' i sprawdzamy, czy jego wartość to '12489'. Oczywiście można tę wartość zmienić, lecz należy wtedy pamiętać, by to samo zrobić w Nagiosie. Po zmianie pliku NCS.ini należy zrestartować usługę 'NSClient++'. Restart z linii komend:

Net stop „nsclient++ (x64)" & Net start „nsclient++ (x64)"

Przydała by się opcja 'restart' w komendzie 'net'? A od czego mamy PowerShell:

Restart-Service „nsclient++ (x64)"

Teraz musimy wrócić do linuxa z Nagiosem i skonfigurować monitorowanie w2k8r2.

Aby to wykonać, należy przeprowadzić edycję pliku '/usr/local/nagios/etc/objects/windows.cfg'. Szukamy linii składających się z:

Dokonujemy zmian na:

Dodajemy usługi, które chcemy monitorować. W tym samym pliku zmieniamy dla nich konfigurację.

Domyślnie dodanych jest kilka usług, takich jak: NSClient++ Version, Uptime, CPU Load, Memory Usage, C:\ Drive Space, W3SVC, Explorer. Edytujemy te, które są nam potrzebne. Możemy także zdefiniować inne, co pokażę za chwilę. Póki co skonfigurujemy usługi domyślne. W naszym przypadku wybieramy wszystkie, poza W3SVC, ponieważ nie mamy IIS na w2k8r2. Edytujemy plik konfiguracyjny Nagiosa: nagios.cfg by poprzez usunięcie komentarza:

cfg_file=/usr/local/nagios/etc/objects/windows.cfg

włączyć monitorowanie węzłów platformy Windows. Następnie weryfikujemy konfigurację i restartujemy usługę Nagiosa.

Wracamy do strony WWW Nagiosa i widzimy, że pojawiły się nowe dane o statusie 'PENDING':

Nagios domyślnie odświeża widok po paru minutach więc wszelkie zmiany będą widoczne dopiero po tym czasie. Kolory, które są wykorzystane w monitoringu to:

• Zielony - usługa/serwer jest OK
• Żółty - usługa/serwer jest w trybie ostrzeżenia
• Czerwony - usługa/serwer jest w trybie awarii
• Szary - usługa/serwer jest w trybie oczekiwania na dane

Po około 5 minutach wszystkie usługi są już aktywne i mają status OK:

To, co wykonaliśmy do tej pory, to podstawowy sposób monitorowania. Wykorzystaliśmy jeden z możliwych modułów, jakim jest 'check_nt'. Innym, bardziej rozbudowanym i przez to częściej używanym, jest NRPE (wykorzystywany skrypt 'check_nrpe'). NRPE jest skrótem od Nagios Remote Plugin Executor i daje możliwość, jak to określa twórca, "normalnego monitorowania". Oprócz 'check_nt' i 'nrpe' jest jeszcze zaawansowany moduł 'ncsa server'. My zajmiemy się modułem NRPE, który dodatkowo umożliwia używanie skryptów do analizy i oceny systemu. Jedną z podstawowych różnic w stosunku do 'check_nt' jest port, na którym działa moduł: 5666. Ważne, by w firewallu przepuścić na ten port ruch do monitorowanego serwera.

Osoby, które będą chciały zapoznać sie z dokumentacją projektu NSClient++, odsyłam do strony twórcy: http://nsclient.org

Zanim wykorzystamy potencjał NRPE, niezbędne jest zainstalowanie dodatku do Nagiosa. Obecnie dodatek można ściągnąć w wersji 1.12 nrpe-2.12.tar.gz. Pobieramy, rozpakowujemy, konfigurujemy i kompilujemy na linuxie:

W przypadku braku nagłówków ssl instalujemy brakujące pakiety:

yum install openssl-devel

Kończąc kompilację wykonujemy:

make install-plugin

Po stronie linuxa to już wszystko. W tym momencie warto zapoznać się z dokumentacją, która zawarta jest w podkatalogu 'docs' paczki. Są tam dwa pliki. Jeden w formacie .pdf, a drugi .odt.

Musimy jeszcze wykonać konfigurację po stronie w2k8r2. W pliku NSC.ini należy edytować trzy linijki w sekcji [NRPE], aby wyglądały następująco:

'Allow_arguments' pozwala na przesyłanie do w2k8r2 komend z argumentami, a parametr 'Allow_nasty_meta_chars' umożliwia stosowanie w zapytaniach znaków, takich jak: <>|", które mają znaczenie przy niektórych nazwach usług, np. MSSQL$InstanceName. Dokonawszy zmiany, należy zrestartować usługę NSClient++. Po tych wszystkich zabiegach mamy już skrypt w Nagiosie (check_nrpe) do odpytywania modułu NRPE. Prostym sposobem, by przekonać się, że na w2k8r2 jest poprawny kontakt z modułem NRPE, jest uruchomienie z linuxa:

/usr/local/nagios/libexec/check_nrpe -H adres_ip_w2k8r2

Jeżeli zwrócony wynik będzie wyglądał tak:

I (0.3.8.76 2010-05-27) seem to be doing fine...,

to oznacza, że wszystko jest w porządku. Możemy więc przystąpić do bardziej wyrafinowanego monitorowania.

NRPE

NSClient++ jest bardzo rozbudowanym narzędziem. Moduł NRPE umożliwia uruchomienie wielu mechanizmów sprawdzania. Monitorowanie odbywa się za pomocą wbudowanych komend jak np. komenda sprawdzająca stan usługi, procesu, liczników wydajności, czy też określonych zdarzeń w dzienniku zdarzeń systemu. NRPE daje ponadto sposobność wykonywania komendy odpytującej WMI oraz komendy uruchamiającej skrypty bat,vbs,ps1,lua. Dzieki skryptom mamy prawie nieograniczony dostęp do wszystkich elementów systemu. Poprawna i przemyślana konfiguracja Nagiosa i NSClienta daje potężny oręż monitorowania. W dalszej części skupię się na monitorowaniu z wykorzystaniem, moim zdaniem najważniejszych, komend:

• CheckServiceState. Monitorowanie usługi: Active Directory Domain Services.
• CheckProcState. Monitorowanie procesu: Active Directory Web Services.
• CheckEventLog. Monitorowanie zdarzeń błędów systemu.
• CheckExternalScripts. Monitorowanie poprzez skrypty.

Monitorowanie usługi: Active Directory Domain Services.

NRPE, w odróżnieniu od 'check_nt', w którym zdefiniowane są elementy do sprawdzania, daje możliwość monitorowania stanu działania usług.

Z serwera w2k8r2 dowiadujemy się, jaka jest nazwa systemowa usługi, którą będziemy monitorować. W tym przypadku „Active Directory Domain Services" nosi nazwę „NTDS". Sprawdzamy, jak będzie wyglądała linia komend na linuxie, służąca do weryfikowania tej usługi. Komenda z dokumentacji o module NRPE, która to umożliwia to: CheckServiceState. Cała komenda wygląda następująco:

/usr/local/nagios/libexec/check_nrpe -H adres_ip_w2k8r2 -p 5666 -c CheckServiceState -a ShowAll "NTDS"

Uwaga!: wielkość liter parametrów ma znaczenie. Błędne jest użycie „showall" zamiast „ShowAll".

Po wykonaniu powyższej komendy zostaje zwrócony wynik:

OK: NTDS: started

który oznacza, że usługa jest uruchomiona. Jeśli ją wyłączymy, aby zasymulować uszkodzenie, wynik zapytania będzie wyglądał następująco:

CRITICAL: NTDS: stopped (critical)

Można także monitorować, czy żądana usługa jest wyłączona:

/usr/local/nagios/libexec/check_nrpe -H adres_ip_w2k8r2 -p 5666 -c CheckServiceState -a ShowAll "NTDS"=stopped

Wartością wyniku w przypadku wyłączonej usługi będzie 'OK', więc monit o problemie przyjdzie wtedy, gdy zostanie ona włączona. W w2k8r2 nie ma usługi Messenger, ale jest ona dobrym przykładem do takiego monitorowania. Administratorzy często ją wyłączają, ponieważ jej stan uruchomienia uznawany jest jako zmniejszenie bezpieczeństwa systemu.

Wiadomo już, jak wygląda zapytanie monitorujące, to przejdziemy więc teraz do konfigurowania Nagiosa, aby wyświetlał stan usługi.

W pierwszej kolejności należy dodać w pliku „commands.cfg" odpowiedni schemat komendy monitorującej, która będzie wywoływana. W schemacie tym występują parametry, których wartości będą się zmieniały w zależności dla jakiej usługi i dla jakiego serwera będzie wywoływana komenda.

Dodajemy następujący szablon komendy do „commands.cfg" (/usr/local/nagios/etc/objects):

gdzie:

$USER1$ - ścieżka do katalogu, w którym znajduje się skrypt 'check_nrpe'. Parametr ten zdefiniowany jest w pliku: '/usr/local/nagios/etc/resource.cfg'.
$HOSTADDRESS$ - adres IP monitorowanego serwera.
$ARG1$ - nazwa monitorowanej usługi.

Wykonanie monitorowania usługi NTDS zostanie skrócone do postaci:

check_nrpe_service!NTDS

Łańcuch „NTDS" zostanie przekazany jako wartość $ARG1$. Powyższa komenda musi być oczywiście umieszczona, w naszym przypadku, w pliku 'windows.cfg' (/usr/local/nagios/etc/objects) jako zdefiniowana usługa, do której będzie można przypisywać monitorowane kontrolery domeny:

Powyższe zmiany wystarczą by Nagios mógł monitorować usługę NTDS i generować wizualne powiadomienia. Restartujemy usługę Nagiosa i obserwujemy panel WWW:

Widać, że stan usługi jeszcze nie został sprawdzony. Czekamy około 5. minut i sprawdzamy ponownie:

Informacja o usłudze NTDS wyświetla się teraz w kolorze zielonym, czyli jest włączona (przypominam o możliwości monitorowania wyłączonych usług, o czym pisałem wyżej). Usługa katalogowa na serwerze w2k8r2, który jest kontrolerem domeny, działa poprawnie.

Sprawdzanie procesu: Active Directory Web Services.

Monitorowanie procesów realizowane jest w podobny sposób jak monitorowanie usług. Jedyną zmianą jest komenda modułu NRPE, wskazująca na proces CheckProcState. W pierwszej kolejności należy dodać w pliku 'commands.cfg' odpowiedni schemat komendy, a następnie jego wywołanie w pliku 'windows.cfg'. Schemat komendy wygląda następująco:

Wywołanie schematu w pliku 'windows.cfg':

Powyższe zmiany wystarczą by Nagios mógł monitorować proces „Microsoft.ActiveDirectory.Webservices.exe" i generować wizualne powiadomienia. Restartujemy usługę Nagiosa i obserwujemy panel WWW:

Widać, że stan procesu jeszcze nie został przez Nagiosa sprawdzony. Czekamy około 5. minut i sprawdzamy ponownie:

Informacja o procesie wyświetla się teraz w kolorze zielonym, czyli jest on uruchomiony (przypominam o możliwości monitorowania wyłączonych procesów, które konfiguruje się identycznie jak w monitorowaniu usług, poprzez dodanie po nazwie procesu łańcucha „=stopped"). Proces AD Web Services działa poprawnie.

Monitorowanie zdarzenia typu 'błąd' w dzienniku zdarzeń systemowych.

Na wstępie chciałbym zaznaczyć, że w tym momencie (lipiec/sierpień 2010) moduł NRPE, dotyczący monitorowania zdarzeń (CheckEventLog), nie jest jeszcze dopracowany. Problem występuje w filtrowaniu zdarzeń. W niektórych przypadkach używanie dwóch i więcej filtrów fałszuje wyniki. Jeśli chcemy np. ograniczyć wyniki do zdarzeń typu 'error', wygenerowanych w określonym przedziale czasu, nie możemy posługiwać się łańcuchem dla typu zdarzenia, lecz musimy stosować identyfikator liczbowy. Zostanie to pokazane w poniższym przykładzie. Załóżmy, że chcemy monitorować ilość zdarzeń typu 'błąd', które wystąpiły w ciągu ostatnich 24. godzin. Monitorowanie dziennika zdarzeń realizowane jest za pomocą następującej komendy modułu NRPE: CheckEventLog. Na przykładzie poprzednich dwóch komend modułu NRPE należy dodać odpowiedni schemat komendy w pliku 'commands.cfg' a następnie wywołanie tego schematu w pliku 'windows.cfg'. Schemat komendy wygląda następująco:

Wywołanie schematu w pliku „windows.cfg":

Jak widać, do schematu komendy można dodawać dowolną liczbę zmiennej $ARGx$. Odpowiednie wartości muszą się znaleźć przy wywołaniu komendy. Przedziela się je znakiem „!". Powyższe zmiany wystarczą, by Nagios mógł monitorować zdarzenia i generować wizualne powiadomienia. Restartujemy usługę Nagiosa i obserwujemy panel WWW:

Widać, że stan zdarzeń jeszcze nie został przez Nagiosa sprawdzony. Czekamy około 5. minut i sprawdzamy ponownie:

Informacja o zdarzeniach typu 'błąd' wyświetlana jest w kolorze żółtym, a więc pojawił się stan ostrzeżenia. W naszym przypadku stało się tak, ponieważ argumenty MaxWarn i MaxCrit zdefiniowaliśmy odpowiednio na poziomach 50 i 100. Liczba znalezionych zdarzeń wynosi 89, jest więc większa od MaxWarn, ale mniejsza od MaxCrit. Nagios wygenerował ostrzeżenie, a nie stan krytyczny. Warunki MaxWarn i MaxCrit można zamienić na MinWarn i MinCrit, aby monitorować liczbę oczekiwanych zdarzeń.

CheckExternalScripts. Monitorowanie poprzez skrypty
(http://nsclient.org/nscp/wiki/CheckExternalScripts).

Monitorowanie poprzez skrypty jest chyba najbardziej interesującym sposobem monitorowania. Obsługa skryptów .vbs, .bat, .ps1,.lua (http://www.lua.org/) daje nieskończone możliwości sprawdzania każdej części systemu. Aby móc przystąpić do uruchamiania monitorowania skryptów, należy odpowiednio skonfigurować Nagiosa. Pierwszym krokiem będzie włączenie w pliku NCS.ini, poprzez usunięcie komentarza, biblioteki „CheckExternalScripts.dll" oraz skonfigurowanie segmentów [External Script] oraz [External Scripts]. Pierwszy segment zawiera dane odnoszące się do dozwolonych opcji i parametrów, a drugi aliasy do skryptów, które są wywoływane z Nagiosa. NSClient domyślnie zainstalowany jest wraz z przykładowymi skryptami, które można wykorzystać do przetestowania tego typu monitorowania.

Jeśli skonfigurowane zostały w/w elementy, czas uruchomić monitorowanie skryptem. Wykorzystamy przykładowy skrypt .bat, który jest bardzo prosty. Jego działanie sprowadza się do wyświetlania krótkiego tekstu:

OK: Everything is going to be fine!

Jest on przekazywany przez moduł NRPE do Nagiosa i wyświetlany w panelu WWW. Wywołanie komendy do monitorowania poprzez skrypt na linuxie wygląda następująco:

/usr/local/nagios/libexec/check_nrpe -H adres_ip_w2k8r2 -p 5666 -c check_es_ok

Informacja o skrypcie przekazywana jest jako wartość opcji -c. W tym przypadku to 'check_es_ok'. Jeśli spojrzymy w plik konfiguracyjny NSClienta, to w sekcji [External Scripts] znajdziemy taką linię:

check_es_ok=scripts\check_ok.bat

Definiowanie skryptów odbywa się poprzez aliasy, jak widać powyżej, a ich składnia wygląda następująco:

<alias> = <ścieżka wraz ze skryptem> <parametry>

Do aliasów można dodawać parametry w postaci jaką znamy z szablonu komendy, czyli '$ARG1$ $ARG2$ $ARG3$'. Przykład:

check_script_with_arguments=scripts\script_with_arguments.bat $ARG1$ $ARG2$ $ARG3$

Wywołanie w linuxie wygląda wtedy tak:

./check_nrpe ... -c check_script_with_arguments -a arg1 arg2 arg3

Teraz należy dodać odpowiedni schemat komendy w pliku „commands.cfg", a następnie wywołanie tego schematu w pliku „windows.cfg". Schemat komendy wygląda następująco:

define command{
command_name    check_nrpe_extscript
command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c $ARG1$
}

Wywołanie schematu w pliku „windows.cfg":

define service{
use                     generic-service
host_name               w2k8r2
service_description     Monitorowanie wyniku skryptu
check_command           check_nrpe_extscript!check_es_ok
}

Parametr przekazywany do wykonania skryptu zawiera nazwę aliasu skryptu. Jest to wygodne, ponieważ dla innego aliasu wystarczy tylko nowe wywołanie schematu komendy 'check_nrpe_extscript'. Powyższe zmiany wystarczą, by Nagios mógł monitorować zdarzenia i generować wizualne powiadomienia. Restartujemy usługę Nagiosa i obserwujemy panel WWW:

Widać, że wynik skryptu jeszcze nie został przez Nagiosa sprawdzony. Czekamy około 5. minut i sprawdzamy ponownie:

Zwrócony wynik skryptu zawiera status 'OK', pojawia się więc kolor zielony.  W kolumnie 'Status Information' widać treść zwróconą przez wywołanie skryptu: „OK: Everything is going to be fine!". Teraz pojawia się pytanie: jak wygenerować status ostrzeżenia lub awarii?. Aby wygenerować status ostrzeżenia, kod wyjścia skryptu musi mieć wartość '1', dla awarii jest to wartość '2', dla stanu nieokreślonego '3', a dla stanu porządku '0'.

Na koniec

Tym samym doszliśmy do końca. Nagios, jak już wspominałem, to narzędzie bardzo przydatne dla administratora. Ciekawych funkcji posiada dużo więcej, niż udało mi się opisać. Wraz z NSClientem stanowią super narzędzie. Zachęcam do zgłębiania dokumentacji, ponieważ jest jeszcze wiele rzeczy, które da się skonfigurować. Mogą być nimi np. odpowiednio sformatowane polityki wysyłania mailowych informacji. Definiuje się je w pliku '/usr/local/nagio/etc/contacts.cfg'. Innym, często stosowanym ustawieniem, jest wysyłka informacji o problemach na sms. Ciekawostką jest interaktywna mapa sieci, która dostępna jest pod linkiem 'Map':

Istnieją wtyczki dla mapy Nagiosa, wizualizujące sieć w postaci modelu, który możemy obracać, przybliżać itd. W prosty sposób możemy definiować zależności pomiędzy serwerami i urządzeniami sieciowymi, by w przypadku uszkodzenia, np. switcha, nie były wysyłane monity o braku połączenia z serwerami do niego podpiętymi. Kolejną interesującą wtyczką jest "powiadamiacz" (Nagios Checker), jako ikona w przeglądarce, która informuje na bieżąco, co dzieje się w naszych systemach, bez konieczności odwiedzania panelu WWW Nagiosa. Ostatnio, podczas jednej z prezentacji na żywo na wss.pl, zauważyłem, że prelegent posiada taką wtyczkę w przeglądarce i wyglądała ona tak:

Czy wiecie, kto i jaka to była sesja? :)

Tak.. tak... jest tego naprawdę dużo i, żeby nie być gołosłownym, podam adresy serwisów z dodatkami do Nagiosa, by jeszcze bardziej można było go modelować pod kątem własnych potrzeb: http://exchange.nagios.org/, http://nagiosplugins.org/.

Linki:

• Nagios - http://www.nagios.org/
• Bazy dodatków do Nagiosa - http://exchange.nagios.org/, http://nagiosplugins.org/
• W2k8r2 - http://www.microsoft.com/windowsserver2008/en/us/default.aspx
• NSClient++ - http://nsclient.org/nscp/
• NRPE - http://en.wikipedia.org/wiki/NRPE
• Centos - http://www.centos.org/

Autor:

Wojciech Napierała
MCSA i MCP

„Co usłyszę, zapomnę. Co zobaczę, zapamiętam. Co zrobię, zrozumiem.”