Gradivni elementi monitoringa

Glavni smisao monitoringa je doći do informacija o trenutnom stanju sistema, u kontekstu

njegovih nedavnih performansi. Izvučene informacije pomažu u davanju odgovora na
mnoga važna pitanja, učestvuju u proveri nestandardnog ponašanja, omogućuju dolaženje
do dodatnih informacija u vezi sa događajem koji je prijavljen i pomažu u proceni kapaciteta
sistema. U ovoj nastavnoj jedinici ćemo se detaljnije baviti osnovama gradivnih blokova
sistema, od dna ka vrhu.

Prikupljanje podataka

Proces monitoringa počinje prikupljanjem podataka od strane prikupljačkih agenata

(collection agenata). Prikupljački agenti su specijalizovani programi koji se izvršavaju na
posmatranim entitetima kao što su hostovi, baze podataka ili mrežni uređaji. Agenti hvataju
važne sistemske informacije, pakuju ih u kvantitativne ulazne podatke i zatim dostavljaju
ove ulazne podatke monitoring sistemu, u definisanim vremenskim intervalima. Ulazi se
potom sređuju i postavljaju u metrike, kako bi bili predstavljeni kao tačke sa podacima u
vremenskim serijama, u sledećoj fazi. Prikupljanje ulaza može da bude kontinuiran proces ili
se može odvijati periodično, u vremenskim intervalima, zavisno od prirode merenja i cene
resursa koji su angažovani u prikupljanju podataka. Agenti za prikupljanje podataka mogu
da budu podeljeni u sledeće grupe.

• White box (bele kutije)

o Log parseri. Oni izvlače određene informacije iz log zapisa, kao što su statusni
kodovi ili vreme odgovora na zahtev sa web servera.
o Log skeneri. Njihova uloga je da broje ponavljanja nekog stringa u log
fajlovima, definisanog na osnovu regularnih izraza. Na primer, da biste
napravili uvid u standardne greške i kritične greške, možete da proverite broj
pojavljivanja regularnog izraza „ERROR|CRITICAL” u log fajlu.
o Čitači interfejsa. Oni čitaju i intepretiraju interfejse sistema i uređaja. Primer
može da bude čitanje iskorišćenosti procesora iz Linux/proc pseudo-fajl
sistema ili čitanje vrednosti temperature ili vlažnosti vazduha u data centru,
sa nekog specijalizovanog uređaja.

• Black box (crne kutije)

o Proberi, koji se pokreću van posmatranog sistema i šalju zahtev na sistem

kako bi utvrdili da li sistem odgovara na zahtev. Po tom principu funkcionišu
ping komande ili HTTP upiti veb-sajtu, kako bi se utvrdila njegova dostupnost.
o Sniferi nadgledaju mrežni interfejs i analiziraju statistiku saobraćaja kao što
je broj prenesenih paketa, oborenih od strane protokola.

Pre nego što prikupljanje podataka dođe na red, agenti moraju da budu implementirani na
posmatranim sistemima. Međutim, u nekim situacijama, može da bude poželjno da udaljeni
sistem bude nadgledan bez upotrebe implementiranih agenata. Ovaj alternativni pristup se

Copyright © Link group

naziva „agentless data collection”, tokom koga se podaci transportuju sa posmatranog
entiteta kroz dogovoren protokol i interpretiraju se van posmatranog sistema.

Možda ćete ponekad pribeći rešenju monitoringa bez agenata, u sistemima sa značajnim
restrikcijama u pogledu softvera koji se na njima koriste, kao što su zatvoreni sistemi na
kojima je onemogućeno dodavanje bilo čega od strane korisnika, sistemi koji ne podržavaju
pokretanje agenata i visokobezbednosni sistemi sa restrikcijama forsiranim od strane polisa.
Primeri prikupljanja podataka bez korišćenja agenata su:

• prikupljanje statističkih informacija sa zatvorenih operativnih sistema koji se

izvršavaju u mrežnom okruženju, koristeći Simple Network Management Protocol
(SNMP),
• Periodično pokretanje dijagnostičkih komandi preko SSH protokola i parsiranje izlaza,
• mountovanje /proc u Linuxu udaljenim putem preko sshfs fajl sistema za potrebe
lokalne interpretacije.

Monitoring bez korišćenja agenata ima i neke slabosti:

• nedostupnost mrežne veze između posmatranog i interpretacionog entiteta može

izazvati nedostatak nekih tačaka sa podacima u vremenskim serijama;
• postoji dodatni overhead, pošto podaci moraju prvo da budu transferovani do
interpretacionog entiteta, gde će ulaz biti raspakovan.

Monitoring overhead i efekti posmatranja

Agenti su procesi I, kao takvi, oni zauzimaju mali deo resursa na posmatranom entitetu. To
se zove monitoring overhead – mala cena koju je neophodno „platiti” u cilju prikupljanja
podataka. Ovaj overhead ne bi trebalo mešati sa efektima posmatranja, koji se odnose na
promenu u ponašanju konkretnog entiteta, u trenucima njegovog posmatranja.

Agenti mogu da generišu propratne efekte posmatranja ukoliko utiču na promenu stanja
posmatranog objekta ili kada se proces prikupljanja podataka intenzivira ili oslabi na osnovu
rezultata merenja. Na primer, pretpostavimo da neki agent meri performanse objekta
svakih 60 sekundi u sklopu uobičajne procedure. Ali kada izmerene vrednosti izađu van
definisanih granica, postavljena logika agenta navodi ga da pokrene probne procese svake
sekunde, kako bi se prikupile što detaljnije informacije. Ovakav pristup značajno intenzivira
učestalost proba, koje zauzimaju proporcionalno više resursa. Efekti posmatranja izazvani
dodatnim probama će verovatno pogoršati stanje sistema.

Veoma je važno da zapamtite da bi monitoring agenti trebalo da sačuvaju svoju logiku

jednostavnom i da pritom realizuju dva zadatka: prikupljanje ulaznih podataka i njihovo
prosleđivanje do monitoring sistema. Svaka dodatna funkcionalnost će dovesti do
nepotrebnih varijacija u procesu pretrage i detekcije.

Copyright © Link group

Pitanje:

Log skeneri funkcionišu na osnovu:

a. Regularnih izraza,
b. Overheada,
c. Propratnih efekata,
d. Statusnih kodova.

Objašnjenje: Uloga log skenera je da broje ponavljanja nekog stringa u log fajlovima,
definisanog na osnovu regularnih izraza.

Resursi

Svaka aktivnost u sistemu zauzima određenu količinu procesorskog vremena. Mnoge

aktivnosti zauzimaju i memorijske resurse ‒ razmena podataka zauzima bandwidth, podaci
zauzimaju skladišne kapacitete, a kumunikacija između uređaja koristi I/O protok. Paterni
korišćenja resursa se menjaju u zavisnosti od njihovog zauzeća. Veliki sistemi u kojima
postoje ljudski korisnici imaju težnju da prate paterne opterećenja na osnovu dnevnog
ritma, sa povećanom potrošnjom resursa tokom dana i smanjenim korišćenjem tokom noći.
Veoma je važno da pri analizi odredite o kom tipičnom paternu opterećenja je reč.
Monitoring korišćenja resursa može da vam pomogne u tome. Mrežni i računarski resursi
zahtevaju stalno praćenje.

Podaci o iskorišćenosti i dostupnosti resursa mogu da budu prikupljeni direktno sa uređaja

na kome se nalaze resursi. Nivoi korišćenja se dostavljaju u statističkoj formi, od drajvera
do programabilnog interfejsa.

• Mreža. Podaci isporučeni kroz mrežu putuju ponekada sa značajnijim kašnjenjem,

koje je uzrokovano digitalnim procesiranjem i fizičkim karakteristikama transportnih
medija. Mrežna konekcija takođe ima svoj ograničen kapacitet koji se definiše kao
količina informacija prenesena u jedinici vremena. Kašnjenje bi trebalo održavati na
što manjim vrednostima, a što je propusni opseg veći time su i performanse bolje.
Poremećaji u prenosu podataka mogu biti izraženi kroz povećanje kašnjenja i
smanjenje propusne moći mrežne konekcije.

Kako su računarske mreže centralni element ideje distribuiranih informacionih

tehnologija, svaki poremećaj u mreži će se nedvosmisleno manifestovati u
performansama celokupnog sistema. Aplikacije se dizajniraju tako što se polazi od
pretpostavke da mreža uvek funkcioniše, ali u realnosti je veoma opasno uzeti to kao
aksiom. U realnom okruženju gubitak paketa se događa, kašnjenja u mreži utiču na
performanse aplikacija, a propusna moć mreže je, više-manje, ograničena. Iz tih
razloga, praćenje mreže se postavlja kao neophodnost.

• Računski resursi. Osnovna valuta u sistemu informacionih sistema je jedinica

kapaciteta. Cena svake korisničke aktivnosti može da se izrazi u kontekstu resursa
koje koristi. Ali, prekoračenje vrednosti ove valute nije dozvoljeno, zbog čega je
važno neprekidno pratiti zauzeće resursa. Tipična računarska aktivnost u web servis
okruženju je – zahtev. Svaki zahtev zauzima resurse. U najblažem slučaju on
zauzima memoriju i procesorsko vreme, ali vrlo često zahtev čita i upisuje neke
podatke na druge uređaje kao što su hard diskovi, što dovodi do korišćenja I/O

Copyright © Link group

 protoka. Zauzeće bilo kog resursa potrebnog za realizaciju zahteva vodi do
formiranja takozvanog „uskog grla”. Paterni korišćenja ne mogu uvek da budu
predviđeni sa tačnošću od 100% i kratkotrajna nedostupnost resursa ne može uvek
biti sprečena adekvatnim planiranjem kapaciteta ili dinamičkim alociranjem instanci u
cloudu. Imajte na umu da zadovoljenje opterećenja pomoću dodatnih kapaciteta nije
uvek poželjno rešenje. Uzmimo na primer Denial of Service (DoS) napade, gde je cilj
hakera da obori servis tako što će upravljati opterećenjem deficitarnog resursa.
Monitoring računskih resursa u kontekstu sistemskog korišćenja je neophodan kako
bi se prepoznali paterni i reagovalo pravoremeno.

• Solution stack. Solution stack se najčešće sastoji od tri komponente: operativnog

sistema (OS), middlewarea i aplikacija koje se izvršavaju na vrhu stacka. Svaki sloj
generiše informacije o stanju pojedinačne komponente. Važno je da imate pregled i
prikupljene metrike za sve komponente solution stacka, zbog toga što greške mogu
da se pojave u bilo kom sloju. Što je više softverskih metrika koje prave izveštaje,
više zaključaka ćete moći da izvedete bez „kopanja” po logovima. Ne postoji ništa
loše u analizi logova (logovi sadrže krucijalne, precizne informacije koje se možda
nikada neće pojaviti u vremenskim serijama), ali plotovanje metrika je mnogo brže,
a uz to u većini slučajeva vam korist od preciznih podataka u logovima neće ni biti
potrebna, pošto ćete uvek imati potrebu da vidite slikoviti prikaz date situacije.

• Operativni sistem. Kako je čvrsto vezan za korišćenje resursa, monitoring

operativnog sistema ispituje korišćenje resursa više na softverskom nivou, pošto ima
za cilj da dođe do informacija o tome koliko se efikasno resursi koriste, u kojoj
proporciji i od strane koga. Uobičajeno, OS metrike izveštavaju o proporciji korisnik-
sistem u kontekstu procesorskog vremena, upravljanju virtuelnom memorijom
uključujući swapping i statistike o memoriji, upravljanju procesima, uključujući
context switching i stanje redova čekanja, kao i statistike na nivou fajl sistema, kao
što su inode informacije. Različiti operativni sistemi reaguju drugačije na različite
paterne korišćenja i u okviru svakog operativnog sistema mnogi parametri mogu da
se podešavaju. Fino podešavanje operativnog sistema u skladu sa konkretnom
sistuacijom može da rezultuje boljim performansama, koje će se odraziti i na
monitoring metriku. Pravovremeno ukazivanje na greške u radu fizičkog hardvera
ponekada može da bude prikazano u logovima na OS nivou, što administratoru
sistema omogućava da reaguje pre nego što sistem pređe u stanje nedostupnosti.

• Middleware. Iznad operativnog sistema se nalazi sloj middlewarea, kao platforma za

aplikacije. Ovaj sloj omogućuje standardan skup kombinujućih, namenskih
softverskih komponenti, koje zajedno funkcionišu kao mehanizam za generisanje
rešenja. Middleware u distribuiranim informacionim sistemima sadrži softverske web
servise i radna okruženja aplikacionih servera. Za potrebe monitoringa, oni generišu
informacije po zahtevu, prateći obim otvorenih sesija i stanja transakcija.

• Aplikacije. Aplikacione metrike sadrže specifične informacije samo o operacijama i

stanju aplikacija. One često imaju apstraktne konstrukcije visokog nivoa
karakteristične za vrstu aplikacija. Tako sistem za obradu serija podataka može da
prikaže seriju u obliku veličine i broja elemenata od kojih se sastoji. Sistem za
upravljanje sadržajem može da opiše operaciju promene na osnovu veličine promene
(veća ili manja), tipa (dodavanje, brisanja ili obe), vremena kada je korisnik preuzeo
update, itd. Ulazi aplikacija mogu da variraju od veoma retkih dugotrajnih događaja
(na primer, pokretanje sesije) do veoma velikog broja kratkotrajnih metrika (kao što
je prikaz online oglasa). U oba slučaja je sasvim odgovarajuće izmeriti njihovo vreme
obrade i prikazati ga u obliku utvrđenog kašnjenja. Merenja opeterećenja na nivou

Copyright © Link group

 aplikacija može da bude prikazano kroz ulazne nivoe (na primer, ulazni saobraćaj i
broj zahtevanih ulaza).

Dostupnost se takođe meri na aplikacionom nivou stacka. Problem u bilo kom od

nižih nivoa sistemskog stacka će dovesti do sveukupne nedostupnosti sistema. Zbog
toga, kako bi metrika dostupnosti imala značaj, ona mora da bude realizovana na
eksternoj lokaciji, pa se na taj način vrši merenje i parametara mreže.

• Korisničko iskustvo. Posmatranje ponašanja korisnika se sprovodi analitičkim web

softverom, kako bi se došlo do odgovora na pitanja o korisničkom iskustvu. Klasične
metrike korisničkog ponašanja koje se koriste na veb-sajtovima su merenje
prosečnog vremena provedenog na sajtu i procenat posetilaca sajta koji dolaze
ponovo (returning visitors). Monitoring ponašanja korisnika je veoma široka oblast,
kojom se bave neke druge discipline i neće biti predmet ovog kursa.

Rezime

• Proces monitoringa počinje prikupljanjem podataka od strane prikupljačkih agenata

(collection agents). Agenti hvataju važne sistemske informacije, pakuju ih u
kvantitativne ulazne podatke i zatim dostavljaju ove ulazne podatke monitoring
sistemu. Ulazi se potom sređuju i postavljaju u metrike, kako bi bili predstavljeni kao
tačke sa podacima u vremenskim serijama, u sledećoj fazi. Agenti za prikupljanje
podataka mogu da budu podeljeni u grupe navedena u nastavku.

o White box (bele kutije):

Log parseri,
Log skeneri,
Čitači interfjesa.

o Black box (crne kutije):

Proberi,
Sniferi.

• U nekim situacijama, može da bude poželjno da udaljeni sistem bude nadgledan bez
upotrebe implementiranih agenata. Ovaj alternativni pristup se naziva „agentless
data collection”.

• Monitoring overhead – mala cena koju je neophodno „platiti” u cilju prikupljanja

podataka. Efekti posmatranja se odnose na promenu u ponašanju konkretnog
entiteta, u trenucima njegovog posmatranja. Monitoring agenti bi trebalo da
sačuvaju svoju logiku jednostavnom i da pritom realizuju dva zadatka: prikupljanje
ulaznih podataka i njihovo prosleđivanje do monitoring sistema.

• Kompletan monitoring bi trebalo da pokrije tri glavne grupe metrika:

o dostupnost resursa,
o performanse softvera,
o ponašanje korisnika (tamo gde je to primenjivo).

Copyright © Link group

• Pun monitoring pokriva mreže, hardver, operativne sisteme, middleware, aplikacije i
skup ključnih indikatora performansi.

• Veliki sistemi u kojima postoje ljudski korisnici imaju težnju da prate paterne
opterećenja na osnovu dnevnog ritma, sa povećanom potrošnjom resursa tokom
dana i smanjenim korišćenjem tokom noći. Podaci o iskorišćenosti i dostupnosti
resursa mogu da budu prikupljeni direktno sa uređaja na kome se nalaze resursi.

o Mreža
o Računski resursi
o Solution stack
o Operativni system
o Middleware
o Aplikacije
o Korisničko iskustvo

Copyright © Link group