Monitoring sinusoidy czyli Nagios i dynamicznie zmieniające się progi

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 --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.

Tagi: ,

Dodaj odpowiedź