Cacti - monitorowanie serwera DNS - BIND9

Do uruchomienia monitorowania serwera DNS Bind9 będa potrzebne:
- skrypty i template do Cacti - bind9-stats-2.0.tar
- biblioteka do Perla - libsnmp-extension-passpersist-perl

Ponieważ nie mam jej w dystrybucji Debian Squeeze należy pobrać pakiet deb na dysk i zainstalować za pomocą:
# dpkg - i libsnmp-extension-passpersist-perl_0.06-1_all.deb

Przed instalacja należy doinstalować pakiety:

• libclass-accessor-perl (>= 0.30)
• liblist-moreutils-perl (>= 0.21)

1. Konfiguracja Binda i sprawdzenie działanie narzędzie RNDC

- do pliku konfiguracyjnego Binda dodajemy sekcje z kluczem MD5 dla RNDC, musi byc on zgodny z kluczem w pliku konfiguracyjny rndc.conf, oraz konfigurujemy Binda by generował statystyki do pliku (jeżeli Bind jest uruchamiany w sand-boxie, podajemy zwykłą ścieżkę do pliku, bez żadnych dodatkowych informacji)


key rndc-key {
        algorithm hmac-md5;
        secret " jakis sekretny klucz MD5 ";
        };

zone-statistics         yes;

dump-file               "/var/cache/bind/cache_dump.db";

statistics-file         "/var/cache/bind/named_stats.txt";

memstatistics-file      "/var/cache/bind/named_mem_stats.txt";

- restart Binda i sprawdzenie działanie narzędzia RNDC
# /etc/init.d/bind9 restart

# rndc status
version: 9.7.3 (DNS)

CPUs found: 1

worker threads: 1

number of zones: 28

debug level: 0

xfers running: 0

xfers deferred: 0

soa queries in progress: 0

query logging is OFF

recursive clients: 0/0/1000

tcp clients: 0/100

server is up and running

- sprawdzamy czy rndc generuje plik

# rndc stats
# more /var/cache/bind/named_stats.txt

+++ Statistics Dump +++ (1353929701)

++ Incoming Requests ++

                 123 QUERY

++ Incoming Queries ++

                 117 A

                   6 AAAA

++ Outgoing Queries ++

[View: internal]

[View: external]

[View: _bind]

++ Name Server Statistics ++

                 123 IPv4 requests received

                  54 requests with EDNS(0) received

                  62 recursive queries rejected

                 123 responses sent

                  54 responses with EDNS(0) sent

                  55 queries resulted in successful answer

                  61 queries resulted in authoritative answer

                   6 queries resulted in nxrrset

                  62 other query failures

++ Zone Maintenance Statistics ++

                   9 IPv4 notifies sent

++ Resolver Statistics ++

(...)

- i dodajemy wywołanie skryptu do crona, generowanie statystyk nastąpi co 5 minut

*/5 * * * * /usr/share/bind9/bind9-genstats.sh > /dev/null 2>&1

2. Plik bind9-stats-2.0.tar rozpakowujemy np. do /usr/share/bind9

3. Modyfikujemy skrypty. W obu należy ustawić ścieżkę do pliku named_stats.txt. Tu podajemy już pełną ścieżkę w systemie plików

/usr/share/bind9/bind9-genstats.sh

STAT_FILE=/var/lib/named/var/cache/bind/named_stats.txt

/usr/share/bind9/snmp/bind9-stats-snmpd.pl

$STAT_FILE = "/var/lib/named/var/cache/bind/named_stats.txt";

4. Do pliku snmpd.conf dodajemy:

pass .1.3.6.1.4.1.2021.55 /usr/bin/perl /usr/share/bind9/snmp/bind9-stats-snmpd.pl

restartujemy demona
# /etc/init.d/snmpd restart

i sprawdzamy:

#snmpwalk -v 2c -c <snmp_community> localhost .1.3.6.1.4.1.2021.55

UCD-SNMP-MIB::ucdavis.55.1.0 = INTEGER: 0

UCD-SNMP-MIB::ucdavis.55.1.1 = INTEGER: 1

UCD-SNMP-MIB::ucdavis.55.1.2 = INTEGER: 2

UCD-SNMP-MIB::ucdavis.55.1.3 = INTEGER: 3

UCD-SNMP-MIB::ucdavis.55.1.4 = INTEGER: 4

UCD-SNMP-MIB::ucdavis.55.1.5 = INTEGER: 5

UCD-SNMP-MIB::ucdavis.55.1.6 = INTEGER: 6

UCD-SNMP-MIB::ucdavis.55.2.1 = STRING: "GLOBAL"

(...)

5. Na koniec kopjujemy plik 

# cp /usr/share/bind9/snmp/bind9-stats-snmp.xml /usr/share/cacti/resource/snmp_queries/

oraz importujemy do Cacti template cacti_data_query_bind_9_statistics_snmp.xml

6. Dodajemy do hosta na którym mamy uruchomiony serwer DNS data query BIND 9 Statistics (SNMP), po czym wykonujemy odczyt danych z serwera (Verbose query) i normalnie dodajemy potrzebne wykresy.

Data Query
Obrazek z http://forums.cacti.net

Statystyka ogólna serwera DNS Bind9
Obrazek z http://forums.cacti.net

Cacti - monitorowanie kontrolera zasilania Tahoe 8216 GSM

Zacząłem ostatnio używać bardzo fajny system do zdalnej kontroli zasilania urządzeń w szafie rackowej. Szczególnie użyteczne jest to w miejscu, gdzie dojazd zabiera trochę czasu a trzeba szybko zrestartować jakieś urządzenie przez wyłączenie zasilania. System zdalnego zasilania Tahoe 8216 GSM udostępnia kontrolę nad zasilanie urządzeń zarówno przez sieć LAN/WAN, jak i pozwala na kontrolę zasilania za pomocą telefonu, przez wysyłanie wiadomości SMS. Oprócz dostępnych 10 gniazdek na jednostce główniej, system umożliwia podłączenie 31 jednostek podrzędnych do pozwala na kontrolowania naprawdę dużej ilości urządzeń :) Oprócz tego urządzenie potrafi w oparciu o zdefiniowane watchdogi samodzielnie restartować wybrane urządzenia, które np. nie odpowiadają na ping przez 5 minut.

Więcej informacji o Tahoe 8216 GSM tutaj.

Przez SNMP urządzenie udostępnia kilka parametrów środowiskowych, takich jak: napięcie, pobór prądu i mocy, temperatura urządzenia i inne. Wszystkie informacje są dostępne w gałęzi enterprice OID: 

.1.3.6.1.4.1.3600.4.2 

oraz standardowym

.1.3.6.1

MIBy do urządzania są tutaj. MIB jest kompatybilny z firmware 1.4.2 rev.499

Co do monitorowania samego urządzenia to stworzyłem do Cacti template urządzenia Tahoe do monitorowania wspomnianych parametrów. Plik jest utworzony w wersji Cacti 0.8.8a.

 cacti_host_template_tahoe_8216gsm.xml

Całość wygląda tak:

Nagios - monitorowanie kontrolera RAID 3WARE 9650SE

Z uwagi na budżet, nie używam "dużych" serwerów takich jak np. HP Proliant DL380 G7. Do wykorzystywanych przeze mnie funkcjonalności w zupełności wystarcza najmniejszy HP Proliant DL 120 G6 i G7. Niestety HP ograniczyło ich funkcjonalność przez zastosowanie kontrolera RAID SmartArray B110i SATA, który nie jest wspierany przez XenServer. Nie zależnie od ustawień w BIOSie maszyny, XenServer widzi dyski fizyczne a nie np. zestaw RAID1. Funkcjonalność serwera DL120 można poprawić przez zastosowanie kontrolera RAID 3Ware z rodziny 9560SE. Są ta bardzo zaawansowane kontrolery obsługujące od 4 do 24 dysków SATA i umożliwiające zbudowanie macierzy RAID praktycznie każdego poziomu  z RAID6 włącznie. Mogą być one doposażone w moduł bateryjny służący do podtrzymania cache dyskowego w razie nagłej utraty zasilania, co zapobiega utracie danych przy trybie zapisu writeback cache. Niestety jest też dość znaczący minus. Normalnie serwer posiada moduł diagnostyczny i w razie awarii dysku na kieszeni wyświetlany jest alarm w postaci diody LED. Po zastosowaniu kontrolera nie mamy dostępu do tej funkcjonalności. Jest to prawdopodobnie do obejścia, ale wymaga ingerencji w okablowanie wewnętrzne serwera. Z pomocą do monitoringu stanu pracy macierzy, dysków i baterii przyszedł mi Nagios i plugin napisany przez Mariusa Heina z firmy Netways Gmbh a znaleziony na http://exchange.nagios.org. Marius ograniczył się do testowania wyłącznie zestawów RAID na lokalnej maszynie. Rozbudowałem ten plugin o możliwość monitorowania maszyny zdalnej, testowanie dysków fizycznych i baterii. Dzięki temu uzyskałem w pełni funkcjonalny monitoring stanu macierzy dyskowej w serwerach.


jak to działa???

Plugin jest napisany w Perlu, wykorzystuje protokół SSH do zdalnego wykonania programu na monitorowanym serwerze. Do logowania się na zdalnej maszynie użyłem kluczy RSA by nie było konieczności podawania hasła - opisane tutaj. 

UWAGA: Skrypt używa konta roota dla dostępu do zdalnej maszyny - tak wiem jest to niebezpieczne, ale w posiadanym przeze mnie środowisku jest to nieistotne. Można przystosować skrypt do użycia z dowolnym użytkownikiem, który będzie miał możliwość wykonania kodu na zdalnej maszynie. 

Oprócz tego potrzebny będzie interfejs CLI kontrolera 3Ware. To za jego pomocą uzyskamy dostęp do kontrolera i stanu poszczególnych komponentów systemu RAID. W zależności od systemu Linux potrzebny będzie jeden z poniższych plików:
     
tw_cli-linux-x86_64-9.4.1.3.tgz
tw_cli-linux-x86_64-9.5.3.tgz
tw_cli-linux-x86-9.3.0.7.tgz

Program tw_cli odpowiada za bezpośredni dostęp do interfejsu kontrolera, program tw_sched jest portem pomiędzy cronem a tw_cli i pozwala na automatyzację niektórych funkcji, np. cykliczne test macieży. Składnia obu programów jest opisana w załączonej dokumentacji.

Ostatnim krokiem jest konfiguracja Nagiosa - komendy, testy itp.


konfiguracja

Teraz trzeba zebrać to w całość i uruchomić. Zatem po kolei:

1. instalacja tw_cli 

Kopiujemy i rozpakowujemy archiwum z oprogramowaniem dla kontrolera

# tar -xvf tw_cli-linux-x86-9.3.0.7.tgz

Program ma bardzo bogaty help, opisany również w manach.

2. instalacja i konfiguracja pluginu

Plik z pluginem należy skopiować do katalogu /usr/lib/nagios/plugins i upewnić się że użytkownik nagios może wykonywać skrypt, np.

-rwxr-xr-x 1 root root 6723 06-25 13:29 check_3ware.pl

Plugin jest to pobrania TUTAJ

Oprócz tego, jeśli to konieczne należy zmienić użytkownika, który loguje się przez SSH do maszyny - linia 55

$conf{'path'} = 'ssh root@';



3. konfiguracja Nagiosa

W katalogu /etc/nagios-plugins/config należy utworzyć plik z konfiguracją komend dla Nagiosa:


# 'check_3ware' command definition
define command{
        command_name    check_3ware_raid
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -U $ARG2
        }

define command{
        command_name    check_3ware_disc
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -D $ARG2$
        }

define command{
        command_name    check_3ware_bbu
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -B $ARG2$
        }

Następnie w pliku konfiguracyjnym dodajemy nowe serwisy, należy pamiętać o zmianie   parametru hostgroup_name na odpowiedni dla posiadanej konfiguracji.


define service {
        hostgroup_name          xen-servers
        service_description     RAID Unit 0
        check_command           check_3ware_raid!0!0
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     RAID Unit 1
        check_command           check_3ware_raid!0!1
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     BBU
        check_command           check_3ware_bbu!0!0
        use                     template-service
}
define service {

        hostgroup_name          xen-servers
        service_description     Disc 0
        check_command           check_3ware_disc!0!0
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     Disc 1
        check_command           check_3ware_disc!0!1
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     Disc 2
        check_command           check_3ware_disc!0!2
        use                     template-service
}

define service {

        hostgroup_name          xen-servers

        service_description     Disc 3

        check_command           check_3ware_disc!0!3

        use                     template-service

}

Na koniec weryfikujemy konfigurację Nagiosa i restartujemy serwis.

# /usr/sbin/nagios3 -v /etc/nagios3/nagios.cfg
# /etc/init.d/nagios3 restart



4. A oto efekt

Alarm modułu bateryjnego

Alarmu dysku fizycznego i macierzy

Cacti - wykresy stanu portów w switchach

Cacti jest przepotężnym narzędziem do zbierania i graficznej prezentacji najprzeróżniejszych parametrów sieci. W podstawowej instalacji są to wykresy obciążenia procesora, interfejsów sieciowych, zajętości pamięci itp. Cacti może być rozbudowane o wiele przeróżnych wykresów jak monitorowanie środowiska, zasilania, stanu serwerów (HTTP, DNS) i wiele innych. 

Niedawno spotkałem się z potrzebą monitorowania zajętości portów na switcha. Najprostszym sposobem było zaprzęgnięcie działającego już w sieci Cacti do dodatkowej pracy. W tym celu znalazłem na forum Cacti skrypt, który w zamierzeniu autora miał odczytywać potrzebne parametry - ilość wszystkich portów ethernet i portów, które działają w danym momencie. Przerobiłem go do swoich celów i dodałem nową funkcjonalność - odczyt portów w stanie Admin Up. Dodatkowo przystosowałem skrypt do działania z innymi switchami, nie tylko Cisco, ale również HP Procurve i 3COM.

Poniższe skrypty należy skopiować do katalogu /usr/share/cacti/site/scripts

check_ports_cisco.php

check_ports_hp.php

check_ports_3com.php

Cisco - większość switchy, sprawdzone na C3560, C2960, C3750 i C6505

HP - Procurve 2510G, 2524 (będzie działać ze wszystkimi switchami które numerują interfejsy cyframi), 1810G-8 i 4000M (modularny)
3COM - SuperStack II 3300, SuperStack III 4400 i 4500, Baseline 2226 Plus

Następnie, po zalogowaniu się do Cacti z prawami administratora musimy skonfigurować kilka zależnych od siebie elementów:

1. Data Input Methods

Input Fields - przy ich pomocy przekazujemy parametry do skryptu

Output Fields - przy ich pomocy odbieramy ze skryptu dane, ich nazwy muszą być identyczne z tymi które są w skrypcie

Jeżeli chcemy, by parametry do skrypty były przekazywane automatycznie na podstawie informacji zdefiniowanych w karcie urządzenia (Device), takich jak. IP adres, SNMP community, czy SNMP version, należy przy definiowaniu Input Field w polu Special Type Code wpisać jedno z podanych słów kluczowych, np. hostname dla adresu IP lub nazwy kanonicznej urządzenia.

2. Data Templates

W Data Templates definiujemy w jaki sposób RRDTools ma obsługiwać napływające ze skryptu dane. Ważne jest zdefiniowanie odpowiedniej ilości pól w szablonie, należy pamiętać o zapisywaniu szablonu po każdorazowym utworzeniu i edycji nowego pola.

3. Graph Templates  

 Tu definiujemy jak ma wyglądać wykres.

4. Device i Create Graph

Na koniec na karcie urządzenia dodajemy z listy rozwijanej nowy szablon i po wybraniu linka Create Graph For This Host dodajemy nowy wykres.

5. A tak wygląda efekt końcowy

Pole niebieskie to całkowita ilość interfejsów. Pole zielone to interfejsy w stanie Admin UP a czerwona linia to aktualnie aktywne interfejsy - w stanie Oper Up.

Pliki z gotowymi szablonami do switchy Cisco i HP 

generowane za pomocą Cacti 0.8.8a 

Rancid - narzędzie do monitorowania zmian i backupu konfiguracji - część 1

W codziennej pracy z sieciami prędzej czy później natkniemy się na problem archiwizacji konfiguracji urządzeń sieciowych - routerów, switchy, firewalli itp. Na rynku jest dostępne wiele różnych płatnych narzędzi takich jak Kiwi CatTools czy kombajn Cisco LMS . Co jednak w sytuacji, gdy np. budżet IT niedużej firmy nie pozwala na zakup komercyjnego rozwiązania? Przy małej ilości urządzeń można sobie pozwolić na ręczne backupy konfiguracji urządzeń, ale gdy ilość urządzeń rośnie nakład czasu potrzebny do wykonania backupów rośnie. Oczywiście można się posiłkować skryptami automatyzującymi pracę, lecz może być to dość karkołomne dla mniej doświadczonych adminów.

Rozwiązaniem tego problemu może być RANCID (Really Awesome New Cisco confIg Differ) - znakomite narzędzie przeznaczone do automatycznego backupu konfiguracji urządzeń sieciowych. Oprócz tego RANCID potrafi zachowywać różne wersje konfiguracji i porównywać je za pomocą CVS (Concurrent Version System). Wbrew nazwie RANCID potrafi backupować urządzenia różnych producentów takich jak:  Juniper, HP, Foundry itd. Do działania nie są potrzebne dodatkowe protokoły jak SNMP. Rancid loguje się do urządzenia i kopjuje konfigurację. Sam RANCID jest narzędziem działającym w trybie tekstowym, można go jednak doposażyć w graficzną nakładkę CVS-WEB.

 instalacja RANCIDa

Opis instalacji dotyczy systemu Linux Debian 6.0
Do prawidłowego działania RANCIDa potrzebne są następujące programy:
- Apache2
- CVS
- RANCID :)
- CVS-WEB  

Do instalacji pakietów możemy użyć albo graficznego managera pakietów, albo tekstowego apt-get. W obu przypadkach, przy prawidłowo zainstalowanym Debianie, instalacja pakietu RANCID automatycznie zainstaluje potrzebne powiązane pakiety (Apache2, CVS). Na koniec będzie potrzebne doinstalowanie pakietu CVS-WEB.

Zatem zaczynamy:

1. Najpierw instalujemy RANCIDa

    #apt-get install rancid

W trakcie instalacji zostanie utworzone konto użytkownika i jego katalog domowy.

2. Teraz edytujemy plik konfiguracyjny rancid.conf znajdujący się w katalogu /etc/rancid . Należy dodać przynajmniej jedną grupę. 

   LIST_OF_GROUPS="urzadzenia"

Przy większych sieciach, może być pomocne skonfigurowanie kilku grup. Nazwy grup muszą być rozdzielone znakiem spacji. 

   LIST_OF_GROUPS="ruter switch firewall"  

 3. Następnie należy skonfigurować plik o nazwie .cloginrc zawierający hasła potrzebne do zalogowania się na urządzenia. Edytujemy plik zachowując odpowiednią składnię w zależności od urządzenia, w przykładzie składnia dla urządzeń Cisco

add password 1.1.1.1 {USER_PASSWORD} {ENABLE_PASSWORD}
add autoenable 1.1.1.1 1

Jeśli urządzenie używa protokołu SSH zamiast telnet (np. Cisco PIX/ASA) do konfiguracji  dodajemy: 

add method 1.1.1.1 ssh

Znak "#" standartowo oznacza komentarz, zatem jeśli chcemy z jakiegoś powodu wyłączyć dane urządzenie z backupów to wystarczy że postawimy "#" na początku odpowiedniej linii.

Należy być bardzo ostrożnym z uprawnieniami pliku .cloginrc gdyż przechowuje on hasła w postaci tekstowej niezaszyfrowanej. Jedyną możliwością ochrony pliku jest ograniczenie praw dostępu do pliku wyłacznie dla właściciela. Zatem ustawiamy

  chmod 600 /home/rancid/.cloginrc
  chown -R rancid:rancid /home/rancid 

4. Kolej teraz na stworzenie architektury CVS. W tym celu należy zalogować się na konto użytkownika rancid 

  su rancid
  rancid@linux:~ /home/rancid/rancid/bin/rancid-cvs

Po tym w katalogu rancida powinna zostac utworzona struktura CVS on nazwie grupy jaką podaliśmy w pliku konfiguracyjnym.

5. Teraz dodajemy urządzenia do grupy /home/rancid/rancid/{nazwa_grupy}/router.db
Składnia pliku jest prosta: "ip_address":"typ_urządzenia":"status"  np.:

   1.1.1.1:cisco:up

 Następnie testujemy, czy rancid ma dostęp do skonfigurowanego urządzenia.

   rancid@linux:~ /home/rancid/rancid/bin/clogin 1.1.1.1

1.1.1.1
spawn telnet 1.1.1.1
Trying 1.1.1.1...
Connected to 1.1.1.1.
Escape character is '^]'.

User Access Verification

Username:
Password:
Router#

6. I uruchamiamy RANCIDa

  rancid@linux:~ /home/rancid/rancid/bin/rancid-run

Logi RANCID są dostępne w katalogu /var/log/rancid. 

7. By RANCID sprawdzał konfiguracje bez naszego udziału trzeba do crona dodać

   crontab -e -u rancid

   # uruchom rancid-run każdego dnia o 01:00 
   0 1 * * * /home/rancid/rancid/bin/rancid-run

Poza tym możemy pokusić się o automatyczne usuwanie logów. Rancid zapisuje osobne logi dla każdej grupy po każdorazowym zakończeniu pracy. Przy dużej ilości urządzeń i grup oraz szczególnie częstym uruchamianiu skryptu logów będzie bardzo dużo i ich ilość będzie przyrastała w zastraszającym tempie. Pokusiłem się o automatyczne usuwanie starych logów. By to zrobić do crona należy dodać linię.

  crontab -e -u rancid 

  # czyść logi co miesiąc o 00:15 

  15 00 1 * * find /var/lib/rancid/logs/ -type f -mtime +30 -exec rm {} \;

 instalacja CVS-WEB

RANCID pracuje, ale jak odczytać wyniki jego pracy? Można zrobić to przez interfejs tekstowy CVSa, ale jest to dość trudne. Z pomocą przychodzi nam bardzo przejrzysty i łatwy w użyciu CVS-WEB.
Zatem:

1. Instalujemy pakiet

  apt-get install cvsweb

2. W pliku /etc/cvsweb/cvsweb.conf należy odnaleźć sekcję @CVSrepositories i dodać katalog gdzie znajduje się główne repozytorium.

@CVSrepositories = (
#'local' => ['Local Repository', '/var/lib/cvs'],
'moje_urzadzenia' => ['urządzenia', '/var/lib/rancid/CVS'],
#'freeebsd' => ['FreeBSD', '/var/ncvs'],
#'openbsd' => ['OpenBSD', '/var/ncvs'],
#'netbsd' => ['NetBSD', '/var/ncvs'],
#'ruby' => ['Ruby', '/var/anoncvs/ruby'],
);

Następnie tworzymy link symboliczny do katalogu, gdzie znajdują się ikony i pliki css

  ln -s /usr/share/cvsweb /var/www/cvsweb

3. Teraz możemy przetestować CVS-WEB wpisując w przeglądarce:

  http://127.0.0.1/cgi-bin/cvsweb