Co zrobić gdy monitorowane wartości zmieniają się w czasie i to w dodatku o kilka rzędów wielkości? Raczej nie mamy dużego pola manewru – ja w większości używanych wtyczek do Nagios nie znalazłem niczego poza sztywnymi zakresami.
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--modepodczas wywołania,name– to co wname2jeśli jest lub wname(chyba tylko pierwszy wyraz) lub jako wartość parametrudbthresholds; 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.
Tagi: check_oracle_health, Nagios