Makra w nagiosie i jego pochodnych

[ArturB]

Każdy kto bliżej przyjrzał się projektowi nagios prędzej czy później uświadomi sobie że makra są silnym elementem tego systemu monitorowania.
Makr można używać w sprawdzeniach, notyfikacjach, obsłudze zdarzeń. Ze względu na zasięg możemy podzielić na makra dostępne w obrębie:
a) hosta

KOD: ZAZNACZ CAŁY

Code:

np. $HOSTADDRESS$ $HOSTSTATE$ $HOSTNAME $HOSTGROUPSNAME$ $HOSTPERFDATA$ $HOSTOUTPUT$ etc.

b) grupy hostów

KOD: ZAZNACZ CAŁY

Code:

$HOSTGROUPALIAS$ $HOSTGROUPMEMBERS$ $HOSTGROUPNOTES$ $HOSTGROUPNOTESURL$ $HOSTGROUPACTIONURL$

c) serwisu - niedostępne z poziomu hosta z oczywistych przyczyn

KOD: ZAZNACZ CAŁY

Code:

np. $SERVICESTATE$ $SERVICEDESC$ $SERVICEGROUPNAMES$ $SERVICEPERFDATA$ $SERVICEOUTPUT$ etc.

d) grupy serwisów

KOD: ZAZNACZ CAŁY

Code:

$HOSTGROUPALIAS$ $HOSTGROUPMEMBERS$ $HOSTGROUPNOTES$ $HOSTGROUPNOTESURL$ $HOSTGROUPACTIONURL$

e) kontaktu (dostępne tylko w notyfikacjach)

KOD: ZAZNACZ CAŁY

Code:

$CONTACTNAME$ $CONTACTALIAS$ $CONTACTEMAIL$ $CONTACTPAGER$ $CONTACTADRRESSn$

f) grupy kontaktów

KOD: ZAZNACZ CAŁY

Code:

$CONTACTGROUPALIAS$ $CONTACTGROUPMEMBERS$

e) globalne

KOD: ZAZNACZ CAŁY

Code:

np $TOTALHOSTUP$ $TOTALHOSTDOWN$ $TOTALSERVICEOK$ $TOTALSERVICESWARNING$ $TOTALSERVICESCRITICAL$ $TOTALSERVICESUNKNOWN$ $DATE$ $TIME$ $TIMET$ $MAINCONFIGFILE$ $STATUSDATAFILE$ $TEMPFILE$ $LOGFILE$ $HOSTPERFDATAFILE$ $SERVICEPERFDATAFILE$ etc.

f) notyfikacji

KOD: ZAZNACZ CAŁY

Code:

$NOTIFICATIONTYPE$ $NOTIFICATIONRECIPIENTS$

g) użytkownika

KOD: ZAZNACZ CAŁY

Code:

$ARGn$ $USERn$ tzw. CUSTOMVARIABLE

Pełną listę możemy znaleźć np na nagios.sourceforge.net/docs/3_0/macrolist.html.

To co warto zauważyć w tym momencie, to to że np możemy przesłać do serwisu informację w jakim stanie znajduje się host, do jakich hostgroup należy, jaki jest stan naszego systemu, a także jaki był jego poprzedni stan, w tym np. poprzednia wartość liczbowa jakiegoś sprawdzenia (output, perfdata).
Nie da się ukryć że pozwala to na wiele, np na sprawdzenia przyrostowe. Jako takowy przykład możemy podać np. liczbę błędów na interfejsie sieciowym, znając czas i wartość bezwzględną poprzedniego sprawdzenia możemy w przybliżeniu wyliczyć wartość np na 60s i taka wartość jest nam bardziej pomocna niż liczba bezwzględna.

Skupmy się jednak na ostatniej grupie makr - makr użytkownika.
Z $ARGn$ spotkał się chyba każdy już przy pierwszym kontakcie z nagiosem. To jest po prostu n'ty argument przekazywany do komendy sprawdzenia (niezależnie czy hosta czy serwisu). Nagios wspiera do 32 argumentów.
$USERn$ również powinna rzucić się w oczy ponieważ w $USER1$ zwykle widujemy domyślny katalog pluginów naszego systemu monitorowania. Znajdują się one zwykle w pliku resource.cfg. Jakie zastosowanie możemy sobie wyobrazić? Pomysłów pewnie jest tyle ile użytkowników, mogą to być ścieżki konfiguracyjne dla wtyczek, pliki haseł, albo nawet same hasła. Gdzie możemy z nich skorzystać? Jako command_arg, w definicji komendy. Nie możemy natomiast przypisać ich wartość do tzw. CUSTOM VARIABLES
Ten typ macr jest moim zdaniem najfajniejszy. Możemy np w konfiguracji hosta dopisać linię
_ZMIENNA WARTOSC, a później w obrębie hosta (i jego serwisów) odwoływać się do wartości za pomocą $_HOSTZMIENNA$, podobnie w przypadku serwisów ($_SERVICEZMIENNA$) i kontaktu $_CONTACTZMIENNA$. Dlaczego warto z nich korzystać?
1. Jako progi wywołania mamy czytelniejszy niż w przypadku command_arg sposób ich zapisu.
2. Jako dodatkowe pola definiujące np osobę odpowiedzialną, numer inwentarzowy, lokalizację - możemy ich używać w powiadomieniach.

Możemy je wpisywać do command_arg, chociaż prywatnie wolę zastępować w definicji komendy $ARGn$ na customy.

Dodatkową niewątpliwą zaletą w przypadku op5 Monitora jest łatwość propagacji takiej zmiennej. Możemy sobie przecież wyobrazić sytuację w której na jakiejś grupie serwisów chcemy zmienić tylko jeden parametr (np imię i nazwisko osoby kontaktowej), a pozostałe pozostawić dla nich różne. Propagacja command_arg w całości nie wchodzi wtedy w grę.