Każdy klient w pewnym momencie chce zakończyć wdrożenie i zacząć samodzielnie utrzymywać, dostrajać i rozwijać swój system. Z tego powodu otrzymujemy szereg niewinnych pytań, które można by streścić w jednym - jak napisać wtyczkę do op5/nagiosa?
Na samym początku powinniśmy wybrać technologię, a jeszcze wcześniej zastanowić się gdzie ta wtyczka ma się uruchomić - na serwerze monitoringu, czy może na monitorowanej maszynie...
W końcu jeśli ma się wykonać po stronie agenta NRPE (Nagios Remote Plugin Executor), wybranie np. Javy albo PHP może okazać się bardzo złym wyborem, ze względu na potrzebę instalacji dodatkowych pakietów na wielu maszynach.
Moim osobistym zdaniem dobrze jest oprzeć się na językach interpretowanych. W końcu na każdej nowożytnej maszynie znajdzie się bash (ewentualnie ksh), perl również nie powinien być niczym obcym.
Kilka zasadniczych pytań to:
1) jak to się dzieje że stawiamy basha, perla, php czy javę obok siebie
2) skąd op5/nagios wie czy "lampka" ma się świecić na zielono, żółto, czerwono, czy pomarańczowo
3) jak ustalić co pojawi się w outpucie
4) jak standardowo powinniśmy postąpić żeby dane dobrze rysowały się na wykresie w pnp4nagios
Odpowiedzi są dość proste:
1) scheduler nagiosa jest bardzo ciekawym i wydajnym rozwiązaniem. Każdy wykonywany proces to tak naprawdę komenda wysyłana do systemu. Nie weryfikujemy czy wykonywany plik jest skompilowany, czy to skrypt...
2) o statusie decyduje kod zwracany do systemu (w c/c++ będzie to return funkcji main(), w bashu czy php exit <kod>...) - przyjęto że 0 to stan "OK", czyli poprawna praca monitorowanego parametru, 1 to stan "WARNING", 2 to stan "CRITICAL, a 3 - "UNKNOWN".
3) output brany do nagiosa to standardowe wyjście (wyjście błędów jest ignorowane). Sam output powinien być formatu "Status Information | Performance Data". Pierwszy element, "Status Information", będzie widoczny w op5 czy nagiosie w kolumnie obok serwisów, drugi posłuży nam do zbierania danych w plikach rrd a następnie generowaniu wykresów.
4) o ile w przypadku Status Information dobrze jest zacząć od OK, WARNING, CRITICAL, UNKNOWN... (ale nie jest to wymagane) np.
, to w performance data standardowo powinniśmy postąpić tak:
czyli
Czyli całe wyjście z programu/skryptu:
Mały akademicki przykład:
Dodajmy komendę do op5 i stwórzmy kilka serwisów.
ten sam przykład w innych językach:
Na samym początku powinniśmy wybrać technologię, a jeszcze wcześniej zastanowić się gdzie ta wtyczka ma się uruchomić - na serwerze monitoringu, czy może na monitorowanej maszynie...
W końcu jeśli ma się wykonać po stronie agenta NRPE (Nagios Remote Plugin Executor), wybranie np. Javy albo PHP może okazać się bardzo złym wyborem, ze względu na potrzebę instalacji dodatkowych pakietów na wielu maszynach.
Moim osobistym zdaniem dobrze jest oprzeć się na językach interpretowanych. W końcu na każdej nowożytnej maszynie znajdzie się bash (ewentualnie ksh), perl również nie powinien być niczym obcym.
Kilka zasadniczych pytań to:
1) jak to się dzieje że stawiamy basha, perla, php czy javę obok siebie
2) skąd op5/nagios wie czy "lampka" ma się świecić na zielono, żółto, czerwono, czy pomarańczowo
3) jak ustalić co pojawi się w outpucie
4) jak standardowo powinniśmy postąpić żeby dane dobrze rysowały się na wykresie w pnp4nagios
Odpowiedzi są dość proste:
1) scheduler nagiosa jest bardzo ciekawym i wydajnym rozwiązaniem. Każdy wykonywany proces to tak naprawdę komenda wysyłana do systemu. Nie weryfikujemy czy wykonywany plik jest skompilowany, czy to skrypt...
2) o statusie decyduje kod zwracany do systemu (w c/c++ będzie to return funkcji main(), w bashu czy php exit <kod>...) - przyjęto że 0 to stan "OK", czyli poprawna praca monitorowanego parametru, 1 to stan "WARNING", 2 to stan "CRITICAL, a 3 - "UNKNOWN".
3) output brany do nagiosa to standardowe wyjście (wyjście błędów jest ignorowane). Sam output powinien być formatu "Status Information | Performance Data". Pierwszy element, "Status Information", będzie widoczny w op5 czy nagiosie w kolumnie obok serwisów, drugi posłuży nam do zbierania danych w plikach rrd a następnie generowaniu wykresów.
4) o ile w przypadku Status Information dobrze jest zacząć od OK, WARNING, CRITICAL, UNKNOWN... (ale nie jest to wymagane) np.
KOD: ZAZNACZ CAŁY
Code:
OK - Connected users 5
, to w performance data standardowo powinniśmy postąpić tak:
KOD: ZAZNACZ CAŁY
Code:
users=5;10;12;0;15 active=3;5;7;0;12
czyli
KOD: ZAZNACZ CAŁY
Code:
etykieta=wartość;próg warning;próg critical;minimalna wartość na osi y wykresu;maksymalna wartość na osi y wykresu
Czyli całe wyjście z programu/skryptu:
KOD: ZAZNACZ CAŁY
Code:
OK - Connected users 5|users=5;10;12;0;15 active=3;5;7;0;12
Mały akademicki przykład:
KOD: ZAZNACZ CAŁY
Code:
#!/bin/bash
if [ $# -ne 1 ];then
echo "Usage: $0 <RETURN_CODE>";
exit 3;
fi
case $1 in
0) echo "OK"; exit 0;;
1) echo "WARNING"; exit 1;;
2) echo "CRITICAL"; exit 2;;
*) echo "UNKNOWN"; exit 3;;
esac;
Dodajmy komendę do op5 i stwórzmy kilka serwisów.
ten sam przykład w innych językach:
KOD: ZAZNACZ CAŁY
Code:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv){
int value;
if (argc!=2){
printf ("Usage: %s <RETURN_CODE>\n", argv[0]);
return 3;
}
value=atoi(argv[1]);
switch(value){
case 0:
printf("OK\n");
return 0;
break;
case 1:
printf("WARNING\n");
return 1;
break;
case 2:
printf("CRITICAL\n");
return 2;
break;
default:
printf("UNKNOWN\n");
return 3;
}
}
KOD: ZAZNACZ CAŁY
Code:
<?php
if ($argc != 2 ){
echo "Usage: php $argv[0] <RETURN_CODE>";
exit(3);
}
switch($argv[1]){
case 0:
echo "OK";
exit(0);
break;
case 1:
echo "WARNING";
exit(1);
break;
case 2:
echo "CRITICAL";
exit(2);