Sistem upozoravanja

Postoji mišljenje da je postavljanje sistema upozoravanja vrsta veštine, koja zahteva godine
vežbanja, što podrazumeva veliki broj pokušaja i grešaka. Međutim, u praksi često nije
moguće toliko čekati na sticanje potrebnog iskustva. Zbog toga je veštinu postavljanja
sistema upozoravanja bolje posmatrati kao naučnu disciplinu, zasnovanu na logici i
verovatnoći. U svakom slučaju, postavljanje sistema upozoravanja se svodi na balansiranju
između dva suprotstavljena cilja: osetljivosti (koja treba da da odgovor kada neku
anomaliju klasifikovati kao problematičnu) i specifičnosti (odnosno, kada je bezbedno
pretpostaviti da problem ne postoji). Ova dva cilja usmeravaju konfigurisanje sistema
upozoravanja u dva suprotna smera. Odabir prave strategije nije jednostavan zadatak.
Dobar izbor je uslovljen organizacionim prioritetima, nivoom oporavka koji je moguće
postići u posmatranom sistemu, kao i očekivanim posledicama kada stvari krenu po zlu. U
skladu sa svim navedenim, u ovoj nastavnoj jedini ćemo se baviti izazovima postavljanja
sistema upozoravanja, preduslovima za njegovo postavljanje, razjašnjavanjem grešaka i
njihovog uticaja na sistem, anatomijom upozorenja i vrstama upozorenja.

Izazovi u postavljanju sistema upozoravanja

U procesu iščekivanja pojave problema, nije moguće fokusirati se samo na vremenske

serije. Velika količina informacija koja protiče kroz sistem proizvodi veliki broj vremenskih
serija koje je moguće pratiti. Zapošljavanje velikog broja stručnjaka koji bi bili zaduženi
samo za posmatranje performansi grafika vremenskih serija nije ni finansijski, a ni
organizovano opravdano. Čak i kada bi se pribeglo takvom rešenju, teško da bi operateri
mogli da prepoznaju paterne na osnovu kojih bi bilo potrebno izdati upozorenje, bolje nego
što bi to sistem i softver uradili.

Proces upozoravanja (alerting) je prepun promenljivih varijabli koje su uglavnom

kvantitativne prirode, ali taj proces sa sobom nosi i određeni nivo odgovornosti. O
prioritetima u konfiguraciji sistema upozoravanja može da se diskutuje, ali nivo njihove
važnosti obično zavisi od toga šta se gubi ukoliko oni ne odrade svoj zadatak. Ukupan
pritisak koji se javlja u procesu odgovora na incidentne situacije je promenljiv od
organizacije do organizacije, ali ceo proces u različitim organizacijama ima jedinstven
patern. Cilj upozoravanja je skrenuti pažnju operatera, odnosno administratora na primetnu
degradaciju performansi, koja može da se manifestuje na tri standardna načina:

• smanjen kvalitet izlaza,

• povećano vreme odgovora (odziva),
• pojava nedostupnosti.

Zadatak operatera koji primi upozorenje, odnosno administratora zaduženog za monitoring,

je da odgovori na njega u vremenskom roku, koji odgovara ozbiljnosti problema
(degradacije performansi). Njegov zadatak je da izoluje i identifikuje izvor problema i ublaži
njegove posledice u što kraćem roku. Izazov balansiranja između osetljivosti i specifičnosti
se manifestuje u prijavljivanju upozorenja, što je pre moguće, ali bez formiranja lažnih
upozorenja.

Copyright © Link group

Preduslovi

Efektivan sistem upozoravanja je više od običnog kreiranja upozorenja (alarma) i slanja

notifikacija, s obzirom da je njegov zadatak da ujedno olakša ljudsku reakciju na pojavu
problema, kao i da doprinese kontinuiranom procesu unapređenja sistema. Da bi se ovi
ciljevi postigli, sistemu upozoravanja su potrebne neke osnovne komponente IT
infrastrukture, bez kojih ozbiljan organizacioni sistem ne bi mogao da postoji.

Platforma za nadzor i upozoravanje

Prvi, osnovni preduslov je posedovanje monitoring platforme koja zadovoljava nekoliko

uslova: ona mora da poseduje dobro podržan i lako odrediv način za implementaciju
agenata za prikupljanje podataka; trebalo bi da ima fleksibilan i funkcionalan mehanizam za
iscrtavanje grafikona, koji može da prikaže više vremenskih serija u istom grafiku; mora da
poseduje i sistem upozoravanja koji podržava sofisticirano konfigurisanja alarma (koji može
da broji i desetine hiljada alarma, a mora da podržava i agregaciju i deaktivaciju alarma).

Praćenje traga

Mnogi događaji su rezultat prestanka rada sistema zbog planiranih izmena u produkcionom
sistemu. Neke od tih izmena se pokreću automatski, kao što su periodične primene
bezbednosnih zakrpa, dok su druge manuelne, kao što su konfiguracione izmene koje
realizuje administrator mreže, po sistemu „korak po korak”. Upravljanje preciznim i
potpunim nadzorom (hronološkom evidencijom promena u sistemu), pomaže u markiranju
uzroka i posledica, tako što povezuje nedozvoljena stanja sistema sa tačnim vremenima u
evidenciji događaja (logovima). Na taj način se formira trag o svakom događaju u sistemu,
koji je moguće pratiti. Brzo otkrivanje grešaka na ovaj način značajno pospešuje proces
oporavka.

Praćenje događaja

Sistem za praćenje događaja (issue tracking system – ITS) pomaže u postavljanju prioriteta
prijavljenih upozorenja, što doprinosi praćenju situacije dok problem ne bude rešen.
Koordinacija osoba koje sarađuju na rešavanju problema se obavlja pomoću tiketa (tickets),
što obezbeđuje da ni u jednom trenutku proces rešavanja ne ostane nedovršen. Zbog toga
bi svako upozorenje trebalo da bude evidentirano u ITS-u. Na taj način, efektivnost sistema
upozoravanja može u bilo kom trenutku da bude relevantno izmeren.

Razumevanje grešaka i njihovih posledica

Uspostavljanje kompleksne konfiguracije sistema upozoravanja počinje još sa analizom

troškova uzrokovanih incidentnim situacijama i značaja pravovremene reakcije. Troškovi
mogu da se prikažu na različite načine, u obliku: vremena, novca, uloženog rada, kvaliteta
itd. Svaka kompanija može da formira sopstvene definicije. Suština je u tome da svaki
problem za posledicu ima određene troškove, koji odgovaraju stepenu uticaja problema na
rad sistema. Prvi potez koji bi trebalo preduzeti u cilju efikasnog upozoravanja je ustanoviti
jasan opseg značaja problema, u cilju ispravnog postavljanja prioriteta.

Copyright © Link group

Definisanje značaja problema

Kod velikog broja problema i incidentnih situacija koje mogu da se pojave u dnevnim
operacijama nekog sistema, samo jedan deo njih iziskuje opravdanu intervenciju
administratora. Problemu koji se pojavi dodeljuje se alarm kada je značaj tog problema
toliki da utiče na funkcionisanje sistema. Opšteprihvaćeno pravilo je da prag tog značaja
bude situacija u kojoj sistem ne može sam da se oporavi nakon što se problem javi. Zbog
toga, ozbiljnost neke incidentne situacije može da se analizira po dva osnova: mogućnost
oporavka i stepen uticaja na sistem.

Mogućnost oporavka je sposobnost sistema da povrati svoje stanje na nivo na kom je bio
pre nastanka problema, bez intervencije administratora. Mogućnost oporavka može da se
izrazi i kao odnos verovatnoće nestanka problema koji se javio i potrebnog vremena da se
taj proces realizuje.

Stepen uticaja na sistem može da se predstavi kao negativan efekat na sistemske

operacije, koji se manifestuje na nivou korišćenja resursa, kao i u pogledu korisničkog
iskustva. Može se predstaviti i kao neočekivani trošak, čije vrednosti variraju između
različitih amplituda. Neki od tipova problema koji imaju uticaj na sistem su:

• trajna nedostupnost,
• delimičan gubitak dostupnosti,
• povećano vreme odziva,
• smanjen kvalitet servisa,
• nedovoljno korišćenje resursa.

Mogućnost oporavka (Recoverability) i mogućnost uticaja na sistem (Impact) možemo

analizirati pomoću grafikona na slici 5.1. Grafik će nam bolje predstaviti ozbiljnost
neželjenih događaja, tako što događaje klasifikuje u devet odvojenih celina, čiji neželjeni
efekti idu od najmanje ozbiljnih do najozbiljnih.

Copyright © Link group

 4. Događaji koji mogu da se oporave. Negativni događaji koji nemaju kritičan efekat na
rad sistema, ali imaju potencijal da prerastu u veće probleme ukoliko ne usledi
intervencija administratora u predviđenom vremenskom roku. Na primer, problem u
pozadinskom map-reduce procesu inicijalno nije kritičan događaj po funkcionisanje
sistema i nije potrebno aktivirati alarm ukoliko otpočne proces koji za njim sledi, što
znači da je prethodni proces uspešno završen. U suprotnom, ukoliko u definisanom
vremenskom roku (računajući i kašnjenje u obradi) proces ne bude završen,
potrebno je aktivirati alarm.

5. Događaji koji ne zahtevaju intervenciju. Grupa događaja koja uzrokuje da manji broj
korisnika primećuje prolazne, ali ozbiljne probleme koji momentalno nestaju sami od
sebe. Zbog velike brzine oporavka, ovi događaji ne zahtevaju intervenciju jer su
rešeni „sami od sebe”, pre nego što administrator može da ih „uhvati” i analizira.
Zbog toga, nema nikakvog efekta aktivirati alarm za ovakav tip događaja. Učestalost
ovakvih događaja bi u svakom slučaju trebalo da se proverava, kako bi se potvrdilo
da su trenutni padovi u performansama ostali neznatni.

6. Automatizovani zadaci. Greške koje nemaju momentalni uticaj na funkcionisanje

sistema, ali imaju potencijal da doprinesu eskalaciji drugih problema.

7. Rani indikatori. Prolazni događaji koji imaju mali do srednji uticaj na manji skup
korisnika. Oni su posledica trenutnih opterećenja resursa i manjih grešaka u
softveru. Ovi događaji mogu da budu rani pokazatelji da sistem ne može uspešno da
realizuje sve zadatke u trenucima kada postoji veći broj zahteva.

8. Optimizacioni zadaci. Događaji koji nemaju nikakav efekat na rad sistema, ali mogu
da budu uzrok neefikasnom korišćenju resursa. Moguće ih je eliminisati hardverskim
restruktuiranjem sistema ili softverskom optimizacijom.

9. Ne uzrokuju nikakav problem. Anomalije čiji uticaj nije moguće primetiti i koje se
manifestuju kao sastavni deo drugih sistemskih operacija.

Samo prve četiri grupe događaja zahtevaju implementaciju sistema upozoravanja, zbog
toga što je samo u slučaju njihovog pojavljivanja sistem pod rizikom, pa je jedino tada
neophodna intervencija administratora u cilju promene stanja sistema. Za prve četiri grupe,
konfiguracija sistema upozoravanja se razmatra u kontekstu dva kontradiktorna cilja: brzine
i pouzdanosti detekcije problema.

Alarmi za kritične događaje bi trebalo da se aktiviraju čim se simptomi ozbiljnih problema

pojave. Kritični događaji zahtevaju momentalnu intervenciju, tako da je dopustivo da, na
štetu pouzdanosti detekcije problema, bude aktiviran pravovremeni alarm, kako bi se dobilo
dovoljno vremena za sprovođenje odgovarajuće akcije. Ako se nakon više javljanja alarma
za kritične događaje pojavi i nekoliko „lažnih”, to je prihvatljiva cena u cilju sveukupne
bezbednosti i stabilnosti funkcionisanja sistema.

Druga grupa događaja se klasifikuje kao urgentni događaji i oni isto tako zahtevaju brzu
intervenciju, ali njihova relativno visoka učestalost i manja opasnost od kritičnih događaja
dopuštaju mogućnost čekanja na kreiranje dodatnih tačaka podataka, pre aktivacije
upozorenja. Alarm se i kod ovih događaja aktivira relativno rano, ali sa većom pouzdanošću.

Sistemski problemi koji iziskuju intervenciju administratora sistema, ali ne momentalnu

intervenciju, dopuštaju mogućnost dodatnog vremenskog intervala u kome je moguće da

Copyright © Link group

prikupite još informacija. Upozorenje bi trebalo da se aktivira samo kada se konstatuje
postojanje problema sa visokim stepenom sigurnosti, odnosno kada je evidentiran dovoljan
broj tačaka podataka koje ukazuju na problem.

Slično kao u prethodnom opisu, događaji nakon kojih se sistem odmah oporavlja ne bi
trebalo da aktiviraju alarm, sve dok ne postane očigledno da oporavak traje isuviše dugo ili
dok se ne konstatuje da mogu da prerastu u ozbiljne probleme.

Preostalih pet grupa ne zahteva aktiviranje upozorenja, ali u mrežnim okruženjima nekih
kompanija, administratori mogu da se odluče da postave podešavanja koja će i za njih
aktivirati alarme i kreirati tikete niskog prioriteta, za potrebe evidencije i proučavanja van
sistema. U praksi, dovoljno je da događaji koji imaju uticaj od malog značaja budu
nadgledani i povremeno proučavani, kako bi se potvrdilo da njihov nivo uticaja na rad
sistema ne raste.

Identifikacija uzroka

Veliki spektar različitih uzroka koji mogu da izazovu greške i problem može da se klasifikuje
u četiri grupe.

1. Nedostupnost i preopterećenje resursa. Ovo je najčešći problem u produkcionim

sistemima. Zagušenja u mrežnom saobraćaju i preopterećenje resursa uzrokuju
povećanja vremena odziva. U ekstremnim slučajevima, ovi uzroci mogu da budu
odgovorni za kompletnu nedostupnost servisa. Događaji koji uzrokuju prekomerno
opterećenje resursa su:

1.1. Izuzetno visok nivo ulaza,

1.2. Maliciozni napadi,
1.3. Gašenje delova sistema u cilju održavanja,
1.4. Spektar grešaka uzrokovanih ljudskim faktorom,
1.5. Veoma često ovi uzroci postepeno dovode do opterećenja, dok su retke
situacije kada momentalno izazivaju pojavu opterećenja. Zbog toga ih je
moguće sprečiti ukoliko se detektuju na vreme. Dobro dizajnirani sistemi
imaju implementiran mehanizam prigušenja (throttling mechanism) ili
neku drugu vrstu ulazne kontrole za postepenu degradaciju performansi
pod povećanim opterećenjem, kako bi se sprečili brzi i teški padovi
sistema.

2. Softverski problemi. Softverske greške su prilično česte i tu spadaju arhitektonska

rešenja softverskog paketa, problemi zavisnosti i sl. Softverske greške su prisutne
svuda, ali verovatnoća za njihovo javljanje je veća u okruženjima sa većom
kompleksnošću, u privremenim verzijama aplikacija, lošem dizajnu i slaboj kontroli
kvaliteta softverskog proizvoda. Neke greške je moguće reprodukovati pod visokim
opterećenjem, dok se druge javljaju tek nakon dužeg perioda korišćenja softvera.
Kada se jednom identifikuju, moguće ih je otkloniti prilično brzo, kroz implementaciju
patcheva i updateova.

Softverski problemi ne mogu da nestanu sami od sebe, tako da je neophodno baviti

se njima na nivou dnevnih operacija. Kada proces monitoringa skrene pažnju
administratora na softverske greške, ti administratori bi trebalo da budu osposobljeni
za preduzimanje odgovarajućih korektivnih akcija. Da bi operacija otklanjanja

Copyright © Link group

 grešaka bila efektivna, administratorima je potrebna šema svih verzija i bogato
razvojno okruženje kako bi mogli da probaju izvršene izmene i vrše povratak na
prethodno stanje, ukoliko probe pokažu da problem nije otklonjen.

3. Greške u konfigurisanju. Ove greške su posebna vrsta operativnih grešaka, čiji je

uzrok ljudski faktor. Konfiguracione greške je teško pronaći namenskim traganjem za
njima. S obzirom da prolaze neprimetno u opažanju od strane čoveka, veći broj
ovakvih grešaka će uspešno proći i QA testove (ukoliko su Quality Assurance testovi
deo procesa konfiguracije sistema). One dovode do neželjenih posledica i često budu
primećene od strane korisnika, pre nego što proces ublažavanja posledica i može da
se preduzme. Tipičan primer mogu da budu greške u podešavanju bezbednosnog
softvera, gde će, na primer, antivirus za sve tipove fajlova prijavljivati da sadrže
maliciozni saržaj. Konfiguraciona podešavanja softvera bi trebalo pratiti i po
verzijama aplikacije, kako bi bilo moguće vratiti podešavanja u stabilno stanje u
skladu sa odgovarajućom verzijom, ukoliko izmene ne daju očekivane rezultate.

4. Hardverski problemi. Problemi u funkcionisanju hardvera se javljaju ređe nego

softverski problemi, ali kada se pojave, često ih je teško izolovati i njihovo rešavanje
može da bude skupo. Teškoće se nalaze u fizičkoj prirodi primene rešenja. Dok se
hardverske greške u sistemima srednje veličine otkrivaju u manjem obimu, one
imaju tendeciju naglog porasta u intenzivnije korišćenim produkcionim okruženjima.
Hardverske greške mogu da izazovu značajna kašnjenja u izvršavanju operacija ili da
izazovu totalno otkazivanje uređaja. Neki hardverski problemi mogu da budu
otkriveni pomoću pretrage poruka o greškama u logovima na nivou operativnog
sistema, ali većina njih ne prikazuje jasno svoje prisustvo. Greške postaju vidljivije
tokom nadgledanja grupe uređaja, gde pojedinačan uređaj ili host otkriva svoje
neobično ponašanje.

Anatomija alarma

Smisao alarma je njegovo pokretanje (okidanje) kada se detektuju nepravilnosti u

vremenskim serijama, ali bi sistem upozoravanja takođe trebalo da podržava agregaciju i
uslovno gašenje (deaktivaciju) alarma. Suštinski, sva tri načina funkcionisanja predstavljaju
mozaik kreiranja robusne i sofisticirane konfiguracije sistema upozoravanja. U ovom delu
nastavne jedinice ćemo predstaviti praktičan model za konfiguraciju alarma. Uz pomoć
takvog znanja, administratori mogu da dizajniraju veoma sofisticiranu konfiguraciju
alarmnog sistema, koristeći Bulovu (Boolean) logiku, čime će sistem održati jednostavnim i
funkcionalnim.

Bulova funkcija

Alarm može da bude prikazan u obliku Bulove funkcije. U bilo kom trenutku, njegova
vrednost vraća jedno od dva moguća stanja: „alarm” ili „ništa”. Njima možemo da dodelimo
binarne vrednosti 1 i 0, respektivno. Kada se rezultat obrade funkcije promeni iz 0 u 1 ili iz
1 u 0, takva situacija se zove promena stanja alarma ili alarm state transition. Alarmna
funkcija prikazuje odnose između određenih ulaza, koji mogu da pripadaju jednom od tri
tipa: metrički kontrolori (metric monitors), procena datuma/vremena (date/time
evaluations) i ostali alarmi. Sva tri tipa takođe mogu da imaju vrednosti 1 ili 0. Alarmna
funkcija se ponovo proračunava kada bilo koja od ulaznih komponenti promeni svoje stanje.
Svaki put ponovno izračunavanje stanja može da rezultuje u njegovoj promeni (iz 0 u 1 ili iz

Copyright © Link group

1 u 0) ili stanje može da ostane nepromenjeno. Ukoliko dođe do promene stanja, moguće je
okinuti predefinisanu transition akciju: slanje alarma, kreiranje tiketa ili obe.

U suštini, alarm može da se definiše kao zatvorena kutija u kojoj se nalaze uslovi i akcija
koje će se pokrenuti ukoliko su uslovi ispunjeni. Ovo predstavlja najjednostavniji model. Ali,
zavirimo sada u niže nivoe i elemente alarmne funkcije, kako bi bilo jasnije šta ovoj
konstrukciji daje mogućnost kreiranja sofisticiranih konfiguracija.

Metrički kontrolori

Metrički kontrolori ili metric controlors su srž većine alarma. Oni opisuju uslove
prekoračenja praga i menjaju njihovo stanje kada dođe do prekoračenja (ili pada ispod)
definisanih limita za tačke podataka, u posmatranim vremenskim serijama. Metrički
kontrolori su sastavljeni iz četiri dela:

• naziv i dimenzija metrike, zajedno sa sumarnom statistkom formiraju određenu

vremensku seriju;
• tip i vrednost praga;
• minimalno trajanje prekoračenja ili podbačaja (broj tačaka podataka iznad ili ispod
praga koji mora da se pojavi kako bi se alarm aktivirao);
• vreme potrebno za oporavak (definisana količina vremena tokom koga je potrebno
čekati da se tačke podataka vrate u normalno stanje, odnosno vreme nakon koga se
operacije sistema vraćaju u redovan režim funkcionisanja).

Često se događa da se posmatrane vremenske serije oporavljaju već posle prve

prekoračene tačke podataka. Takvi događaji uzrokuju mali efekat ili ga uopšte i ne uzrokuju.
Kako bi se izbeglo aktiviranje alarma zbog prolaznih anomalija, kontrolor definiše minimalni
broj tačaka podataka koje je potrebno da se pojave kako bi se prešlo u stanje upozorenja.
Suprotno tome, ukoliko je vremenska serija duži vremenski period u prekoračenju, jedna
regularna tačka podataka nije obavezno pokazatelj oporavka i svakako nije razlog da se
automatski proglasi da je stanje sistema regularno. Iz tog razloga, kontrolor bi trebalo da
definiše i minimalan broj regularnih tačaka podataka koje će biti garancija da je stanje
sistema postalo stabilno. Najčešće se koriste četiri tipa prekoračenja:

• iznad definisane vrednosti (gornja granica),

• ispod definisane vrednosti (donja granica),
• van opsega,
• tačke podataka nisu evidentirane.

Gornja granica. Kontrolori prekoračenja gornje granice se aktiviraju kada tačke podataka
prekorače definisanu vrednost. To su najčešće korišćeni tipovi prekoračenja. Kada u
metrikama posmatrate ekstremno visoke vrednosti povećanog korišćenja resursa (što često
vodi i ka povećanju troškova) ili ekstremno visoke vrednosti degradacije performansi,
preporuka je da koristite kontrolor prekoračenja gornje granice. Na taj način ćete omogućiti
da vam metrike za praćenje korišćenja resursa izbace upozorenje o dostizanju definisanih
limita, a metrike za praćenje kašnjenja da prikažu upozorenje o usporenom izvršavanju
serverisa.

Donja granica. Kontrolori prekoračenja donje granice se aktiviraju kada nivo izmerenih
vrednosti padne ispod definisane granice. Njihova uloga je da skrenu pažnju administratora

Copyright © Link group

na depresiju u grafiku ili odsustvo toka događaja ili prestanak korišćenja resursa. Donje
granice su posebno korisne u metrikama protoka. Takođe su dobre i za upozoravanje na
gubitak dostupnosti.

Van opsega. Kontrolori izlaska van opsega se koriste u vremenskim serijama u kojima se
očekuje da njihove tačke podataka osciliraju u oblasti ograničenom donjom i gornjom
graničnom vrednošću. Korisni su za nadgledanje dvosmernog odstupanja od standardne
norme. Kontrolor izlaska van opsega može da se predstavi kao kombinacija dva kontrolora:
kontrolora prekoračenja donje granice i kontrolora prekoračenja gornje granice, koji su
povezani logičkim OR (ILI) operatorom. Analogno tome, postoji mogućnost pravljenja
kontrolora unutrašnjeg opsega, ali takvi kontrolori se uglavnom retko koriste.

Objašnjenje

U većini slučajeva kontrolori prekoračenja gornje granice bolje zadovoljavaju potrebe

nego kontrolori izlaska van opsega. To što grafik vremenske serije oscilira u određenom
opsegu ne znači da je dobro rešenje koristiti praćenje izlaska van opsega. Uzmimo za
primer metriku korišćenja DNS keša izraženu na sledeći način: prati se koji procenat
zahteva za razrešenjem naziva hosta opslužuje DNS server koristeći svoj keš, umesto da
zahtev prosleđuje svojim DNS forwarderima. Pretpostavimo da vrednosti osciliraju u
rasponu od 30-70%. Ukoliko vrednost padne na 10% to može da znači da se veći deo
upita (oko 90%) prosleđuje direktno forwarderima. Ovo svakako nije situacija za brigu, s
obzirom da su vraćeni rezultati relevantniji nego rezultati dobijeni iz DNS keša (zbog
zastarelosti zapisa u DNS kešu, DNS cache poisoninga i slično). Međutim, ukoliko
vrednost prekorači definisani gornji limit, to znači da se veći deo upita razrešava pomoću
DNS keša. U toj situaciji bi bilo potrebno postaviti alarm za gornju vrednost, kako bi
administrator intervenisao na vreme (na primer, preduzimanjem čišćenja DNS keša).

Tačke podataka nisu evidentirane. U nekim situacijama sistem može da bude ugašen,
što za posledicu ima prestanak evidentiranja bilo kakvih informacija. Tehnički gledano, kada
nema novih tačaka podataka, neće doći ni do prekoračenja donje ili gornje granice, ali to ne
znači da je sa sistemom sve u redu, već, naprotiv, da on ne funkcioniše kako bi trebalo.
Ovakva situacija je dopustiva kada monitoring sistem kasni za jednu ili dve tačke podataka
iza procesa prikupljanja podataka u realnom vremenu, ali ukoliko više tačaka podataka nije
prikazano, to bi trebalo da bude dovoljan razlog za analizu situacije. Ovaj tip prekoračenja
se aktivira upravo tada – ne postoji definisana granična vrednost, već maksimalni broj
zakasnelih tačaka podataka koji se smatra prihvatljivim, nakon čega sledi stanje koje
iziskuje slanje notifikacije administratoru.

Ovaj tip prekoračenja može da se koristi za nadgledanje neregularnih događaja sa

nepredvidivim trajanjem. Uzmimo na primer instalaciju softvera koja standardno traje
satima. Pretpostavimo da, u zavisnosti od kombinacije paketa koji se instaliraju sa
osnovnim softverom, proces instalacije može da traje od 2 do 5 sati, ali da nikada ne bi
trebalo da traje duže od 6 sati. Svaki put kada se instalacija nekog od paketa završi, šalje
se informacija i postavlja se tačka podataka u metriku, koja ima časovnu granulaciju.
Kontrolor koji konstatuje 3 prazne tačke podataka bi mogao da izda upozorenje o neobično
dugom trajanju procesa instalacije, čije odsustvo rezultata zahteva pažnju ili intervenciju
administratora.

Copyright © Link group

Procena vremena

Funkcija procene vremena definiše vremenski uslov koji vraća vrednost true u definisanim
trenucima i vrednost false za ostatak vremena (sve ostale trenutke). Potoji mnogo razloga
zbog kojih biste mogli da uključite funkciju procene vremena kao ulaz za određeni alarm. Na
primer:

• želite da deaktivirate neku grupu alarma u određenom trenutku tokom dana, kada se
sprovode redovne aktivnosti održavanja sistema;
• ne želite da se alarmi aktiviraju tokom vikenda.

Funkcije procene vremena svoju primenu najčešće nalazi u deaktivaciji alarma, ali mogu da
budu korišćene i kao pomoćni okidači. Na primer:

• ako neke metrike odu van uobičajenih nivoa u nekom trenutku (zbog prirode
poslovnih aktivnosti koji se tada realizuju), možete formirati alarm koji će se
pokrenuti kada metrike ostanu stabilne za vreme kada se očekuje pojava pikova; To
su, zapravo, alarmi koji se aktiviraju kada izostanu očekivani događaji;
• kada želite da inicirate simulaciju prekida rada u cilju testiranja, napravićete alarm
koji će se isključiti određenog dana, jednom kvartalno;
• možete, jednostavno, da obavestite tim inženjera i podsetite ih na predstojeći
događaj u sistemu, koji zahteva njihovu pažnju.

Pitanje

Grupa događaja koja uzrokuje da manji broj korisnika primećuje prolazne, ali ozbiljne
probleme koji momentalno nestaju predstavlja:

a. urgnentne događaje,
b. događaje koji zahtevaju intervenciju,
c. događaje koji ne zahtevaju intervenciju,
d. automatizovane zadatke,
e. rane indikatore.

Objašnjenje: Zbog velike brzine oporavka, ovi događaji ne zahtevaju intervenciju jer su
rešeni „sami od sebe”, pre nego što administrator može da ih uhvati i analizira. Zbog toga
nema nikakvog efekta aktivirati alarm za ovakav tip događaja. Učestalost ovakvih
događaja bi u svakom slučaju trebalo da se proverava, kako bi se potvrdilo da su trenutni
padovi u performansama ostali neznatni.

Ostali alarmi kao ulazni resursi

Kako stanja alarma mogu da uzmu Bulove vrednosti, ne postoji nijedan razlog zbog koga
izlaz iz jednog alarma ne bi mogao da predstavlja ulaz za druge alarme. Ugnježdavanje
alarma je moćan koncept, koji omogućava kreiranje hijerarhije alarma. Posebna pažnja
mora da se obrati na kružne zavisnosti u kojima dolazi do direktnog ili indirektnog
referenciranja na sopstvene vrednosti, naročito kod posrednih alarma. Ovakve situacije
nemaju praktičnu upotrebu i trebalo bi ih izbegavati.

Copyright © Link group

Deaktivacija

Alarmi se postavljaju kako bi se eliminisala potreba za nadzorom od strane čoveka, a u cilju

neprekidnog nadgledanja stanja sistema. Međutim, za vreme zakazanih procesa održavanja,
prekidi su svakako očekivani, a sistemske metrike bi trebalo da budu detaljno praćene sve
vreme. Očekivano je da ove metrike prikažu anomalije, a planirana nedostupnost ne bi
trebalo da pokrene seriju notifikacija, jer tako nešto ne bi imalo nikakav smisao u kontekstu
planirane nedostupnosti. Zbog toga je veoma preporučljivo momentalno deaktivirati alarme
za koje se zna da će se pokrenuti. Deaktivirati alarm znači sprečiti ga da se aktivira čak i
kada su prekoračene definisane vrednosti praga.

Deaktiviranje alarma može da se sprovede na dva načina: automatski i manuelno. Manuelno

deaktiviranje bi trebalo omogućiti samo za definisani vremenski period, uz pretpostavku da
će se alarm uključiti automatski nakon što taj period istekne. Ovakav pristup otklanja
mogućnost da će administrator mreže zaboraviti da aktivira alarm nakon sprovedenih
procesa održavanja sistema, što bi potencijalno moglo da dovede do nepredviđene
disfunkcionalnosti sistema upozoravanja.

Pored manuelne kontrole, postoji i mogućnost automatske deaktivacije. Zahvaljujući

bulovskom razvoju alarma, deaktivaciju je vrlo jednostavno implementirati zbog toga što je
moguće koristiti stanje drugog kontrolora kao Bulov ulaz. Pojasnimo to u jednom primeru.
Pođimo od pretpostavke da u istoj mreži postoje dve nezavisne sistemske komponente, A1 i
A2. Svaka može da doživi problem zbog brojnih nezavisnih razloga, tako da se ove dve
komponente posmatraju pomoću dva odvojena kontrolora dostupnosti. Kada kontrolor
(monitor) detektuje gubitak dostupnosti, za datu komponentu se pokreće alarm i kreira se
tiket, koji se postavlja u red čekanja. Jedan od uzroka problema može da bude sama
mrežna konekcija, koja se takođe posmatra, ali pomoću posebnog monitora. Konfiguracija
alarma za ovaj sistem, generalno, može da se prikaže na sledeći način:

Alarm1 = ServiceA1_Monitor
Alarm2 = ServiceA2_Monitor
Alarm3 = Network_Monitor

Kada mreža prestane da funkcioniše, sva tri alarma će se aktivirati i operator će primiti tri
tiketa za jedan isti slučaj. U većini situacija ovako nešto nije poželjno. Kako bi se
deaktiviralo generisanje tiketa i notifikacija za downstream elemente sistema, moguće je
dodati logiku maskiranja događaja. To se svodi na jednostavno produženje uslova alarma
Alarm1 i Alarm2 pomoću sintakse „AND NOT SupressionCondition” na sledeći način:

Alarm1 = (ServiceA1_Monitor AND NOT Network_Monitor)

Alarm2 = (ServiceA2_Monitor AND NOT Network_Monitor)
Alarm3 = Network_Monitor

Na ovaj način, kada dođe do pada u mrežnoj konekciji, operator će dobiti jedan tiket za
događaj sa najjačim uticajem. Ako nakon oporavka mrežne konekcije bilo koji od servisa
bude u disbalansu i njegovo stanje zahteva praćenje, odgovarajući tiketi će se generisati
automatski, odmah nakon što se uspostavi funkcionisanje mreže i pravila za deaktivaciju
više ne budu korišćena.

Copyright © Link group

Agregacija

Treći krucijalni element sistema aktivacije alarma je agregacija, odnosno mogućnost

grupisanja povezanih alarmnih ulaza u cilju smanjenja duplih notifikacija. Agregacija ima tri
osnovna oblika.

1. Any. Tip agregacije Any ima značenje logičkog OR (ili) povezivanja ulaza. Ovo je
najosetljiviji tip agregacije i trebalo bi da se koristi samo kada posmatrani entiteti
imaju puno kritičnih komponenti, gde svaka ima nizak stepen javljanja problema.
Šablon za Any agregaciju izgleda ovako:

AnyAlarm = (Input1 OR Input2 OR Input3)

Primer koji pokazuje kako Any agregacija može da bude adekvatno primenjena bi
mogao da glasi ovako. Uzmimo serijski tok podataka, koji se sastoji od pet
elemenata: A1, A2, A3, A4 i A5. Podaci se unose počev od A1 i procesiraju redno dok
se ne završi obrada podatka A5. Ukoliko se dogodi problem sa jednim elementom ili
bilo kojom kombinacijom elemenata, tok podataka će biti zaustavljen. Zbog toga,
logičko povezivanje OR-om individualnih monitora uvek vraća informaciju o
stopiranju procesa i generiše samo jedan tiket.

2. All. Tip agregacija All se sastoji od logičkog AND (i) povezivanja ulaza. Ovaj veoma
zahtevni tip agregacije se koristi kod entiteta višeg nivoa koji sadrže više ne tako
kritičnih podentiteta, sa relativno visokom verovatnoćom pojave greške. Odnosno, to
se može predstaviti i situacijom kada redudantne komponente dele isti zadatak, a
jedna od njih može da preuzme procese koje izvršavaju ostale.

AllAlarm = (Input1 AND Input2 AND Input3)

Kao dobar primer, uzmimo mali map-reduce klaster u kome postoje tri servera, gde
svaki ima relativno visok stepen javljanja grešaka. Međutim, tokom vremena većina
servera je sposobna da se sama oporavi od greške. Jedna mašina u klasteru može da
preuzme na sebe većinu zadataka koji se izvršavaju u klasteru, mada će to usloviti
njen sporiji rad u odnosu na brzinu rada kada funkcionišu sva tri servera u klasteru.
Vaš cilj je da se alarm aktivira samo ukoliko dođe do prekida izvršavanja zadatka,
što će se dogoditi samo u slučaju da sva tri servera prestanu sa radom u isto vreme.
Rešenje je da sakupite sva tri monitora u jedan alarm pomoću logičkog operatora
AND.

3. By Count agreagacija dodaje rezultat Bulovih ocena (binarne vrednosti 1 i 0) iz

svakog od ulaza i proverava rezultat u odnosu na maksimalno dozvoljenu vrednost.
Na primer, dopušteno je da najviše jedan ulaz bude u alarmu u datom trenutku i
pokreće se alarm ukoliko dva ulaza imaju vrednost 1:

ByCount Alarm = ((Input1 + Input2 + Input3) >= 2)

Na primer, pretpostavimo da imamo grupu hostova na kojima posmatramo zauzeće

računskih resursa, kao što je procesor. Ideja je da se alarm aktivira što je pre
moguće kada zauzeće CPU-a dostigne 70% na najmanje 35% svih hostova, bez
obzira da li i koliko ima hostova na kojima procesori nisu zauzeti uopšte.

Copyright © Link group

Agregacija je jednako važna za efektivan sistem upozoravanja, kao i dobijanje relevantne
informacije o dostizanju definisanog praga. Kada proračunavate koliko je Vaš sistem
upozoravanja precizan, potrebno je da duplirane tikete tretirate kao lažna upozorenja. Tu u
pomoć može da priskoči agregacija, jer je mogućnost korišćenja agregacije lako uočiti u
strukturi sistema upozoravanja. Ukoliko agregaciju u početku i ne primenite na najbolji
mogući način, to ne predstavlja veliki problem. Kao rezultat toga pojaviće se veliki broj
dupliranih upozorenja tokom vremena, tako da ćete na osnovu njih moći da vidite gde ste
napravili propuste i potom da ih ispravite.

Tipovi alarma

Kada se alarm aktivira i sistem pređe u stanje upozorenja, postoji mogućnost slanja
notifikacija administratoru kako bi mu se skrenula pažnja na novonastali problem.
Notifikacija o alarmu se odnosi na pojam upozoravanja. Bez obzira da li se pokreće zbog
zlonamernih korisnika, loše planiranih kapaciteta, preopterećenosti bandwidtha ili
softverskih grešaka, rezultujući alarm mora da omogući reakciju administratora. To znači da
administratoru mora da omogući da eliminiše grešku ili problem koji se pojavio. Ukoliko
administrator nema konkretnu ideju šta bi trebalo da uradi, najbolje bi bilo da isprati
definisanu proceduru prosleđivanja problema na dalje rešavanje (tzv. eskalaciju problema).
Alarmi mogu da imaju različite oblike i forme, navešćemo nekoliko.

• E-mail. Najčešći oblik notifikacija je e-mail poruka, zbog toga što one praktično ne
iziskuju nikakve dodatne troškove, e-mail sistemi su široko dostupni i imaju visoku
pouzdanost što se tiče vremena isporuke. E-mail se uobičajeno koristi kao pomoćni
notifikacioni mehanizam, zbog toga što se u današnje vreme razmenjuje veliki broj
e-mail poruka i neretko se dešavaju situacije da se pročitana e-mail poruka brzo
zaboravi ili čak spontano ignoriše. Kao dodatak ovom načinu upozoravanja, mnogo
češće se koristi GSM tehnolgoija, zbog svoje prirode da je dostupnija nego pristup
internetu. Kao posledica ove činjenice, notifikacija zasnovana na SMS-u i mobilnim
telefonima se smatra mnogo pouzdanijom.

• SMS. Administrator ili operater koji je na dužnosti može da primi tekstualnu poruku
sa kratkim opisom problema i referencom ka odgovarajućem tiketu. Kako
notifikacioni sistem nema načina da „sazna” da li je odgovorna osoba kojoj je poruka
poslata istu i pročitala i upoznala se sa njenim sadržajem, ukoliko na poruku ne bude
odreagovano u kratkom vremenskom intervalu (5-10 minuta), sistem će otpočeti
proceduru automatskog preusmeravanja problema na viši nivo podrške, u skladu sa
hijerarhijom. Glavna prednost SMS poruka je njihova niska cena, brza i pouzdana
isporuka i visoka zastupljenost korišćenja mobilnih telefona.

• Telefonski poziv. Notifikacije putem telefona podrazumevaju digitalizovani telefonski

poziv osobi ili osoblju koje je na dužnosti. Ovaj vid notifikacije se razlikuje od ostalih
notifikacija po tome što iziskuje momentalnu potvrdu statusa i obično podrazumeva
momentalno kreiranje neke vrste odluka. Administratoru se prezentuju moguće
opcije koje može da izabere biranjem dodeljenog „akcionog” telefonskog tastera, kao
što su: 1 – potvrda prijema informacije, 4 – eskalacija problema višem nivou
podrške, 7 – rešen problem.

Najveća prednost sistema upozoravanje putem glasovnog poziva je to što skoro da

ne postoji vreme čekanja. Ukoliko odgovorna osoba ne preuzme poziv, moguće je
odmah aktivirati proceduru eskalacije. Statistike pokazuju da primanje
automatizovanog govornog poziva traje u proseku od 15 sekundi do jednog minuta.

Copyright © Link group

 Iako je istovremeni prijem velikog broja SMS poruka uglavnom prihvatljiv, pravljenje
prioriteta u velikom broju poziva, na primer, u slučaju otkaza rada većeg broja
uređaja, može da predstavlja značajnu poteškoću.

• Ostali tipovi notifikacija. Zvučna i vizulena (treperenje, promena boje i sl.)

upozorenja su alternativni načini skretanja pažnje administratora na pojavu
problema u sistemu. Ovaj tip upozoravanja se retko koristi zbog nedostataka vezanih
za njegovo trajanje (nema potvrdne informacije da se upozorenje aktiviralo) i
nedostataka u vezi sa potvrdom isporuke notifikacije (na primer, administrator
trenutno nije fokusiran na aplikaciju u kojoj tereperi upozorenje o problemu).

Svi alarmi koji se pojave trebalo bi da budu evidentirani u ITS tiketima. Na taj način se
sprečava da nešto promakne i moguće je kreirati metainformacije o procesu upozoravanja,
koje kasnije mogu da budu analizirane, merene i korišćene u cilju poboljšanja sistema
upozoravanja.

Rezime

• Cilj upozoravanja je skrenuti pažnju operatera, odnosno administratora na primetnu

degradaciju performansi. Izazov balansiranja između osetljivosti i specifičnosti se
manifestuje u prijavljivanju upozorenja, što je pre moguće, ali bez formiranja lažnih
upozorenja. Mnogi događaji su rezultat prestanka rada sistema zbog planiranih
izmena u produkcionom sistemu. Neke od tih izmena se pokreću automatski, dok su
druge manuelne. Upravljanje preciznim i potpunim nadzorom (hronološkom
evidencijom promena u sistemu), pomaže u markiranju uzroka i posledica, tako što
povezuje nedozvoljena stanja sistema sa tačnim vremenima u evidenciji događaja
(logovima). Sistem za praćenje događaja (issue tracking sistem – ITS) pomaže u
postavljanju prioriteta prijavljenih upozorenja. Koordinacija osoba koje sarađuju na
rešavanju problema se obavlja pomoću tiketa, što obezbeđuje da ni u jednom
trenutku proces rešavanja ne ostane nedovršen.

• Svaki problem za posledicu ima određene troškove, koji odgovaraju stepenu uticaja
problema na rad sistema. Problemu koji se pojavi se dodeljuje alarm kada je značaj
tog problema toliki da utiče na funkcionisanje sistema. Ozbiljnost neke incidentne
situacije može da se analizira na dva osnova: mogućnost oporavka i stepen uticaja
na sistem. Klasifikacija događaja: kritični, urgentni, zahtevaju intervenciju, mogu da
se oporave, ne zahtevaju akciju, automatizovani zadaci, optimizacioni zadaci i ne
uzrokuju nikakav problem. Samo prve četiri grupe događaja zahtevaju
implementaciju sistema upozoravanja, zbog toga što je samo u slučaju njihovog
pojavljivanja sistem pod rizikom. Preostalih pet grupa ne zahteva aktiviranje
upozorenja, ali u mrežnim okruženjima nekih kompanija, administratori mogu da se
odluče da postave podešavanja koja će i za njih aktivirati alarme i kreirati tikete
niskog prioriteta.

• Veliki spektar različitih uzroka koji mogu da izazovu greške i probleme može da se
klasifikuje u četiri grupe:

o nedostupnost i preopterećenje resursa,

o softverski problem,
o greške u konfigurisanju,
o hardverski problem.

Copyright © Link group

• Alarm može da bude prikazan u obliku Bulove funkcije. U bilo kom trenutku, njegova
vrednost vraća jedno od dva moguća stanja: alarm ili ništa. Njima možemo da
dodelimo binarne vrednosti 1 i 0, respektivno. Alarmna funkcija se ponovo
proračunava kada bilo koja od ulaznih komponenti promeni svoje stanje. Alarm može
da se definiše kao zatvorena kutija u kojoj se nalaze uslovi i akcija koja će se
pokrenuti ukoliko su uslovi ispunjeni.

• Metrički kontrolori opisuju uslove prekoračenja praga i menjaju njihovo stanje kada
dođe do prekoračenja (ili pada ispod) definisanih limita za tačke podataka, u
posmatranim vremenskim serijama. Kako bi se izbeglo aktiviranje alarma zbog
prolaznih anomalija, kontrolor definiše minimalni broj tačaka podataka koje je
potrebno da se pojave kako bi se prešlo u stanje upozorenja. Najčešće se koriste
četiri tipa prekoračenja:

o iznad definisane vrednosti (gornja granica),

o ispod definisane vrednosti (donja granica),
o van opsega,
o tačke podataka nisu evidentirane.

• Funkcija procene vremena definiše vremenski uslov koji vraća vrednost true u
određenim trenucima i vrednost false za ostatak vremena (sve ostale trenutke).

• Deaktivirati alarm znači sprečiti ga da se aktivira čak i kada su prekoračene

definisane vrednosti praga. Deaktiviranje alarma može da se sprovede na dva
načina: automatski i manuelno. Treći krucijalni element sistema aktivacije alarma je
agregacija, odnosno mogućnost grupisanja povezanih alarmnih ulaza u cilju
smanjenja duplih notifikacija. Agregacija ima tri osnovna oblika: Any, All i ByCount.

• Notifikacija o alarmu se odnosi na pojam upozoravanja. Bez obzira da li se pokreće

zbog zlonamernih korisnika, loše planiranih kapaciteta, preopterećenosti bandwidtha
ili softverskih grešaka, rezultujući alarm mora da omogući reakciju administratora.
Alarmi mogu da imaju različite oblike i forme, a tipični su:

o e-mail,
o sms,
o telefonski poziv,
o ostali tipovi notifikacija.

• Svi alarmi koji se pojave trebalo bi da budu evidentiratni u ITS tiketima.

Copyright © Link group