Prawa ręka admina

Monitorowanie sieci
SYSADMIN
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
A
dministratorzy, 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 atrak-
cyjne 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 119.
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
www.linux-magazine.pl
Luty 2004
63
SYSADMIN
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?
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.
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 dostar-
Listing 1. Skrypt simple_livecheck.sh
01 #! /bin/bash
02
03 # Skrypt sprawdzajacy czy
serwer odpowiada i
04 # czy jest dostepny
05
06 WDIR=/usr/local/shellscripts/
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
64
Luty 2004
18 echo 'Server $IP ($NAME):
ping OK';
19
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
www.linux-magazine.pl
cza 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], RRDTool 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.
Monitorowanie sieci
Zestawienia obciążenia sieci
Narzędzie IPTraf
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.
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
SYSADMIN
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;
11923 packets,
7214522 bytes outgoing
Listing 2. Skrypt alarm_livecheck.sh
01 #! /bin/bash
02
03 # Skrypt sprawdza czy
serwer odpowiada
04 # w razie bledu uruchamia alarm
05
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
19 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)
24
25
26
27
28
29
30
came back to life';
rm $WDIR/deadhost/$IP;
fi
## tutaj sprawdzamy porty
for j in `cat $WDIR/etc/$i`; do
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
www.linux-magazine.pl
Luty 2004
65
SYSADMIN
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 \
02
03
04
05
06
07
08
09
10
11
DS:smtp:ABSOLUTE:600:U:U \
DS:pop3:ABSOLUTE:600:U:U \
RRA:AVERAGE:0.5:1:600 \
RRA:AVERAGE:0.5:6:700 \
RRA:AVERAGE:0.5:24:775 \
RRA:AVERAGE:0.5:288:797 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
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 COUNTER, 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
01 #! /bin/bash
02
03 sleep 5 # dajemy czas IPTraf
zeby zapisal wyniki do pliku
04
05 TRAFLOG=/var/log/iptraf
06 WDIR=/usr/local/shellscripts/
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
19
20 if [ -z $POP ]; then
21 POP='0';
22 fi
66
Luty 2004
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'
www.linux-magazine.pl
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-
Monitorowanie sieci
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.
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 \
02 DS:ram:GAUGE:600:U:U \
03 DS:swap:GAUGE:600:U:U \
04 RRA:AVERAGE:0.5:1:600 \
05 RRA:AVERAGE:0.5:6:700 \
06 RRA:AVERAGE:0.5:24:775 \
07 RRA:AVERAGE:0.5:288:797 \
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.
08
09
10
11
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
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 GAUGE. 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
01 #! /bin/bash
02
03 # Skrypt sprawdza ilosc
wolnej pamieci (RAM i swap) i
04 # uzywajac RRDTool rysuje wykres
05
06 WDIR=/usr/local/shellscripts/
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
SYSADMIN
14 ## zapisujemy dane do RRD
15
16 rrdtool update $WDIR/rrdtool/
mailmemory.rrd $TODAY:$RAM:$SWAP
17
18 ## rysujemy wykres
19
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'
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.
■
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
www.linux-magazine.pl
Luty 2004
67