monitorowanie-dostepnosci-i-wydajnosci, informatyka-zbiór-2

[ Pobierz całość w formacie PDF ]
Monitorowanie dostepnosci i wydajnosci.
Ziemek Borowski
Pingwinaria 2001. Szczytno 6-8.07.2001
1 Problem: wiedziec co i w jaki sposób działa
Czesto spotykanym problemem w bardziej złozonych instalacjach jest zbieranie danych o istotnych para-
metrach pracy systemu, oraz informacji o awariach
1
. Rózne s a metody pozyskania tych informacji: od naj-
prostszego w implementacji – czekac na zgłoszenia uzytkowników, zazwyczaj rozsierdzonych nie działaniem
którejs z usług (i tutaj generalnie wkraczamy w poboczny dla naszych rozwaza n problem usług help-desku),
poprzez proste skrypty pinguj ace poszczególne maszyny, programy pozwalaj ace na systematyczne zbieranie
danych o dostepnosci – tak samych maszyn jak i ich usług – az do złozonych systemów zarz adzania sie-
ci a. Spróbuje opisac dostepne oprogramowanie Open Source pozwalaj ace na monitorowanie infrastruktury,
zbieranie informacji o obci azeniu poszczególnych systemów, a takze próbuj acych ułatwiac zarz adzanie i nad-
zorowanie wielkich systemów.
2 Proste monitorowanie dostepnosci
2.1 Najprostszy mozliwy skrypt
Ponizszy skrypt moze byc uruchamiany z crona co jakis czas. Mozna puscic go tez w niesko nczonej petli.
#!/bin/sh
for host in 192.168.42.{1,2,3}
do
ping -c 2 $host > /tmp/o.$i || mail -s "$host: down " zmb < /tmp/o.$host
done
Oczywiscie przy pomocy np.
netcat
a mozna adaptowac go do wiekszosci usług TCP/IP. Sam skrypt
w tej postaci zakłada niezachwian a prace poczty elektronicznej (co moze byc złudne). Alternatywnym po-
mysłem jest np. wysyłanie SMS przy pomocy telefonu podł aczonego do serwera monitoruj acego (np. pakiet
gnokii
pozwala na wysyłanie SMSów z linii komend, dla niektórych typów aparatów).
2.2 BigBrother
Pierwszym programem przeznaczonym do monitorowania zdalnych maszyn, którego próbowałem uzyc
w administrowanych przeze mnie sieciach był
BigBrother
Seana MacGuire. Powstał w 1997 roku, jako
prosty zestaw skryptów
bash
a – i w takiej postaci (minimalnie zmodyﬁkowanej – czesc rzeczy przepisano
do C) istnieje do dzis. Posiada relatywnie prosty plik konﬁguracyjny
$BBHOME/etc/bbhosts
w postaci:
1
Nieco innym problemem (nie poruszanym tutaj) jest problem nadzoru zwi azanego z bezpiecze nstwem systemów (przegl adanie
i automatyczne sumowanie logów, systemy wyrywania intruzów, kontrola narusze n reguł ﬁrewalla).
1
# THE BIG BROTHER HOSTS FILE
group STE servers farm
172.16.249.9 nt-dc-009 #
group World network
193.59.201.34 www.nask.pl #
Pozwala na róznicowanie sposobów powiadamiania poszczególnych osób odpowiedzialnych za usługi (plik
$BBHOME/etc/bbwarnrules.cfg
). Działa w srodowisku klient-serwer: posiada agenty na rózne po-
pularne systemy, odpowiadaj ace na pytania (na porcie 1984) dotycz ace stanu monitorowanego systemu (nie
uzywa SNMP ani innych standaryzowanych metod dostepu).
Z zauwazonych wad: potworne kolory, brak prostych mozliwosci dostosowywania, nieklarowna licencja
(generalnie darmowy, choc autorzy sugeruj a mozliwe wpłaty na konto).
2.3 NetSaint
O wiele bardziej rozbudowanym narzedziem okazał sie
NetSaint
Ethana Galstada. Pozwala on na mo-
nitorowanie o wiele szerszego zakresu usług, przede wszystkim sieciowych, lub posiadaj acych sieciowe in-
terface (dzieki rozwijanym w powi azaniu, choc jako osobny projekt, „wtyczkom”): nie tylko HTTP, czy SSH
ale równiez Oracle Net8, MySQL, SMB, czy konkretne parametry SNMP. Pozwala na szeroki zakres reakcji
na zdarzenia – tak metod i warunków powiadamiania odpowiedzialnych za dan a grupe serwerów administra-
torów jak i (choc w mniejszym zakresie) reakcji pozwalaj acych na przywrócenie stanu pocz atkowego.
Podobnie jak i w wypadku BigBrother wiekszosc operacji na na interface uzytkownika wykonuje sie za
posrednictwem serwera HTTP i przegl adarki – równiez i tu nie ma specjalnych mozliwosci wpływania na
wygl ad. Choc trzeba przyznac, ze akurat tej czesci programu nie trzeba wielu zmian.
Z domyslnej konﬁguracji po zainstalowaniu nalezy na pewno zmodyﬁkowac plik
/etc/netsaint/hosts.cfg
zawieraj acy deﬁnicje serwisów do nadzorowania
2
. Zawiera on deﬁnicje hostów do monitorowania, usług
zwi azanych z tymi hostami, deﬁnicje kontaktów do powiadamiania (powi azane z grupami hostów). Ponizej
przykład typowej deﬁnicji hosta i usługi
host[cos]=cos;192.168.43.248;gw;check-host-alive;3;5;24x7;1;1;1;
service[cos]=PING;0;24x7;3;3;1;linux-admins;120;24x7;1;1;1;;check_ping
service[cos]=SMTP;0;24x7;3;3;1;linux-admins;120;24x7;0;0;0;;check_smtp
service[cos]=FTP;0;24x7;3;5;1;linux-admins;120;24x7;0;0;0;;check_ftp
Powyzsza deﬁnicja opisuje sprawdzanie hosta przez 24 godziny (przy czym co to oznacza deﬁniuje sie w
oddzielnej sekcji) co cztery minuty, pod k atem działania ICMP (ping), SMTP i FTP, z powiadamianiem tylko
w wypadku niedostepnosci echa ICMP (bez informowania o błedach w SMTP i FTP). Lista dostepnych usług
jest bardzo długa – nie dosc, ze istniej a wtyczki do znacznej czesci wykorzystywanych w srodowisku Open
Sources serwerów sieciowych, to jeszcze, dzieki
check_by_ssh
mozna kontrolowac procesy/wydarzenia
wewn atrz odległych maszyn. Podobn a rozszerzaj aca role spełnia
check_snmp
: mozna odpytywac go o do-
wolny OID – byle tylko z odpowiednimi parametrami (monitoruje w ten sposób zajetosc procesora na głównej
maszynie, oraz zajetosc dysków na naszej maszynie roboczej/routerze). Jedyn a wad a
check_snmp
jest fakt,
ze obsługuje niestety tylko SNMP v1 (choc mógłby i SNMP v2c i SNMP v3 poniewaz jak zwykle opiera sie
na
ucd-snmp
).
Podane wyzej opcje mog a byc modyﬁkowane przez inne parametry (np. informacje o przedziałach czasu w
jakich dana grupa administratorów powinna byc informowana o awarii). Kazdy z serwerów musi przynalezec
do jednej z grup:
hostgroup[blueskyers]=Linux server;linux-admins;cos
2
W wygenerowaniu nowej listy moze pomóc skrypt
nmap2netsaint.pl
2
Z kolei od grup zalezy informowanie o awariach – bowiem na bazie informacji o
hostgroup
tworzone s a
informacje o kontaktach
contactgroup[linux-admins]=Linux Administrators;z
contact[z]=Ziemek;24x7;24x7;1;1;0;0;0;0;notify-by-email;notify-by-email;z@ziembor.waw.pl;
Po wprowadzeniu jakichkowiek zmian w konﬁguracji warto sprawdzic ich poprawnosc:
netsaint -v
/etc/netsaint/netsaint.cfg
Jak na razie, jesli chodzi o monitorowanie dostepnosci usług
netsaint
wiekszosc moich potrzeb. Bra-
kuje mi troche powiadamiania SMSem (ale to jest raczej kwestia przył aczenia telefonu jako bramki SMSowej
i uzycia odpowiedniego oprogramowania) o awariach oraz nieco czytelniejszej konﬁguracji.
2.4 inne
mon –
– napisany przez Jima Trockiego z Trans-
meta Corp. został napisany w całosci w Perlu ;-). Pozwala na na monitoring sporej ilosci serwisów,
ustalaj ac, m.in. reguły dla kazdej z grup w całosci, nie bezposrednia dla kazdego z hostów z osobna.
Interface tak CLI jak i webowy.
BigSister –
– jeden z pierwszych programów nasladuj acych
BigBrother. Napisany w C, poza typowymi dla programów tej klasy sondami HTTP, SMTP, POP3 po-
siada takze moduł do pobierania danych po SNMP, potraﬁ takze wysyłac SNMP trap w wypadku wyst a-
pienia błedów. Pozwala nie tylko na alarmowanie o przekroczeniu warunków ale równiez na zbieranie
informacji o istotnych parametrach.
PIKT
–
Problem Informant/Killer Tool
–
– rozproszony
system monitorowania, zarz adzania konﬁguracj a oparty na zestawach skryptów i sond. Pozwala na deﬁ-
niowanie zachowania sie systemów w okreslonych sytuacjach (m.in. wysyłanie raportów, choc czesciej
np. restart usługi).
3 Zbieranie i analiza danych o wydajnosci
3.1 SNMP
SNMP – Simple Network Management Protocol – jest narzedziem słuz acym do konﬁguracji urz adze n sie-
ciowych i hostów działaj acych w sieciach IP. Pozawala na szeroki zakres operacji, pocz awszy od typowego
monitorowania poprzez sterowanie poszczególnymi urz adzeniami do zarz adzania – z wykorzystaniem dedy-
kowanych pakietów oprogramowania – całymi sieciami.
Historia
W drugiej połowie lat osiemdziesi atych, po ustabilizowaniu sie protokołu TCP/IP rozpoczeły sie
prace i starania nad unormowaniem protokołów i narzedzi zwi azanych z zarz adzaniem sieci a. Jedn a z pierw-
szych propozycji był
High Level Entity Management System
–
HEMS
. Równolegle OSI/ISO zapropono-
wało swój
Common Management Information Protocol
–
CIMP
oraz jego modyﬁkacje
CIMP over TCP/IP
(
CMOT
) do zarz adzania nie tylko sieciami opartymi na modelu OSI ale i do TCP/IP. Wreszcie trzecia gru-
pa zaproponowała (i co wazniejsze zaimplementowała na wielu dostepnych systemach operacyjnych)
Simple
Gateway Monitoring Protocol
–
SGMP
. Wobec takiego rozwoju sytuacji IAB powołało komitet, który zde-
cydował o wyborze (nie gotowego wtedy jeszcze)
CMOT
jako podstawowego protokołu zarz adzania sieci a.
SGMP
został zaakceptowany jako tymczasowe, prowizoryczne rozwi azanie (głównie z powodu dosc szero-
kiej akceptacji) maj ace byc zast apione z czasem przez
CMOT
. W celu umozliwienia transmisji z jednego
rozwi azania na drugie opracowany został (pod kierunkiem Marshalla T. Rose) szkielet, który mógłby byc
uzywany przez obydwa. Z czasem okazało sie, ze grupa opracowuj aca
Internet-standard Network Manage-
ment Framework
nie potraﬁ sie porozumiec co do szczegółów technicznych z grup a pracuj aca nad
CMOT
.
Efektem tego było powstanie
SNMP
jako samodzielnego protokołu – w RFC 1157, w maju 1990 roku.
3
Wkrótce po tym rozpoczeły sie prace nad kolejn a, drug a, wersj a protokołu. Rychło jednak okazało sie,
ze proponowane rozszerzenia nie odpowiadaj a przemysłowi – spowodowało to rewizje juz opublikowanych
propozycji i podzielenie SNMP v2 na kilka podzbiorów:
SNMP v2 z zabezpieczeniami na poziomie uzytkownika (SNMPv2u)
SNMP v2 z zabezpieczeniami na poziomie uzytkownika oraz dodatkowymi MIB-ami (SNMPv2*)
SNMP v2 bez jakichkowiek (poza juz istniej acym juz mechanizmem community) zabezpiecze n (SNNPv2c)
(RFC 1901 – 1996)
I jak zwykle odbiorcy standardów wybrali rozwi azanie łatwiejsze do implementacji i wyjasnienia, choc mniej
bezpieczne. Powszechnie zaakceptowany SNMPv2c pozostał w fazie RFC eksperyntalnego – i rozpocz ał sie
proces przygotowywania kolejnej wersji, v3, protokołu. W tej chwili SNMP v3 (zdeﬁniowany w RFC 2570-
2580) osi agn ał status Standard Track – dojrzałej propozycji gotowej do implementacji. Czesc dostawców
oprogramowania SNMP wspiera ten standard od dłuzszego juz czasu, choc problemem nadal jest jego po-
wszechna akceptowalnosc – choc np. cisco udostepnia go w swoich urz adzeniach, podobnie 3Com, choc
jeszcze nie np. Intel.
3.1.1 Bezpiecze nstwo!!!
Niezaleznie od zakresu implementacji MIBów w agencie standardowo udostepniany zestaw danych pozwa-
la bardzo duzo dowiedziec sie o odpytywanej maszynie. Pocz awszy od uzywanego systemu operacyjnego,
poprzez liste interface sieciowych sko nczywszy na procesach i ich PIDach. Uzytkownik maj acy dostep do
agenta, nawet w trybie RO zyskuje wiedze dostepn a uzytkownikom lokalnym!!!. I st ad sie bierze powszechna
niechec specjalistów od bezpiecze nstwa do SNMP – czeste stosowanie SNMP v1 lub nawet SNMP v2c, z
domyslnymi community powoduje, ze SNMP jest typow a furtk a do sieci... Szczególnie złoszcz a przykłady
pozostawiania (na routerach brzegowych) wł aczonego community
private
z prawem zapisu z całego swia-
ta. Kolejn a wad a jest uzywany protokół transportowy: UDP – utrudniaj acy szyfrowanie sesji (np. wewn atrz
tunelu SSLowego). Wada ta była by o wiele mniej istotna, gdyby bardziej powszechne było wsparcie (tak w
agentach, jak i w narzedziach wykorzystuj acych SNMP – stacjach zarz adzaj acych, programach monitoruj a-
cych itp) dla SNMP v3, a zwłaszcza
User Security Model
. Lub gdyby uzytkownicy staranniej ograniczali
dostep do agentów (np. na poziomie TCP/IP,
tcp_wrappers
lub samego
snmpd
).
3.1.2 ucd-snmp agent
UCD-SNMP
, czy moze raczej, od marca tego roku
NET-SNMP
jest projektem maj acym na celu implemen-
tacje agenta oraz narzedzi pomocnych w pracy z SNMP w systemach zgodnych z POSIX. Oparty został (w
znacznej czesci) o dokonania
cmu-snmp
– pierwszej z implementacji agenta SNMP na Linuksie (juz niestety
nie rozwijanej). W wersji 4.2.1 agent obsługuje udostepnianie nastepuj acych statystyk:
MIB-2 – statystyki sieciowe (RFC 1213)
własne rozszerzenia UCD (procesy, przestrze n dyskowa, pamiec, obci azenie systemu, komendy ze-
wnetrzne)
zasoby hosta (RFC 1514) (niepełna implementacja)
SNMPv3 (RFCs 2571-6)
Implementuje wiekszosc wytycznych SNMP v1, SNMP v2c, SNMP v3 oraz w celu współpracy z innymi
agentami (lub zródłami informacji o stanie systemu) SMUX (RFC 1227) master agent oraz AgentX (RFC
2257 ) tak w trybie master oraz subagent. Istotne jest równiez to, ze potraﬁ sie komunikowac takze po TCP
(daj ac – na przykład – mozliwosc tunelowania SNMP po SSLu).
4
Konﬁguracja
Minimalna konﬁguracja agenta polega na wyzerowaniu lub usunieciu plików:
/etc/snmp/snmpd.conf
,
/usr/share/snmp/snmpd.conf
oraz
/var/ucd-snmp/snmpd.conf
. Po starcie serwera w pliku logu
/var/log/snmpd.log
poja-
wi sie zapis:
2001-06-01 15:01:04 UCD-SNMP version 4.2
– agent bedzie pozwalał na odczyt
zmiennych z uzyciem community o nazwie
public
, bez mozliwosci zapisu (
private
nie działa – zreszt a,
w wypadku ucd-snmp pod Linuksem zapisywanie zwykle nie działa ;-). Nalezy czym predzej zmienic do-
mysln a community na wybran a przez nas, np.
rocommunity domek
. Mozna równiez uzyc pliku
EXAM-
PLE.conf
ze zródeł programu – odpowiednio go modyﬁkuj ac. Sugerowałbym te metode poniewaz (pomi-
jaj ac na chwile SNMP v3 i USM) pozwala ona zwiekszyc bezpiecze nstwo agenta, ograniczaj ac do n dostep
3
.
Szczegóły dotycz ace konﬁguracji agenta tak, aby uzywał opcji pochodz acych z SNMP v3 (takich jak uwie-
rzytelnianie poszczególnych uzytkowników, oraz ograniczanie dostepu do agenta) znajduj a sie w dokumen-
tacji pakietu (Zachecam zwłaszcza dokładne przejrzenie pliku
FAQ
oraz
Tutoriala (dostepnego niestety tylko on-line)).
Rozszerzanie funkcjonalnosci
Jedn a z podstawowych zalet agenta
ucd-snmp
agenta jest mozliwosc jego
rozszerzania, nie tylko przy pomocy mechanizmów takich jak AgentX, SMUX czy SNMP Proxy, ale równiez
przez np. przechwytywanie wyjscia okreslonych polece n, np. who
exec .1.3.6.1.4.1.2021.420 w
/usr/bin/w
. Podobn a metod a do exec jest uzycie dyrektywy
pass
– rózni sie tym, ze w drzewie MIBo-
wym nie s a zwracane statusy wykonania komend.
Co mozna monitorowac na hoscie Linuksowym
enterprises.ucdavis.memory
– zuzycie pamieci
enterprises.ucdavis.dskTable.dskEntry
– poziom zajetosci okreslonych (np. dyrektyw a
disk / 1000
w konﬁguracji agenta) przestrzeni dyskowych
enterprises.ucdavis.laTable.laEntry
– load systemu (
load 0 1 1
)
enterprises.ucdavis.systemStats
– statystyki zajetosci pocesora...
mib-2.host.hrSystem.hrSystemNumUsers
– ilosc aktywnych uzytkowników
mib-2.host.hrSystem.hrSystemUptime.0
– czas pracy hosta
mib-2.host.hrSystem.hrSystemProcesses
– działaj ace procesy
i wiele innych parametrów. . .
3.1.3 Narzedzia SNMP
narzedzia z pakietu ucd-snmp
Podstawowym narzedziem wykorzystywanym przeze mnie przy przygotowywaniu do monitorowania sie-
ci z uzyciem SNMP jest
snmpstatus
. Zwraca on podstawowe informacje o urz adzeniu, zawarte w MIB II,
pozwalaj ac zorientowac sie czy agent został poprawnie skonﬁgurowany.
z@n z$ snmpstatus -c zgadnij-kotku lxhost
[lxhost]=>[Linux foobar 2.2.19 #7 SMP Tue Apr 3 09:24:11 CEST 2001 i686] Up: 4 days, 7:16:25.25
Interfaces: 0, Recv/Trans packets: 4400840/4400840 | IP: 27669143/27020156
Czasem istnieje potrzeba zast apienia typowej konsoli SNMP (np. dedykowanego oprogramowania pocho-
dz acego od producenta sprzetu) i wprowadzenia pewnych danych z linii polece n. Słuzy do tego
snmpset
:
3
Wystarczy jedynie wymienic string
COMMUNITY
na porz adan a przez nas nazwe, oraz w miejsce
NETWORK
wpisac adres lokalnej
sieci. Wypada zmienic jeszcze kilka parametrów, takich jak np.
sysLocation
ale sam agent bedzie działał i bez tego.
5
[ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

kazimierz.htw.pl