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