RSS Feed

Konfiguracja Nagiosa – dziedziczenie

Kwiecień 18, 2011 by 0verlord

W sumie, to takie HOWTO, ale nie HOWTO, bo jednak podstawową wiedzę o Nagiosie trzeba mieć, to taki esej o możliwościach konfiguracji Nagiosa. Tym razem będzie o dziedziczeniu i zmiennych.

Po pierwsze: dziedziczenie.

Nagios zapewnia całkiem ciekawe możliwości dziedziczenia. Każdy, kto zapoznał się z podstawami templatek (dyrektywa use), wie, że pomiędzy różnymi częściami konfiga można przekazywać wiele parametrów. Dokumentacja o tym nie wspomina, ale można je także nadpisywać. Na przykład:

definiujemy templatkę ogólną hosta, nic szczególnego, żywcem wyjęta z dokumentacji:
define host{
name generic-host ; The name of this host template
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
check_command check_ping!120.0,15%!300.0,60%
max_check_attempts 10
notification_interval 0
notification_period 24x7
notification_options d,u,r
contact_groups admins
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
}

a potem hosta:

define host{
use generic-host
host_name mojhost.pl
alias alias
address 1.2.3.4
parents gateway
contact_groups admini,mroczniadmini
}

Ogólnie dokumentacja mówi o takich szablonach bardziej jako o sposobie, żeby nie w kółko nie pisać tych samych kawałków konfiga i tych samych dyrektyw. Ale sam mechanizm jest bardziej mroczny i przydatny. Jeżeli w templatce zdefiniujemy jakąś dyrektywę, ale jakiś host powinien mieć którąś opcję zdefiniowaną inaczej, można ją nadpisać. Na przykład tak:

define host{
use generic-host
host_name mojhost.pl
alias alias
address 1.2.3.4
parents gateway
max_check_attempts 20
contact_groups admini,mroczniadmini
}

W tym przypadku, nadpisujemy max_check_attempts. Gdybyśmy tego nie zdefiniowali, obiekt odziedziczyłby predefiniowaną wartość max_check_attempts 10 z definicji templatki (use generic-host.
To jest proste, zapewne intuicyjnie wiele razy korzystaliście z takiego sposobu – teraz będziecie robić to świadomie ;-).

Po drugie: zmienne.

Ten mechanizm można także wykorzystać do przekazywania i nadpisywania zmiennych. W dokumentacji są to custom object variables.
Poniżej opiszę, jak przekazać community snmp i jednocześnie zachować możliwość nadpisania go dla dowolnego hosta.

Weźmy np. taką, uproszczoną do minimum, templatkę:
define host {
name generic-host
register 0 # to templatka, więc 0
_snmp_community blabla
}

i hosta wykorzystującego tą templatkę:

define host {
host_name testowy
use generic-host
_snmp_community bleble
}

I teraz, gdzie tutaj sztuczka magiczna?
Ogólnie mamy dwa razy zdefiniowaną zmienną, _snmp_community (w Nagiosie każda wartość zaczynająca się od podkreślenia, _ to zmienna). Według zasad dziedziczenia ta, która została zdefiniowana ostatnia – wygrywa. Czyli nasz host ma ustawioną zmienną na bleble, a jeżeli nie nadpiszemy tej zmiennej – zostanie blabla. Ayt? 🙂 Tylko jak to teraz wstawić do definicji serwisu?

Żeby uniknąć duplikacji zmiennych, Nagios automatycznie dodaje każdej prefix, w zależności od miejsca zdefiniowania. _HOST, _SERVICE i _CONTACT, czyli naszą zmienną _snmp_community, możemy w dowolnym innym miejscu konfiga odczytać jako $_HOSTSNMP_COMMUNITY$. Oczywiście trzeba uważać, żeby sobie tej zmiennej nie nadpisać w innym miejscu tej samej sekcji.

Czyli teraz bierzemy definicję serwisu wykorzystującego community snmp, np. taką, i zamiast wpisywać do check_command po prostu community, wstawiamy tam naszą zmienną, np. tak jak w przykładzie poniżej:

define service {
host mojhost
service_description snmp-uptime
display_name SNMP System uptime
check_command check_system_uptime!$_HOSTSNMP_COMMUNITY$
use generic-service
notification_interval 0 ;
}

W ten sposób ustawiamy community dla hosta tam, gdzie to wynika ze zdrowego rozsądku, tj. w definicji hosta, a serwisy już automagicznie biorą właściwą wartość.

W następnych postach pokażę jeszcze kilka sztuczek optymalizacyjnych i organizacyjnych, np. jak optymalnie wykorzystać hostgroupsy.


Brak komentarzy »

No comments yet.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

− osiem = jeden