Monitoring: Jak używać prostych narzędzi do wykrywania słabych punktów wydajności. Prawa ręka admina Kiedy serwer przestaje pracować, powinny cię o tym poinformować przede wszystkim odpowiednie narzędzia, a nie sami użytkownicy. Zestaw narzędzi opisany w tym artykule pomoże w monitorowaniu twoich serwerów i udostępnianych przez nie usług, generując dodatkowo wykresy z analizą obciążenia. CHARLY KÜHNAST Administratorzy, gromadzący dane na temat sieci i stanu serwera oraz wizualizujący te dane, są w stanie szybko znaleźć wąskie gardła wydajności i źródła spadku wydajności, bez konieczności ręcznego przeszukiwania plików zdarzeń. Istnieje wiele pożytecznych narzędzi do monitorowania, które mogą wykonywać takie zadania, przykładami są Nagios czy Big Sister. Obydwa programy były opisywane w angielskojęzycznej wersji Linux Magazine [1], [2]. Jednak niniejszy artykuł nie będzie poświęcony ich używaniu zamiast tego skupimy się na narzędziach zawartych standardowo w każdej dystrybucji Linuksa. Przygotujemy kilka prostych, ale efektywnych skryptów Bash, które pozwolą śledzić sytuację. Prawdziwą zaletą tych narzędzi w porównaniu z rozbudowanymi systemami zarządzania siecią jest to, że zawsze istnieje możliwość dokonywania takich modyfikacji, które pozwolą dostosować je do indywidualnych warunków twojej infrastruktury IT, oto przykładowe możliwości: możliwość generowania niestandardowych statystyk oprócz domyślnych komunikatów masz również dostęp do zebranych danych w przypadku konieczności szczegółowej analizy zdarzenia możliwość szybkiego opanowania skryptów przez administratora dla entuzjastów Linuksa/Uniksa używanie skryptów jest daleko bardziej atrakcyjne niż programów binarnych. Oczywiście takie rozwiązanie ma również wady: potrzeba więcej czasu, żeby dostosować skrypty do wymagań środowiska produkcyjnego ma o wiele mniej funkcji istnieje trudność rozwoju skryptów wraz z systemem, zwłaszcza jeśli zajmuje się nim jeden programista. livecheck czy serwer odpowiada? Zajmijmy się najpierw najważniejszym zadaniem: administratorzy muszą przede wszystkim wiedzieć, czy ich serwery działają i czy usługi są dostępne. Prosty skrypt powłoki Bash o nazwie simple_livecheck.sh będzie w tym bardzo pomocny, jednak do pracy będzie on potrzebował kilku dodatkowych plików i katalogów. Katalog roboczy skryptu to /usr/local/shellscripts/livecheck. Utwórz w nim podkatalog o nazwie etc i użyj edytora tekstowego w celu utworzenia plików konfiguracyjnych dla każdego z monitorowanych serwerów. Zawartość pliku musi być zgodna z następującą konwencją: adres_ip.sld.tld; np. 10.0.0.2_funghi.gondor.com. Następnie dodaj porty, które powinny być dostępne w trakcie normalnej pracy serwera: 25 80 110 Postępuj zgodnie z tym przykładem dla każdego serwera, który chcesz monitorować, inny serwer w naszym przykładzie 10.0.0.12_inn.kuehnast.com, musi mieć monitorowany jedynie port 1. Nmap użyteczne narzędzie Skrypt przechodzi przez listę plików, które sprawdzają, czy serwery w ogóle działają (odbywa się to poprzez proste wykonanie polecenia ping). Do sprawdzania dostępności poszczególnych portów skrypt używa programu nmap 3.00 [3]. Listing 1 pokazuje skrypt powłoki Bash (no cóż, zapewne Perl jest bardziej eleganckim rozwiązaniem Michael Schilli autor naszej kolumny o Perlu będzie załamywał ręce czytając ten artykuł). W naszym przykładzie serwer generuje następujące komunikaty: Server 10.0.0.2 (funghi.u kuehnast.com): ping OK 10.0.0.2: Port 25 is up 10.0.0.2: Port 80 is up 10.0.0.2: Port 110 is up Dla przeprowadzenia testu zatrzymałem ręcznie serwer Apache: Server 10.0.0.2 (funghi.u kuehnast.com): ping OK 10.0.0.2: Port 25 is up 10.0.0.2: Port 80 is down 10.0.0.2: Port 110 is up 63
Monitorowanie sieci Działa tak jak oczekiwaliśmy. Jednak dla wielu początkujących administratorów wyprowadzanie komunikatów na konsolę jest mało przydatne. Większy sens oprócz wyprowadzania komunikatów na konsolę miałoby zapisywanie komunikatów do pliku zdarzeń syslog-a. Ponadto skrypt nie będzie uruchamiany ręcznie i lepiej go uruchamiać jako zadanie cron-a. Dobrze byłoby pomyśleć o bardziej praktycznym przesyłaniu alarmów przez e-mail czy SMS [4]. Alternatywne sposoby alarmowania Sposób alarmowania zależy oczywiście od tego, jaką rolę pełni monitorowany serwer, przede wszystkim musimy uniknąć wysyłania alarmów co 5 minut. Nawet jeśli masz w swoim telefonie komórkowym ustawiony zabawny dzwonek, to nieustanne odbieranie SMS-ów z alarmami doprowadzi cię do szału. Skrypt wymaga zatem kilku modyfikacji po uruchomieniu powinien zadziałać według następującego algorytmu: Jeśli host lub port nie działa, to sprawdź czy wyłączył się po wcześniejszym wykonaniu się skryptu? Jeśli wszystko było OK podczas ostatniego sprawdzenia, upewnij się czy niedziałający host albo port działa poprawnie? 03 # Skrypt sprawdzajacy czy serwer odpowiada i 04 # czy jest dostepny lm-livecheck 07 08 for i in `ls $WDIR/etc/`; do 09 10 ## wyciagamy IP i FQDN z nazwy pliku 11 IP=`echo $i cut -f1 -d'_'`; 12 NAME=`echo $i cut -f2 -d'_'`; 13 14 ## pingujemy serwer sprawdzajac czy dziala 15 PING=$(/bin/ping -c2 -q -w2 $IP grep transmitted cut -f3 -d',' cut -f1 -d',' cut -f 1 -d'%') 16 if [ $PING -eq ' 0' ]; then 17 ## serwer dziala Listing 1. Skrypt simple_livecheck.sh Rysunek 1: Wykres obciążenia serwera WWW wskazuje, że narzędzie do wykonywania kopii zapasowych zajmuje zbyt wiele zasobów serwera. Administrator powinien rozważyć to definiując wartości progowe dla alarmów. W przeciwnym wypadku po uruchomieniu nocnego backup-u, gdy wartość loadavg przekroczy 5.0, nieustannie będą generowane alarmy, które zaleją SMS-ami komórkę administratora. 18 echo 'Server $IP ($NAME): ping OK'; 20 ## teraz sprawdzamy porty 21 for j in `cat $WDIR/etc/$i`; do 22 23 RET=`/usr/bin/nmap -r --host_timeout 2500 --initial _rtt_timeout 2000 -p $j $IP grep $j/tcp cut -f1 -d'/'`; 24 25 if [ -z $RET ]; then 26 echo '$IP: Port $j is down'; 27 ## Alarm: port nie odpowiada ## 28 else 29 echo '$IP: Port $j is up'; 30 fi 31 done 32 33 else 34 echo 'Server $IP ($NAME): no response'; 35 fi 36 done Pierwszym krokiem w rozbudowie skryptu alarm_livecheck.sh jest utworzenie podkatalogu deadhost w /usr/local/shellscripts/livecheck. Kiedy skrypt zidentyfikuje niedziałający host, po prostu tworzy plik zawierający adres IP w tym katalogu. W przypadku gdy usługa nie działa, skrypt wywołuje plik IP_Port. Jedynym przeznaczeniem tego pliku (może być pusty) jest informowanie skryptu, czy serwer działa, czy poprzednie uruchomienie skryptu zakończyło się powodzeniem oraz czy dana usługa albo serwer pracują. Listing 2 pokazuje gotowy do uruchomienia skrypt w tym celu możesz użyć cron-a. Skrypt dostarcza codziennych informacji na temat dostępności serwerów oraz udostępnianych przez nie usług. Dzięki temu możesz określić stopień dostępności usług i słabe punkty wydajności w sposób automatyczny bez potrzeby ręcznej analizy logów. Oczywiście jest wiele możliwości usprawnienia działania opisanych skryptów, a zwłaszcza dostosowania ich do lokalnych warunków i upodobań administratora. Obciążenie serwera Następną interesującą każdego administratora informacją jest to, jak ciężko pracują jego serwery. Można w tym celu wykorzystać kilka narzędzi, takich jak MRTG [5], RRD- Tool i Cacti. Wybrałem Cacti (w wersji 0.6.8) współpracujący z RRDTool 1.0.40. Cacti posiada elastyczną konfigurację i jest stosunkowo prosty, bliższy opis programu znajdziesz tutaj [6]. Cacti generuje zarówno statystyki dotyczące sieci, jak i obciążenia systemu (load average) te dwa parametry są najbardziej interesujące przy tworzeniu statystyk dostępności systemu. Wykresy obciążenia pozwalają natychmiast wychwycić nienormalne zachowanie, takie jak np. nagłe skoki obciążenia. Ostatnio Cacti pomógł mi w dość nieoczekiwanej sytuacji. Otóż przygotowałem pewien skrypt i uruchomiłem go jako zadanie cron-a na serwerze WWW. Cacti odczytywał /proc/loadavg w pięciominutowych odstępach informując mnie, że obciążenie systemu (load average) w krótkim czasie wzrosło dramatycznie do 8.0. Wykres wygenerowany przez Cacti na Rysunku 1 ilustruje ten nagły skok obciążenia. Wykres pokazuje, że obciążenie interfejsu sieciowego jest w normie, a zatem coś musiało się wydarzyć na samym serwerze. Dzięki temu dość szybko znalazłem winowajcę proces wykonywania kopii zapasowej. 64 Luty 2004 www.linux-magazine.pl
Zestawienia obciążenia sieci Jedną z istotnych cech Cacti jest możliwość zbierania i wyliczania globalnego obciążenia dla jednego lub wielu interfejsów sieciowych. Czy jednak nie byłoby dobrze wiedzieć, jakie jest obciążenie w rozbiciu na poszczególne usługi? Ponownie użyjemy funghi.kuehnast.com jako serwera testowego. Działa na nim serwer WWW, SMTP oraz POP3. Załóżmy, że Cacti wskazuje nadmierne obciążenie na interfejsie sieciowym pojawia się wówczas pytanie, która z usług jest źródłem problemów. Normalnie musiałbyś przekopywać się przez system, żeby znaleźć sprawcę problemów. Jednak lepszym wyjściem jest posiadanie narzędzia, które pokazuje obciążenie na każdym z portów. Moglibyśmy do tego celu użyć programu Cacti, jest jednak inne bardziej elastyczne narzędzie IPTraf i właśnie jego użyjemy. Narzędzie IPTraf Do zbierania danych wybrałem program IPTraf [7]. Jest to idealne narzędzie, ponieważ dostarcza szczegółowych informacji na temat interfejsów sieciowych zarówno bieżącego obciążenia na każdy z interfejsów, jak i wielkości pakietów oraz statystyk w rozbiciu na poszczególne porty. Posłużymy się programem IPTraf w wersji 2.7.0. Większość administratorów wykorzystuje IPTraf w trybie interaktywnym do przeglądania bieżącego ruchu sieciowego. Na szczęście IPTraf może także działać jako demon zapisuje wówczas rezultaty śledzenia w pliku (zazwyczaj /var/log/iptraf), który można później poddać przetwarzaniu. Dodaj do cron-a następujący wpis uruchamiający IPTraf: */5 * * * * /usr/sbin/iptraf -s U eth0 -t 5 -B -L /var/log/iptraf Parametr -s nakazuje, aby IPTraf zbierał dane o ruchu i sortował je według portów. Opcja -t 5 oznacza, że IPTraf po pięciu minutach przerwie pracę i zapisze rezultaty obserwacji do pliku. Opcja -B oznacza, że IPTraf jest uruchamiany w trybie demona. IPTraf tworzy pliki w formacie podobnym do poniższego: TCP/25: 169107 packets, 90804448 bytes total; 96958 packets, 86978452 bytes incoming; 72149 packets, 3825996 bytes outgoing TCP/110: 20174 packets, 7575496 bytes total; 8251 packets, 360974 bytes incoming; 123 packets, 7214522 bytes outgoing Listing 2. Skrypt alarm_livecheck.sh 03 # Skrypt sprawdza czy serwer odpowiada 04 # w razie bledu uruchamia alarm 06 07 WDIR=/usr/local/shellscripts/ lm-livecheck 08 09 for i in `ls $WDIR/etc/`; do 10 11 ## wyciagamy adres IP i FQDN z nazwy pliku 12 IP=`echo $i cut -f1 -d'_'`; 13 NAME=`echo $i cut -f2 -d'_'`; 14 15 ## pingujemy serwer sprawdzajac czy dziala 16 PING=$(/bin/ping -c2 -q -w2 $IP grep transmitted cut -f3 -d',' cut -f1 -d',' cut -f 1 -d'%') 17 if [ $PING -eq ' 0' ]; then 18 ## serwer dziala echo 'Server $IP ($NAME): ping OK'; 20 21 ## sprawdzamy tutaj czy host nie jest wylaczony 22 if [ -e $WDIR/deadhost/$IP ]; then 23 echo 'Server $IP ($NAME) came back to life'; 24 rm $WDIR/deadhost/$IP; 25 fi 26 27 ## tutaj sprawdzamy porty 28 for j in `cat $WDIR/etc/$i`; do 29 30 RET=`/usr/bin/nmap -r --host_timeout 2500 --initial _rtt_timeout 2000 -p $j $IP grep $j/tcp cut -f1 -d'/'`; 31 32 if [ -z $RET ]; then 33 echo '$IP: Port $j is down'; 34 35 ## sprawdzamy czy port byl wczesniej wylaczony 36 if [ -e $WDIR/deadports/$IP_$j ]; then 37 echo 'Port $j on server $IP ($NAME) is still dead'; 38 else 39 echo 'Port $j on server $IP ($NAME) has just died'; 40 touch $WDIR/deadports/$IP_$j; 41 ## umiesc tutaj polecenie wysylajace alarm ## 42 fi 43 else 44 echo '$IP: Port $j is up'; 45 ## sprawdzamy czy port byl wylaczony i czy uruchomil sie poprawnie ## 46 if [ -e $WDIR/deadports/$IP_$j ]; then 47 echo 'Port $j on server $IP ($NAME) came back to life'; 48 rm $WDIR/deadports/$IP_$j; 49 fi 50 fi 51 done 52 53 else 54 echo 'Server $IP ($NAME): no response'; 55 56 ## sprawdzamy czy serwer byl wczesniej wylaczony 57 if [ -e $WDIR/deadhost/$IP ]; then 58 echo 'Server $IP ($NAME) is still dead.'; 59 else 60 echo 'Server $IP ($NAME) has just died.'; 61 touch $WDIR/deadhost/$IP; 62 ## umiesc tutaj polecenie wysylajace ## 63 fi 64 65 fi 66 done 65
Monitorowanie sieci Szczególnie interesujące jest wartość bytes total i powinniśmy ją zachować do późniejszych analiz. Dlatego potrzebne jest zapisanie ich w RRD (Round Robin Database), żeby stanowiły podstawę do generowania histogramów. W tym celu musisz utworzyć podkatalog o nazwie data, będą w nim przechowywane pliki z danymi dotyczącymi poszczególnych usług. Nazwa usługi i data będą zapisywane bezpośrednio w nazwie pliku. Przykładowo plik smtp-history.20031115 będzie zawierał dane na temat ruchu SMTP zarejestrowane przez IPTraf 15 listopada 2003. Baza statystyk dla Cacti Zajmijmy się teraz RRD: najpierw utwórz podkatalog o nazwie rrdtool w katalogu /usr/local/shellscripts/iptraf. Będzie tutaj przechowywana baza danych dla naszego przykładowego serwera. Samo polecenie tworzące bazę jest nieco skomplikowane: 01 rrdtool create /usr/local/ shellscripts/iptraf/rrdtool/ mailserver.rrd \ DS:smtp:ABSOLUTE:600:U:U \ 03 DS:pop3:ABSOLUTE:600:U:U \ 04 RRA:AVERAGE:0.5:1:600 \ RRA:AVERAGE:0.5:6:700 \ 06 RRA:AVERAGE:0.5:24:775 \ 07 RRA:AVERAGE:0.5:288:797 \ 08 RRA:MAX:0.5:1:600 \ 09 RRA:MAX:0.5:6:700 \ 10 RRA:MAX:0.5:24:775 \ 11 RRA:MAX:0.5:288:797 Krótka uwaga dla osób znających narzędzie RRDTool w przeciwieństwie do danych zbieranych poprzez SNMP, źródło danych nie jest kwalifikowane jako CO- UNTER, lecz jako ABSOLUTE. Jest tak, ponieważ IPTraf zeruje swój licznik co pięć minut. Postępując analogicznie, możesz dodać RDD dla innych serwerów, pamiętając o zastąpieniu pliku mailserver.rrd i wpisów DS. Mimo, że powyższe długie polecenie tworzenia bazy wystarczy wykonać jeden raz, najlepiej jest je wpisać do skryptu, aby można było szybko włączyć monitorowanie dla kolejnego nowego serwera. Listing 3. Skrypt plot_mailserver.sh 03 sleep 5 # dajemy czas IPTraf zeby zapisal wyniki do pliku 04 TRAFLOG=/var/log/iptraf iptraf 07 TODAY=$(/bin/date +%s) 08 UDATE=$(/bin/date +%Y%m%d) 09 10 SMTP=$(grep 'TCP/25' $TRAFLOG tail -n1 cut -f2 -d',' cut -f2 -d' ') 11 POP=$(grep 'TCP/110' $TRAFLOG tail -n1 cut -f2 -d',' cut -f2 -d' ') 12 13 echo 'smtp: $SMTP' 14 echo 'pop3: $POP' 15 16 if [ -z $SMTP ]; then 17 SMTP='0'; 18 fi 20 if [ -z $POP ]; then 21 POP='0'; 22 fi 23 24 # wyniki archiwizujemy 25 26 echo $SMTP > $WDIR/data/smtp-history.$UDATE 27 echo $POP > $WDIR/data/pop-history.$UDATE 28 29 rrdtool update $WDIR/rrdtool/ mailserver.rrd $TODAY:$SMTP: $POP3 30 31 # rysujemy wykres 32 33 rrdtool graph /usr/local/ httpd/htdocs/protostats/ mailserver.gif \ 34 --start -86400 \ 35 --vertical-label 'bytes per second' \ 36 -w 600 -h 200 \ 37 DEF:smtp=$WDIR/rrdtool/ mailserver.rrd:smtp:average \ 38 DEF:pop3=$WDIR/rrdtool/ mailserver.rrd:pop3:average \ 39 AREA:smtp#00ff00:'SMTP traffic' \ 40 LINE1:pop3#0000ff:'POP3 traffic' Krótki skrypt o nazwie plot_mailserver.sh (patrz Listing 3) zajmuje się archiwizacją i rysowaniem wykresów. Rysunek 2 pokazuje wyniki jego działania. Podobne skrypty można łatwo napisać dla każdej innej usługi, którą chcesz obserwować, np. HTTP, FTP lub NNTP. Skrypty i narzędzia opisane powyżej dają administratorom solidną bazę wiedzy, która pozwoli rozwiązywać problemy z wydajnością i znajdywać słabe punkty infrastruktury. W moim przypadku nie musiałem długo czekać na okazję przetestowania przydatności tego rozwiązania. Nagła śmierć Zastanówmy się nad następującym, jakże częstym scenariuszem serwer pocztowy zawiesza się od czasu do czasu (właśnie z czymś takim miałem do czynienia niedawno). Łańcuch wydarzeń jest zawsze taki sam: pierwszy alarm jest generowany przez skrypt alarm_livecheck.sh, ponieważ port SMTP nie jest dostępny, następnie przestaje działać port POP3, niebawem serwer odpowiada nieregularnie tylko na ping i wreszcie w ogóle przestaje odpowiadać. Wykres obciążenia sieci, wygenerowany przez Cacti, pokazuje wzmożoną aktywność interfejsu sieciowego na około 30 minut przed zawieszeniem serwera, ale nie było to coś, co mogło zawiesić Postfix-a. Wykres Loadavg dawał więcej do myślenia: pokazywał skoki obciążenia do 40 i nagły spadek do 0. Takie symptomy są typowe dla maszyn, które mają zbyt mało pamięci RAM i muszą od czasu do czasu intensywnie korzystać z powolnej pamięci wirtualnej. Rzeczywiście serwer pocztowy miał 64 MB pamięci RAM i 128 MB pamięci wirtualnej (swap). Z drugiej strony serwer Postfix nie jest zbyt łapczywy na zasoby serwera. To skierowało moją uwagę na kolejnego podejrzanego program Spamassassin [8], który niedawno zainstalowałem. Żeby przeprowadzić ostateczny test, uruchomiłem program top i wysłałem setkę wiadomości do serwera pocztowego z innej maszyny. Niedługo potem Spamassassin zapchał pamięć serwera pocztowego do granicy pamięci wirtualnej. W tej sytuacji wymyśliłem dwa rozwiązania: sztuczne spowalnianie serwera Postfix w celu zredukowania częstotliwości przetwarzania wiadomości. Dałoby to czas programowi Spamassassin na zakończenie przetwarzania warunków antyspamowych i zwolnienie pamięci. Ta- 66 Luty 2004 www.linux-magazine.pl
ka konfiguracja byłaby łatwa do osiągnięcia poprzez odpowiednią konfigurację main.cf, chociaż jest to dość nieeleganckie rozwiązanie. zainstalowanie większej ilości pamięci RAM. Byłem zwolennikiem drugiego rozwiązania. Problem zniknął po dodaniu 512 MB pamięci RAM i 1 GB pamięci wirtualnej. Ten przykład pokazuje, że rozwiązywanie tego typu problemów jest łatwiejsze, jeśli monitorowane jest zużycie pamięci przez system. Rysunek 2: Wykres utworzony przez skrypt plot_mailserver.sh pokazujący obciążenie portów 25 i 110. Jak widać na tym drugim porcie brak aktywności. Monitorowanie użycia pamięci Trzymając się sprawdzonego wcześniej podejścia, postanowiłem napisać krótki skrypt, który odczytuje informacje o zajętości pamięci RAM i pamięci wirtualnej z /proc/meminfo, zapisuje wyniki do RRD i rysuje wykres na podstawie pobranych informacji. Oczywiście pierwszym krokiem będzie stworzenie RRD: 01 rrdtool create /usr/local/ shellscripts/iptraf/rrdtool/ mailmemory.rrd \ DS:ram:GAUGE:600:U:U \ 03 DS:swap:GAUGE:600:U:U \ 04 RRA:AVERAGE:0.5:1:600 \ RRA:AVERAGE:0.5:6:700 \ 06 RRA:AVERAGE:0.5:24:775 \ 07 RRA:AVERAGE:0.5:288:797 \ 08 RRA:MAX:0.5:1:600 \ 09 RRA:MAX:0.5:6:700 \ 10 RRA:MAX:0.5:24:775 \ 11 RRA:MAX:0.5:288:797 Dla zachowania przejrzystości, baza będzie przechowywana wraz z wykresami obciążenia sieci w używanym już poprzednio katalogu rddtool. Zauważ, że źródło danych jest w tym przypadku zdefiniowane jako GAU- GE. Jest tak, ponieważ w przeciwieństwie do danych programu IPTraf, licznik nie jest tym razem zerowany po każdym odczycie. Po utworzeniu bazy, skrypt meminfo.sh pokazany na Listingu 4, może zacząć zbierać dane i generować wykres. Patrząc w kryształową kulę Oczywiście funkcja archiwizacji skryptu IPTraf jest bardzo przydatna i zamierzam Listing 4. Skrypt meminfo.sh jej użyć w przyszłości do generowania średnioterminowych prognoz obciążenia sieci. Rzut oka na wykres RRDTool pokazuje liniowy wzrost obciążenia sieci w określonym przedziale czasu. Pozwala to na przewidywanie przyszłych problemów z wydajnością. Pierwszym krokiem do tego jest generowanie linii trendu hipotetycznej linii, która przebiegając przez cały wykres, odzwierciedla średnie wartości obciążenia. Drugim krokiem jest wyliczenie gradientu, przy założeniu, że przyszłe wyniki będą leżały w sąsiedztwie linii trendu. Ta metoda jest przydatna pod warunkiem, że twój system już teraz nie osiągnął granicy wydajności. Oczywiście sama sieć WAN także może przestać działać, jednak taka możliwość jest wprost proporcjonalna do wielkości twojego ISP, większe firmy zazwyczaj posiadają łącza zapasowe i routing dynamiczny. 03 # Skrypt sprawdza ilosc wolnej pamieci (RAM i swap) i 04 # uzywajac RRDTool rysuje wykres iptraf 07 TODAY=$(/bin/date +%s) 08 09 ## pobieramy informacje o pamieci z /proc/meminfo 10 11 RAM=`grep MemFree /proc/ meminfo tr -s [:blank:] cut -f2 -d' '` 12 SWAP=`grep SwapFree /proc/ meminfo tr -s [:blank:] cut -f2 -d' '` 13 14 ## zapisujemy dane do RRD 15 16 rrdtool update $WDIR/rrdtool/ mailmemory.rrd $TODAY:$RAM:$SWAP 17 18 ## rysujemy wykres 20 rrdtool graph /usr/local/httpd/htdocs/ protostats/mailmemory.gif \ 21 --start -86400 \ 22 --vertical-label 'kbytes free' \ 23 -w 600 -h 200 \ 24 DEF:ram=$WDIR/rrdtool /mailmemory.rrd:ram:average \ 25 DEF:swap=$WDIR/rrdtool /mailmemory.rrd:swap:average \ 26 AREA:ram#00ff00:'RAM' \ 27 LINE1:swap#0000ff:'Swap' INFO [1] D. Ruzicka, Network Management with Nagios, Netsaint s Sucessor : Linux Magazine, numer 29, str. 62 [2] J. Fritsch and T. Aeby, Always There: Introducing Network Monitoring with Big Sister : Linux Magazine, numer 38, str. 55 [3] Nmap: http://www.insecure.org/nmap [4] C. Kühnast, The Sysadmin s Daily Grind: Yaps : Linux Magazine, numer 30, str. 55 [5] W. Boeddinghaus, Network Management with MRTG : Linux Magazine, numer 24, str. 56 [6] A. Schrepfer, Graphical Monitor: Cacti Web Front-end for RRDtool : Linux Magazine, numer 35, str. 55 [7] IPTraf: http://iptraf.seul.org [8] Spamassassin: http://eu3.spamassassin.org 67