07-31-2019, 06:46 AM
Aplikacje monitorujące kontrolują środowisko IT na wiele sposobów. Jednym z nich jest odczyt parametrów SNMP z urządzeń. Aplikacje odczytują wartości katalogu OID, które producent zaszył w urządzeniu.Jest to podstawowa funkcjonalność Nagios i op5 Monitor. Kolejnym hasłem wykorzystania protokołu SNMP jest obsługa zdarzeń, czyli przyjmowanie SNMP traps. Tu op5 wypada lepiej, ponieważ posiada dodatkowy moduł, pozwalający na proste przeglądanie rejestrowanych zdarzeń oraz podejmowanie akcji powiadamiania o ich wpłynięciu.
Oba scenariusze są intuicyjną i standardową funkcją monitoringu. Zdarza się jednak, że chcemy aby zdarzenia SNMP były generowane również poprzez nasz system monitoringu. Taka potrzeba pojawia się wtedy, gdy chcemy zintegrować nasz system monitoringu z już istniejącą aplikacją typu HP Open View, NMS, Tivoli.
op5 Monitor, Nagios w przypadku wykrycia nieprawidłowości wykonują powiadamianie email oraz SMS. Odpowiednie wiadomości są wysyłane poprzez uruchomienie lokalnego skryptu powiadomień. Naszym celem jest stworzenie analogicznej komendy, która wygeneruje zdarzenie SNMP zamiast wysyłki email. W typ celu w aplikacji musimy utworzyć odpowiednią metodę powiadomień SNMP.
Uruchamiane polecenia realizują typowy schemat powiadomień, czyli mogą przyjmować w parametrach makra i zmienne systemowe takie jak nazwę serwisu, status, czas wystąpienia itp. W naszym przykładzie obowiązkowymi parametrami jest adres monitorowanego urządzenia, status i opis. Komendy tworzymy dwie, dla obsługi hosta oraz jego serwisu. W komendzie na stałe podajemy adres stacji odbierającej komunikaty SNMP oraz ciąg znaków community dla poprawnej komunikacji.
Wysyłka komunikatów SNMP jest zgodna z standardem Nagios-MIB. Odpowiednia biblioteka jest do pobrania pod adresem:
https://sourceforge.net/projects/nagiosplug/files/
Pobrane biblioteki MIB powinny zostać załadowane na stacji odbierającej powiadomienia SNMP.
Utworzone komendy powiadomień na razie nie są jeszcze aktywne. W kolejnym kroku przyporządkujemy je do użytkownika po stronie op5/nagios.
Od tego momentu posiadamy użytkownika, który dodany do metod hosta będzie uruchamiał odpowiednie skrypty generowania SNMP traps. Ostatnim krokiem jest utworzenie konkretnych skryptów realizujących wysyłkę.
Wywołanie komendy snmptrap z odpowiednimi zmiennymi.
-v - wersja snmp
-c - ciąg znaków community
$1 - stacja do zarządzania SNMP Trap pod adresem IP lub nazwa hosta
W kolejnych dwóch apostrofach określone są znaki specjalne reprezentujące część wiadomość trap.
Dane wynikowe po uruchomieniu polecenia snmptramp zapisywane są z aktualnym czasem pracy systemu wytwarzającego wiadomości trap.
Nagios-notify-MIB są to nazwy modułów w bibliotece MIB. Natomiast nSvcEvent/nHostEvent jest definicją wiadomość trap, która jest wysyłana w momencie błędu. Połączeniem obu tych elementów tworzy zaawansowany ciąg znaków OID.
Ostatnim parametrem komendy snmptrap jest określenie listy indywidualnych OID – uzyskane w ten sposób dane dołączane są do generowanej wiadomość trap. Wiadomość tworzona jest z poszczególnych elementów w kolejności: nazwa hosta, opis usługi, numer identyfikacyjny hosta/usługi w postaci numerycznej oraz stan sprawdzenia hosta czy usługi.
Wprowadzane wartości składają się z wielu znaków, żeby uniknąć błędu należy zapisać je w cudzysłowie.
Oba scenariusze są intuicyjną i standardową funkcją monitoringu. Zdarza się jednak, że chcemy aby zdarzenia SNMP były generowane również poprzez nasz system monitoringu. Taka potrzeba pojawia się wtedy, gdy chcemy zintegrować nasz system monitoringu z już istniejącą aplikacją typu HP Open View, NMS, Tivoli.
op5 Monitor, Nagios w przypadku wykrycia nieprawidłowości wykonują powiadamianie email oraz SMS. Odpowiednie wiadomości są wysyłane poprzez uruchomienie lokalnego skryptu powiadomień. Naszym celem jest stworzenie analogicznej komendy, która wygeneruje zdarzenie SNMP zamiast wysyłki email. W typ celu w aplikacji musimy utworzyć odpowiednią metodę powiadomień SNMP.
KOD: ZAZNACZ CAŁY
Code:
# 'send-service-trap' command definition
define command{
command_name send-service-trap
command_line $USER1$/send-service-trap manager public "$HOSTNAME$" "$SERVICEDESC$" $SERVICESTATEID$ "$SERVICEOUTPUT$"
}
KOD: ZAZNACZ CAŁY
Code:
# 'send-host-trap' command definition
define command{
command_name send-host-trap
command_line $USER1$/send-host-trap manager public "$HOSTNAME$" $HOSTSTATEID$ "$HOSTOUTPUT$"
}
Uruchamiane polecenia realizują typowy schemat powiadomień, czyli mogą przyjmować w parametrach makra i zmienne systemowe takie jak nazwę serwisu, status, czas wystąpienia itp. W naszym przykładzie obowiązkowymi parametrami jest adres monitorowanego urządzenia, status i opis. Komendy tworzymy dwie, dla obsługi hosta oraz jego serwisu. W komendzie na stałe podajemy adres stacji odbierającej komunikaty SNMP oraz ciąg znaków community dla poprawnej komunikacji.
Wysyłka komunikatów SNMP jest zgodna z standardem Nagios-MIB. Odpowiednia biblioteka jest do pobrania pod adresem:
https://sourceforge.net/projects/nagiosplug/files/
Pobrane biblioteki MIB powinny zostać załadowane na stacji odbierającej powiadomienia SNMP.
Utworzone komendy powiadomień na razie nie są jeszcze aktywne. W kolejnym kroku przyporządkujemy je do użytkownika po stronie op5/nagios.
KOD: ZAZNACZ CAŁY
Code:
define contact{
contact_name SNMPtrap
use generic-contact
alias SNMPtrap
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands send-service-trap
host_notification_commands send-host-trap
}
Od tego momentu posiadamy użytkownika, który dodany do metod hosta będzie uruchamiał odpowiednie skrypty generowania SNMP traps. Ostatnim krokiem jest utworzenie konkretnych skryptów realizujących wysyłkę.
KOD: ZAZNACZ CAŁY
Code:
===/usr/local/bin/send-service-trap ====
# Arguments:
# $1 = Management Station
# $2 = Community String
# $3 = host_name
# $4 = service_description (Description of the service)
# $5 = return_code (An integer that determines the state
# of the service check, 0=OK, 1=WARNING, 2=CRITICAL,
# 3=UNKNOWN).
# $6 = plugin_output (A text string that should be used
# as the plugin output for the service check)
#
/usr/bin/snmptrap -v 2c -c $2 $1 '' NAGIOS-NOTIFY-MIB::nSvcEvent nSvcHostname s "$3" nSvcDesc s "$4" nSvcStateID i $5 nSvcOutput s "$6"
KOD: ZAZNACZ CAŁY
Code:
===/usr/local/bin/send-host-trap=======
# Arguments:
# $1 = Management Station
# $2 = Community String
# $3 = host_name
# $4 = HostStatID A number that corresponds to the current state of the host: 0=UP, 1=DOWN, 2=UNREACHABLE.
# $5 = HOSTOUTPUT The first line of text output from the last host check (i.e. "Ping OK").
#
#
/usr/bin/snmptrap -v 2c -c $2 $1 '' NAGIOS-NOTIFY-MIB::nHostEvent nHostname s "$3" nHostStateID i $4 nHostOutput s "$5"
Wywołanie komendy snmptrap z odpowiednimi zmiennymi.
-v - wersja snmp
-c - ciąg znaków community
$1 - stacja do zarządzania SNMP Trap pod adresem IP lub nazwa hosta
W kolejnych dwóch apostrofach określone są znaki specjalne reprezentujące część wiadomość trap.
Dane wynikowe po uruchomieniu polecenia snmptramp zapisywane są z aktualnym czasem pracy systemu wytwarzającego wiadomości trap.
Nagios-notify-MIB są to nazwy modułów w bibliotece MIB. Natomiast nSvcEvent/nHostEvent jest definicją wiadomość trap, która jest wysyłana w momencie błędu. Połączeniem obu tych elementów tworzy zaawansowany ciąg znaków OID.
KOD: ZAZNACZ CAŁY
Code:
Nagios-notify-MIB::nSvcEvent
Nagios-notfy-MIB::nHostEvent
Ostatnim parametrem komendy snmptrap jest określenie listy indywidualnych OID – uzyskane w ten sposób dane dołączane są do generowanej wiadomość trap. Wiadomość tworzona jest z poszczególnych elementów w kolejności: nazwa hosta, opis usługi, numer identyfikacyjny hosta/usługi w postaci numerycznej oraz stan sprawdzenia hosta czy usługi.
Wprowadzane wartości składają się z wielu znaków, żeby uniknąć błędu należy zapisać je w cudzysłowie.