RSS Feed

Posts Tagged ‘nagios’

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


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


  3. Nagios i template’y

    Grudzień 29, 2010 by 0verlord

    Mocą Zabbixa była możliwość zarządzania hostami przez dość mocno skomplikowany system template’ów.
    Template, inaczej szablon, służy do określania standardowego zestawu takich samych rzeczy, które mają być wykonane zawsze w przypadku hosta z danej grupy. Natomiast jak się ostatnio dowiedziałem z lektury manuala, Nagios potrafi to robić nie gorzej.

    Do czego przydaje się template? Jeżeli mamy 200 hostów, w których monitorujemy np. SSH na porcie 22, a nagle z powodu nadmiaru skanów potrzebujemy przestawić sshd na port 2223, to warto by też przepiąć monitoring. Jeżeli nie mamy szablonów ze standardowymi usługami, a serwisy definiowane dla każdego hosta z osobna, musimy zmienić 200 wpisów. Jeżeli ktoś jest pracowity – do boju do boju do boju wks. Ja jestem przykładem skrajnego lenia i wolę sobie raczej życie ułatwiać, niż utrudniać.

    Więc definiujemy sobie szablon, w obcym jezyku: template. Szablon może dotyczyć hosta oraz serwisu. Host, to wiadomo co to jest. Serwis (service) to np. sprawdzanie SSH albo pinga. W Nagiosie robi się to tak:

    define host{
            name                            generic-host   
            notifications_enabled           1      
            event_handler_enabled           1   
            flap_detection_enabled          1    
            failure_prediction_enabled      1   
            process_perf_data               1       
            retain_status_information       1   
            retain_nonstatus_information    1 
                    check_command                   check-host-alive
                    max_check_attempts              10
                    notification_interval           0
                    notification_period             24x7
                    notification_options            d,u,r
                    contact_groups                  admins
            register                        0      
            }
    

    Interesuje nas name oraz

    register 0

    . To pierwsze wiadomo, trzeba się jakoś do templatki odwołać. To drugie oznacza, że ta definicja tak na prawdę nie jest hostem, i nie należy tego sprawdzać. Za to należy po tym obiekcie dziedziczyć różne rzeczy. Np. powiadomienia. Albo komendy sprawdzające (check_commands). Zresztą nawet wielkie ostrzeżenie w obcym języku tłumaczy opcję register (DONT REGISTER THIS DEFINITION – ITS NOT A REAL HOST, JUST A TEMPLATE!) .

    Takich szablonów można stworzyć wiele, i wcale nie muszą być aż tak rozbudowane jak ten z domyślnego przykładu.
    Nagios pozwala podłaczać wiele szablonów do jednego hosta. A robi się to np. tak:

    define host{
            use             generic-host,specific-host,mroczny-host
            host_name       hostek.domena.com
            alias           hostek
            address        1.2.3.3
            parents         badbadparent
            contact_groups  plumk
    } 
    

    Kluczem jest tutaj linijka z use. Po przecinku listujemy templatki, które mają być zastosowane do hosta. Niestety jeszcze nie doczytałem, która ma pierwszeństwo w przypadku nachodzenia się poniektórych opcji, ale zaktualizuję wpis, jak się dowiem.
    Ten sam mechanizm działa także dla serwisów.

    Za to w Zabbixie, stackowanie templatek (mądre słowo, oznacza dodawanie wielu szablonów do jednego hosta), zostało wprowadzone dopiero od wersji 1.4.x, i generalnie używanie tego jest mroczne jak używanie samego Zabbixa.


  4. Monitoring sieci cz. 1.2

    Grudzień 27, 2010 by 0verlord

    Z ciekawostek monitoringowych, obejrzałem sobie Icingę. To taki klon na bazie Nagiosa, podobno posiadający wszystko to, czego brakuje nagiosowi. Odpaliłem, spróbowałem, odinstalowałem. Sam nie wiem, czy do tego wrócę, bo jeszcze jest za mało natywnych wtyczek pod ten projekt. Wszystkie są pod Nagiosa ;-)Ale kto wie. Jak się projekt ustabilizje, czemu nie.

    Niby Icinga jest w testingu, niby jest kompatybilna z Nagiosem (to akurat sprawdziłem, Icinga rozmawiała do uruchomionych nagios-nrpe-serverów), natomiast takie rzeczy jak nagiosgrapher nie do końca działają, bo mają w Depends: nagiosa3. Trzeba by przekompilować te paczki, żeby można było takich dodatków używać, a to jest dość słabe, bo dochodzi pilnowanie własnego repo i aktualizacji np. security. Lipa.

    Na pewno ma ładniejsze UI, ale z drugiej strony, nie interfejs powoduje, że narzędzie do monitoringu jest lepsze, czy gorsze. Ma kilka dodatków jak super ekstra wypasiony nowy lepszy UI – icinga-web, albo ifejs dla urządzeń mobilnych (icinga-mobile). Ale to mnie jakoś nie ujęło, bo po defaultowej instalacji wszystko się ładowało i ładowało, i nie bardzo chciało cokolwiek pokazać.
    Generalnie po przejrzeniu konfiguracji usunięciu jednej ścieżki zahardkodowanej na stałe, wszystko ruszyło. Wolno. Nawet przeraźliwie wolno. Interfejs jest przepiękny, animacja mapy przefajna. Prędkość działania już nie.
    Tutaj jednak moc starutkiego UI Nagiosa, pokazuje pazur. Ładuje się w pół sekundy i widać dokładnie to, co trzeba, żeby wiedzieć, co się dzieje w sieci. Ładne, nie zawsze oznacza funkcjonalne jak widać.

    Jest też jedna wisienka do tego tortu – dokumentacja. Niby jest wzięta z Nagiosa, ale jakoś się ją lepiej czytało. I tutoriale jak np. odpalić ndoutils polecam szczerze. W Nagiosie są mało czytelne, długie i przeraźliwie nudne.


  5. Nagios3 i grupy

    Grudzień 21, 2010 by 0verlord

    Nagios ma kilka ciekawych funkcjonalności pozwalających zapanować nad chaosem, który niezauważalnie powoli zasysa każdego admina.
    Pierwsza z nich to grupy. Oczywiście można grupować hosty, ten podział jest oczywisty, natomiast znacznie ciekawsze jest grupowanie grup, hostów i możliwości negacji jednego i drugiego.

    Załóżmy, że mamy grupy hostów, www, smtp i ssh.

    Standardowa definicja grupy wygląda np. tak:

    define hostgroup {
       hostgroup_name wszyscy
       alias blablalias
       members host1, host2, host3, host4
    
    }
    

    Jeżeli chcemy wykluczyć jakiegoś hosta z grupy, używamy wykrzyknika:

    define hostgroup {
       hostgroup_name ale_nie_host4
       alias blablalias
       members host1, host2, host3, !host4
    
    }
    

    Żeby grupować grupy, należy użyć dyrektywy hostgroup_members (dostępne chyba od Nagiosa 3)

    define hostgroup {
       hostgroup_name www_i_ssh
       alias blablalias
       hostgroup_members www, ssh
    
    }
    

    Oczywiście i tutaj działa negacja z wykrzyknikiem.

    define hostgroup {
       hostgroup_name wszystkie_grupy_bez_ssh
       alias blablalias
       hostgroup_members www, smtp, !ssh
    
    }
    

    Co ciekawe, kombinacje grup i hostów można łaczyć, np. wykluczamy hosta host1 z grupy wszystkie_grupy i dodajemy hosta666, którego wcześniej nie było nigdzie.

    define hostgroup {
       hostgroup_name wszystkie_grupy_bez_ssh
       alias blablalias
       members host666, !host1
       hostgroup_members www, smtp, ssh
    
    }
    

    A ten sposób mamy możliwość grupowania i wykluczania dowolnych grup, grup hostów i samych hostów. Niezłe, niezłe.


  6. monitoring sieci i systemów – kilka słów ogólnie

    Grudzień 3, 2010 by 0verlord

    Jeżeli chodzi o monitoring sieci, tak na prawdę mamy do dyspozycji dwa poważne rozwiązania i kilkanaście mniej poważnych. Poważne są Nagios i Zabbix, mniej poważna – cała reszta.

    Na co należy zwrócić uwagę przy wyborze systemu monitorowania? Mógłbym wskazać kilka punktów determinujących wybór.

    Wielkość sieci. Małe rzeczy najlepiej monitorować małymi narzędziami. Mało hostów nie wymaga rozwiązania, które umożliwia skalowanie do tysięcy.

    Ilość zmian. Jeżeli mamy małą sieć, mało hostów i mało zmian, wygoda korzystania z narzędzia jest sprawą drugorzędną. Jeżeli mamy tego więcej, ergonomia narzędzia robi się kluczowa. Sytuacja: monitorujemy 2k serwisów na 30 serwerach, a nagle upgrade spowoduje, że proces serwera www przestanie się nazywać httpd, a zacznie apache2, Trzydzieści hostów jeszcze można przeklikać ręcznie. A jeżeli będzie 130 hostów? Trzeba poszukać narzędzia zapewniającego łatwą zmianę. Z tego miejsca pragnę pozdrowić wszystkich, którzy mają np. Cacti i siec, w której się sporo dzieje. Aktualizowanie nowych hostów to padaczka.

    Różnorodność i powtarzalność. Czy możemy w prosty sposób dodawać jedną definicję do wielu serwerów? Czy możemy prosto wykluczać monitorowanie niektórych elementów w zależności od hosta?

    Zasobożerność. Co z tego, że nasz soft może dużo, jeżeli np. generuje przy 20 serwerach i 200 serwisach 1k zapytań do bazy na sekundę (heloł Zabbix)? Czy nie lepiej postawić coś, co pozwoli nie generować aż takiego obciążenia?

    Skalowalność i możliwość replikacji. Jeżeli mamy wiele sieci, które generują różny output, fajnie by było, gdyby dało się rozkładać ruch, a nie zrzucać wszystko na jeden serwer. Najczęściej przy rozproszonej strukturze wybranymi elementami zajmują się rózni ludzie, którzy powinni mieć dostęp do odpowiedniej części systemu.

    Czas wejścia i zrozumienia systemu. Co z tego, że system jest super, jeżeli wdrożenie nowego człowieka w system trwa 3 tygodnie? A szkolenie ze zrozumienia jego komunikatów kilka dni? Tak, mówię o Zabbixie, ma najbardziej pokręcony interfejs świata. Tam nic nie jest intuicyjne. Poprawili trochę odkąd korzystałem z wersji 1.1 (teraz jest 1.8) , ale to dalej ta sama wielka i niezrozumiała kobyła. Natomiast jego możliwości zarządzania szablonami (templae’ami) zabijają. Jak ci ludzie potrafili takie szaleństwo przenieść na schemat bazy danych, to ja nie wiem. Mroczni lordowie wszechświata 😉