RSS Feed

Posts Tagged ‘monitoring’

  1. monitoring systemu w pasku menu w OSX Lion

    Sierpień 21, 2011 by 0verlord

    Fajnie jest mieć monitoring w pasku menu. Od razu widać, czy coś nam nie żre pamięci, nie zabija sieci, czy też nie dzieją się inne rzeczy.

    Generalnie do czasów Snow Leoparda korzystałem z iStatMenus, były za darmo i były fajne. Po upgrade do Liona, niestety przestały działać, a wersja 3.x niestety jest płatna. Niewiele w sumie, bo 16$, ale zawsze.

    Poszukałem alternatyw i jak na razie tylko jedna jest sensowna, atMonitor, wygląda średnio co prawda, ale działa jak należy. Nie znalazłem też opcji chowania ikony z docka, a szkoda. Z ciekawostek, ma triggery, czyli wyświetla alarmy, jeżeli jakiś wskaźnik pokaże zbyt dużą, zdefiniowaną wcześniej wartość.

    Wygląda toto tak:

    Z płatnych, jest w AppStorze System Monitor. Ten kosztuje niecałe 5$ i wygląda całkiem zacnie. 15 pln to jeszcze nie jest zdzierstwo w biały dzień ;-).

    A z cyklu: „nie tykać, omijać z daleka” jest sobie Magician Monitor.

    Nie chciało mi się dalej szukać, oczywiście można by poszukać wersji z krakowa (błąd celowy, korekta nie poprawiać), no, ale to już jak kto woli.


  2. Konfiguracja Nagiosa – dziedziczenie

    Kwiecień 18, 2011 by 0verlord

    W sumie, to takie HOWTO, ale nie HOWTO, bo jednak podstawową wiedzę o Nagiosie trzeba mieć, to taki esej o możliwościach konfiguracji Nagiosa. Tym razem będzie o dziedziczeniu i zmiennych.

    Po pierwsze: dziedziczenie.

    Nagios zapewnia całkiem ciekawe możliwości dziedziczenia. Każdy, kto zapoznał się z podstawami templatek (dyrektywa use), wie, że pomiędzy różnymi częściami konfiga można przekazywać wiele parametrów. Dokumentacja o tym nie wspomina, ale można je także nadpisywać. Na przykład:

    definiujemy templatkę ogólną hosta, nic szczególnego, żywcem wyjęta z dokumentacji:
    define host{
    name generic-host ; The name of this host template
    notifications_enabled 1 ; Host notifications are enabled
    event_handler_enabled 1 ; Host event handler is enabled
    flap_detection_enabled 1 ; Flap detection is enabled
    failure_prediction_enabled 1 ; Failure prediction is enabled
    process_perf_data 1 ; Process performance data
    retain_status_information 1 ; Retain status information across program restarts
    retain_nonstatus_information 1 ; Retain non-status information across program restarts
    check_command check_ping!120.0,15%!300.0,60%
    max_check_attempts 10
    notification_interval 0
    notification_period 24x7
    notification_options d,u,r
    contact_groups admins
    register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
    }

    a potem hosta:

    define host{
    use generic-host
    host_name mojhost.pl
    alias alias
    address 1.2.3.4
    parents gateway
    contact_groups admini,mroczniadmini
    }

    Ogólnie dokumentacja mówi o takich szablonach bardziej jako o sposobie, żeby nie w kółko nie pisać tych samych kawałków konfiga i tych samych dyrektyw. Ale sam mechanizm jest bardziej mroczny i przydatny. Jeżeli w templatce zdefiniujemy jakąś dyrektywę, ale jakiś host powinien mieć którąś opcję zdefiniowaną inaczej, można ją nadpisać. Na przykład tak:

    define host{
    use generic-host
    host_name mojhost.pl
    alias alias
    address 1.2.3.4
    parents gateway
    max_check_attempts 20
    contact_groups admini,mroczniadmini
    }

    W tym przypadku, nadpisujemy max_check_attempts. Gdybyśmy tego nie zdefiniowali, obiekt odziedziczyłby predefiniowaną wartość max_check_attempts 10 z definicji templatki (use generic-host.
    To jest proste, zapewne intuicyjnie wiele razy korzystaliście z takiego sposobu – teraz będziecie robić to świadomie ;-).

    Po drugie: zmienne.

    Ten mechanizm można także wykorzystać do przekazywania i nadpisywania zmiennych. W dokumentacji są to custom object variables.
    Poniżej opiszę, jak przekazać community snmp i jednocześnie zachować możliwość nadpisania go dla dowolnego hosta.

    Weźmy np. taką, uproszczoną do minimum, templatkę:
    define host {
    name generic-host
    register 0 # to templatka, więc 0
    _snmp_community blabla
    }

    i hosta wykorzystującego tą templatkę:

    define host {
    host_name testowy
    use generic-host
    _snmp_community bleble
    }

    I teraz, gdzie tutaj sztuczka magiczna?
    Ogólnie mamy dwa razy zdefiniowaną zmienną, _snmp_community (w Nagiosie każda wartość zaczynająca się od podkreślenia, _ to zmienna). Według zasad dziedziczenia ta, która została zdefiniowana ostatnia – wygrywa. Czyli nasz host ma ustawioną zmienną na bleble, a jeżeli nie nadpiszemy tej zmiennej – zostanie blabla. Ayt? 🙂 Tylko jak to teraz wstawić do definicji serwisu?

    Żeby uniknąć duplikacji zmiennych, Nagios automatycznie dodaje każdej prefix, w zależności od miejsca zdefiniowania. _HOST, _SERVICE i _CONTACT, czyli naszą zmienną _snmp_community, możemy w dowolnym innym miejscu konfiga odczytać jako $_HOSTSNMP_COMMUNITY$. Oczywiście trzeba uważać, żeby sobie tej zmiennej nie nadpisać w innym miejscu tej samej sekcji.

    Czyli teraz bierzemy definicję serwisu wykorzystującego community snmp, np. taką, i zamiast wpisywać do check_command po prostu community, wstawiamy tam naszą zmienną, np. tak jak w przykładzie poniżej:

    define service {
    host mojhost
    service_description snmp-uptime
    display_name SNMP System uptime
    check_command check_system_uptime!$_HOSTSNMP_COMMUNITY$
    use generic-service
    notification_interval 0 ;
    }

    W ten sposób ustawiamy community dla hosta tam, gdzie to wynika ze zdrowego rozsądku, tj. w definicji hosta, a serwisy już automagicznie biorą właściwą wartość.

    W następnych postach pokażę jeszcze kilka sztuczek optymalizacyjnych i organizacyjnych, np. jak optymalnie wykorzystać hostgroupsy.


  3. Monitorowanie interfejsu po snmp w Nagiosie

    Styczeń 15, 2011 by 0verlord

    Skryptów sprawdzających to wszystko jest dość sporo. Jeżeli ktoś nie ma potrzeby monitorowania ani rysowania liczby pakietów na interfejsie (pps), może skorzystać z np. check_snmp_int.pl lub jego kolegi check_snmp_netint.pl
    Powyższe skrypty doskonale dają sobie radę z interfejsami i ruchem na nich.

    Natomiast jeżeli ktoś zapragnie monitorować ppsy, w zasadzie zostaje mu tylko kawałek pakietu SNMP4Nagios, który posiada odpowiednie narzędzie – check_if_by_snmp. Narzędzie to ma jeden zasadniczy problem – należy mu podać do monitorowania nie interfejs, tylko index interfejsu, który można sobie wyciągnąć z snmpwalka po tablicy iso.3.6.1.2.1.31.1.1.1.1 np. tak:

    snmpwalk -v 2c -c   iso.3.6.1.2.1.31.1.1.1.1 | grep 
    

    Problem w tym, że indeksy interfejsów nie są stałe i moga się np. zmienić po reboocie, a na pewno zmienią się indeksy interfejsów vlanowych (802.1q) jak je dodamy lub/i odejmiemy.

    Popełniłem banalnie prosty wrapper w bashu do załatwienia tego problemu, wygląda on tak:

    #!/bin/bash 
    
    while getopts "H:C:I:" Option
    do
      case $Option in
        H)  HOSTADDRESS=$OPTARG;;
        C)  COMMUNITY=$OPTARG;;
        I)  IFACE=$OPTARG;;
      esac
    done
    shift $(($OPTIND - 1))
    # Move argument pointer to next.
    
    IFINDEX=`/usr/bin/snmpwalk -v 2c -c $COMMUNITY \
    $HOSTADDRESS iso.3.6.1.2.1.31.1.1.1.1  | grep "$IFACE" | \ 
    cut -d' ' -f1 | cut -d'.' -f12`
    
    /usr/lib/nagios/plugins/check_if_by_snmp -H $HOSTADDRESS -C $COMMUNITY \ 
    -i $IFINDEX -I $IFACE -T -N -L -R /var/lib/nagiosgraph/rrd/
    

    Wrapper pobiera parametry przekazywane do skryptu przez Nagiosa, robi snmpwalka, grepem wyjmuje indeks snmp interfejsu, który podamy jako argument, po czym wstawia go do oryginalnego skryptu z SNMP4Nagios. W ten sposób zawsze będziemy monitorować właściwy interfejs, a nie tylko ten sam indeks.

    Wyjaśnienia wymaga chyba tylko ostatnia linijka i opcja -R, która pokazuje, gdzie skrypt ma zapisywać pliki rrd z perfdata do rysowania wykresów. U mnie, prosto do katalogu nagiosgrapha.

    Nie wiem, dlaczego inne pluginy nie monitorują liczby ppsów, przecież np. w ten sposób da się wykryć na interfejsie ddos, albo inną anomalię ruchu. A tutaj tylko jeden skrypt to robi, i na dodatek lekko bez sensu.

    Oczywiście mój wrapper będzie pewnie niewydajny w przypadku wykonywania wielu checków – pytanie jak bardzo niewydajny i kiedy zabija hosta.