Rozpatrzmy przypadek ruchu sieciowego przechodzącego przez jedną z maszyn. Wykres poniżej:

Jak widać w nocy ruch jest mniejszy, a godziny szczytu przypadają na 10.00 – 16.00.
Standardowo mamy więc następujące możliwości:
a) określić wartości minimalną (noc) i maksymalną (dzień) – np. na podstawie wcześniejszych obserwacji w Cacti i użyć ich jako progów; w tym przypadku byłoby to jakoś 0 – 16 Mbps; wadą takiego rozwiązania jest to, że wykluczymy wiele anomalii – co w przypadku gdy ruch nocny wzrośnie do 10 Mbps lub w dzień spadnie do zera? nic – nie zostaniemy o tym fakcie powiadomieni,
b) dopisać usługę do konfiguracji kilka razy, za każdym razem podając inne progi dla ostrzeżenia i alarmu i inne godziny monitorowania; obejście dobre, w powyższym przykładzie można wyróżnić 3 – 4 takie okresy; wada – im bardziej zróżnicowany wykres, tym więcej konfiguracji, nie mówiąc o problemach z późniejszymi zmianami.

Niestety nie podam ogólnych lepszych rozwiązań, bo ich nie znam, ale za to chętnie poznam Wasze sposoby na okiełznanie tego tematu.

Wiem natomiast jak poradzić sobie z tym problemem jeśli monitorujemy bazę (dane w bazie) Oracle za pomocą wtyczki check_oracle_health od ConSol Labs (lub SQL Server wtyczką check_mssql_health; pozostałe dwie – check_mysql_health i check_db2_health nie mają tej funkcjonalności).

W sierpniu zeszłego roku (wersja wtyczki 1.6.6) pojawił się przełącznik dbthresholds. Dodanie go przy wywołaniu skryptu powoduje, że robione jest dodatkowe zapytanie do tabeli check_oracle_health_thresholds. Struktura dość prosta (Oracle):

pluginmode varchar2(32)
name varchar2(32) NULL
warning varchar2(8) NULL
critical varchar2(8) NULL

No to krótki opis co w której kolumnie powinno się znaleźć:

• pluginmode – to co w --mode podczas wywołania,
• name – to co w name2 jeśli jest lub w name (chyba tylko pierwszy wyraz) lub jako wartość parametru dbthresholds; nie pamiętam kolejności sprawdzania,
• warning – progi dla ostrzeżenia,
• critical – progi dla błędu.

Oczywiście gdyby wtyczka miała pełną obsługę zakresów byłoby już całkiem fajnie. Niemniej to co jest daje spore możliwości.
Po pierwsze sztywną tabelę zamieńmy na widok, a wtyczkę przeróbmy tak:

--- /usr/lib/nagios/plugins/check_oracle_health 2011-09-12 08:06:23.000000000 +0200
+++ /tmp/check_oracle_health 2011-09-20 12:03:04.000000000 +0200
@@ -4225,6 +4225,9 @@ sub set_global_db_thresholds {
if ($self->{handle}->fetchrow_array(q{
SELECT table_name FROM user_tables
WHERE table_name = 'CHECK_ORACLE_HEALTH_THRESHOLDS'
+ UNION
+ SELECT view_name FROM user_views
+ WHERE view_name = 'CHECK_ORACLE_HEALTH_THRESHOLDS'
})) {
my @dbthresholds = $self->{handle}->fetchall_array(q{
SELECT * FROM check_oracle_health_thresholds

W tabeli można dodać dowolne kolumny – ja dodałem dzień tygodnia i godzinę, a widok tworzę z podaniem odpowiedniego warunku:

CREATE OR REPLACE FORCE VIEW "NAGIOS"."CHECK_ORACLE_HEALTH_THRESHOLDS" ("PLUGINMODE", "NAME", "WARNING", "CRITICAL") AS
SELECT pluginmode, name, warning, critical FROM nagios.t_check_oracle_health_threshol WHERE hour = TO_CHAR(SYSDATE, 'HH24') AND dayOfWeek = TO_CHAR(SYSDATE, 'D')

Tym samym danych w tabeli mogę mieć ile chcę, a dla Nagios będzie serwowana tylko porcja odpowiadająca aktualnej godzinie w konkretny dzień tygodnia. A to oznacza, że jeśli o trzeciej w nocy spodziewamy się ruchu do 2 Mbps, to dostaniemy alarm, gdy dojdzie do 25 Mbps.

Monitorując temperaturę w serwerowni raczej mamy stałe zakresy, ale sprawdzając wysycenie łącza, ilość procesów czy zalogowanych użytkowników dynamicznie zmieniające się zakresy mogą nam jeszcze bardziej pomóc.

Życzę sukcesów w przerabianiu swoich wtyczek.

--- /usr/lib/nagios/plugins/check_oracle_health 2011-09-12 08:06:23.000000000 +0200
+++ /tmp/check_oracle_health    2011-09-22 10:13:32.000000000 +0200
@@ -4094,6 +4094,13 @@ sub check_thresholds {
# warning = 10, critical = 20, warn if > 10, crit if > 20
$level = $ERRORS{WARNING} if $value > $self->{warningrange};
$level = $ERRORS{CRITICAL} if $value > $self->{criticalrange};
+  } elsif ($self->{warningrange} =~ /(\d+):(\d+)/ &&
+      $self->{criticalrange} =~ /(\d+):(\d+)/) {
+    # warning = 78:84, critical = 70:90, warn if < 78 or > 84, crit if < 70 or > 90
+    $self->{warningrange} =~ /(\d+):(\d+)/;
+    $level = $ERRORS{WARNING} if $value < $1 || $value > $2;
+    $self->{criticalrange} =~ /(\d+):(\d+)/;
+    $level = $ERRORS{CRITICAL} if $value < $1 || $value > $2;
} elsif ($self->{warningrange} =~ /(\d+):/ &&
$self->{criticalrange} =~ /(\d+):/) {
# warning = 98:, critical = 95:, warn if < 98, crit if < 95

Nie jestem programistą Perl, jeśli da się to ‘upiększyć’, proszę o komentarz.
Oczywiście można pójść dalej (i zrobię to w wolnym czasie):

• Nagios plug-in development guidelines -> Plugin Output for Nagios -> Threshold and ranges

Mam pod opieką modele Sentry ST60 z modułem NetMan 101/102 plus. Moduł umożliwia odczyt niezbednych wartości przez prostą stronę WWW lub za pomocą protokołu SNMP. Oczywiscie dla Nagios lub Cacti przyda się ten drugi sposób.
Poniżej odpowiednie identyfikatory (OID) wraz z opisem i sposobem wykorzystania.

• .1.3.6.1.2.1.33.1.2.3.0 szacowany czas podtrzymania (w minutach)
• .1.3.6.1.2.1.33.1.2.4.0 naładowanie baterii w procentach
• .1.3.6.1.2.1.33.1.2.5.0 napięcie baterii (dziesięciokrotność)
• .1.3.6.1.2.1.33.1.2.7.0 temperatura pracy urządzenia
• .1.3.6.1.2.1.33.1.3.3.1.2.1 częstotliwość napięcia wejściowego, pierwsza faza (dziesięciokrotność)
• .1.3.6.1.2.1.33.1.3.3.1.2.2 częstotliwość napięcia wejściowego, druga faza (dziesięciokrotność)
• .1.3.6.1.2.1.33.1.3.3.1.2.3 częstotliwość napięcia wejściowego, trzecia faza (dziesięciokrotność)
• .1.3.6.1.2.1.33.1.3.3.1.3.1 napięcie wejściowe, pierwsza faza
• .1.3.6.1.2.1.33.1.3.3.1.3.2 napięcie wejściowe, druga faza
• .1.3.6.1.2.1.33.1.3.3.1.3.3 napięcie wejściowe, trzecia faza
• .1.3.6.1.2.1.33.1.4.2.0 częstotliwość napięcia wyjściowego (dziesięciokrotność)
• .1.3.6.1.2.1.33.1.4.4.1.2.1 napięcie wyjściowe, pierwsza faza
• .1.3.6.1.2.1.33.1.4.4.1.2.2 napięcie wyjściowe, druga faza
• .1.3.6.1.2.1.33.1.4.4.1.2.3 napięcie wyjściowe, trzecia faza
• .1.3.6.1.2.1.33.1.4.4.1.5.1 procentowe obciążenie wyjścia, pierwsza faza
• .1.3.6.1.2.1.33.1.4.4.1.5.2 procentowe obciążenie wyjścia, druga faza
• .1.3.6.1.2.1.33.1.4.4.1.5.3 procentowe obciążenie wyjścia, trzecia faza
• .1.3.6.1.2.1.33.1.5.1.0 częstotliwość bajpasu (dziesięciokrotność)
• .1.3.6.1.2.1.33.1.5.3.1.2.1 napięcie bajpasu, faza pierwsza
• .1.3.6.1.2.1.33.1.5.3.1.2.2 napięcie bajpasu, faza pierwsza
• .1.3.6.1.2.1.33.1.5.3.1.2.3 napięcie bajpasu, faza pierwsza

Dołączenie szacowanego czasu podtrzymania i temperatury pracy urządzenia do konfiguracji Nagios:

define command{
command_name check_snmp
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -C $ARG2$ -P $ARG3$ $ARG4$
}

define service {
use generic-service
host_name UPS
service_description UPS Autonomy Time
check_command check_snmp!mib-2.33.1.2.3.0!public!2c!-w 15:9999 -c 2:9999
}

define service {
use generic-service
host_name UPS
service_description UPS Temperature
check_command check_snmp!mib-2.33.1.2.7.0!public!2c!-w 20:25 -c 15:32
}

Monitorowanie czasu podtrzymania jest zrozumiałe, progi jakie ustawiłem, to 15 min dla ostrzeżenia i 2 minuty dla błędu krytycznego. Poniżej tego czasu generator, z którym współpracują może nie być w stanie się uruchomić. Oczywiście te parametry trzeba dopasować do swojej struktury. Należy pamiętać, że ta wartość to szacowany czas na podstawie obciążenia w momencie pomiaru.

Jeśli chodzi o temperaturę, to odczyt z tego OID da nam przybliżoną wartość dla okolic urządzenia, gdzie zazwyczaj stoją baterie, których to producenci zalecają 20 – 22 stopni Celsjusza. Naturalnie można to sprawdzać innym urządzeniem, ale skoro producent zamontował czujnik w UPS, to czemu by z niego nie skorzystać.
Temperatura ma duży wpływ na żywotność ogniw, więc warto utrzymywać ją w odpowiednim zakresie i zapewnić wentylację pomieszczenia, w którym się znajdują.
Organizacja ASHARE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) wydała dokument pt. Thermal Guidelines for Data Processing Environments, w którym opisane są warunki, jakie powinny panować m. in. w serwerowni. Esencja z niego została zawarta w polskojęzycznym artykule, który na swojej stronie prezentuje firma EP&M.

Na początek dokumentacja do przejrzenia:

• Icinga Quickstart
• docs/en/quickstart-icinga.html

Dodanie użytkownika icinga-cmd do właściwej grupy:

/usr/sbin/usermod -a -G icinga-cmd lighttpd

Kompilacja i instalacja:

make cgis
make install-cgis
make install-html
mkdir -p /etc/httpd/conf.d
make install-webconf (/etc/httpd/conf.d)

Hasło do zasobu:

htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin (app-admin/apache-tools)

I tu skończyłem notowanie. Nie wiem czy dalej coś specjalnego robiłem, żeby uruchomić ten system (być może dostosowanie konfiguracji Lighttpd).

OK - tbs SOMETBL usage is 2.24% | 'tbs_sometbl_usage_pct'=2.24%;90;98 'tbs_sometbl_usage'=752590MB;30198988;32883343;0;33554431 'tbs_sometbl_alloc'=778240MB;;;0;33554431

Zaalokować możemy 778’240 MB, zajęte mamy już 752’590 MB, ale procentowa zajętość to 2,24 %? Otóż zapytanie formatując wynik bierze pod uwagę również kolumnę autoextensible i maxbytes z dba_data_files. Jeśli przestrzeń może się rozszerzać, to do 32 GB dla każdego pliku danych (lub 32 TB w przypadku bigfile tablespace) i to właśnie jest 100% – nawet niezależnie od tego czy mamy miejsce na dysku czy nie.
Pytanie podobne często pojawia się na forum (i w komentarzach przy dodatku), więc wymaga wyjaśnienia. Ja sam też się nad nim jakiś czas zastanawiałem – stąd w ogóle ten wpis.

Co zrobić, jeśli jednak chcemy zignorować autoextensible? Powodem może być problem z wydajnością bazy podczas rozszerzania, bo zazwyczaj trafi to w najmniej oczekiwanym momencie (w godzinach największego obciążenia). Najprościej zmodyfikować zapytanie. Zaczyna się od linii 2693, a właściwy wiersz to 2710:

SUM(DECODE(a.autoextensible, 'YES', a.maxbytes, 'NO', a.bytes)) maxbytes

Zmieniona postać może wyglądać po prostu tak:

SUM(a.bytes) maxbytes

Fajnie, jakby był do tego mimo wszystko jakiś przełącznik. A może jest… Powyższe dotyczy wersji 9.x i nowszych. Dla Oracle 8.x (DBD::Oracle::Server::return_first_server()->version_is_minimum("8.x")), odpowiednia linia to 2793. Wcześniejsze wersje nie są testowane w ten sposób.

Sprawdzając zajętość w oparciu o możliwość rozszerzania wymaga, by kontrolowane było również miejsce na dyskach. Czasami jednak gdy zasoby są przeznaczone tylko dla bazy, dyski są wypełnione blisko 100%, więc automatyczne rozszerzanie nie zadziała, a tym samym nie dostaniemy żadnego ostrzeżenia przed wystąpieniem problemu.

1. Bezpieczeństwo: katalog z wynikami

Katalog z wynikami testów nie powinien być dostępny dla nikogo poza użytkownikiem, z którego prawami uruchomiony jest Nagios. To są wrażliwe informacje tak jak konfiguracja całego systemu. Zadbaj o nie.

2. Bezpieczeństwo: uwierzytelnianie CGI

Dostęp do konfiguracji, wyników testów i struktury sieci dla napastnika, to spore ułatwienie w przygotowaniu ataku. Dostęp przez przeglądarkę to coś więcej niż ładne tabelki i wykresy.

3. Bezpieczeństwo: pełne ścieżki w nazwach komend

Jeśli chcemy mieć pewność, że uruchamiamy właściwy skrypt / program przy wykonywaniu testów, podajmy w konfiguracji (commands.cfg) pełne ścieżki.

4. Bezpieczeństwo: zabezpieczony dostęp do agentów

Jeśli na monitorowanych serwerach używamy agentów (NRPE, NSClient, SNMP), ograniczmy do nich dostęp. Komunikacja odbywa się z wykorzystaniem SSL (wyłączając SNMP), ale bez uwierzytelniania przy pomocy użytkownika i hasła.

5. Testy aktywne (active checks) vs. pasywne (passive)

Aktywny test wykonywany jest przez system Nagios + odpowiedni plugin. Test pasywny wykonuje zewnętrzny program, a swój wynik dostarcza do Nagios. W dużych środowiskach może to mieć wpływ na wydajność i zalecane jest sprawdzanie pasywne.

6. Jeśli uda się naprawić problem, zawsze zostaniemy o tym powiadomieni

Jeśli dostaliśmy komunikat [d]own, niezależnie od schematu czasowego po naprawie usterki dostaniemy [r]ecovery.

7. Częste zmiany stanu

Zmieniające się stany (state flapping) spowodowane są rzeczywistymi problemami monitorowanego środowiska lub błędną konfiguracją. Twórcy Nagios’a opracowali algorytm pomagający to wykrywać.

8. Jak informować

Dane wpisane w dyrektywach kontaktów, jak: email, pager, address[1-6], wykorzystywane są przez notification_command, więc to od nas zależy jak zostaną wykorzystane, ale podawajmy logiczne wartości, byśmy sami nie mieli problemów ze zorientowaniem się o co chodzi.

9. Poprawianie czytelności raz jeszcze

* (wszystko) i ! (negacja) skraca zapisy. Jeśli chcesz, możesz również użyć wyrażeń regularnych (use_regexp_matching).

10. Planowane wyłączenie usług

Jeśli planujesz wyłączenie serwera np. na czas czyszczenia czy aktualizacji oprogramowania, zaplanuj to. System nie będzie rozsyłał zbędnych raportów. Jeśli np. Twój ISP informuje Cię o czasowym odłączeniu od sieci, które jest niezbędne do przeprowadzenia konserwacji i zapewnia Cię, że nie potrwa to dłużej jak godzinę, sprawdź go.

11. Monitorowanie klastrów

Nagios wspiera monitorowanie klastrów (poprzez wtyczkę check_cluster). Klastrów w rozumieniu wielu serwerów świadczących tą samą usługę, na które jest rozkładany ruch (np. DNS czy bramy pocztowe). Test ten to nic innego jak sprawdzenie wyników testów usług na poszczególnych serwerach składowych. Jako progi dla ostrzeżeń i alarmów ustawiamy ilość składowych, które nie działają.

12. Połączenie z innym oprogramowaniem

Dzięki NDOUtils konfigurację Nagios możemy przechowywać w bazie MySQL. NDOUtils jest niezbędne przy wielu dodatkach.

13. Właściwe powiadamianie

Powiadamianie za pomocą poczty elektronicznej jest mało skuteczne. Zwłaszcza gdy awarii ulegnie serwer pocztowy lub ma zapchaną kolejkę. Nie zawsze jesteśmy też przy kliencie poczty, więc nie mamy możliwości odczytania wiadomości. Jeśli to możliwe, skorzystajmy z alternatywnego kanału komunikacji – np. SMS (pager chyba u nas jest mało popularny).
Wykorzystać też możemy dodatek do przeglądarki (np. Nagios checker), samodzielną mini-aplikację czy komunikator (np. gadu-gadu czy jabber).

14. Nagios to nie wszystko

Są ludzie, którzy narzekają na brak rozwoju Nagios lub prowadzenie prac w złym kierunku. Tacy ludzie robią odgałęzienia projektu (fork). Jednym z nich jest ICINGA. Ładniej wygląda, zapewnia kompatybilność konfiguracji i ma czytelniejszą mapę!

1. Nagios na osobnym serwerze tak, by nie zależał od środowiska, które monitoruje

To dość oczywiste, ale w czasach popularności wirtualizacji instalujemy system monitoringu gdzieś, gdzie da się go jeszcze upchnąć przydzielając minimum zasobów. System radzi sobie świetnie, bo wiele nie wymaga, ale czasami na wyniki jego testów mają wpływ inne maszyny wirtualne pracujące równolegle na tym samym hypervisor‘ze (I/O, sieć). Warto to wziąć pod uwagę instalując system.

2. Nie monitoruj tylko z wewnątrz, wykorzystaj ‘satelity’

Fakt, że serwer HTTP działa nie wystarcza, by spać spokojnie. Ważne jest też, by był dostępny dla klientów. Monitorowanie wewnątrz LAN / DMZ ma sens, ale jego uzupełnieniem powinno być monitorowanie z poza własnej sieci (tanie dodatkowe łącze od innego ISP, instalacja w oddziale firmy, VPS lub wzajemne sprawdzanie z zaprzyjaźnionym Sysadminem).

3. Ogólne ustawienia w szablonach (template), szczególne w host / service

Dla czytelności starajmy się części wspólne konfiguracji zawierać w szablonach. Natomiast szczególne dyrektywy umieszczajmy w blokach odpowiedzialnych za usługi i hosty. Jeśli to możliwe, stosuj wykluczenia (np. exclude w schematach czasowych).

4. Twórz konfigurację jeszcze bardziej czytelną

Przyporządkowanie np. hosta do grupy można zrobić na dwa sposoby – w definicji hosta (hostgroups) lub w definicji grupy (hosts). Pierwszy sposób zwiększy ilość linii w konfiguracji, ale pozwala jednoznacznie określić który host należy do której grupy. Dziś monitorujesz kilka składników, pomyśl co będzie jak będziesz monitorował kilkaset.

5. Grupuj podobne hosty / usługi

Jeśli na wielu maszynach sprawdzana jest ta sama usługa (chociażby najprostsze check_ping) wygodniej do definicji service dodać całą grupę (hostgroup_name), niż n hostów (host_name).

6. Nie używaj znaków specjalnych w nazwach

To działa, ale mogą być problemy. Nagios dokonuje powiązań właśnie po nazwach. Jeśli chcesz opisać usługę jako „Serwer WWW (dla klientów)” – użyj aliasów.

7. Sprawdź konfigurację wszystkich składników zanim zaczniesz pracę z Nagios

Sprawdź konfigurację po poprzednim administratorze, ale zajrzyj też do domyślnych ustawień. Widziałeś zapis „Linux admins hate to be woken up, so we only notify during the day” w szablonie linux-server?

8. Nie dręcz się zbytnio

Jeśli znasz swoją sieć, wyłącz komunikaty [u]nreachable. Każdy serwer za wyłączonym przełącznikiem jest nieosiągalny. Pamiętaj jednak, że naprawa takiego przełącznika ma wyższy priorytet.

9. Relacje vs. zależności

Nagios umożliwia definiowanie relacji (parent/child relationship) i zależności (dependencies). Te pierwsze mają jedynie wpływ na powiadomienia [d]own i [u]nreachable (ale w dużym środowisku i tak nie poprawiają czytelności mapy). Drugie to zaawansowane podejście do monitoringu umożliwiające określanie warunków dla których ma wystąpić powiadomienie w przypadku gdy host / usługa zależy od innych czynników.

10. Usługi mogą zależeć od usług na innych hostach

To daje nam możliwość dokładnego odwzorowania środowiska. Np. serwer POP3  na serwerze A uwierzytelnia użytkowników korzystając z danych w bazie SQL zainstalowanej na serwerze B.

11. Zależności usług mogą być czasowe (dependency_period)

Ta opcja najbardziej przydatna jest w okienkach backupowych. np. poprawne wykonanie kopii zależy od dostępności macierzy A, napędu taśmowego N i przełączników X oraz Y. Ale tylko w weekend.

12. Własne dyrektywy dla host / service

Jeśli chcemy użyć dyrektyw specyficznych dla konkretnej usługi lub hosta, a nie są one zdefiniowane (jak adres IP), możemy je dodawać samodzielnie ustawiając jako _zmienna, a używając dalej po podaniu $_HOSTZMIENNA$.

13. Bezpieczeństwo: hasła przekazywane w komendach są widoczne

Jeśli podamy jako własną dyrektywę nazwę użytkownika i hasło do sprawdzania usługi, pamiętajmy, że jest to wyświetlane w interfejsie web, a co za tym idzie, może być dostępne dla osób niepowołanych. Zamiast tego skorzystajmy z możliwości zdefiniowania makra (macro) w pliku resource.cfg. Do dyspozycji mamy 32 zapisy $USERn$.

14. Bezpieczeństwo: nie uruchamiaj z prawami root

Jeśli jakiś plugin wymaga zwiększonych uprawnień, użyj sudo zamiast uruchamiać Nagios z prawami administratora.

To pierwsza część. Następna wkrótce.

No to teraz zmykam na demotywatory.pl i bash.org.pl :-)

Najprostsze było podłączenie obwodów zasilania – urządzenie może testować maksymalnie trzy. MIB’y z grupy: .1.3.6.1.4.1.1909.10.6.1.1.3, zwracają INTEGER. Skrypt do Nagios, którego używam – check_infratec_rms.pl, jako domyślne zakresy definiuje 215 – 250 [V] dla ostrzeżenia i 210 – 255 [V] dla błędu. Działa dobrze i nie było problemów.

Kolejny etap to podłączenie czujnika dymu RMS-SS (ESSER 761362), który korzysta z portu alert-in. Trzeba pamiętać, że zdarzenie powoduje zmianę stanu portu, ale powrót do stanu pierwotnego należy wykonać ręcznie.
W tym przypadku MIB’y z grupy .1.3.6.1.4.1.1909.10.2.2.1. Oprócz nazw (.2) mamy stan (.3), czas od ostatniej zmiany (.4) i ilość zmian stanu (.5). Wspomniany skrypt po 60 sekundach zgłasza błąd (ostrzeżenie, jak mniemam celowo, ustawione jest na 900 sekund, czyli powyżej błędu). Dla tego czujnika trzeba zmienić rozpoznawanie stanu za pomocą parametru -i on.
Testy przy użyciu palącego kolegi i jednego papierosa potwierdziły poprawne działanie urządzenia.

Na jutro zostawiam czujnik otwarcia drzwi (MEDER electronic MK02/0-1A66-4000W; symbolu Infratec AG nie znam) i detektor ruchu (Pyronix seria KX).

Proponuję (wersja 0.1) przerobić DSN (linia 298) i wyrzucić nazwę bazy zupełnie (pozostawić `:’ – dwukropek) lub zmienić nazwę na information_schema, bo do tego prawo ma każdy użytkownik (dla wersji > 5.0).

--- /usr/lib64/nagios/plugins/check_mysql-replication.pl 2009-10-22 13:17:26.000000000 +0200
+++ check_mysql-replication.pl 2009-10-22 13:17:33.000000000 +0200
@@ -295,7 +295,7 @@ EOT
# ------------------------------
sub request_executor() {
my ($host,$port,$user,$pwd,$request) = @_;
- my $dsn = "DBI:mysql:mysql;host=$host:$port";
+ my $dsn = "DBI:mysql:;host=$host:$port";
my $dbh = DBI->connect($dsn, $user, $pwd) or die "connexion failed $DBI::errstr\n";
my $sth = $dbh->prepare($request);
$sth->execute();

Autor obiecał, że wprowadzi stosowną poprawkę – tymczasem można łatać.