Introdution to ITIL - IT Service Management - Uvod u upravljanje IT Servisima, skripta- srpski

VISOKA TEHNIČKA ŠKOLA KRAGUJEVAC

ODSEK INFORMATIKA

SPECIJALISTIČKE STUDIJE

PREDMET: UPRAVLJANJE IT SERVISIMA

UPRAVLJANJE IT SERVISIMA

PREMA ITSM PRINCIPIMA

ITSM, definicija servisa

ITL principi:

Service Design - Service Transition

- Service Operations - Continual Service Improvement

ISO 20000 standard za upravljanje IT Servisima

Alati otvorenog koda za implementaciju ITSMa

NaGioS

Predavač

Mr Srđan Atanasijević, dipl.ing.inf

skripta

Verzija 0.5.2012

Kragujevac, septembar 2012.

Upravljanje IT servisima /.skripta Visoka tehnička škola Kragujevac - Specijalističke studije

V01.2012 strana 2

Sadržaj:

1 ITSM (uvod) ............................................................................................................... 7

1.1 Pojava ITIL-a, kao koncepta ................................................................................... 7

1.2 Poslovne koristi korišćenja ITIL ............................................................................. 9

1.3 Poslovna perspektiva............................................................................................. 11

1.4 Upravljanje ICT infrastrukturom .......................................................................... 12

1.5 Planiranje implementacije upravljanja sa IT uslugama ........................................ 13

1.5.1 Projektovanje i testiranje usluge ................................................................... 14

1.6 Upravljanje aplikacijama ...................................................................................... 14

1.7 Isporuka usluge ..................................................................................................... 15

1.7.1 Upravljanje nivoom usluge ........................................................................... 16

1.7.2 Upravljanje finansijama za IT usluge ........................................................... 16

1.7.3 Upravljanje kapacitetom ............................................................................... 17

1.7.4 Upravljanje kontinuitetom IT usluge ............................................................ 17

1.7.5 Upravljanje raspoloživošću ........................................................................... 18

2 Procesi podrške usluzi ............................................................................................... 19

2.1 Upravljanje konfiguracijom .................................................................................. 19

2.2 Upravljanje promenom ......................................................................................... 20

2.3 Upravljanje izdanjima ........................................................................................... 21

2.4 Upravljanje Incidentom......................................................................................... 22

2.5 Problem Management ........................................................................................... 22

2.6 Service Desk ......................................................................................................... 23

3 ITIL danas ................................................................................................................. 24

3.1.1 Definicija najbolje prakse ............................................................................. 24

3.1.2 ITIL V3 ......................................................................................................... 24

4 Životni ciklus IT usluge prema ITIL konceptu ......................................................... 26

4.1.1 Uzorak životnog ciklusa IT usluge prema ITIL konceptu ............................ 26

4.1.2 Konntinuirano unapredenje usluga (Continual Service Improvement) ........ 28

4.2 Dizajn IT usluga (Service Design) ........................................................................ 30

4.2.1 Cilj faze dizajn IT usluga .............................................................................. 30

4.2.2 Koristi pravilnog dizajniranja IT usluga ....................................................... 31

4.2.3 Delokrug faze dizajn usluga .......................................................................... 31

4.2.4 Revizija trenutnog stanja ............................................................................... 32

4.2.5 Ključni procesi Service Design faze ............................................................. 32

4.2.6 Upravljanje katalogom usluga (Service Catalogue Management) ................ 33

Visoka tehnička škola Kragujevac - Specijalističke studije /.skripta Upravljanje IT servisima

V01.2012 strana 3

4.2.6.1 Katalog usluga ............................................................................................... 33

4.2.7 Upravljanje dogovorenim nivoima servisa (Service Level Management ) ... 34

4.2.7.1 Svrha i cilj SLM faze .................................................................................... 35

4.2.7.2 Delokrug SLM faze ....................................................................................... 36

4.2.7.3 Politike / principi / osnovni pojmovi ............................................................. 36

4.2.8 Upravljanje kapacitetima (Capacity Management) ....................................... 50

4.2.8.1 Aktivnosti procesa upravljanja kapacitetima ................................................ 50

4.2.9 Upravljanje raspoloživošću (Availability Management) .............................. 52

4.2.10 Upravljanje kontinuitetom IT usluga (melita) (IT Service Continuity

Management) 53

4.2.11 Upravljanje informacionom sigurnošću (Information Security Management)54

4.2.12 Upravljanje dobavljačima (Supplier management) ....................................... 56

5 Menadžment sigurnošću informacija ........................................................................ 57

5.1 Koristi od ITIL-a za korisnike ............................................................................... 57

6 BS15000 .................................................................................................................... 59

6.1 Istorija .................................................................................................................... 59

6.2 Svrha standarda BS15000 ..................................................................................... 59

7 ISO/IEC 20000 (Međunarodni standard za upravljanje IT uslugama) .................... 60

7.1 ISO/IEC 20000-1 ................................................................................................... 60

7.1.1 Sadržaj ISO/IEC 20000 -1 ............................................................................ 60

7.1.1.1 Predmet i područje primene .......................................................................... 61

7.1.1.2 Termini i definicije ........................................................................................ 61

7.1.1.3 Zahtevi za upravljanje sistemom ................................................................... 61

7.1.1.4 Planiranje i implementacija upravljanja uslugama ...................................... 62

7.1.1.5 Planiranje i implementacija novih ili izmijenjenih usluga............................ 62

7.1.1.6 Proces isporuke usluga ................................................................................. 63

7.1.1.7 Veze između procesa ..................................................................................... 64

7.1.1.8 Odlučujući procesi ........................................................................................ 65

7.1.1.9 Proces kontrole ............................................................................................. 65

7.1.1.10 Proces izdavanja ........................................................................................... 66

7.2 ISO/IEC 20000-2 - Kodovi prakse za upravljanje IT uslugama .......................... 68

7.2.1 Sadržaj ISO/IEC 20000-2 .......................................................................... 68

7.3 ISO/IEC i ITIL ...................................................................................................... 74

7.3.1 ITIL, ISO 20000 i BS15000 Korisničke grupe ............................................. 74

7.4 Zašto ISO/IEC 20000 ............................................................................................ 74


V01.2012 strana 4

7.4.1 Kako ISO/IEC 20000 sertifikuje procese u organizaciji ............................... 75

7.4.2 10.2 Ček lista................................................................................................. 76

7.5 Prednosti implementacije ISO/IEC 20000 ............................................................ 78

7.6 Nadgradnja standarda ISO/IEC 20000 ISO/IEC TC 1/SC 7/WG 25 ................. 78

7.7 Veze između standarda? ........................................................................................ 79

7.7.1 Certifikacija revizije ...................................................................................... 80

7.7.2 Uticaj ISO / IEC 20000 ................................................................................. 80

7.7.3 Novi ISO/IEC 20000-3 ................................................................................. 81

7.7.4 Treće izdanje ITILa ....................................................................................... 83

7.7.5 Poboljšanja prvog i drugog dela standardna ISO/IEC 20000 ....................... 84

7.7.6 Usklađivanje normi i ISO/IEC 20000 ........................................................... 84

1. Zaključak ................................................................................................................... 86

2. Literatura ................................................................................................................... 91

3. Dodatak ..................................................................................................................... 93

3.1. Slike ...................................................................................................................... 93

3.2. Tabele .................................................................................................................... 94

3.3. No table of figures entries found.Grafovi ............................................................. 94


V01.2012 strana 5

Predgovor

prvom izdanju skripte za podršku nastavi predmeta “UPRAVLJANJE IT SERVISIMA” na

smeru Informatika, na specijalističkim studijama, Visoke tehničke škole u Kragujevcu.

Poštovane kolege,

pokušali smo da u ovom materijalu objedinimo teme koje smo prošli tokom semestra kako na

predavanjima, tako na laboratorijskim vežbama i seminarskom radovima.

Ovaj materijal je osnov za polaganje završnog ispita, ali, nadam se i korsno stručno štivo koje će

vam pomoći u praksi kada se na svojim radnim zadacima susretnete sa specifičnim

problematikom procene rizika od napada, detektovanja napada, predmeta napada, određivanje

obima ugroženosti prilikom napada i načina restauracije na poznato, konzistentno stanje pre

napada u okviru informacionih sitema za koje ste zaduženi na vašim radnim mestima.

Zahvalnost:

Ovom prilikom želim da se zahvalim kolegama koji su svojom izuzetnom istrajnošću, fokusom i

posvećenošću učinili da obogatim predavanja, vežbe i ovu skriptu.

Zahvaljujem se kolegama Nenadu Babajiću, koji je u toku nastave na sebe preuzeo organizaciju

dela vežbi koje su se odnosile na Nagios i za tu priliku razvio Laboratorijsku vežbu kojom

demonstrira priorodu ITILA kroz Nagios, alat otvorenog koda za upravljanje ICT

infrastrukturom.

Zahvaljujem se diplomcima, Amrku Marković, Mili Petrović i Mariji Mitrović, koji su u svojim

radovima obradili deo tema iz oblasti Uravaljanja IT usluga i Nagiosa. Delove njihovih radova

nalaze se i kao deo materijala skripte.

Želim da se zahvalim i studentima prve generacije specijalističkih studija VTS Kragujevac, koji

su radeći seminarske radove, pomogli da se na naš jezik prevede deo materijala najsavremenije

literature ove oblasti.

Komplet nastavnog materijala na predmetu “Bezbednost Informcionih sistema- napredne

tehnike” sastoji se iz:

1. Internet sajta: https://sites.google.com/site/VtsItsm sa svojim sadržajima

a) Slajdovima sa predavanja,

b) Laboratorijskim vežbama,

c) Internet linkovima ka alatima koji su korišćeni kao primeri na vežbama i

predavanjima

d) Standardima za bezbednost i informacionu sigurnost,

e) Odabranim seminarskim radovima studenata,

f) Agenda sa rasporedom termina predavanja, laboratoriskih vežbi, termina

konsultacija i ispitnih rokova


V01.2012 strana 6

2. Skripta sa materijalom koji je iznet na predavanjima i vežbama,

3. Softverski alati otvorenog koda za analizu logova i otkrivanje ranjivosti informcinih

sistema

4. eMail adresa na koju možete postavljati pitanja i slati seminarske radove:

5. [email protected]

mailto:[email protected]


V01.2012 strana 7

1 ITSM (IT Service Management) - koreni

Kupci i korisnici IT usluga sve više zahtevaju da pružaoci IT usluga, bilo unutrašnji ili spoljnji,

demonstriraju merljive vrednosti resursa investiranih u IT. IT pruža široku lepezu inovativnih

tehnologija i rešenja koja te tehnologije omogućuju, međutim koristi i rešenja koje te tehnologije

i donose čitavom poslovnom sistemu teško su merljive.

Istraživanja su pokazala da investicije u nove IT tehnologije i infrastrukturu ne rezultuju

koristima razmernim troškovima investicije.1

Bilo da se radi o poslovnim organizacijama koje nastupaju na tržištu ili vladinim i civilnim ne

vladinim organizacijama, nedostatak merljive vrednosti od investiranja u IT proizlazi iz

neefikasne poslovne prakse davalaca IT usluga. Poslovne prakse davalaca IT usluge uključuju

metode, procese, procedure i pravila koje organizacija sledi kako bi postigla svoje ciljeve.

Mnoge IT organizacije su razvile, definsale i implementirale operativne poslovne prakse kao što

su upravljanje promenama, upravljanje konfiguracijom, upravljanje dostupnošću kako bi uspešno

upravljale svojom IT tehničkom infrastrukturom.

Usvajanjem poslovnih praksi IT organizacije mogu poboljšati nivo usluga kroz efikasnije

korištenje resursa. Fokus ovog rada je na specifično područje IT prakse vezano uz dizajn i

upravljanje IT uslugama, merenje njihovih performansi s ciljem poboljšanja zadovoljstva klijenta

IT uslugom koja mu se pruža.

Kako bi optimizovalei potrošnju IT sektora i poboljšale fokus na klijenta, organizacije

pokušavaju osigurati da su IT usluge i tehnologije isporučene na vreme, unutar budžeta i u

merljivoj vrednosti za krajnje poslovne jedinice. Da bi povratak investicije u IT bio što veći,

organizacije teže poboljšanju usluga po što nižoj ceni.

IT organizacije na raspolaganju imaju niz alata i tehnika kojima to mogu ostvariti. Dobavljači

programskih rešenja i sklopova brzo razvijaju nova i bolja rešenja za automatizaciju operativnih

IT funkcija. Često IT organizacije preduzimaju jednokratne projekte kao što su konsolidacija

servera ili aplikacija u cilju smanjenja troškova i pružanja brže i kvalitetnije IT usluge. Takođe

sve više IT organizacija je usmereno na razvoj ili sticanje novih vještina i sposobnosti potrebnih

za isporuku trenutnih i rešenja u razvoju.

Mnoge IT organizacije implementiraju elemente iz jednog ili više okvira najboljih praksi za

upravljanje IT uslugama. De facto međunarodni okvir najbolje prakse za upravljanje IT

uslugama je ITIL. ITIL pruža okvir za upravljanje IT uslugama i fokusira se na kontinuirano

merenje i poboljšanje kvalitete isporučenih IT usluga s perspektive klijenta i davalaca IT usluge.

ITIL definiše upravljanje IT uslugama (Service Level Management) kao funkciju koja

pregovara, usaglašava i dokumentuje ciljeve IT usluga sa predstavnicima klijenta koji zahtevaju

usluge, a zatim prati i proizvodi izveštaje o sposobnosti davalaca IT usluga da isporuči

dogovoreni nivo usluge.

1.1 Pojava ITIL-a, kao koncepta

Upravljanje IT uslugama javilo se kao posledica razvoja tehnologije koja je realizovala uslugu.

U početku svog razvoja IT industrija uglavnom je bila orijentisana na razvoj aplikacija.

Razvijene aplikacije nudile su se kao mali deo celokupne usluge.

1 Ryan R., Raducha-Grace T., The Business of IT: How to Improve Service and Lower Cost,

IBM, Boston, 2010. str. 15.


V01.2012 strana 8

Krajem osamdesetih godina prošlog veka polje upravljanja uslugama počelo se naglo razvijati, a

taj nagli razvoj bio je popraćen i zavisnošću poslovanja od upravljanja uslugama. Počelo se

pojavljivati sve više kompanija koje su koristile IT u isporuci svojih usluga klijentima. Kako bi

se zadovoljile potrebe poslovanja potreban je bio snažniji fokus na upravljanje IT uslugama.

Slika 1 - ITIL – IT infrastructure Library

U isto to vreme Vlada Velike Britanije prepoznala je važnost pronalaska efikasnog upravljanja

uslugama. Na samom početku posebna vladina kancelarija Central Computer and

Telecomunications Agency (CCAT) je samo prikupljala podatke kako se najuspešnije

organizacije odnose prema upravljanju uslugama. Krajem osamdesetih i početkom devedesetih

godina prošlog veka iz svih prikupljenih informacija sastavljena je serija knjiga koje

dokumentiraju pristup upravljanju IT uslugama u svrhu podrške poslovnih korisnika.

Taj skup knjiga nazvan je IT Infrastructure Library, odnosno ITIL.2

U današnje vreme, CCAT je deo Vlade Velike Britanije pod nazivom Office of Goverment

Commerece (OGC). OGC je zadužen za održavanje i ažuriranje ITIL biblioteke.3

U početku se broj knjiga popeo se na četrdeset. Za temu koju su knjige pokrivale pojavio se

veliki interes u Velikoj Britaniji u grupi ljudi koja se bavila upravljanjem uslugama. Pojam

upravljanje IT uslugama se pojavio u isto to vreme kako je popularnost ITIL serije knjiga rasla.

Sredinom devedesetih godina prošlog veka počela je revizija ITIL serijala knjiga. Godine 2004.

predstavljena je grupa od devet knjiga, poznatija kao ITIL verzija 2. Ovim serijalom premošten

je jaz između tehnologije i poslovanja. Fokus knjiga je snažno usmeren na procese potrebne za

efikasno pružanje usluga poslovnim korisnicima.

Upravljanja usluga vodi poreklo iz tradicionalnih uslužnih industrija poput bankarske, avionske,

hotelske, telefonske industrije, itd. Primena prakse upravljanja uslugama počela se širiti nakon

što su IT organizacije počele usvajati uslužno orijentisan pristup u upravljanju IT aplikacijama,

2 OGC, The Official Intorduction to the ITIL Service Lifecycle, The Stationery Office, London,

2007., str. 3

3 HP, ITIL Service Manager for Service Delivery, student guide, Hewlett Packard, 2007, str.2-

9


V01.2012 strana 9

infrastrukturom i procesima. Sve više rešenja poslovnih problema i podrške poslovnom modelu i

strategiji je u obliku usluga. Sve više outsourcinga i pružanja zajedničkih usluga takođe je

doprinielo tome da sve više i više organizacija postaje isključivo isporučilac usluga. Isto vredi i

za organizacijske jedinice unutar firme koje postaju pružaoci usluga ostalim jedinicama a sve u

cilju sveopšteg funkcionirasanja čitave organizacije.

Slika prikazuje poziciju ITIL koncepta u upravljanju IT infrastrukturom kao poslovnim

uslugama.

Slika 2 - Upravljanje infrastrukturom kao poslovnim uslugama

1.2 Poslovne koristi primene ITIL

Usvajanje i korišćenje ITIL - biblioteke IT infrastrukture omogućava IT organizaciji da:

Vodi IT kao biznis koji je sposoban da upravlja troškovima, kvalitetom i rizikom IT

usluga dok obezbeđuje poslovnu agilnost – imperativno je da IT organizacije razviju i

gaje ove karakteristike da bi mogle da se transformišu u pravog isporučioca usluga.

Povezivanje IT usluga, radne snage, tehnologije i menadžmenta IT procesima u

sistem – bez širenja preduzeća. Isporuka „end-to-end“ IT usluga ne može se kompletirati

bez potpuno integrisanog ljudstva, procesa i tehnologije.

Pristupanje trenutnim i željenim stanjima i identifikovanje mogućih praznina – ITIL

se može koristiti da IT osoblje brzo identifikuje procese na radnom mestu i otpočne

usaglašavanje sa drugim ključnim IT procesima. Kao brz referentni alat, model može da

ukaže na željenu budućnost i krajnji cilj za IT organizaciju i obezbedi solidnu osnovu za

strateško planiranje.

Prioritetni radni napori – dok model predstavlja procese koje organizacija mora da ima

da bi mogla da isporuči konzistentnu, kvalitetnu uslugu, operativni poslovi moraju

fokusirati napore tamo gde su odmah potrebni. IT organizacija mora da odluči o prioritetu


V01.2012 strana 10

implementacije procesa. ITIL pomaže organizacijama da brzo odluče o prioritetima,

naglašavanjem odnosa i veza unutrašnjih procesa, dozvoljavajući IT organizaciji da

proceni značajnost i vrednost primene jednog pristupa u odnosu na drugi.

Početak diskusije o organizacionim promenama – mada je model mapa međusobnih

odnosa procesa, a ne organizacioni model, ITIL se može efikasno koristiti za početak

diskusije i planiranje organizacionih promena unutar IT organizacije. Razmatranje uloga

opisanih procesa u životnom ciklusu IT usluge, raspodela uloga i odgovornosti i

potencijalni konflikti interesa pojedinih funkcija, mogu da budu korisna početna tačka i

referenca za rekonstrukciju IT organizacije.

Identifikacija područja primene tehnologija koje omogućavaju procesni pristup –

ulazeći dublje u model da bi se analizirali detalji procesa i tačke integracije, ITIL

omogućava IT specijalistima da izaberu tehnologije kojima će realizovati procesni pristup i

obezbediti efikasno i efektivno postizanje postavljenih ciljeva u podršci poslovnim

procesima.

Identifikacija sopstvenih slabosti i prednosti, benchmarking – ITIL set oblasti i procesa

sadržanih u njima može se upotrebiti ne samo za poboljšavanje postojeće prakse

upravljanja IT uslugama, već i za uspostavljanje novih sposobnosti IT organizacije

potrebnih da podrži (i u većini slučajeva da vodi) promene u poslovnim procesima kupca

da bi njegovo poslovanje bilo u skladu sa promenama u poslovnom okruženju, promenama

zahtevanim za opstanak, ili održavanje konkurentnosti. Kao primer već par godina je IT

svet konfrotiran sa novim poslovnim izazovom, takozvanom „umreženom ekonomijom“, u

kojoj elektronsko poslovanje pokreće značajne IT investicije i podiže lestvicu kvaliteta i

potrebnih sposobnosti i biznisa i podržavajućih IT usluga na viši nivo. IT unutar

elektronskog poslovanja nije samo podrška primarnim poslovnim procesima nego je deo

primarnog poslovnog procesa, što dodatno proširuje i zaoštrava zahteve kvaliteta za

raspoloživost, integritet i poverljivost informacija procesiranih/sadržanih u primarnom

procesu.

ITIL obezbeđuje model zrelosti sposobnosti (urađen po uzoru na CMM4), tako da

organizacija može upotrebom modela zrelosti utvrditi svoje slabosti i sposobnosti u

svakom od procesa, i od interesa za zadovoljenje potreba krajnjeg kupca IT usluga. Model

zrelosti omogućava kvantificiranje sposobnosti u sledećim oblastima:

- vizija i sistem upravljanja, strateški ciljevi i usmerenja

- procesi (zrelost procesa isporuke i podrške uslugama),

- osoblje (kultura, stav, verovanja, znanja i veštine)

- tehnologija (infrastruktura, uključujući i alate).

Poređenjem potrebne/zahtevane kompetentnosti sa sopstvenim sposobnostima IT

organizacija može transparentno doneti odluke koje procese, tehnologije i proizvode će

sama obezbediti ili će poveriti realizaciju drugim organizacijama (“outsorcing)”

zadržavajući za sebe samo upravljanje zahtevima za te procese ili proizvode/usluge. IT

servis provajder mora da kombinacijom sopstvenih i „outsorsiranih“ sposobnosti (kroz

ugovore sa partnerima) obezbedi potpunu realizaciju primerenog nivoa usluge (SLA -

Service Level Agreement) zahtevanog od strane kupca.

4 CMM – Capabilty Maturity Model, © CMU/EDU, 1993. – Model zrelosti sposobnosti za

softver


V01.2012 strana 11

Upravljanje životnim ciklusom IT usluga – ITIL opisuje životni ciklus usluge ne samo u

„normalnim“ okolnostima, već zahteva (i omogućava) da organizacija predvidi i planira

razvoj novih/izmenjenih usluga. Ono što je kod mnogih organizacija na zapadu (USA

posebno) naglašeno jeste planiranje za svaku eventualnost i planiranje oporavka posle

katastrofalnih događaja. To je odavno predviđeno u ITIL. No realnost je da je taj proces

jedan od najmanje implementiranih iz prostog razloga što planovi i ako postoje (što

podrazumeva i da su odobreni od najvišeg rukovodstva) najčešće nisu provereni da li su

efektivni, obzirom da provera zahteva značajna sredstva i organizacije se radije odlučuju

da prihvate rizik da plan neće biti adekvatan nekoj od mogućih katastrofičnih situacija.

Kao što ova nabrajanja prikazuju, ITIL može da obezbedi trenutne dobiti, što je od presudne

važnosti za održavanje pozitivne klime u organizaciji i doprinosi održavanju privrženosti

promenama. Posmatrano dugoročno, ITIL obezbeđuje veze sa drugim oblastima od interesa za

organizacije kao što su IT Governance5 i sigurnost informacija. Upravo radi usaglašavanja sa

novim izdanjima CobiT 4.0 i Standarda ISO/IEC 27001:2005 i ISO/IEC 17799:2005 OGC se

odlučio na veliku reviziju ITIL, čija realizacija je u toku; prva izdanja najavljena su za jesen

2006.

Slika 2 -Temelji ITSM-a

1.3 Poslovna perspektiva

Poslovna perspektiva (videti sliku 2.) je namenjena rukovodiocima organizacije da se upoznaju

sa osnovnim komponentama i arhitekturom dizajnirane ICT (Information and Communications

Technology) infrastrukture potrebne za podršku njihovih poslovnih procesa i postizanje

razumevanja uloge standarda i najbolje prakse u upravljanju IT uslugama. Poslovna perspektiva

pomaže poslovnim menadžerima ne samo da razumeju dobiti od implementacije najbolje prakse

upravljanja IT uslugama, nego:

Omogućava da sa razumevanjem pregovaraju o Servis Level Agreement (SLA)

Da ih kvalifikuje da sutra budu kompetentni članovi CAB (Change Advisory Board)

5 IT Governance, autoru nije raspoloživ prevod ovog pojma


V01.2012 strana 12

Poslovna perspektiva pomaže Servis provajderu da obrazloži zašto predlaže takav nivo usluga

kao podršku poslovnim procesima Kupca i da pregovara o uslovima isporuke takve usluge sa

poslovnim menadžerima. Ako se malo analizira prethodna rečenica, zahteva se od IT servis

menadžera da u potpunosti razume poslovne procese svog kupca i da na osnovu toga predloži

odgovarajuću IT podršku tim procesima. Također, IT servis menadžer može da svom kupcu

predloži i reinženjering poslovnih procesa imajući u vidu šta IT može da obezbedi za te poslovne

potrebe kupca. Usaglašena i prihvaćena Poslovna perspektiva je osnova za izradu Plana

implementacije IT usluga, koji će biti prilog ugovoru o nivou IT usluga - SLA i sadržavati sve

potrebne tehničke detalje i aktivnosti upravljanja isporukom IT usluge, uključujući i obaveze

kupca.

Da bi IT servis provajder izvršio usklađivanje svog poslovanja sa procenjenim tržištem IT

usluga, on treba da uradi SWOT6 analizu svojih sposobnosti. U tome mu ITIL pruža

neprocenjivu pomoć kroz specifikaciju procesa i kriterijume nivoa sposobnosti. Imajući ove

informacije IT servis provajder može da definiše potrebe svog poslovanja i definiše IT strategiju

kojom doprinosi korporativnom lancu vrednosti. Ovaj proces prepoznaje da IT organizacija

uslugama mora da ima solidno razumevanje toga šta konkurencija radi, koje usluge su važne za

kupce, i koliko je kupaca spremno da plati za usluge. Periodični ciklusi planiranja poslovanja i

industrijskih promena tipično pokreću procenjivanje poslovanja, koje obično otkriva mogućnosti

za novim uslugama ili poboljšanja trenutnih. Procenjivanje poslovanja zahteva razumevanje

tržišta uslugama i interakciju sa drugim IT procesima, uključujući menadžment kupcima, IT

strategiju, planiranje arhitekture IT-a, i planiranje usluga.

Sledeće aktivnosti su deo procenjivanja poslovanja:

definisanje tržišnog segmenta i SWOT analiza

definisanje karakteristika usluga za koje postoji tržišna potražnja

preispitivanje veličine tržišnog segmenta i mogućnosti rasta

sprovođenje analize lanca segmentne vrednosti

sprovođenje komparativne analize

priprema analize marketinga

1.4 Upravljanje ICT infrastrukturom

Upravljanje ICT infrastrukturom (videti sliku 2.) obuhvata sve aspekte informaciono

komunikacione infrastrukture od identifikacije poslovnih zahteva preko tenderskog procesa do

testiranja, instalacije, puštanja u rad i tekućeg održavanja ICT komponenata i IT usluga.

Upravljanje ICT infrastrukturom opisuje glavne procese uključene u upravljanje u svim

oblastima i aspektima tehnologije. Pored ostalih to uključuje:

procese dizajniranja i planiranja usluge

procese instalacije i puštanja u rad

procese funkcionisanja

procese tehničke podrške.

Pored nabrojanih tehničkih procesa ITIL u ovom poglavlju (zasebna knjiga) definiše i niz

upravljačkih aktivnosti kojima se obezbeđuje funkcionisanje veza između procesa i

6 SWOT – Strengths and Weaknesses, Opportunities and Threats, Jake i slabe strane

organizacije, prilike i pretnje sa kojima se susreće.


V01.2012 strana 13

odgovrarajuću raspodelu odgovornosti za pojedine detalje i upravljanje ICT infrastrukturom u

celosti.

1.5 Planiranje implementacije upravljanja sa IT uslugama

IT servis provajder prvo mora, kao i svaka druga organizacija definisati svoju misiju, viziju,

principe kojima će se rukovoditi (videti standard ISO 9001) i izabrati strategiju postizanja vizije.

Ukoliko i IT organizacija, i korisnik IT usluga, imaju uspostavljen i sertifikovan sistem

menadžmenta kvalitetom tada je identifikacija prioriteta u uspostavljanju ITSM kod IT servis

provajdera podržana prioritetima koje je definisao kupac. Ovi dokumenati omogućavaju IT

servis provajderu da utvrdi svoju sveukupnu poziciju, skalu vrednosti – zasnovanu na rezultatima

poslovnih procena – i generiše celovitu IT strategiju i plan arhitekture IT-a. Usklađivanje opštih

(ISO 20000-1) i posebnih (kupci) zahteva za kompetentnost i svojih sposobnosti IT servis

provajder treba da dokumentuje kroz razradu dokumentovanog strateškog plana. Ova razrada

kao izlaz treba da dâ jasan plan postizanja pojedinačnih taktičkih i operativnih ciljeva, kojima se

podržava realizacija vizije IT servis provajdera i obezbeđuje zadovoljavanje zahteva kupaca IT

usluga.

Sledeće aktivnosti su deo IT strategije i planiranje arhitekture IT-a:

usklađivanje dizajna IT organizacije sa tekućim biznis zahtevima

definisanje i dokumentovanje IT vizije

razvoj izjave o IT strategiji

izvođenje strateških analiza

ustanovljavanje IT budžeta

identifikacija strateških ciljeva

razvijanje i komuniciranje (saopštavanje) strateškog IT plana

razvijanje definicije tržišnih usluga

utvrđivanje rešenja za usluge

definisanje IT arhitekture

identifikacija omogućavajućih tehnologija

preispitivanje budžeta i korekcije

Strategija postizanja vizije i strateški ciljevi moraju biti razrađeni i detaljno raščlanjeni na

taktičke i operativne ciljeve, koji su osnova za projekte realizacije, od kojih svaki mora

zadovoljiti osnovne principe projekta. Svaki projekt razvoja IT usluge mora imati svoj

cilj/ciljeve i zadovoljiti zahteve za kvalitet, cenu i rok. S druge strane, marketing obezbeđuje

tržišne procene što omogućava da se pri planiranju usluga pronalaze putevi da se maksimizira

povratak investicija (ROI7) novih i postojećih usluga isporučenih kupcima kroz angažovanje

poslovnih jedinica. Tokom planiranja usluga, IT verifikuje da se usluge poklapaju i sa biznis

zahtevima i mogućnostima isporuke IT-a, i vredne informacije se primaju od procesa dizajna i

menadžmenta uslugama. Ishodi uključuju detaljne specifikacije dizajna usluge koja se onda

uklapa u procese razvoja i lansiranja usluga.

Sledeće aktivnosti su deo planiranja usluga:

planiranje za nove (standardne) usluge,

sprovođenje analize rizika usluge,

7 ROI – Return of investment, povraćaj investiranog, isplativost investicije


V01.2012 strana 14

definisanje funkcionalnih potreba,

analiziranje razlika sposobnosti i potreba,

preispitivanje marketinga usluga „kupi ili napravi“,

utvrđivanje ROI usluga,

pravljenje specifikacije dizajna usluge,

upravljanje vrednostima usluga, itd.

1.5.1 Projektovanje i testiranje usluge

Kada je završena specifikacija usluge, odnosno sklopljen ugovor o nivou IT usluga koje IT servis

provajder treba isporučivati korisniku, proces projektovanja i testiranja usluge omogućava IT

servis provajderu da razvije i potvrdi funkcionalnu verziju komponente, funkciju usluge, ili end-

to-end uslugu. Kao deo ovog procesa, IT organizacija pribavlja ili pravi neophodne komponente,

funkcije usluge – kao što su mogućnosti backup-a ili funkcionalnost Web-a – i čak end-to-end

rešenja usluge – kao što je na primer SAP. Jednom sastavljena, komponenta, funkcija, ili end-to-

end usluga mora biti temeljno testirana. Pravljenje i testiranje usluge je direktno povezano sa

menadžmentom promenama, menadžmentom konfiguracije, i puštanjem u proizvodnju, kao i sa

drugim procesima u modelu.

Sledeće aktivnosti su deo procesa pravljenja i testiranja usluge:

pribavljanje komponenata usluge

identifikovanje projektnog tima

razvijanje smernica za pripremu usluge

razvijanje smernica za upravljanje operativnim radom i infrastrukturom

integracija primene i infrastrukture

sertifikacija hardware-a i softver-a usluge

konstruisanje mehanizama podrške i kontrole usluge

sprovođenje testova usluge i podrške

razvijanje planova obuke IT osoblja i osoblja korisnika

dokumentovanje izrade usluge (ili glavnih šematskih planova) za izradu plana proizvodnje

Uvek važi posebna napomena: IT servis provajder mora imati sopstvenu infrastrukturu koja će

obezbediti adekvatnu simulaciju realnog poslovnog okruženja i na kojoj će vršiti testiranja novih

i/ili izmenjenih usluga. Sprovođenje testova u „živom okruženju“ može se dopustiti samo u

posebnim slučajevima uz preduzimanje adekvatnih mera koje će omogućiti siguran povratak na

prethodno stanje. Ovo lakše reči nego realizovati, pogotovao danas, kada mnoge organizacije

korisnici IT usluga poveravaju brigu o funkcionisanju svoje ICT infrastrukture „kompjuterskim

hobistima“ koji najčešće nemaju adekvatno obrazovanje i nisu svesni rizika po poslovne procese

korisnika.

1.6 Upravljanje aplikacijama

Upravljanje aplikacijama (videti sliku 2.) pored opisa životnog ciklusa razvoja softvera,

obuhvata i pitanja procesa podrške životnom ciklusu aplikacija i testiranje IT usluga. Upravljanje

aplikacijama takođe obuhvata pitanja koja se odnose na promene u IT usluzi, sa naglašavanjem

na jasno definisanje zahteva za promene i raspodelu odgovornosti i nadležnosti. Promene u

aplikacijama mogu biti poverene organizaciji koja je razvila aplikaciju i poseduje izvorni kod. I u

tom slučaju kada IT servis provajder „outsorsira“ proces izvršenja izmena u aplikaciji on je taj


V01.2012 strana 15

koji je primarno odgovoran za definisanje zahteva za promenu i prijem rezultata. Organizacije

opredeljene za proces održavanja aplikacije bi za razvoj svoje kompetentnosti u oblasti razvoja

softvera trebale da koriste CMM ili ISO 90003 (ISO 9001 sa dodatnim pojašnjenjima šta zahtevi

standarda znače za organizaciju koja razvija softver).

1.7 Isporuka usluge

Isporuka IT usluge (videti sliku 2.) obuhvata grupu od pet procesa koji se odnose na obezbeđenje

isporuke IT usluga kojima se zadovoljavaju ciljevi postavljeni (specificirani) u SLA. To su

sledeći procesi (videti sliku 4.):

Upravljanje nivoom usluga

Upravljanje raspoloživošću

Upravljanje kapacitetom

Upravljanje finansijama u vezi sa IT uslugom

Upravljanje kontinuitetom IT usluge

Ovi procesi čine nerazdvojivu celinu (zasebna OGC knjiga) i sa drugom gupom procesa

„podrška uslugama“ čine zajedno ključni „high level“ proces ISPORUKA USLUGE. Ove dve

grupe procesa su srž ITIL-a i osnova su za implementaciju sistema upravljanja IT uslugama

specificiranog u ISO/IEC 20000-1:2005.

Slika 3 – Procesi isporuke IT usluga


V01.2012 strana 16

1.7.1 Upravljanje nivoom usluge

Upravljanje nivoom usluga omogućava IT-u da definiše, prati, izveštava, i kontroliše specifične

nivoe usluga za kupce unutar predefinisanih standardnih parametara usluge. Od velikog značaja

je povezanost između planiranja usluge i menadžmenta nivoom usluge. Sa detaljnom

specifikacijom usluge na raspolaganju, proces menadžmenta nivoom usluga može utvrditi

merljivost, dostižnost ciljeva nivoa usluge za potencijalne kupce, i omogućiti IT menadžmentu

da lako i brzo specificira SLA sa kojim je kupac saglasan. Oba procesa, i planiranje usluge i

menadžment nivoom usluge su zavisni od rezultata interakcije sa drugim IT procesima.

Sledeće aktivnosti su deo menadžmenta nivoom usluge:

mapiranje standardnih usluga i zahteva korisnika IT usluga

dokumentovanje ciljeva za nivoe usluga

pregovaranje i dokumentovanje SLAs

koordinacija uspostavljanja operacionog nivoa saglasnosti (OLA) i osnovnih ugovora

uspostavljanje osnovnih linija isporuke

analiza performansi i kvaliteta usluge

sprovođenje preispitivanja usluge sa kupcima

preduzimanje povremenih aktivnosti upoređivanja vrednosti

predlaganje poboljšanja usluge.

Upravljanje nivoom usluge obuhvata proces planiranja, koordiniranja, izrade nacrta ugovora,

usaglašavanja ugovora, i proces izveštavanja o sporazumima o nivou usluga (SLA) sa kupcima

sa jedne strane i sa jednim ili više „outsource“ isporučilaca, kao i proces tekućeg preispitivanja

postignutih rezultata IT usluga u podršci poslovnim procesima. Upravljanje nivoom usluga treba

da osigura da je zahtevani i cenovno opravdani kvalitet usluge održavan i gde je to potrebno

stalno poboljšavan. SLAs obezbeđuju osnovu za upravljanje odnosima između provajdera i

Kupca.

1.7.2 Upravljanje finansijama za IT usluge

Upravljanje finansijama omogućava IT-u da ustanovi troškove pružanja usluge i da povrati te

troškove kroz cenu alocirane strukture. Ključne aktivnosti među kojima je praćenje i

kontrolisanje stvarnih troškova od strane isporučioca usluga i od strane korisnika kao i

naplaćivanje korisnicima za isporuku usluge. Važno je precizno pratiti troškove za svaki IT

proces i prenositi ovu informaciju zaposlenima u procesu finansijskog menadžmenta. Finansijski

menadžment je u interakciji sa usklađivanjem IT-a i biznisa (iz razloga budžetiranja) i sa

planiranjem usluga i menadžmentom nivoa usluga (zbog procene cene usluga).

Sledeće aktivnosti su deo finansijskog menadžmenta:

proračunavanje postojećih troškova usluge

analiza projektovanih dobiti

razvijanje budžeta usluga

analiza iskorišćenosti usluge i troškova

razvijanje „kupi ili napravi“ preporuka

proračunavanje porudžbina kupaca

naplata usluga

ustanovljavanje strukture alokacije troškova i naplata


V01.2012 strana 17

proračunavanje ukupnih troškova vlasništva (TCO).

1.7.3 Upravljanje kapacitetom

Upravljanje kapacitetom IT usluga je proces koji omogućava IT-u da definiše, prati i kontroliše

kapacitete usluga, da utvrdi da su radne norme usluga spremne da ispune prethodno ugovorene

nivoe performansi. Od suštinske važnosti je da upravljanje kapacitetom ima tesnu, dvosmernu

vezu sa poslovnom strategijom i procesima planiranja unutar organizacije IT servis

provajdera s jedne strane i sa SLAs s druge strane. Proces upravljanja kapacitetom bi trebalo

da obezbedi informacije o najsvežijim idejama, trendovima i tehnologijama koje se razvijaju od

strane isporučilaca hardvera i softvera, kako bi organizacija mogla da sagleda sve aspekte

dugoročne strategije poslovanja.

Sledeće aktivnosti su deo menadžmenta kapacitetom:

popis servisnih resursa

karakterizacija radnih normi usluga i zahteva

definisanje profila kapaciteta usluga

sprovođenje analize nedostatka kapaciteta

razvijanje „kupi ili napravi“ preporuka (kapaciteta)

analiza podataka performansi usluga (menadžment performansama)

upravljanje zahtevima usluga.

1.7.4 Upravljanje kontinuitetom IT usluge

Upravljanje kontinuitetom IT usluga odnosi se na sposobnost IT organizacije da kontinualno

pruža predeterminisane nivoe usluga kupcima održavajući prekide izazvane incidentima u okviru

ugovorom dopuštenih granica raspoloživosti. Da bi IT servis provajder bio potpuno efektivan,

ovaj proces bi trebalo uključiti kao integralni deo većeg korporativnog procesa upravljanja

kontinuitetom poslovanja kupca. Pošto mnoge organizacije značajno zavise od raspoloživosti

ugovorenih IT usluga, nivo sposobnosti IT provajdera da ispuni zahteve kupca postao je primarni

i prioritetni kriterijum pri odabiru IT servis provajdera, značajniji čak i od kvaliteta IT usluge.

Proces upravljanja kontinuitetom usluge je odgovoran za preduzimanje mera za upravljanje

rizikom da bi se umanjila verovatnoća nastanka velikih otkaza i za izradu plana oporavka, koji

ima vezu sa svim ostalim planovima kontinuiteta poslovanja. Planovi IT oporavka trebalo bi da

budu cost-efektivni, usaglašeni sa poslovanjem i odobreni od najvišeg rukovodstva. Najčešći

slučaj je da izrađen i odobren plan nije proveren u praksi, a osnovni razlog za to je nedostatak

resursa i naročito ukupna cena provere, koja bi morala da simulira realnu katastrofalnu situaciju.

Svetske procene su da cena provere oporavka IT infrastrukture i nastavka poslovanja ide i do

nekoliko miliona dolara.

Sledeće aktivnosti su deo menadžmenta kontinuitetom poslovanja:

identifikacija ključnih IT usluga koje zahtevaju kontigentno8 planiranje za postupanje u

slučajevima materijalizacije pretnji poslovanju organizacije;

identifikacija pretnji, procena rizika po IT usluge i uticaja neraspoloživosti IT usluge na

poslovni proces/procese;

ustanovljavanje zahteva za sposobnost IT usluge/usluga;

8 Contingency planning - planiranje za svaku eventualnost, nepredviđen događaj


V01.2012 strana 18

identifikovanje i priprema za primenu podesnih mehanizama oporavka usluga;

upoznavanje zaposlenih o planu kontinuiteta usluge;

provera i revizija plana oporavka IT usluge i poslovnih procesa na dogovoreni nivo;

Omogućavajući proces je upravljanje rizikom, detaljnije opisan u poglavlju sigurnost

informacija.

1.7.5 Upravljanje raspoloživošću

Proces upravljanja raspoloživošću usluge sadrži aktivnosti dizajna, implementacije, merenja i

upravljanja sa raspoloživošću IT infrastrukture sa ciljem da osigura dosledno zadovoljenje

iskazanih poslovnih zahteva za raspoloživost usluge. Upravljanje raspoloživošću treba da

razmotri sve aspekte (IT infrastrukture i organizacije koja pruža usluge) koji mogu imati uticaj

na raspoloživost, uključujući: obuku, veštine, politike, procese, procedure, i alate.

Sledeće aktivnosti su deo menadžmenta raspoloživošću:

utvrđivanje zahteva za pouzdanost i ispravnost funkcionisanja

sprovođenje analize nedostataka (gap analysis)

izrada preporuka „kupi ili napravi“ u vezi sa raspoloživošću

razvoj „kupi ili napravi“ specifikacija (raspoloživošću)

uspostavljanje veza sa dobavljačima

sprovođenje preispitivanja dobavljača


V01.2012 strana 19

2 Procesi podrške usluzi

Podrška usluzi opisuje pet ključnih procesa koji se odnose na podršku IT usluga za korisnika,

zajedno sa Service Desk funkcijom koja inicira sve ostale procese i predstavlja jedinu tačku

kontakata9 ne samo za korisnike usluga, nego i interno u okviru organizacije servis provajdera.

Međusobne odnose procesa podrške usluzi i ključnih aktivnosti predmetnih procesa prikazuje

Slika 4 – Procesi podrške isporuci IT usluga.

2.1 Upravljanje konfiguracijom

Proces upravljanja konfiguracijom obuhvata identifikaciju svih značajnih komponenata unutar IT

infrastrukture i detaljne zapise o tim komponentama u bazi podataka upravljanja konfiguracijom

(Configuration Management Database - CMDB). CMDB takođe beleži odnose između svih tih

komponenata infrastrukture koji omogućavaju da svi ostali procesi funkcionišu efektivno i

efikasno i sadrži podatke o (ili vezu sa) Definite Software Library10

.

Menadžment konfiguracijom centralno registruje, prati i izveštava o svakoj IT infrastrukturnoj

komponenti. Uobičajen naziv je „element konfiguracije“ (CI) koji je pod kontrolom

konfiguracije. Proces uključuje identifikaciju CI atributa, CI status, i međusobni odnos sa drugim

elementima konfiguracije. Ovi podaci se čuvaju u logičkom entitetu poznatom kao Baza

Podataka Menadžmenta Konfiguracijom (CMDB). Bilo koji drugi IT proces koji utiče na

infrastrukturu mora da sarađuje sa ovim procesom.

Početak implementacije CMDB je zasnovan na inventarisanju IT dobara (IT Asset

Management), što je ujedno jedina briga upravljanja dobrima, procesa koji je knjigovodstvene

prirode i koji vodi računa o licencama i troškovima posedovanja IT dobara.

Sledeće aktivnosti su deo menadžmenta konfiguracijom:

definisanje i održavanje CIs

sprovođenje kontrole IT dobara i računovodstvo statusa

izveštavanje o statusima CMDB

verifikacija integriteta CMDB

9 SPOC – single point of contact

10 Definite Software Library – konačna biblioteka softvera, odobrena za upotrebu u konkretnom

IT sistemu.


V01.2012 strana 20

Slika 4 – Procesi podrške isporuci IT usluga

Treba napomenuti da postoji nekoliko referenci koje obrađuju ovu oblast, počev od ISO/IEC

12207 - Procesi životnog ciklusa softvera i na odredbama ovog „high level“ standarda zasnovan

ISO/IEC TR 15846 – Configuration Management, koji je usaglašen sa ISO 10007:1995 –

Quality Management, Guidelines for Configuration Management. Da ima prostora za i druge

aspekte u vezi sa ovom oblašću svedoći i ISO/IEC 19770:2006 – Software Asset Management.

Međutim, kada potražite gotovo automatizovano rešenje susrešćete se sa softverskim paketima

koji ili imaju ili nemaju dokaz o usaglašenosti sa ITIL.

2.2 Upravljanje promenom

Upravljanje promenom obuhvata proces menadžmenta IT promena za sve tipove promena, od

zahteva za promenu, do procene prioriteta i redosleda sprovođenja promena, testiranja promene,


V01.2012 strana 21

odobravanja, implementacije i na kraju preispitivanja uspešnosti sprovedene promene. Proces

upravljanja promenom je taj koji generiše odobrenje za bilo koju predloženu promenu.

Za velike promene, promene od znatnog uticaja na podršku poslovnim procesima odluke donosi

CEO11

na predlogCAB12

, koji sastavljen uglavnom od poslovnih menadžera kupca i obavezno

od menadžera servis provajdera zaduženih za upravljanje problemima, promenama i

konfiguracijom.

Menadžment promenama osigurava da IT organizacija koristi standardne metode i procedure za

rukovanje sa svim proizvodnim promenama iz okruženja u cilju minimizacije uticaja problema

vezanih za promene na kvalitet usluge. Ovaj proces beleži sve značajne promene u okruženju

preduzeća, koordinira radne naloge povezane sa promenama, dodeljuje prioritete zahtevima za

promene, autorizuje proizvodne promene, raspoređuje resurse, i procenjuje rizik i uticaj svih

promena u IT okruženju. Dati obim ovih procesa, lako je videti zašto je u vezi sa svim drugim

procesima u ITSM referentnom modelu. Kako su procesi predstavljeni, oni neizbežno vrše uticaj

na IT okruženje. Menadžment promenama je važan IT proces koji reguliše ove promene, i kao

rezultat, igra glavnu ulogu u smanjenju nestabilnosti infrastrukture.

Sledeće aktivnosti su deo menadžmenta promenama:

procesiranje zahteva za promenama (RFC)

procena uticaja

verifikacija i validacija promene

odobrenje promene

raspoređivanje i koordinacija promena

koordinacija povratka na prethodno stanje posle neuspele promene

upravljanje hitnim promenama

2.3 Upravljanje izdanjima

Upravljanje izdanjima je veoma tesno povezano sa upravljanjem konfiguracijom i upravljanjem

promenom, i preduzima planiranje, dizajn, izradu i testiranje hardvera i softvera da se kreira set

“release komponenata” za živo okruženje. Aktivnosti obuhvataju planiranje, pripremu i

raspored/redosled puštanja na lokacijama kupca, puštanje i izveštavanje. Posebno su važni

detaljni zapisi kojima se ažurira CMDB.

Upravljanje izdanjima dopušta IT-u da napravi jednu ili više proizvodnih kopija nove ili

nadograđene komponente, funkcije usluge, ili end-to-end usluge za određenog kupca, baziranu

na detaljnom planu proizvodnje. Potrebne komponente izdanja su odobrene (izveštaj o testiranju

promene) i evidentirane u DSL - „Definite Software Library“. Izdanje nije samo sastavljeno od

novih i/ili izmenjenih softverskih komponenata, već i od standardizovanih pratećih komponenata

potrebnih za regularnu instalaciju u „živo“okruženje. Osoblje zaduženo za instalaciju u živo

okruženje je obučeno i plan distribucije i instalacije izdanja je usaglašen sa kupcem i

korisnicima.

Sledeće aktivnosti su deo procesa puštanja u proizvodnju:

nabavljanje resursa

planiranje i realizacija potrebnih obuka

11 CEO – Corporate executive officer – izvršni direktor

12 CAB - Change Advisory Board, Odbor za promene


V01.2012 strana 22

sastavljanje i distribucija komponenti usluge

primena podrške usluzi/mehanizmi kontrole

primena komponenti usluge end-to-end

izvođenje softverske administracije

izvođenje testa proizvodnje

izvođenje testa prihvatanja

2.4 Upravljanje Incidentom

Primarni cilj procesa upravljanja incidentom je restauracija normalne usluge što je brže moguće

posle gubitka usluge i da se minimiziraju negativni uticaji incidenta na poslovne operacije.

Zadatak upravljanja incidentom je, prema tome, osiguravanje da su održavani najbolji mogući

nivo kvaliteta usluge i raspoloživost usluge. Incident se definiše kao bilo koji događaj koji nije

deo standardnih operacija usluge i koji uzrokuje, ili može uzrokovati, prekid ili umanjenje

kvaliteta te usluge. Pored upravljanja incidentima funkcija Servis deska (reaktivna po prirodi)

kao SPOC13

je zadužena i za registraciju svih ostalih informacija koje su od korisnika upućene

IT servis provajderu, među kojima na prvom mestu su zahtevi za izmene. Servis desk mora imati

nesmetan pristup CMDB da bi identifikovao konfiguraciju u kojoj je nastao incident, mogao da

proceni značaj incidenta i pristupio bazi rešenih problema. Ukoliko osoblje servis deska nije u

mogućnosti da otkloni neusaglašenost ono obavezno prosleđuje incident ka upravljanju

problemima ili ka upravljanju sigurnošću. U ovom drugom slučaju obavezno izveštavaju lice

zaduženo za nadzor nad sigurnošću informacija.

Sledeće aktivnosti su deo menadžmenta incidentima:

beleženje incidenata i zahteva za uslugom

kategorizacija incidenata i zahteva za uslugom

prioritetizacija incidenata i zahteva za uslugom

otpremanje zahteva za uslugom

izolacija incidenata

intenziviranje – eskalacija incidenta (unutar procesa ili hijerarhije)

praćenje incidenata i napredovanja zahteva za uslugom

obaveštavanje korisnika

rešavanje incidenata (samostalno ili od strane upravljanja problemom)

zatvaranje incidenta ili zahteva za uslugu

2.5 Problem Management

Cilj procesa upravljanja problemom je da brzim rešenjem problema minimizira negativan uticaj

incidenata i problema na poslovne procese koji su uzrokovani greškama unutar IT infrastrukture,

i da spreči ponovno pojavljivanje incidenata uzrokovanih tim greškama. Problem menadžment

ima reaktivni i proaktivni aspekt.

1. Reaktivni aspekt – korekcije se odnose na rešavanje nastalog problema u vezi sa jednim

ili više incidenata – poznato rešenje, otklonjene ili ublažene posledice incidenta, uzrok

nije otklonjen.

13 SPOC – Single Point of Contact


V01.2012 strana 23

2. Proaktivni aspekt – korektivne mere se odnose na identifikaciju i otklanjanje uzroka

nastalog incidenta prije nego se on ponovo pojavi.

Aktivnosti upravljanja problemom uključuju i analize trendova i kontrolu grešaka sa ciljem da se

obezbede dugoročna rešenja. Ovaj proces kao ulaz dobija podatke i informacije od Servis deska i

rešenja vraća Servis desku koji planira dalje postupanje i komunikaciju sa korisnikom. U

mnogim organizacijama osoblje Servis deska i osoblje zaduženo za proces upravljanja

problemima čine jedan pul međusobno izmenjivih i kompetentnih specijalista, tako su svi

upoznati sa najčešćim problemima, poznatim problemima i potencijalnim problemima unutar

infrastrukture. To omogućava da mogu brzo reagovati, čime je bar jedna od karakteristika usluge

zadovoljena.

Sledeće aktivnosti su deo problem menadžmenta:

evidencija incidenata

komunikacija sa korisnikom

analiziranje trenda incidenata

beleženje problema

identifikovanje osnovnih uzroka

praćenje napredovanja rešenja problema

verifikovanje poznatih grešaka

kontrolisanje poznatih grešaka

rešavanje problema

zatvaranje problema/poznate greške

ažuriranje baze poznatih problema.

2.6 Service Desk

Servis desk je funkcija, za razliku od ostalih procesa koji čine podršku usluzi. U upotrebi su i

druge forme i sadržaji ove funkcije, zavisno od potreba. Najčešće Call Centar ili Help Desk

prirodno evoluiraju u Servis Desk kada organizacija preduzme korake poboljšavanja i proširenja

sveukupne usluge kupcu. Bitno je napomenuti da se SPOC – Single (or Central) Point Of

Contact odnosi i na korisnike i na osoblje IT servis provajdera, koje je upravo ovakvim

pristupom oslobođeno od svakodnevnog komuniciranja sa korisnikom. Funkcija servis deska

kroz komunikaciju sa korisnikom/korisnicima prihvata i razrešava izveštaje kupca o otkazima,

poteškoćama, žalbama ili pitanjima u vezi sa IT uslugom. Servis desk obezbeđuje vezu sa

drugim aktivnostima kao što su zahtevi kupca za izmene, ugovori o održavanju, softverske

licence, sporazumi o nivou usluga i upravljanje konfiguracijom.


V01.2012 strana 24

3 ITIL danas

Godine 2004. Kancelaraija Vlade Velike Britanije - Office of Government Commerce započeo je

drugu fazu modernizacije ITIL standarda. Do tog koraka je došlo zbog masivnog napretka u

razvoju tehnologije što je rezultujelo nastajanjem novih izazova za davaoce IT usluga.

Nakon dvadeset godina od svog nastanka ITIL je i dalje ostaje najšire poznat okvir za

upravljanje IT uslugama na svetu. Uprkos razvoju i proširenju materije i dalje sadrži

fundamentalne koncepte najbolje prakse u industriji.

Princip ITIL standarda najjednostavnije bi bilo opisati sledećim rečima: „Radi ono što

funkcioniše.“ A ono što funkcioniše prilagodi zajedničkom okviru praksi koje ujedinjuju sva

područja IT usluga, a sve sa ciljem isporuke vrednosti poslovanju.

Sledeće četiri karakteristike ITIL-a su zaslužne za globalnu prepoznatljivost tog standarda :

1. Vlasništvo – ITIL se ne bazira na specifičnoj tehnološkoj platformi stoga je primenjiv u

bilo kojoj organizaciji. ITIL je u vlasništvu Vlade Velike Britanije i nije vezan za nikakva

komercijalna rešenja i prakse.

2. Primenjivost – ITIL je testiran kroz vreme i može se primeniti na sve vrste uslužnih

organizacija. Može se koristiti u privatnom i javnom sektoru, u odeljenjima organizacija

zaduženih za unutrašnje funkcionisanje ali i sektorima koji pružaju usluge prema

spoljnjim klijentima. Takođe primjenjiv je u malim, velikim i srednjim organizacijama

bez obzira na tehnološku okolinu.

3. Najbolja praksa – ITIL se sastoji od najboljih praksi prikupljenih od najuspešnijih i

najefikasnijih organizacija koje pružaju usluge

4. Dobra praksa – ITIL sadrži skup najboljih i dobrih praksi, najbolje praksu sazrevaju

vremenom i postaju dobre prakse, te postepeno s vremenom bivaju zamenjene novim

principima

3.1.1 Definicija najbolje prakse

Najbolja praksa je niz smernica utemeljenih na iskustvima najkvalifikovanijih i stručnih

profesionalaca iz pojedinih područja.

Najbolja praksa se bazira na :

Iskustvu i znanju više od jedne osobe

Iskustvu više od jedne organizacije

Više od jedne tehnologije

Više od jednog događaja

3.1.2 ITIL V3

Treća i trenutno aktualna verzija ITIL standarda pokriva područje upravljanja uslugama sa šest

publikacija:

1. Uvod u ITIL princip upravljanja uslugama

2. Strateško planiranje IT usluga (Service Strategy)

3. Dizajn IT usluga (Service Design)

4. Tranzicija IT usluga u operativnu uporabu (Service Transition)


V01.2012 strana 25

5. Operativna uporaba IT usluga (Service Operation)

6. Kontinuirano poboljšanje IT usluga (Continual Service Improvement)

Slika 1 Područja pokrivena sa ITIL V3 [The art of Service – The Exam Preparation Book, 2007.

str.13]

Slika 1 prikazuje kako publikacije prate životni ciklus usluge.


V01.2012 strana 26

4 Životni ciklus IT usluge prema ITIL konceptu

ITIL V3 održava holistički pristup upravljanja uslugama koji se temelji se na životnom ciklusu

usluga. Pet ključnih knjiga prate pet ključnih stadijuma životnog ciklusa usluga. Svaka faza

životnog ciklusa utieče na ostale cikluse ali isto tako i ostali ciklusi utieču na njega samog.

Takvim dizajnom osigurano je da se promenom poslovnih zahteva usluga može prilagoditi i

efikasno odgovoriti na novu i drugačiju potrebu.

Bitno je istaknuti da ključni princip u dizajnu životnog ciklusa usluge prema ITIL-u je da sve

usluge moraju proizvoditi merljivu vrednost namenjenu poslovnom sistemu. IT usluga koja se

pruža klijentu mora biti merljiva i mora se moći kvantifikovati u pojmovima vrednosti za čitav

poslovni sistem. Upravo podizanje vrednosti poslovnog sistema je primarni cilj ITIL principa

upravljanja IT uslugama. Taj način postaje sve važniji jer IT organizacije sve više moraju biti

vođene kao poslovne organizacije kako bi opravdale svoje postojanje i prikazale zadovoljavajući

povrat na uloženo.

Slika 2 Životni ciklus usluge prema ITIL konceptu

[OGC, The Official Intorduction to the ITIL Service Lifecycle, 2007, str. 19]

4.1.1 Uzorak životnog ciklusa IT usluge prema ITIL konceptu

Dominantan uzorak životnog ciklusa je sekvencijalni napredak koji počinje strateškim

planiranjem (Service Strategy). Životni vek IT usluge iniciraju poslovni zahtevi koji proizlaze iz

poslovne strategije. Zahtevi se identifikuju i modifikuju kroz paket dogovorenih nivoa usluga

(Service Level Package - SLP) unutar faze strateškog planiranja usluga (Service Strategy). IT


V01.2012 strana 27

organizacija kao davalac usluga mora prepoznati potrebe korisnika i jačati konkurentnost na

tržištu pružanja usluga. Isto tako mora ostvariti sposobnost da korisnici prepoznaju njihove

usluge ne samo za podršku poslovnim procesima, već i za poslovni razvoj i inovacije. U toj fazi

se iz različitih poslovnih studija sagledavaju potrebne usluge, analiziraju, odobravaju i

ugovaraju.

Nakon toga sledi faza dizajna IT usluga (Service Design) koja kreira sva potrebna rešenja za

provođenje IT usluga i pohranjuje ih u paket dizajniranih usluga (Service Design Package

(SDP)).

Sledi faza ocjenjivanja, testiranja i vrednovanja dizajniranih IT usluga (Service Transition) u

kojoj se usluge osposobljavaju za operativnu primjenu. Nakon koje sledi operativna uporaba IT

usluga (Service Operation) koja pak završava u strateškom planiranju.

Međutim to nije jedini obrazac delovanja. Svaki stadijum životnog ciklusa daje povratnu

informaciju i mogućnost kontrole. To omogućava veću fleksibilnost i kontrolu u različitim

okolinama i situacijama. Tako na primer kontrolna perspektiva bazirana na procesima je bolja za

dizajn, razvoj i unaprjeđenje procesa za dizajn IT usluga.

.

Slika 3 Petlja povratnih veza [OCG, The Official Intorduction to the ITIL Service Lifecycle,

2007, str. 21]

Za upravljanje ugovorima i sporazumima prikladniji je kontrolni pristup baziran na životnim

ciklusima

Glavna karakteristika životnog ciklusa IT servisa prema ITIL-u su kontinuirane povratne

informacije kroz svaki stadijum životnog ciklusa. Povratne informacije osiguravaju da se

optimizacijom usluga upravlja iz poslovne perspektive te da se učinak dostavljenih IT usluga

može meriti u smislu vrednosti koja proizlazi iz dostavljene IT usluge u bilo kojem stadijumu

životnog ciklusa.


V01.2012 strana 28

Slika 5 - ITIL – Isporuka usluge i podrška usluzi

Životni ciklus IT usluge prema ITIL-u je dizajniran nelinearno. U svakoj tački životnog ciklusa

IT usluge kontrola, procene i povratne informacije teku između faza. I upravo prema tim

informacijama donose se odluke o promenama u funkcijama ili čitavim uslugama. Na slici 4.

prikazane su povratne veze između faza.

4.1.2 Konntinuirano unapredenje usluga (Continual Service Improvement)

Sve faze životnog ciklusa prate procesi merenja i kontinuiranog unapređenja u svrhu podizanja

nivoa zrelosti IT organizacije, IT procesa i kvalitete IT usluga (Continual Service Improvement)

kao sto je prikazano na slici 5.

Ciklus kontinuiranog unapređenja počinje sa definisanjem vizije i poslovnih ciljeva organizacije

(davalaca usluga). Nakon toga se procenjuje nivo usluga koje se trenutno pružaju, kako bi se

nakon što se počnu implementirati promene procesa mogao mjeriti uspjeh provedenih mjera.

Svaka IT organizacija mora imati program kontinuiranog unaprjeđenja sto znaci da procjenom

svog trenutnog stanja u pružanju vrednosti korisnicima i novim ciljevima koje želi ostvariti u

skladu s vizijom, IT organizacija mora definisati kljucne procese, aktivnosti i organizacijske

odgovornosti za realizaciju istih. Procese koji podupiru životni vijek usluga treba kontinuirano

pratiti i poboljšavati kako bi i nivoa kvalitete usluge bila veća [Kozina, 2007, str. 9].


V01.2012 strana 29

Slika 4 Model kontinuiranog unapređenja usluge



V01.2012 strana 30

4.2 Dizajn IT usluga (Service Design)

Glavna svrha faze dizajn IT usluga je dizajn novih ili promenjenih usluga koje se mogu uvesti u

realno okruženje. Pri tome je bitno usvojiti holistički pristup svim aspektima dizajna usluge –

prilikom promene bilo kog elementa moraju se uzeti u obzir svi elementi koji bi mogli tom

promenom biti obuhvaćeni. Dakle svaki razvoj neke nove usluge ne sme se obavljati u izolaciji

nego treba uzeti u obzir uticaj na celokupnu uslugu, arhitekturu i tehnologije, proces upravljanja

uslugama te načine merenja rezultata usluge. Takvim pristupom osigurava se da se osim

funkcionalnih elemenata i upravljačke i operativne komponente takođe posmatraju kao

elementarni deo procesa dizajna.

Slika 5 Pozicija Dizajna IT usluga u čitavom modelu unapređenja usluge


4.2.1 Cilj faze dizajn IT usluga

Glavni cilj faze dizajna IT usluga je dizajn novih usluga. Zahevi za te nove usluge se izvode iz

portfelja usluga. Svaki zahtev potrebno je analizirati, dokumentirati i donijeti zaključak o

opravdanosti. Kada se dizajnira rješenje zahteva, tj. nova usluga, ona se mora usporediti sa

strategijom i ograničenjima definisanim u fazi Strateško planiranje IT usluga, a kako bi se

osiguralo da odgovara korporativnoj i IT strategiji.

Dizajn IT usluga obuhvata njihovu arhitekturu, procese, politike i dokumentaciju – cilj je

zadovoljenje svi sadašnjih i budućih poslovnih zahteva. Čitava faza započinje definisanjem i

prepoznavanjem poslovnih zahteva, a završava razvojem rešenja za uslugu. Naravno, usluga

mora biti dizajnirana tako da zadovolji sve prethodno definirane poslovne zahteve [Kozina,

2007, str. 11].

Glavni ciljevi ove faze su14:

Dizajn usluga koja će zadovoljiti poslovne zahteve

Dizajn procesa za podršku životnom veku usluge

Dizajn IT infrastrukture, okoline, aplikacija, resursa podataka

Dizajn mernih metoda i metrika

Razvoj veština i sposobnosti unutar IT-a

14 Kozina M., ITIL koncept u uspostavi servisne IT organizacije, FOI, Varaždin, 2007., str. 11.


V01.2012 strana 31

Doprinos celokupnom poboljšanju kvaliteta IT usluga

4.2.2 Koristi pravilnog dizajniranja IT usluga

Dobar dizajn IT usluga omogućava dostavu kvalitetne i jeftine usluge te osigurava da su

poslovni zahtevi ispunjeni.

Ukoliko se usvoji kvalitetna praksa dizajniranja IT usluga dolazi do sledećih koristi15:

Smanjeni ukupni trošak vlasništva – ako su usluga, procesi i tehnologija pravilno

definisani i implementirani u skladu sa dizajnom, smanjuje se trošak vlasništva

komponenti koje su potrebne kako bi se isporučila IT usluga

Unapređen kvalitet usluge – kvaliteta usluge će se poboljšati

Unaprjeđena konzistencija usluge – dosljednost IT usluge je poboljšana jer je dizajnirana u

skladu sa korporativnom strategijom, predviđenom arhitekturom i ograničenjima

Lakša implementacija novih ili promijenjenih IT usluga

IT usluge su usklađenije – pravilno usvojeni koncept dizajna IT usluge osigurava da nove

IT usluge odgovaraju poslovnim zahtevima te da nove usluge ispunjavaju zahteve

definirane u Service Level Agreementu

Efikasnija IT usluga

Unaprijeđeni IT governance

Efektivnije upravljanje IT uslugama i procesima

Kvalitetniji proces donošenja odluka – dobar dizajn usluga olakšava merenje njihovog

učinka i samim time daje podlogu za donošenje kvalitetnijih odluka

4.2.3 Delokrug faze dizajn usluga

Implementacija Service Design faze treba pripremiti i planirati efektivno upotrebom četiri

faktora poznatih pod nazivom 4P. To su16

:

Ljudi (People) – korisnici, klijenti, IT osoblje, menadžeri. Nužno je definisati kanale

komunikacije, jasnu psektoru uloga i odgovornosti i održati treninge ukoliko je to potrebno

za sve uključene strane.

Procesi (Processes)

Proizvodi – usluge, tehnologije, alati (Product)

Partneri (Partners)


2007., str. 45.

16 HP, ITIL V3, student guide, Hewlett Packard, 2007, str. 4-175


V01.2012 strana 32

Slika 6 - 4P faktori

4.2.4 Revizija trenutnog stanja

Pre nego se usvoji model za dizajniranje nove IT usluge potrebno je napraviti reviziju trenutnog

stanja. Posebno treba obratiti pažnju na sve aspekte koji učestvuju u isporuci IT usluge.

Takva revizija treba uključiti17

:

Poslovne zahteve

Opseg i mogućnosti trenutnih IT usluga

Zahteve i ciljeve koje mora zadovoljiti nova usluga

Opseg i mogućnosti dobavljača

Organizacijsku kulturu organizacije koja je obuhvaćena

IT infrastrukturu, aplikacije, podatke

Stupanj razvoja korporativnog i IT upravljanja u organizaciji

Budžet i raspoloživa sredstva

Nivo znanja i veština osoblja koje deluje u organizaciji

4.2.5 Ključni procesi Service Design faze

Ključni procesi Service Design faze su:

Upravljanje katalogom servisa (Service Catalogue Management)

Upravljanje dogovorenim nivoama servisa (Service Level Management)

Upravljanje kapacitetima (Capacity Management)

Upravljanje raspoloživošću (Availability Management)

Upravljanje kontinuitetom IT servisa (IT Service Continuity Management)

Upravljanje informacijskom sigurnošću (Information Security Management)

Upravljanje dobavljačima (Supplier Management)


2007., str. 48.


V01.2012 strana 33

4.2.6 Upravljanje katalogom usluga (Service Catalogue Management)

Sa razvojem organizacije kroz određeni vremenski period, takođe se razvija i mijenja IT

infrastruktura organizacije. Zbog toga ponekad nije u potpunosti jasno koje sve IT usluge se

trenutno osiguravaju i koji su klijenti koji koriste te usluge. Kako bi se ostvarila aktualna slika

trenutnog stanja, preporuča se da portfelj IT usluga sadrži katalog usluga kao centralni

repozitorij informacija o svim uslugama.

4.2.6.1 Katalog usluga

Katalog usluga (Service Catalogue) je detaljan opis usluga koje organizacija može osigurati, a

napisan u terminologiji razumljivoj klijentima. Kao takav olakšava komunikaciju i usklađivanje

između primalaca i davalaca usluga.

Svrha procesa Upravljanje katalogom servisa je održavati informacije sačuvane u katalogu

usluga, tj. osigurati da informacije u katalogu odražavaju točno trenutačno stanje u organizaciji.

Katalog usluga ima dva glavna aspekta18

:

1. Poslovni katalog usluga- sadrži detalje svih IT usluga koje se pružaju klijentu te prikazuje

koji se poslovni procesi oslanjaju na koje IT usluge. To je pogled klijenta na IT usluge.

2. Tehnički katalog usluga – sadrži detalje o svim IT uslugama koje je se pružaju klijentu te

prikazuje veze usluga sa ostalim potpornim procesima koji su potrebni kako bi se te IT

usluge mogle osigurati. Služi kao nadopuna Poslovnom katalogu i nije dio perspektive

klijenta na IT usluge.

Slika 8 prikazuje elemente poslovnog i tehničkog kataloga usluga.


2007., str. 50.


V01.2012 strana 34

Slika 8 Elementi kataloga servisa


4.2.7 Upravljanje dogovorenim nivoima servisa (Service Level Management )

Faza upravljanje dogovorenim nivoom IT usluga ima centralnu ulogu u procesima upravljanja IT

uslugama. U ovoj fazi se pregovara, dogovara i dokumentuje ciljeve koje IT usluge trebaju

postići kako bi poduprle poslovanje. Takođe, u ovoj fazi se i nadzire ostvarenje definisanih

ciljeva i na temelju nadzora se stvaraju izveštaji u kojima se ocjenjuje sposobnost davalaca IT

usluge da dostavi dogovorenu nivo usluge. Ciljevi i odgovornosti za svaku aktivnost u IT

definisani su u dokumentima Service Level Agreement (SLA) i Service Level Requirements

(SLR).19

Ako su ti ciljevi definisani pravilno i u skladu sa zahtevima poslovnog sistema, onda će pružena

IT usluga zadovoljiti zahteve poslovnog sistema i ispuniti očekivanja klijenata u pogledu

kvaliteta usluge.

Ako ciljevi nisu u skladu sa zahtevima poslovnog sistema, tada aktivnosti koje provodi davalac

usluge neće podržati poslovanje na željeni način i problem će eskalirati.

Uspeh ove faze zavisi od kvaliteta portfelja usluga i kataloga usluga i njihovom sadržaju, jer ta

dva dokumenta pružaju potrebne informacije o uslugama koje će se obrađivati u ovoj fazi.

19 OGC, Service Design, The Stationery Office, London, 2007., str. 65.


V01.2012 strana 35

Slika 9 Upravljanje nivoama usluga [OGC, Service Design, 2007, str. 62]

4.2.7.1 Svrha i cilj SLM faze

Cilj faze upravljanje dogovorenim nivoima usluga je osigurati da je isporučen prethodno

ugovoren nivo IT u sadašnjosti ali i budućnosti. Takođe, u ovoj fazi se preduzimaju mere kako bi

se pronašle mogućnosti za unaprjeđenje nivooa usluge koja se trenutno osigurava.

Svrha ove faze je osigurati da se pružene usluge i njihov učinak mere konstantno na konzistentan

način kroz čitavu IT organizaciju te da izveštai koja nastaju na temelju tih aktivnosti

zadovoljavaju zahteve koje definišu klijenti i poslovanje.

Ciljevi faze upravljanje dogovorenim nivoom usluga20

:

Definisanje, dokumentoranje, dogovor, nadziranje, merenje, izveštavanje i revizija nivooa

pruženih IT usluga

Osigurati i unapriediti odnos i komunikaciju za poslovnim sistemom i klijentima

Osigurati da su specifični i merljivi ciljevi definisani za sve IT usluge

Nadzirati i pokušati povećati zadovoljstvo klijenata sa dostavljenim kvalitetom usluge

Osigurati da IT i klijenti imaju jasno i nedvosmisleno razumevanje nivooa IT usluge koja

mora biti isporučena

Osigurati da su proaktivne mjere za poboljšanje usluge implementirane kad god je to

moguće pod uslovom da je trošak opravdan



V01.2012 strana 36

4.2.7.2 Delokrug SLM faze

Faza upravljanje dogovorenim nivooima IT usluga treba biti tačka u kojoj se uspostavlja stalni

kontakt i komunikacija između davalaca IT usluge i klijenta koji koristi uslugu. Ova faza

davalaca IT usluge se predstavlja poslovnom sistemu i poslovni sistem davaoca IT usluge.

Obuhvatiti treba upotrebu postojećih usluga ali i potencijalnih budućih potreba za nove ili

promenu postojeće usluge.

SLM treba upravljati očekivanjima i percepcijom poslovnih korisnika IT usluge i osigurati da

kvaliteta isporučene usluge odgovara tim potrebama i očekivanjima. Da bi se to postiglo

učinkovito, SLM faza treba uspostaviti i održavati SLA za sve sadašnje usluge i upravljati

nivooima kvaliteta usluge na način da zadovolji sve ciljeve definisane u SLA-u.

U SLM fazi takođe se treba definisati SLR za sve planirane nove ili promenjene trenutne usluge.

To će osigurati da su sve usluge i komponente dizajnirane i isporučene tako da podržavaju

poslovni sistem na željeni način.

SLM proces treba uključiti21

:

Razvoj odnosa s poslovnim sistemom

Pregovore i sporazum o trenutnim potrebama za IT uslugom i ciljevima koji trebaju biti

postignuti

Dokumentaciju i upravljanje SLA za sve operativne usluge

Pregovore i sporazume o budućim potrebama i ciljevima

Dokumentaciju i upravljanje SLR za sve predložene nove ili promenjene usluge

Razvoj i upravljanje odgovarajućim OLA kako bi se osiguralo da su ciljevi usklađeni s

ciljevima SLA

Pregled ugovora s dobavljačima kako bi se osiguralo da su ciljevi usklađeni sa ciljevima

SLA

Proaktivna prevencija mogućih kvarova u uslugama, smanjenje rizika i poboljšanje

kvalitete usluge

Sprovođenje i koordinacija plana za poboljšanje procesa

4.2.7.3 Politike / principi / osnovni pojmovi

Faza upravljanje dogovorenim nivoima IT usluga obuhvata procese

planiranja,

koordinacije,

dogovora,

izrade,

nadziranja

i izveštavanja SLA

u cilju postizanja kvaliteta određene IT usluge uz minimalne troškove. Međutim, ova faza se ne

bavi samo trenutnim uslugama, već SLA treba osigurati da novi zahtevi budu na vreme primljeni

te da nove i promenjene usluge podržava poslovanje na željeni način.

4.2.7.3.1 Service Level Aggrement - SLA



V01.2012 strana 37

SLA je osnova upravljanja odnosom između davalaca IT usluge i klijenta. SLA je pismeni

ugovor između davalaca IT usluge i klijenta koji koristi uslugu, te definiše ključne ciljeve i

odgovornosti svih strana.

Naglasak u SLA mora biti na ugovoru. Ugovor se ne koristi kao način da se drugu stranu u

podčinjenom položaju već treba razvijati partnerstvo. Ako se ugovor ne koristi na navedeni

način, počinje sprječavati poboljšanje usluga i razvija se pogrešan odnos između strana vezanih

ugovorom. 22

SLM je takođe odgovoran da svi ciljevi i mjere usuglašeni u SLA-u budu poduprti

odgovarajućim OLA-ima s jedinicama unutrašnje podrške i sa spoljnji m partnerima i

dobavljačima kao sto je ilustrirano na slici.

4.2.7.3.2 Elementi SLA

Većina SLA definisanih prema ITIL-u sadrži nekoliko zajedničkih elemenata23

:

Opis usluge

Obim sporazuma

Raspoloživost usluge

Pouzdanost

Korisničku podršku

Kontakt osobe

Proces eskalacije

Pragovi odnosno okidači eskalacije

Akcije koje se preduzimaju nakon eskalacije

Rečnik

4.2.7.4 Operational Level Aggrement - OLA

OLA je ugovor između davalaca IT usluge i klijenta koji su dio jedne organizacije koja se bavi

pružanjem usluga. OLA treba sadržavati ciljeve koji će podupirati one unutar SLA kako bi se

osiguralo da elementi iz SLA ne budu prekršeni zbog neuspjeha pratećih, potpornih djelatnosti.

24

ITIL savjetuje da svaki SLA bude potpomognut sa jednim ili više OLA, a da SLA djeluje kao

interfejs preko kog se upoznaje poslovni sistem sa odredbama i performansama usluge koja se

osigurava.25

4.2.7.4.1 Elementi OLA

Većina OLA definisanih prema ITIL-u sadrži nekoliko zajedničkih elemenata26

:



IBM, Boston, 2010., str. 39


25 Rob Addy, The Effective IT Service Management, Springer, New York, 2010., str. 279.


V01.2012 strana 38

Detalje o prethodnim izmjenama i dopunama

Djelokrug ugovora

Ciljeve

Raspoloživost usluga

Kontakte u slučaju eskalacije

Definisane odgovornosti i vreme odziva korisničke službe

Upravljanje promenama

Rečnik

Listu izmena

4.2.7.4.2 Aktivnosti, metode i tehnike SLM faze

Ključne aktivnosti u SLM procesu su27

:

Određivanje, pregovaranje, dokumentacija i dogovaranje zahteva za nove ili promenjene

usluge u SLR, upravljanje i revizija tih usluga kroz životni ciklus i uvođenje u SLA

Nadziranje i merenje učinkovitosti IT usluge i upoređivanje sa ciljevima definisanim u

SLA

Merenje i unaprjeđenje zadovoljstva klijenata

Kreiranje izveštaja o uslugama

Pregled i revizija SLA, OLA, ugovora i svih ostalih dokumenata

Razvoj i dokumentovanje kontakta i odnosa sa korisnicima, poslovnim partnerima i svim

interesnim grupama

Razvoj, održavanje i vođenje postupaka za zapisivanje i rešavanje tužbi i pohvala

Upravljanje informacijama koje su potrebne pri upravljanju učinkom i demonstracija

ostvarenja

Redovno održavanje i osiguravanje dostupnosti SLM šablona

Odnosi između aktivnosti prikazani su na slici 10. koja prikazuje glavne aktivnosti SLM

procesa. Sve aktivnosti trebaju biti integrisane u jedan SLM proces koji može biti konstantno

primenjiv na sva područja poslovanja i prema svim klijentima.


IBM, Boston, 2010., str. 43



V01.2012 strana 39

Slika 10 Proces upravljanja nivoima usluga [OGC, Service Design, 2007, str. 68]

4.2.7.5 Dizajniranje SLA okvira:

Koristeći katalog usluga, SLM mora dizajnirati najprikladniju SLA strukturu kako bi se

osiguralo da su sve IT usluge i klijenti pokriveni na način koji najbolje odgovara potrebama

organizacije. 28

Service level agreement može biti definisan na nekoliko načina:

Corporate level SLA

Customer level SLA

Multi level SLA

4.2.7.5.1 Service based SLA

Ugovor pokriva jednu IT uslugu za sve korisnike. Na primer SLA koji pokriva uslugu osiguranja

e-mail pošte – obuhvata sve klijente te usluge. Poteškoće nastaju ako različiti klijenti koji koriste

istu uslugu imaju specifične zahteve ili pak ako su zbog infrastrukture različiti nivoi usluga

neizbežni. U takvim slučajevima definišu se različiti ciljevi unutar istog ugovora.

Gde je moguć isti nivo IT usluge koja se pruža svim područjima poslovnog sistema (npr.

osiguranje e-mail, a telefonskog sistema, i sl.) Service based SLA je efikasan pristup.



V01.2012 strana 40

4.2.7.5.2 Customer based SLA

Ugovor sa grupom korisnika koji pokriva sve IT usluge koje ta grupa koristi (npr. sporazum

između sektora finansija i IT sektora koji pokriva računovodstveni sistem, sistem naplate sistem

javne nabavke i bilo koji drugi informatički sistem koji sektor finansija koristi za svoje

delovanje). Klijenti često preferiraju takav oblik SLA jer u jednom dokumentu su sadržani svi

zahtevi za IT uslugama koje oni koriste.

4.2.7.5.3 Multi level SLA

SLA takođe može biti definisan na više nivoa kao sto je ilustrovano na slici 11. Sledeći primer

opisuje SLA definiran na tri nivoa29

:

1. Korporativni nivo – pokriva sva SLM pitanja za svakog korisnika IT usluge u čitavoj

organizaciji. Situacije koje pokrivaju ovaj nivo su prilično nepromenjiva pa česta

ažuriranja nisu potrebna.

2. Klijentska nivo – pokriva sve situacije vezane uz određenu grupu korisnika ili poslovni

sektor bez obzira na vrstu usluge koju koriste

3. Nivo usluge – pokriva sve situacije vezane uz specifičnu uslugu koji koriste određene

grupe klijenata

Slika 11 Višerazinski SLA [OGC, Service Design, 2007, str. 69]

Ukoliko je struktura SLA definisana na više nivoa potrebno je uložiti dodatan napor kako bi se

izbeglo nepotrebno dupliciranje na različitim nivoama. Takođe potrebno je više rada kako bi se

uredili odnosi i veze između Service Catalogue i Configuration Management System.

Organizacije često definišu svoje standarde i predloške koji zatim služe kao polazna

tačka za sve SLA, SLR i OLA. Razvoj takvih standarda osigurava da su svi sporazumi razvijeni



V01.2012 strana 41

na skladan i konstantan način te to olakšavanja kasnije korištenje i upravljanje tim dokumentima 30.

Tekst SLA treba biti kratak i jasan i ne sme ostavljati mesta dvosmislenosti. Nema

potrebe za pravnom terminologijom već treba težiti svakodnevnom vokabularu. Preporučljivo je

da SLA sadrži rečnik koji definiše sve pojmove korišćene u tekstu ugovora koji bi mogli izazvati

nejasnoće.

Ukoliko SLA pokriva usluge koje se dostavljaju u inostranstvo, treba obratiti pažnju na kvalitet

prevoda. SLA izrađen na jednom jeziku koji se koristi u različitim delovima sveta – mora uzeti u

obzir različitosti u terminologiji, stilu i kulturi različitih zemalja.

Gdje IT usluge pružaju druge organizacije, odnosno spoljnji saradnici, ciljevi IT usluga ponekad

su definisani u ugovoru, a ponekad u SLA koji je pridodan ugovoru. Koji god dokument se

koristi, od ključne je važnosti da su ciljevi jasno i jednoznačno dokumentovani jer to pruža

temelj za uspešan odnos i kvalitetnu isporuku IT usluga. 31

4.2.7.5.4 Utvrđivanje, dokumentacija i usuglašivanje oko zahteva za novim IT uslugama i

definisanje SLR

Kad su definisani katalog IT usluga i struktura SLA, prvi SLR mora biti sastavljen. Poželjno je

uključiti klijente od samog početka definisanja, dakle nakon prvog nacrta ciljeva, načina

upravljanja koji mogu poslužiti kao temelj za detaljnu raspravu.

Bitno je istaknuti važnost određivanja inicijalnih ciljeva koji će biti uključeni u SLR i SLA. Svi

ostali procesi moraju biti razmotreni i konsultovani da li su usuglašeni ciljevi realni i da li je

realno očekivati da će biti ostvareni. Upravljanje incidentima treba konsultovati o ciljevima

vezanim uz incidente, upravljanje kapacitetima i raspoloživošću će pružiti vredne informacije

koje će poslužiti u određivanju ciljeva dostupnosti usluge. Ako ipak postoje sumnje u izvršenje

zadatih ciljeva, mogu se odrediti privremeni ciljevi koji se uključe u pilot SLA koji se prati i

podešava kroz garantni period.32

Osim definisanja SLA, važno je i ustanoviti procedure za definisanje SLR za nove IT usluge

koje se razvijaju ili se nabavljaju izvana. SLR mora biti integralni deo faze dizajna IT usluga. Od

početka životnog ciklusa IT usluge, kroz sve faze treba uključiti SLR. Kako usluga napreduje

kroz faze životnog ciklusa, tako će se i SLR postepeno redefinisati i na kraju postati okvirni

SLA. Taj SLA zatim treba formalizirati prije nego je usluga uvedena u praktičnu upotrebu33.

Ponekad može biti teško definisati zahteve jer krajnji klijenti u poslovnom sistemu nisu sigurni

šta žele. Krajnjim korisnicima, u procesu planiranja, potrebno je pružiti podršku u razumevanju i

definisanju njihovih potreba, posebno u smislu kapaciteta, sigurnosti i dostupnosti IT usluga.

Zahtevi izneseni na početku planiranja najčešće nisu oni koji su usuglašeni na kraju procesa.

Nekoliko iteracija pregovaranja i usuglašavanja može biti potrebno kako bi se pronašla ravnoteža

između onog što je zahtevano i onog što je ostvarivo i pristupačno.

Kad su nove IT usluge uvedene u operativnu primenu, treba obratiti pažnju i na planiranje i

formalizovanje podrške za novu uslugu i njene komponente. Savet treba potražiti od procesa

upravljanja promenama kako bi se osiguralo da je planiranje sveobuhvatno i da obuhvata



32 Ibid, str. 69.

33 Ibid, str. 70.


V01.2012 strana 42

implementaciju i podršku usluge i komponente. Specifične odgovornosti trebaju biti definisane i

dodate postojećim ugovorima, ili se definišu novi. Potporni aranžmani i eskalacijske rute takođe

moraju biti dodati u postojeći CMS, uključujući katalog usluga, tako da korisnička služba i druge

grupe za podršku su svesne nastalih promena. Ukoliko je to prikladno, valja osigurati inicijalni

trening i upoznavanje za Service Desk i ostale grupe za podršku – prenos znanja mora biti

završen pre nego počne operativna upotreba. 34

Treba imati na umu da nove usluge zahtevaju novu podršku, stoga je ponekad potrebno i više

resursa (npr. više osoblja) od trenutno raspoloživih.

4.2.7.5.5 Praćenje ostvarenja nivoa usluga

U SLA ne bi smelo biti uključeno ništa što se ne može učinkovito pratiti u meriti prema

zajednički usuglašenim kriterijumima. Uključivanje stavki koje se ne mogu učinkovito pratiti,

gotovo uvek rezultuje sporovima i gubitkom poverenja u SLM proces. Krajnje posljedice takvih

situacija su veliki troškovi za ispravljanje nesporazuma i negativan uticaj na verodostojnost

organizacije.

Trenutne mogućnosti praćenja treba stalno nadgledati i nadograđivati prema potrebi. Idealno

rešenje je to učiniti pre ili paralelno s izradom SLA. Važno je da praćenje nivoa usluga se

podudara sa korisnikovom percepcijom usluge. To je teško postići jer praćenje samo pojedinih

komponenti (npr. servera) ne znači da će usluga biti dostupna u percepciji korisnika. Percepcija

korisnika je da iako kvar može uticati na više usluga, njih brine samo usluga kojoj trenutno ne

mogu pristupiti. Bez nadzora svih komponenti koje učestvuju u pružanju usluge, prava slika

stanje ne može se dobiti.

Takođe treba edukovati korisnike da prijave incidente odmah, posebno ako su kritični za

pružanje nekih usluga, jer na taj način obaveštavaju davalaca usluga da su dogovoreni nivoi

usluga prekršene.35

Znatan broj organizacija svoj Service Desk povezuju sa sveobuhvatnim Configuration

Management System (CMS) kako bi pratili klijentovu percepciju raspoloživosti. To može

uključivati i specifične promene u načinu prijave incidenta i sučelju preko kojeg se to čini.

Potrebna je i koordinacija sa procesom Availability Management.

Service Desk se takođe može koristi za merenje vremena potrebnog za odgovor i rješenje

prijavljenog incidenta ukoliko se primjene potrebne preinake na sučelju (dopune potrebne za

pohranjivanje izmjerenih podataka).

Bitno je osigurati da su bilo koji ciljevi definisani u SLA, uključeni i u Service Desk alat i da se

prema njima nadgleda eskalacija incidenata. Ukoliko to nije učinjeno na ispravan način, dolazi

do situacije da se prati i nadgleda ostvarenje ciljeva drugačijih od onih koji su usuglašeni u SLA,

te nije moguće utvrditi da li su ciljevi ispunjeni bez dodatne manipulacije i obrade podataka. 36

Izuzetno složeno područje za nadziranje i merenje je vreme odziva (vreme koje protekne između

slanja prijave incidenta i primanja odgovora). Često je vreme odziva vrlo teško pratiti tehnički.


35 OGC, Service Design, The Stationery Office, London, 2007., str.70.

36 Ibid, str.71.


V01.2012 strana 43

U takvim slučajevima nekoliko metoda olakšava situaciju37

:

uključivanje sledeće izjave u SLA: „Usluge pokrivene SLA su dizajnirane za velike brzine

odziva i ne očekuju se značajna kašnjenja. Ukoliko vreme odziva usluge prelazi n sekundi

u n minuta, to treba odmah prijaviti službi za korisnike“

definisati broj incidenata unutar nekog perioda vremena koji se može smatrati

prihvatljivim

definisati posebnu kategoriju za incidente uzrokovane neodgovarajućim vremenom odziva

izrada redovnih izveštaja o situacijama kada je vreme odziva definisano u SLA prekršeno

kako bi problem management mogao ispraviti situaciju

Ovakav pristup prevazilazi tehničke poteškoće praćenja i osigurava da su incidenti prijavljeni na

odgovarajući način i u vreme kad su nastali. Ovo je vrlo važno jer uzrok incidenata prouzročenih

lošim vremenom odziva se često ne može otkriti ukoliko se ne istraži odmah.

U realnim situacijama incidenti prijavljeni uz loše vreme odziva često su problem percepcije

klijenta. Klijenti se naviknu na određenu nivo odziva usluge u određenom vremenskom

razdoblju te se počnu žaliti na sporost usluge čim se vreme odziva uspori iako ciljevi iz SLA nisu

prekršeni. Treba obratiti pozornost da klijenti često misle da je usluga spora i u situacijama kad

nije38

.

4.2.7.5.6 Upoređivanja, merenja i poboljšanja zadovoljstva klijenta

Nekoliko bitnih činilaca se ne može mjeriti i nadzirati klasičnim proceduralnim sredstvima.

Primer je opšte zadovoljstvo klijenta čitavom uslugom. Na primer, čak i kada je došlo do velikog

broja prijavljenih kvarova usluge, klijenti još mogu imati pozitivan stav i biti zadovoljni jer

osjećaju na promenama da su poduzete odgovarajuće radnje da se poboljšaju stvari. Naravno,

situacija može krenuti i u potpuno obratnom smeru, te tako klijenti mogu osjećati nezadovoljstvo

čak i kad ciljevi definisani u SLA nisu prekršeni (neprofesionalan odnos službe za korisnike,

nedostatna komunikacija i sl.).

Od samog početka odnosa, nužno je upravljati očekivanjima klijenta. To znači definisati

odgovarajuća očekivanja i primerene ciljeve. Ukoliko je klijentova percepcija pokrivena

njegovim očekivanjima, klijent će biti zadovoljan.

SLA je samo dokument, te ne može materijalno izmeniti kvalitet usluge koja se pruža ali može

uticati na ponašanje strana i produbiti odnos između klijenta i davalaca usluge te na taj način

ima blagotvoran učinak.

Usluge čije pružanje prouzrokuje troškove trebaju biti uzete u obzir prilikom razmatranja

zahteva klijenata. Klijentima treba omogućiti sve što mogu troškovno opravdati, naravno ukoliko

se to uklapa u korporativnu strategiju i predviđeni budžet. Kod usluga koje nemaju troška treba

osigurati da ne dolazi do preteranih i nerealnih zahteva na teret IT sektora ili bilo kojeg drugog

pojedinca ili grupe.

Sledeće metode mogu se koristiti za merenje zadovoljstva uslugom klijenta39

:

Periodični upitnici i ankete klijenata

37 Ibid, str.71.




V01.2012 strana 44

Povratne informacije od klijenata dobijene na sastancima

Telefonska istraživanja (neplanirana putem službe za korisnike ili planirana putem stalnih

predstavnika)

Poseta klijenata tokom i nakon instalacije

Analiza pritužbi i pohvala

Gdje je to moguće, ciljeve treba definisati prema ovim metodama i pratiti ih prema SLA. Ako

klijenti pružaju informacije potrebno je osigurati da dobe povratne informacije i pokazati im da

su njihovi komentari uvaženi i uključeni u akcijski plan. Sva mjerenja zadovoljstva kupca treba

pregledati, ako su identificirane varijacije, treba ih analizirati i poduzeti radnje da se uklone.

4.2.7.5.7 Pregled i revizija sporazuma i opsega usluga

Davaoci IT usluga su do određene mere zavisni od vlastitih timova za tehničku podršku i

spoljnjih partnera i dobavljača. Oni se ne mogu obvezati na ispunjenje ciljeva definisanih u SLA

ukoliko njihovi vlastiti timovi za podršku i dobavljači ne podržavaju te ciljeve. Osim ugovora sa

spoljnjim partnerima koji su obavezni, mnoge organizacije koriste jednostavne ugovore između

svojih sektora i grupa za podršku. Takvi ugovori zovu se OLA sporazumi. Izraz „podupirajući

sporazumi“ koristi se za sve „unutrašnje“ SLA i OLA podupirajuće sporazume.

Svi ciljevi definisani u takvim sporazumima moraju biti usuglašeni i moraju doprinositi

ostvarenju ciljeva definisanih u SLA ugovorima sklopljenim sa klijentima i poslovnim sistemom.

Može biti nekoliko nivoa tih podupirajućih sporazuma i nužno je su ciljevi svakog nivoa

usklađen i usuglašeni sa ciljevima na višim nivoama.

OLA ugovori ne trebaju biti komplikovani ali trebaju utvrditi specifične zahteve i ciljeve koje

grupa za podršku mora ostvariti, a sve u cilju podupiranja ciljeva definisanih u SLA na najvišom

nivou. Na primer, ako SLA obuhvata ukupno vreme potrebno za reakciju i popravak incidenta,

tada OLA treba sadržavti ciljeve za svaki od elemenata u lancu sistema podrške. Ciljevi za

rešenje incidenata uključeni u SLA ne trebaju odgovarati ciljevima definisanim u OLA jer SLA

ciljevi moraju uključiti elemente za sve faze ciklusa podrške (npr. vreme potrebno za otkrivanje

incidenta, vreme potrebno za zatvaranje incidenta, itd.).

SLA treba obuhvatiti vreme potrebno službi za korisnike da odgovori na upućeni poziv ili

zahtev, vreme potrebno da se zahtev prosledi tehničkoj podršci, vreme potrebno da se istraži i

zatvori incident. Takođe ukupno vreme u kojem je podrška dostupna mora biti dokumentovano,

uključujući izvanredne procedure poput telefonskog kontaktiranja podrške van radnog

vremena.40

Ostvarenje ciljeva iz OLA sporazuma treba nadzirati, a izveštaje o uspehu kao povratnu

informaciju dostaviti menadžerima uključenih timova. To će omogućiti detekciju potencijalnih

problematičnih područja koja se mogu riješiti interno ili daljnjim pregledom SLA i OLA. Timovi

za podršku unutar organizacija, a koji doprinose isporuci čitave IT usluge klijentu trebaju imati

formalni OLA.

Pre nego što se prihvati novi ili izmenjeni SLA sporazum, važno je da se istraže svi postojeći

ugovori na svim nivoama i ukoliko je to potrebno da se nadograde. Nadogradnja najčešće

rezultuje novim troškovima koji moraju biti pokriveni IT budžetom ili se prenesu na klijente.

Ukoliko klijent ne pristaje na to, novi ciljevi se mogu definisati u SLA, a koji neće teretiti

budžet. U ove aktivnosti potrebno je uključiti i dobavljače kako bi se osiguralo su svi procesi

koji učestvuju u isporuci usluge uzeti u obzir.



V01.2012 strana 45

4.2.7.5.8 Izveštaji o uslugama

Odmah nakon što je SLA dogovoren, nadzor sprovođenja SLA mora biti uspostavljen i izvještaj

o ostvarenju ciljeva mora biti dat. Operativni izvještaji moraju biti data često (npr. sedmično) i

gde je to moguće, vanredni izveštaji moraju biti izrađeni za svako kršenje SLA. Ponekad se

javljaju poteškoće u dostizanju ciljeva tokom početne faze života usluge zbog velikog broja

zahteva za promenom (RFC – request for change). Ograničavanje broja zahteva za promenom

tokom rane faze života usluge olakšava uspešno uvođenje usluge u live okruženje. 41

Mehanizam izrade i dostava SLA izveštaja, intervali dostave i format, moraju biti definisani i

dogovoreni zajedno sa klijentima. Učestalost i oblik sastanaka o reviziji usluga takođe moraju

biti usuglašeni, a preporučaju se sastanci u redovnim intervalima propraćeni izveštajima

sinhronizovanimm sa sastancima. Izveštaji trebaju biti dostavljeni nekoliko dana pre sastanka

kako bi se nesuglasice riješile pre redovnog sastanka.

Redovnai izvještaji trebaju uključivati sve relevantne informacije o izvršenju ciljeva definisanih

u SLA, zajedno sa detaljima o trendovima i specifičnim akcijama koje se preduzimaju kako bi se

poboljšao kvalitet usluga. Praktično je koristiti SLM monitoring grafikone koji daju brzi pregled

ostvarenja ciljeva.42

Potrebno je obratiti pažnju na resurse koji su potrebni za izradu i provjeru izveštaja. Proces

izrade i provjere izveštaja zahtijeva puno vremena i ukoliko izveštaji ne odražavaju percepciju

klijenta tačno, situacija će se dodatno pogoršati. Važno je da se prilikom izrade izveštaja koriste

tačne i aktualne informacije iz svih procesa (upravljanje incidentima, upravljanje kapacitetima,

upravljanje raspoloživošću, upravljanje promenama) i područja kvalitetno analizirane i sažete u

sveobuhvatan i jasan izveštaj o uspehu postizanja dogovorenih ciljeva.

Proces upravljanja nivoama usluga treba identificirati specifične potrebe za izveštajima i

automatizirati izradu tih izveštaji u najvećoj mogućoj mjeri. Prilikom odabira alata za podršku,

opseg, točnost i lakoća automatizacije izrade izveštaji su kriteriji koje treba uzeti u obzir. Osim

aktuelnih informacija o trenutnom izvršenju ciljeva, u izveštaje takođe treba uključiti povijesne

podatke i trendove tako da se može mjeriti i predvidjeti utjecaj već poduzetih poboljšanja.

4.2.7.5.9 Pregled i revizija SLA, opsega usluga i podupirajućih sporazuma

Svi sklopljeni sporazumi o podršci, uključujući SLA, OLA moraju se redovno obnavljati.

Periodično se trebaju proveravati, najmanje jednom godišnje, kako bi se osiguralo su stalno

usuglašeni sa poslovnim potrebama i strategijom.

Pregledi moraju osigurati da su usluge pokrivene i da su ciljevi definisani u sporazumima još

uvek aktuelni i da se ništa značajno nije promenilo što bi moglo poništiti sporazum na bilo koji

način (infrastrukturne promene, promene u poslovnom modelu, promene dobavljača, itd.).

Ukoliko je došlo do nekih promjena u okruženju, sporazum mora biti ažuriran kako bi bio

prilagođen novoj situaciji. U preglede takođe treba uključivati i strateške dokumente kako bi se

osiguralo da su sve usluge i sporazumi usuglašeni poslovnom i IT strategijom. 43

4.2.7.5.10 Razvoj kontakata

41 Ibid, str.73.


43 Ibid, str.74.


V01.2012 strana 46

Vrlo je važno da SLM faza razvija međusobno poverenje i poštovanje, između poslovnih

subjekata i davalaca IT usluge. Uz pomoć informacija iz kataloga usluga u SLM fazi može se

razaznati odnos između IT usluga i poslovnih jedinica i procesa koji zavise od tih usluga. Bitno

je definisati sve bitne IT i poslovne kontakt vezane uz IT usluge i poslovne procese, te naznačiti

njihovu ulogu i važnost u čitavom procesu.

4.2.7.5.11 Pritužbe i pohvale

SLM proces treba uključiti aktivnosti i procedure za zapisivanje i upravljanje pritužbama i

pohvalama. Prijave jednih i drugih često se izvode preko korisničke službe. Definicija pritužbe i

pohvale, način prijave te analiza trebaju biti dogovoreni sa klijentima. Sve primljene pritužbe i

pohvale trebaju se evidentirati te dostaviti relevantnim stranama. Sve pritužbe treba riješiti u

najkraćem mogućem roku, na zadovoljstvo autora pritužbe. Ukoliko to nije moguće, treba

definisati procedure za sve pritužbe koje nisu riješene u dogovorenom vremenskom okviru. Svi

izvanredni prigovori trebaju biti analizirani i eskalirani do viših nivoa menadžmenta. Potrebno je

izrađivati izveštaje koji sadrže informacije o broju i vrsti pritužbi, trendovima koji se mogu

primijetiti te akcijama koje su poduzete kako bi se broj pritužbi smanjio. Slične izveštaje treba

definisati i za pohvale. 44

4.2.7.5.12 Okidači SLM aktivnosti

Okidači koji utiču na SLM aktivnosti45

:

Promene u portfelju usluga, novi ili promijenjeni poslovni zahtevi, nove ili promijenjene

usluge

Novi ili izmenjeni sporazumi, SLR, SLA, OLA

Nastanci i reviziji postojećih usluga

Pritužbe i pohvale

Povremene aktivnosti poput revizije, anketiranja i izvještavanja o zadovoljstvu klijenata

Promene u strategiji

4.2.7.5.13

4.2.7.5.14 Ulazi u SLM proces

Mnogo je informacija koje su bitne za SLM proces46

:

Poslovne informacije: iz poslovne strategije organizacije, finansijskih planova i

informacija o trenutnim i budućim potrebama

Analiza uticaja: informacije o uticaja, prioritetu, riziku i broju korisnika povezanih sa

svakom uslugom

Poslovni zahtevi: detalji o usuglašenim, novim ili promenjenim poslovnim zahtevima

Portfelj usluga i katalog servisa

Informacije o promenama, sadašnjim i budućim promenama

Povratne informacije od klijenata – primjedbe i pohvale


45 Ibid, str.75.



V01.2012 strana 47

Savjeti i informacije iz ostalih procesa (upravljanje incidentima, upravljanje kapacitetima,

upravljanje raspoloživošću), postojeći SLA, SLR, OLA, izveštaji o kvaliteti isporučene

usluge

4.2.7.5.15 Izlazi iz SLM procesa

Izlazi SLM procesa trebaju uključivati47

:

Izveštaji o uslugama: detalji o postignutim nivoama usluge u odnosu na ciljeve definirane

u SLA

Plan poboljšanja IT usluga (Service Improvement Plan): sveobuhvatan plan planiranih

mjera u svrhu poboljšanja IT usluga

Predlošci dokumenata: standardni predlošci dokumenata za SLA, SLR, OLA usuglašeni sa

korporativnim standardima

Ugovor o razini usluga (SLA): ciljevi i odgovornosti definisani i dokumentovani za sve

operativne usluge

Service level requirements (SLR): ciljevi i odgovornosti definisani i dokumentovani za

sve nove ili promenjene usluge

Ugovor na operativnoj razini (OLA): ciljevi i odgovornosti definisani i dokumentovani za

sve usluge podrške unutar organizacije

Izveštaji o OLA i podupirajućim ugovorima

Redoviti sastanci o reviziji usluga

4.2.7.5.16 Ključni pokazatelji uspehu

Ključni pokazatelji uspehu (KPI – Key Performance Indicators) i njihova merenja mogu se

koristiti za procenu učinkovitosti SLM procesa u nastojanju poboljšanja usluge. Te mere treba

razviti iz perspektive klijenata, davalaca usluga i poslovnog sistema, a trebaju pokrivati

subjektivna i objektivna merenja koja su definisana u nastavku.48

Objektivni pokazatelji:

Broj ili procenat SLA ciljeva koji su postignuti

Broj i težina incidenata u kojima je prekršen SLA

Broj usluga koje su usuglašene sa trenutnim SLA

Subjektivni pokazatelji:

Poboljšano zadovoljstvo klijenata

SLM proces stvara dobre polazne točke za program unapređenja IT usluga. Gde je utvrđeno da

postoji poteškoća koja utiče na kvalitet usluge, proces upravljanja nivoama usluga mora, u

sqaradnji sa Problem Managementom i upravljanjem kapacitetima podsticati program

unapređenja IT usluga (SIP) da identifikuje i sprovede aktivnosti koje su potrebne da se

preovladaju poteškoće i dostigne željen nivo kvaliteta. Program unapređenja usluga takođe se

može fokusirati na teme poput obuke korisnika, servisa, testiranja sistema i sl.

Korisno je uspostaviti budžet isključivo za sprovođenje inicijativa za poboljšanje kvaliteta

usluga. To omogućava da se aktivnosti sprovode brže i efikasnije.

47 Ibid, str. 75.



V01.2012 strana 48

4.2.7.5.17 Information management

Proces upravljanja dogovorenim nivoama usluga daje ključne informacije o svim operativnim

uslugama, ciljevima koje treba postići i povredama dogovorenih sporazuma. Asistira procesu

upravljanja katalogom servisa i pruža informacije o trendovima zadovoljstva kupaca, uključujući

pritužbe i pohvale. Takođe pruža ključne informacije o ukupnoj kvaliteti IT usluge koja se

isporučuje klijentu i informacije o klijentovim očekivanjima i percepciji kvalitete usluge.49

4.2.7.5.18 Izazovi, kričini činioci uspeha i rizici

Jedan od izazova u procesu upravljanja dogovorenim nivoama usluga je identifikovanje

odgovarajućeg predstavnika klijenata, osobe sa kojom se pregovara. U nekim slučajevima to je

vrlo jasno i jednostavno, međutim u nekim situacijama treba mnogo pažnje posvetiti traženju

osobe koja će preuzeti tu ulogu. Ukoliko se klijenti jave dobrovoljno za preuzimanje te uloge,

treba biti oprezan, jer dobrovoljni predstavnici često iznose vlastito mišljenje, a ne opšti

konsenzus. 50

Idealan pregovarač je osoba koja istinski predstavlja interes i pogled klijenata jer često sarađuje

sa više klijenata i kupaca i na temelju iskustva prepoznaje njihove potrebe.

Ako organizacija nema prethodnog iskustva u procesu upravljanja dogovorenim nivoama usluga,

preporučljivo je početi samo sa nacrtom SLA. Za nacrt treba odabrati pogodnu uslugu i klijenta.

Poželjno je da je klijent motivisan i želi učestvovati u procesu. Takođe, rezultati istraživanja

percepcije i zadovoljstva uslugom mogu pružiti korisne smernice za izradu odgovarajućeg

početnog SLA.

Jedan od problema koji se često susreće je da osoblje na različitim nivoama ima različite ciljeve i

percepcije. Na primer, manager na višoj razini koristi uslugu rietko i više je zainteresovan za

pitanja poput vrednosti za novac koju usluga pruža, dok osoblje na nižim nivoama koje koristi

uslugu svakodnevno je više zainteresovano za pitanja poput vremena odaziva, upotrebljivosti i

pouzdanosti. Važno je da su svi odgovarajući i relevantni zahtevi klijenata, na svim nivoama,

prepoznati i uključeni u SLA. 51

Druga grupa ljudi koja treba biti konsultovana tokom celog procesa su predstavnici davalaca IT

usluga (bilo unutrašnji ili spoljnji dobavljači i partneri). Oni se trebaju složiti da su ciljevi realni

i ostvarivi sa dostupnim resursima. Ako nisu, potrebni su daljnji pregovori dok se ne dođe do

kompromisa prihvatljivog za sve strane.

Kada istorijske informacije nisu dostupne, poželjno je ostaviti nacrt sporazuma kroz određeno

razdoblje sve dok nadzor ne potvrdi da su ciljevi ostvarivi. U nekim slučajevima će biti potrebno

ponovo pregovarati o ciljevima. Kad su ciljevi i vremenski okviri potvrđeni, SLA se može

potpisati.

Kad je inicijalni SLA potpisan i početne poteškoće kad su prevladane, postepeno se počinje

uvoditi SLA za ostale usluge ili klijente. Ako je od samog početka odlučeno da se sledi

višerazinska struktura tada inicijalnim SLA treba pokriti sve razine. 52


50 Ibid, str.77.

51 Ibid, str.77.



V01.2012 strana 49

Na kraju izrade i pregovaračkog procesa, SLA trebaju biti odobreni i potpisani od rukovoditelja

na strani klijenta i korisnika ali i davalaca IT usluge. To obavezuje obje strane da učestvuju u

ostvarenju sporazuma. Općenito govoreći, što su potpisnici sporazuma u svojim organizacijama

na višim pozicijama, to je veća poruka odgovornosti i predanosti izvršenju sporazuma. Nakon što

je SLA potpisan treba iskoristiti publicitet i osigurati da klijenti i IT osoblje podjednako postanu

svjesni postojana sporazuma i dogovorenih ciljeva.

Potrebno je preduzeti mere kako bi se upoznala služba za korisnike i ostale grupe za podršku, sa

postojanjem novih SLA i OLA i detaljima kada postaju važeći. Ključne ciljeve iz SLA treba

izdvojiti i prikazati na različitim mestima kako osoblje uvek bilo svjesno koje ciljeve treba

ostvariti i kojim performansama treba težiti. Ako alati za podršku koji se koriste to omogućavaju,

te ciljeve treba uključiti u alate tako da njihov sadržaj bude poznat svim osobama koje te alate

koriste. Sa sadržajem ugovora takođe treba upoznati i klijente, tako da su i korisnici svjesni što

mogu očekivati od usluga koje koriste i kada imaju opravdane razloge iskazati nezadovoljstvo.53

Važno je da je osoblje u grupi za korisničku podršku predano procesu upravljanja nivoama

usluga i da proaktivno sudjeluje u procesu te prihvati kulturu pružanja usluge, jer ono je prva

točka kontakta za sve pritužbe i upite klijenata. Ako korisnička podrška nije potpuno upoznata sa

SLA i ne djeluje u skladu sa sadržajem SLA, klijenti brzo gube vjeru u SLA.

53 Ibid, str.78.


V01.2012 strana 50

4.2.8 Upravljanje kapacitetima (Capacity Management)

Proces upravljanja kapacitetima (Capacity Management) analizira IT infrastrukturu (sadašnja i

buduća primjena u skladu sa sadašnjim i budućim potrebama poslovanja) te prema tome planira

relevantne IT resurse – cilj je ostvarenje dogovorene razine usluga. U osiguravanju potrebnih

kapaciteta proces upravljanja kapacitetima održava balans između troškova i vremena. Pravilna

implementacija procesa upravljanja kapacitetima sprječava nepotrebna ulaganja i ad hoc

promene kad je u pitanju osiguranje kapaciteta za realizaciju servisa. 54

Glavna svrha upravljana kapacitetima je izbegavanje nepotrebnih troškova. Efikasno upravljanje

kapacitetima pomaže organizaciji da iskoristi postojeće IT resurse u najvećoj mogućoj mjeri i

nove resurse pribavlja u optimalnim količinama.55

Proces upravljanja kapacitetima je tesno povezan sa procesima poslovne i IT strategije jer u tim

procesima se analiziraju poslovni zahtevi.

4.2.8.1 Aktivnosti procesa upravljanja kapacitetima

Proces upravljanja kapacitetom na globalnom nivou obuhvata tri potprocesa56

:

1. Upravljanje poslovnim kapacitetima (Business Capacity Management) – cilj ove analize je

razumeti sadašnje i buduće potrebe poslovanja. Klijenti (organizacija) koji traže IT usluge

od IT organizacije (sektora) ove informacije prezentiraju kroz strateške planove,

marketinške planove, analize trendova i dr.

2. Upravljanje servisnim kapacitetima (Service Capacity Management) – cilj ove analize je

definisati potrebne IT servise koje IT organizacija mora osigurati. Ovaj potproces je usko

povezan s procesom upravljanja dogovorenim nivoama usluga (Service Level

Management) jer se radi o izradi dokumentacije vezane uz dogovorene razine usluga

(SLA). U dokumentaciji je bitno definisati indikatore koji omogućavaju merenje ostvarenja

određene razine usluga (Service Level Performance Indicators) i to iz aspekta klijenta.

3. Upravljanje resursnim kapacitetima (Resource Capacity Management) – cilj ove analize je

utvrditi primjenu IT infrastrukture u svrhu ostvarenja dogovorenih servisa. Proces nadzire i

analizira iskorištenje komponenata infrastrukture i planiranih kapaciteta, a u svrhu

poboljšanja i uvođenja novih kapaciteta.

Planiranje kapaciteta je efikasnije ukoliko je povezano s strateškim procesima poslovnog i IT

planiranja. Prilikom planiranja kapaciteta, menadžerska izveštaji sadrže važne informacije koje

su potrebne prilikom procesa planiranja ali i praćenja iskoristivosti kapaciteta, potrebne analize s

obzirom na tekuće i buduće potrebe poslovanja, potrebnu optimizaciju te implementaciju

poboljšanja [Kozina, 2007, str. 11].


55 Klosterboer L., ITIL Capacity Management, IBM Press, Boston, 2011., str. 6



V01.2012 strana 51

Slika 12 Proces upravljanja kapacitetima [OGC, Service Design, 2007, str. 82]

Kritični faktori uspeha za proces upravljanja kapacitetima57

:

razumevanje IT strategije i potreba poslovanja

adekvatno predviđanje poslovnih potreba i specifikacija zahteva za kapacitetima

znanja o sadašnjim i budućim tehnologijama

suradnja s drugim procesima

optimizacija troškova u skladu s potrebnim kapacitetima

Ključni indikatori performansi (KPI) za proces upravljanja kapacitetima58

:

adekvatnost planiranja kapaciteta u skladu s potrebama poslovanja uključujući mogućnosti

promjena u potražnji za IT servisima

tehnološki indikatori za nadzor komponenata IT infrastrukture fokusirano na praćenje

ostvarenja dogovorenih nivoa servisa

smanjenje troškova u pogledu nepotrebnih ili skupih resursa (kapaciteta) te izrada

investicijskog plana u najranijoj fazi

operativni indikatori vezano za smanjivanje broja incidenata s obzirom na dostupnost

adekvatnih kapaciteta, kontinuirano uvažavanje potreba kupaca (korisnika) u pogledu

osiguranja IT servisa


58 Ibid, str. 20.


V01.2012 strana 52

4.2.9 Upravljanje raspoloživošću (Availability Management)

Upravljanje raspoloživošću osigurava da se klijentu isporuči ugovorena nivoa raspoloživosti IT

usluge. Merenje i nadgledanje raspoloživosti IT usluga je ključna aktivnost u tom procesu. Taj

proces mora kontinuirano optimizirati i preaktivno unaprjeđivati dostupnost IT infrastrukture,

usluga i podrške organizaciji.

Slika 13 Odnos između nivoa raspoloživosti i ukupnih troškova [OGC, The Official Intorduction

to the ITIL Service Lifecycle, 2007, str. 62]

Proces upravljanja raspoloživošću se sastoji od dva ključna elementa59

:

1. Reaktivne aktivnosti – uključuju nadzor, merenje, analizu i upravljanje događajima,

incidentima i problemima koji uzrokuju neraspoloživost usluge

2. Proaktivne aktivnosti – uključuju proaktivno planiranje, dizajn, preporuke i poboljšanje

raspoloživosti

Aktivnosti ovog procesa trebaju uzeti u obzir raspoloživost, pouzdanost, mogućnost održavanja i

korisnost kako na razini usluge, tako i na razini komponenti. Isto tako je važno realizirati sva

potrebna mjerenja i informiranje poslovanja o razini pružene usluge [Kozina, 2007, str. 11].

Upravljanje raspoloživošću se promatra na dvije razine60

:

1. Dostupnost servisa – uključuje sve aspekte raspoloživosti i neraspoloživosti čitavog

sistema i utjecaj neraspoloživosti komponenti na čitav sistem

2. Dostupnost komponenti – uključuje sve aspekte raspoloživosti i neraspoloživosti

komponenti



2007., str. 61.


V01.2012 strana 53

Slika 14 Proces upravljanja raspoloživošću [OGC, The Official Intorduction to the ITIL Service

Lifecycle, 2007, str. 62]

4.2.10 Upravljanje kontinuitetom IT usluga (melita) (IT Service Continuity Management)

Proces upravljanja kontinuitetom IT usluga je deo cjelokupnog procesa upravljanja

kontinuitetom poslovanja (Business Continuity Management (BCM)) i ovisan je o

informacijama iz BCM procesa. Primarni cilj procesa upravljanje kontinuitetom IT usluga je

podržati cjelokupni kontinuitet poslovanja – u slučaju nepogode u optimalnom vremenu vratiti

IT infrastrukturu i IT usluge u normalno stanje. Nepogodama se smatraju događaji koji dovode

do prekida poslovanja i zahtevaju velike napore za povratak poslovanja u normalno stanje.

Primeri nepogoda su: požar, poplava, potres, krađa, računalni kriminal, itd. 61

Zbog ovisnosti poslovanja o IT-u, izuzetno je važno razviti planove za osiguranje kontinuiteta

poslovanja.

Proces upravljanja kontinuitetom poslovanja uključuje procene rizika za poslovanje i cjelokupno

upravljanje kontinuitetom poslovanja. Fokus mu je na razvoju planova za oporavak poslovanja

ali i na mjerama koje se mogu poduzeti kako bi se potencijalni rizik smanjio na najmanju

moguću mjeru ili pak potpuno eliminirao. Upravljanje kontinuitetom IT usluga u skladu sa

procesom upravljanja kontinuitetom poslovanja nastoji vratiti IT usluge u normalno stanje te

prepoznati i eliminirati rizike koji prijete IT sistemu.



V01.2012 strana 54

Glavne aktivnosti upravljanja kontinuitetom IT usluga su62

:

Procena rizika i posledica prekida IT usluga za poslovanja

Identifikacija usluga bitnih za poslovanje za koje se traže dodatne preventivne mjere

Razvoj, testiranje i održavanje planova za povratak usluga u normalno stanje nakon

nepogode u definiranom periodu

Definisanje optimalnog pristupa za oporavak servisa

Definisanje perioda u kojem se može ostvariti oporavak IT servisa

Primjena mjera za sprečavanje i smanjivanje nepogoda

Upravljanje kontinuitetom realizuje se u četiri stadijuma63

:

1. Inicijacija – definisanje opsega i uslova, planiranje projekta i alokacija resursa

2. Zahtevi i strategija – analiza uticaja na poslovanje, procena rizika

3. Sprovođenje – izvršavanje mera za smanjenje rizika, testiranje planova

4. Stalna aktivnost – edukacija i podizanje svesti o upravljanju kontinuitetom, stalno

testiranje

Slika 15 Ciklus upravljanja kontinuitetom [OGC, The Official Intorduction to the ITIL Service


4.2.11 Upravljanje informacionom sigurnošću (Information Security Management)

Upravljanje informacionom sigurnošću treba posmatrati kroz celo poslovanje firme. U

kontekstu upravljanja IT uslugama svrha ovog procesa je uskladiti IT sigurnost sa sigurnošću

62 Ibid, str. 21.


2007., str. 66.


V01.2012 strana 55

celog poslovanja te osigurati da se sa sigurnošću informacija efikasno upravlja u svim

aktivnostima usluga na sledeći način64

:

Informacije su raspoložive i iskoristive kad je to potrebno (raspoloživost)

Informacije su dostupne onima koji na to imaju pravo (povjerljivost)

Informacija je kompletna, tačna i zaštićena od neautorizovanih promena (nepovredivost)

Razmjeni informacija i poslovnim transakcijama se može vjerovati (izvornost i

neporecivost)

Čitav proces upravljanja informacionom sigurnošću treba biti poduprijet generalnom

sigurnosnom politikom koja mora sadržavati i potporne sigurnosne politike (politika kontrole

pristupa, politika kontroliranja zaporki, politika klasifikacije informacija, itd.).

Slika 16 Ciklus upravljanja raspoloživošću [OGC, The Official Intorduction to the ITIL Service


Sljedeće perspektive se uzimaju u obzir kada se nastoji ostvariti uravnotežen pristup sigurnosti

informacija65

:

Organizaciona

Proceduralna

Fizička

Tehnička


65 The Art of Service, Exam Prep Study Guide: ITIL v3 Foundation, Brisbane, Australia , str. 31.


V01.2012 strana 56

Sigurnosne mere koje se koriste mogu se klasificirati u sljedeće skupine66

:

Prevencija

Detekcija

Korekcija

Evaluacija

4.2.12 Upravljanje dobavljačima (Supplier management)

Proces upravljanja dobavljačima osigurava da dobavljači i usluge koje oni osiguravaju na

zadovoljavajući način podupiru IT i poslovna očekivanja. Bitno je da proces upravljanja

dobavljačima uključen u sve faze životnog ciklusa, posebice ako usluge koje pružaju dobavljači

su integralni dio potreban za funkcioniranje čitavog sistema.

Glavni ciljevi procesa upravljanje dobavljačima su67

:

osigurati da ugovori i sporazumi sklopljeni sa dobavljačima su usklađeni sa poslovnim

potrebama, te da podrška pružena od strane dobavljača je u skladu ugovorenim

sporazumima

održavati i upravljati odnos sa dobavljačima

voditi računa o učinku dobavljača

pregovarati sa dobavljačima o uvjetima ugovora

Snažni i pouzdan odnos sa dobavljačima sastavni je element uspješnog upravljanja uslugama.

Sa spoljnji m dobavljačima može se sklopiti nekoliko različitih aranžmana68

:

1. Outsourcing – korišćenje jednog ili više dovaljača za upravljanje ili pomoć u upravljanju

IT uslugama

2. Partnerstvo ili multisourcing – formalni sporazum između dve ili više organizacija o

zajedničkom radu, dizajniranju, održavanju, podršci na IT usluzi ili više usluga. Fokus je

na strateškom partnerstvu kako bi se lakše ostvarile strateške prednosti i iskoristile prilike

na tržištu.

3. Outsourcing poslovnog procesa – formalni sporazum u kojem spoljna organizacija izvršava

i kontroliše kompletan poslovni proces. Česti primeri su računovodstvo, obračun plata,

pozivni centar i sl.

4. Pružanje usluge aplikacije – spoljne organizacije preko računalne mreže pružaju usluge

baziranje na vlastitim računarskim resursima. Složenost i troškovi takve usluge mogu biti

smanjeni i omogućuju manjim organizacijama pristup do takvih usluga uz manje

investicije.

66 Ibid, str.31.


2007., str. 66.

68 The Art of Service, Exam Prep Study Guide: ITIL v3 Foundation, Brisbane, Australia , str. 23.


V01.2012 strana 57

5 Menadžment sigurnošću informacija

Menadžment sigurnošću informacija zahteva da IT definiše, prati i kontroliše sigurnost

korporativnih informacija i usluga. U posebnoj knjizi (jednoj od sedam knjiga) ITL analizira

svaki od Service Delivery i Service Support procesa sa stanovišta sigurnosti informacija. I ITIL i

ISO 20000-1 eksplicitno se pozivaju na standard ISO/IEC 17799:2005, koji sadrži specifikaciju

najbolje prakse u zaštiti informacija. Organizacija je obavezna da uspostavi kompletnu

infrastrukturu kojom obezbeđuje sigurnost informacija sa osnovnom napomenom da je to

prvenstveno proces upravljanja koji započinje uspostavljanjem i objavljivanjem politika

sigurnosti informacija i izjave o primenjivosti. Naime, organizacija ovom izjavom iskazuje svoje

namere da implementira mere zaštite svojih informacija u određenim segmentima poslovanja.

Ovaj proces je integralni deo šireg korporativnog plana sigurnosti, koji pored mera preduzetih na

IT planu obuhvata organizacione i fizičke mere sigurnosti. Sve IT usluge se moraju pridržavati

striktnih korporativnih standarda o sigurnosti informacija u kojima su definisani zahtevi za

raspoloživost, integritet i poverljivost informacija sadržanih/procesiranih u IT infrastrukturi

organizacije.

Sledeće aktivnosti su deo menadžmenta sigurnošću:

definisanje korporativne politike sigurnosti, što obuhvata i politike sigurnosti koje se

odnose na IT;

promovisanje svesnosti o sigurnosti unutar IT-a;

sprovođenje analize o nedostatcima u pogledu sigurnosti;

identifikacija mogućih pretnji po sigurnost informacija;

sprovođenje procene rizika po sigurnost informacija;

procena uticaja incidenata sigurnosti informacija na poslovanje;

odabir i implementacija kontrola kojima će se zadovoljiti zahtevi organizacije za sigurnost

informacija;

sprovođenje provera (audit) sigurnosti informacija.

BS 15000-1:2003 (zamenjen sa ISO 20000-1:2005) zahteva da organizacija mora uspostaviti

sistem upravljanja sigurnošću informacija saglasan sa zahtevima standarda BS 7799-2 (zamenjen

sa ISO 27001:2005).

Ključni proces u uspostavljanju i funcionisanju sistema upravljanja sigurnošću informacija je

upravljanje rizikom. Od raspoloživih, opšte prihvaćenih, referenci treba pomenuti sledeće:

AN/NZS 4360:2004 – Risk Management i pripadajuće uputstvo za primenu HG 436:2004,

ISO/IEC Guide 73 – Risk Management – Vocabulary, ISO/IEC 16085 – Software Engineering –

Software Live Cycle Processes – Risk Management. Kada je sigurnost informacija u pitanju

korisnici standarda će se najverovatnije osloniti na standard BS 7799-3:2006, Information

security management systems - Part 3: Guidelines for information security risk management. U

ISO planu je predviđeno da se i ovaj standard po ubrzanoj proceduri prihvati i uvrsti u seriju

ISO/IEC 27000.

5.1 Koristi od ITIL-a za korisnike

Neke od koristi od ITIL-a su: [1]

pružanje IT usluga postaje sve više usmerena na korisnika; uzajamno dogovaranje i

razumevanje kvaliteta usluga dovodi na kraju do unapređenja odnosa sa korisnikom.


V01.2012 strana 58

usluge su tako opisane da pružaju najvažnije detalje i date su na jeziku koji korisnik

razume.

poboljšanje kvaliteta usluga i upravljanje troškovima.

komunikacija sa IT organizacijom je poboljšana tako što se unapred dogovaraju mesta

kontakta.

ITIL osnove predstavljaju skup minimalnih zahteva koje organizacija mora da usvoji radi

efikasnog upravljanje IT uslugama.

Slika 6 - Razvoj ITMS standarda kroz vreme


V01.2012 strana 59

6 BS15000

6.1 Istorija

Organizacije širom sveta koje su primenile procese „najbolje prakse“ ITIL-a, kao de facto

referencu u upravljanju IT uslugama, nisu bile u mogućnosti da prikažu svoju uspešnost u ovim

okosnicama, pošto je formalno nedostajao dokumentovani standard. Britanska institucija za

standarde (British Standards Institutuion (BSI)) je zvanično utvrdila potrebe za efikasnu isporuku

usluga za isporučioce i njihove korisnike, u britanskom standardu: BS15000. Mada BS15000 ne

uključuje formalno ITIL pristup, on opisuje skup upravljačkih procesa koji su povezani i

komplementarni sa procesnim pristupom definisanim u ITIL-u.

Prvo izdanje BS15000 je objavljeno u novembru 2000, i zasniva se na ranije objavljenom –

DISC PD005:1998 – Kod prakse za upravljanje IT uslugama. Kasnije izdanje BS15000-1:2002

je drugo izdanje, koje je bilo rezultat iskustava i povratnih informacija od onih koji su primenili

prvo izdanje. Zatim je formalna specifikacija (BS15000-1) proširena sa Kodovima prakse

(BS15000-2), koji opisuju „najbolju praksu“ u više detalja, i daju uputstvo i preporuke. Ovi

Kodovi prakse nisu deo zahteva.

6.2 Svrha standarda BS15000

BS 15000 je prvi svetski standard o menadžmentu IT uslugama i ujedno jedina referenca u

odnosu na koju se može izvršiti provera usaglašenosti u oblasti upravljanja IT uslugama.

Standard specificira set međusobno povezanih procesa kojima se obezbeđuje menadžment IT

uslugama. Svaki od procesa definisan je svojim ciljem i specifikacijom aktivnosti – šta

organizacija mora uraditi da postigne definisani cilj.

BS 15000 (2nd edition) sastoji se od dva dela

BS15000-2 sa podnaslovom: kodovi prakse

menadžmenta uslugama ima isti sadržaj kao i

deo 1 standarda. Za svaki zahtev pored cilja

koji se mora postići, date su detaljnije

preporuke šta organizacija može/treba uraditi

da realizuje specificirani cilj. Poznavaoci ove

oblasti prepoznat će mnoge od procesa i

aktivnosti koje su realizovali tokom godina

poslovanja, ali i identifikovati mnoge

aktivnosti koje su takođe godinama izbegavali

da implementiraju, odlažući „to“ za neka bolja

vremena. Stoga, ovaj drugi deo standarda

obezbeđuje isporučiocima IT usluga

konzistentan pristup u uspostavljanju sistema

upravljanja uslugama ili se pripremaju za

proveru usaglašenosti sa zahtjevima BS

15000-1 ili planiraju poboljšavanja svog

sistema upravljanja uslugama. Oba dela

standarda, kao i drugi standardi o sistemima

upravljanja, ograničeni su na „šta se mora

uraditi?“, dok se odgovori na pitanja „kako?“

mogu potražiti u ITIL i mnogim publikacijama

na temu IT usluga.

BS 15000-1 sastoji se od deset sekcija:

1. Predmet i područje primene,

2. Termini i definicije,

3. Zahtjevi za upravljanje sistemom,

4. Planiranje i implementacija

upravljanja uslugama,

5. Planiranje i implementacija

novim ili izmijenjenim uslugama,

6. Proces isporuke usluga,

7. Veze između procesa,

8. Procesi rešavanja problema,

9. Kontrolni procesi i

10. Procesi puštanja usluge.

Koordinirana integracija i

implementacija procesa upravljanja

uslugama osigurava stalnu kontrolu, veću

efikasnost i prilike za poboljšavanja.


V01.2012 strana 60

7 ISO/IEC 20000

(Međunarodni standard za upravljanje IT uslugama)

Slika 7 – ISO/IEC 20000

ISO (Međunarodna organizacija za standardizaciju) i IEC (Međunarodna elektrotehnička

komisija) zajedno formiraju sistem za opštepriznatu standardizaciju kao celinu. Nacionalne

institucije, koje su članice ISO i IEC, učestvuju u razvoju međunarodnih standarda kroz rad u

tehničkim komitetima koje je ustanovila odgovarajuća organizacija radi obrade posebnih oblasti

tehničkih aktivnosti. Tehnički komiteti ISO i IEC sarađuju u poljima od obostranog interesa.

Međunarodne organizacije, vladine i nevladine, koje su u vezi sa ISO i IEC, takođe učestvuju u

tom radu.

U području informacione tehnologije ISO i IEC su ustanovili združeni tehnički komitet, ISO/IEC

JTC 1. Nacrti međunarodnih standarda koje je usvojio združeni tehnički komitet šalju se svim

nacionalnim telima na saglasnost pre njihovog usvajanja kao međunarodnih standarda. Standardi

se usvajaju prema postupku po kome standard mora da usvoji najmanje 75 % članica.

ISO/IEC 20000 je standard za upravljanje IT uslugama Ovaj standard se odnosi na BS 15000.

Kombinuje sve aspekte upravljanja IT uslugama koji su validni u svim IT organizacijama.

Slika 8 - Logotip standarda

Standard ISO/IEC 20000 odnosi se na standard BS 15000 i predstavlja njegovog naslednika. BS

15000 je prvi svetski standard o upravljanju IT uslugama. Standard određuje skup međusobno

povezanih menadžment procesa i zasnovan je na ključnoj referenci ITIL (IT Infrastructure

Library). BS 15000 je transformisan po ubrzanoj proceduri u ISO/IEC 20000 i objavljen

15.12.2005. god.

7.1 ISO/IEC 20000-1

7.1.1 Sadržaj ISO/IEC 20000 -1

Standard ISO/IEC 20000 -1 sastoji se od deset sekcija:

Best Practice

Applied Framework

Organizational Policies, Practices and Procedures

ISO/IEC/IEC 20000

ITIL

Primenjen okvir

Organizacione politike,

iskustva i procedure


V01.2012 strana 61



3. Zahtevi za upravljanje sistemom,

4. Planiranje i implementacija upravljanja uslugama,

5. Planiranje i implementacija novim ili izmijenjenim uslugama,




9. Kontrolni procesi, i

10. Procesi puštanja usluge

1. Predmet i područje primene

Ova specifikacija opisuje zahteve koje mora da zadovolji jedna organizacija da bi isporučila

svoje IT usluge sa prihvatljivim kvalitetom za svoje korisnike. Može biti korišćena u poslovima

koji obuhvataju raspisivanje tendera za svoje usluge, u poslovima koji zahtevaju konzistentan

pristup za sve pružaoce usluga u lancu snabdevanja, od strane isporučioca usluga za benchmark

upravljanja IT uslugama, kao baza za nezavisnu procenu (assessment) od strane organizacije

koja mora da demonstrira mogućost pružanja usluga koje će zadovoljiti zahteve korisnika, i od

strane organizacije koja teži da poboljša usluge kroz efektivnu upotrebu procesa u praćenju i

poboljšanju kvaliteta usluga.

Ovaj standard specificira broj blisko povezanih procesa u upravljanju uslugama, kao što je

prikazano na slici.

2. Termini i definicije

U ovom delu su dati termini i definicije pojednih pojmova usko vezanih za pružanje IT usluga

kao što su: raspoloživost, osnova, izveštaj o promenama, konfiguraciona lista, baza podataka za

upravljanje konfiguracijom, dokument, incident, problem, izveštaj, izdanja, zahtev za

promenom, servis desk (centar za usluge), sporazum o nivou IT usluga, upravljanje uslugama i

pružalac usluga.

3. Zahtevi za upravljanje sistemom

Obezbeđivanje upravljanje sistemom, uključujući politiku i uređenje, radi omogućavanja

efektivnog upravljanja i implementacije svih IT usluga.

3.1 Odgovornost menadžmenta

Kroz vođstvo i akcije, vrhovni/izvršni menadžment treba da uspostavi politiku, ciljeve i planove

upravljanja uslugama; prenosi važnost zadovoljavanja ciljeva upravljanja uslugama i potrebe za

kontinuiranim pobiljšanjima; obezbeđuje da su zahtevi korisnika određeni i zadovoljeni sa ciljem

poboljšanja satisfakcije korisnika; propiše član o odgovornosti upravljanja za koordinaciju i

upravljanje svim uslugama; odredi i obezbedi resurse za planiranje, implementaciju, nadzor,

pregled i poboljšanje upravljanja i isporuke usluge, t.j. zaposli odgovarajuće zaposlene, upravlja

promenom zaposlenih; upravlja rizicima u upravljanju uslugama organizacije i servisa, i prati

preglede upravljanja uslugama, u planiranim intervalima, da bi osigurao kontinuiranu

prikladnost, adekvatnost i efektivnost.


V01.2012 strana 62

Zahtevi dokumentacije

Pružaoci usluge moraju da obezbede dokumente i zapise da bi osigurali efektivno planiranje,

izvršenje i kontrolu upravljanja uslugama. Ovo uključuje dokumentovanu politiku i planove

upravljanja uslugama; dokumentovan sporazum o pružanju IT usluga; dokumentovane procese i

procedure koji se zahtevaju po standardu; i zapise koji se zahtevaju po standardu.

Procedure i odgovornosti moraju biti ustanovljene za stvaranje, pregled, odobravanje,

održavanje, raspored i kontrolu različitih tipova dokumenata i zapisa (dokumentacija može biti u

bilo kojoj formi ili na tipu medijuma).

1. Sposobnost, svesnost i trening

Sva pravila upravljanja uslugama i odgovornosti moraju biti definisana i podržavana zajedno sa

sposobnošću koja zahteva efikasno izvršenje. Sposobnosti zaposlenih i potrebe obuke moraju biti

razmatrani i upravljani tako da omoguće da zaposleni efikasno odrade svoju ulogu. Vrhovni

menadžment mora da obezbedi da njihovi zaposleni budu svesni bitnosti i važnosti svojih

aktinosti i koliko oni doprinose izvršenju ciljeva upravljanja uslugama.

2. Planiranje i implementacija upravljanja uslugama

Metodologija poznata kao „Plan-Do-Check-Act“ (PDCA) može biti primenjena na sve procese.

PDCA može biti objašnjeno na sledeći način:

Plan (planiranje): uspostaviti ciljeve i procese koji su neophodni da bi se došlo do rezultata u

podudardnosti sa zahtevima korisnika i politikom organizacije

Do (primena): implementacija procesa

Check (provera): praćenje i merenje procesa i usluga u odnosu na politike, ciljeve i zahteve i

izveštaji o rezultatima

Act (delovanje): preduzimanje akcija radi kontinuiranog poboljšanja izvršavanja procesa.

Slika 9 P-D-C-A Cyrcle - Demingov krug

3. Planiranje i implementacija novih ili izmijenjenih usluga

Cilj je da nove ili izmenjene usluge budu isporučene po pravoj ceni i kvalitetu.


V01.2012 strana 63

Ponuda novih ili izmenjenih usluga treba da uzme u obzir troškove, organizacione, tehničke i

komercijalne uticaje koji mogu biti rezultat upravljanja i isporuke uslugama.

Nove ili izmenjene usluge moraju biti prihvaćene od strane pružaoca usluge pre implementacije

u okruženje. Pružaoci usluge treba da izveštavaju o izlazima koje dobijaju pri implementaciji

novih ili izmenjenih usluga u odnosu na planirane radi poređenja. Upoređivanje pravih izlaza u

odnosu na planiranje, treba da bude u okviru procesa upravljanja promenama.

4. Proces isporuke usluga

4.1 Service Level Management (Upravljanje nivoom usluge)

Cilj je definisanje, usaglašavanje, izveštavanje i upravljanje nivoom usluge.

Svaka pružena usluga mora biti definisana, usaglašena i dokumentovana u jednom ili više

sporazuma o nivou IT usluga (Service Level Agreements – SLAs). SLAs treba da bude pod

kontrolom procesa upravljanja promenama (Change Management).

4.2 Service reporting (Izveštavanje o uslugama)

Cilj je pravljenje usaglašenih, blagovremenih, pouzdanih, tačnih izveštaja radi donošenja odluka

i efektivne komunikacije. Izveštaji o usluzi moraju biti napravljeni da zadovoljavaju utvrđene

potrebe i zahteve korisnika. Odluke menadžmenta i korektivne akcije moraju biti uzete u obzir

na osnovu izveštaja o uslugama i moraju se odnositi na određene delove.

4.3 Upravljanje kontinuitetom i raspoloživošću usluga

Cilj je da osigura usaglašavanje kontinuiteta i raspoloživosti usluga za korisnika u svim

slučajevima. Zahtevi kontinuiteta i raspoloživosti usluga moraju biti određeni na osnovu

poslovnih planova, SLAs i procene rizika. Zatevi moraju da obuhvataju prava pristupa i vreme

odgovora, isto kao i krajnju raspoloživost komponenti sistema.

Planovi kontinuiteta i raspoloživosti usluga moraju biti ponovo testirani pri svakoj većoj promeni

u poslovnom okruženju. Proces upravljanja promenama mora proceniti uticaj svake promene na

plan kontinuiteta i raspoloživosti usluga.

Raspoloživost mora biti merena i zabeležena. Neplanirana raspoloživost mora biti istražena i

moraju se preduzeti određene akcije. Tamo gde je moguće, potencijalni ishodi bi se morali

predvideti i sprečiti preduzimanjem akcije.

Plan kontinuiteta usluga se mora testirati u zavisnosti od postojećih potreba. Svi testovi

kontinuiteta moraju biti zabeleženi i neuspeli testovi moraju biti formulisani u planove akcija.

4.4 Budžet i račun za IT usluge

Cilj je u obračunavanju troškova pružanja usluge. Troškovi bi trebalo da budu obračunavani sa

zadovoljavajućim detaljima koji omogućavaju efektivnu finansijsku kontrolu i donošenje odluka.

Pružaoc usluge mora da prati i izveštava o troškovima, u odnosu na budžet. Promene u uslugama

moraju biti obračunate i dokazane kroz procese upravljanja promenama.

4.5 Upravljanje kapacitetom

Cilj je osiguravanje da pružaoc usluge ima, sve vreme, zadaovoljavajući kapacitet za sadašnje i

buduće zahteve poslovnih potreba korisnika.

Uz upravljanje kapacitetom treba da se izradi i održava plan kapaciteta. Upravljanje kapacitetom

treba da odražava potrebe i uključuje: sadašnji i predviđeni kapacitet i dostizanje zahteva,


V01.2012 strana 64

indentifikovane vremenske skale, ulaze i troškove za unapređenje usluga, razvoj efekata

predviđenih unapređenja usluga, zahteva za promenama, novim tehnologijama i tehnikom,

predviđanje uticaja spoljašnjih promena, podaci i procesi koji omogućavaju analize za

predviđanje.

4.6 Upravljanje bezbednošću informacija

Cilj je u efikasnom upravljanju bezbednošću infomracija u svim aktivnostima usluga.

ISO/IEC17799:2005 obezbeđuje vodič za upravljanje bezbednošću informacijama. Menadžment

sa odgovarajućim autoritetom treba da dozvoli politiku bezbednosti informacija koje će

komunicirati sa svim relavantnim osobama i korisnicima gde je potrebno. Odgovarajuće kontrole

bezbednosti moraju da razrade implementaciju zahteva politike bezbednosti informacija,

upravljanje rizicima povezanim sa pristupom usluzi ili sistemima.

Kontrole bezbednosti moraju biti dokumentovane.

Incidenti u bezbednosti moraju biti izveštavani i zabeleženi u proceduri upravljanja incidentima

što je pre moguće. Procedure moraju biti postavljene tako da osiguravaju da svi incidenti u

bezbednosti budu istraženi i da budu preduzete upravljačke akcije.

5. Veze između procesa

5.1 Upravljanje poslovnim procesima

Cilj je u uspostavljanju i održavanju dobrih odnosa između pružaoca usluga i korisnika

zasnovanih na razumevanju korisnika i njihovih poslovnih zahteva.

Pružaoci usluga moraju da indentifikuju i dokumentuju korisnike usluga. Pružaoci usluga i

korisnici moraju barem jedanput godišnje prisustvovati ispitivanju usluga radu duskusije o bilo

kojim promenama u predmetu i području primene usluga, SLA, ugovorima (ako postoje) ili

poslovnim potrebama, i moraju držati interne sastanke u dogovorenim intervalima radi diskusije

o ispitivanju, izvršenju i ishodu planova. Ovi sastanci moraju biti dokumentovani. Drugi učesnici

u uslugama mogu takođe biti pozvani na sastanke. Promene u ugovorima, ako postoje, i SLAs

moraju biti praćene kako treba kroz ove sastanke. Ove promene će biti predmet za proces

upravljanja promenama. Pružaoci usluga moraju biti svesni poslovnih potreba i bitnih promena u

cilju pripreme odgovora na ove potrebe.

5.2 Upravljanje dobavljačima

Cilj je u upravljanju dobavljačima radi osiguravanja pružanja kvalitetne usluge.

Predmet ovog standarda isključuje obezbeđivanje dobavljača.

Pružaoci usluga moraju imati dokumentovane procese upravljanja dobavljačima i moraju

imenovati menedžera ugovora koji je odgovoran za svakog dobavljača.

Zahtevi, predmeti, nivo usluge i procesi komunikacije obezbeđeni od strane dobavljača moraju

biti dokumentovani u SLAs ili drugim dokumentima i usaglašeni od strane svih učesnika. SLAs

sa dobavljačima moraju biti izjednačeni sa SLAs sa poslovima.

Ulazi između procesa korišćeni od strane svakog učesnika moraju biti dokumentovani i

usaglašeni.

Sva pravila i veze između vodećih i podugovorenih dobavljača moraju biti jasno dokumentovani.

Vodeći dobavljači moraju biti sposobni da demonstriraju procese da bi osigurali da

podugovoreni dobavljači ispune zahteve.


V01.2012 strana 65

Proces mora biti bar jednom godišnje stavljen na dnevni red formalanih dogovora, da bi se

osiguralo da poslovne potrebe i ugovorene obaveze i dalje budu zadovoljene.

6. Odlučujući procesi

6.1 Upravljanje incidentima

Cilj je u uspostavljanju dogovorene poslovne usluge što pre ili odgovoriti na zahteve za

uslugama. Svi incidenti moraju biti snimljeni. Moraju biti usvojene procedure za upravljanje

incidentima. Procedure treba da definišu snimanje, prioritet, poslovni odgovor, klasifikaciju,

obnavljanje, eskalaciju, rešenje i formalno zatvaranje svih incidenata.

Korisnici moraju stalno biti informisani o napredku njihovih prijavljenih incidenata ili zahteva za

uslugom i unapred upozoreni ukoliko njihov nivo usluge ne može biti zadovoljen i moraju biti

dogovorene akcije.

Svo osoblje uključeno u upravljanje incidentima mora imati prisup bitnim informacijama kao što

su poznate greške, rešenja problema i bazu podataka za upravljanje konfiguracijom (CMDB).

Glavni incidneti moraju biti klasifikovani i vođeni u zavisnosti od definisanog procesa.

6.2 Upravljanje problemom

Cilj je smanjenje poslovnog narušavanje uz pomoć indentifikacije i analize uzroka incidenta i

upravljanje problemima do zatvaranja. Svi otkriveni problemi moraju biti snimljeni.

Moraju biti usvojene procedure za otkrivanje, smanjenje ili izbegavanje incidenta ili problema.

One treba da definišu snimanje, klasifikaciju, obnavljanje, eskalaciju, rešenje i zatvaranje svih

problema. Preventivne akcije moraju biti preduzete da bi smanjile potencijalne probleme.

Promene koje su potrebne radi ispravljanja uzroka problema moraju biti prosleđene do procesa

upravljanja promenama. Rešenje problema mora biti praćeno, pregledano i izveštavano radi

efektivnosti. Upravljanje problemima mora biti odgovorno za osiguranje svežih informacija o

poznatim greškama i ispravljeni problemi koji su dostupni upravljanju incidentima. Akcije za

poboljšanje utvrđene kroz ovaj proces moraju biti snimljene i unešene u plan za poboljšanje

usluga.

7. Proces kontrole

7.1 Upravljanje konfiguracijom

Cilj je u definisanju i kontroli komponenata usluga i infrastrukture i održavanje tačne informacije

o konfiguraciji. Mora postojati integrisani pristup planiranju upravljanja promenama i

konfiguracijom. Mora postojati politika šta je definisano kao predmet konfiguracije i njegove

sastavne komponente. Moraju biti definisane informacije koje se snimaju za svaki predmet i

mora uključiti veze i dokumentaciju potrebnu za efikasno upravljanje uslugama. Upravljanje

konfiguracijom mora obezbediti mehanizam za utvrđivanje, kontrolisanje i praćenje

indentifikovanih komponenti usluga i infrastrukture. Mora biti osigurano da je stepen kontrole

dovoljan da zadovolji poslovne potrebe, rizik od neuspeha i kritične usluge. Upravljanje

konfiguracijom mora obezbediti informacije za proces upravljanja promenama na osnovu uticaja

zahteva za promenom konfigurisane usluge i infrastrukture.

Promene u predmetima konfiguracije moraju biti moguće za praćenje i pregled gde je potrebno,

tj. za promene softvera i hardvera. Procedure kontrole konfiguracije moraju osigurati održavanje

integriteta sistema, usluga i komponenti usluga.

7.2 Upravljanje promenama


V01.2012 strana 66

Cilj je u osiguravanju da su sve promene procenjene, dozvoljene, implementirane i pregledane na

kontrolisan način. Promene usluga i infrastrukture moraju imati jasno definisan i dokumentovan

predmet. Svi zahtevi za promenama moraju biti snimljeni i klasifikovani, kao na primer urgentni,

hitni, bitni i nebitni.

Zahtevi za promenama moraju biti procenjeni koliko su rizični, njihov uticaj i poslovne

prednosti. Proces upravljanja promenama mora uključiti način na koji će promena biti poništena

ukoliko je neuspešna.

Promene moraju biti dozvoljene, a zatim proverene, i moraju biti implementirane na kontrolisan

način. Sve promene moraju biti pregledane zbog uspešnosti i bilo koje akcije preduzete posle

implementacije.

Moraju postojati politike i procedure koje će kontrolisati autorizaciju i implementaciju hitnih

promena.

Slika 10 - Proces upravljanja uslugama

8. Proces izdavanja

8.1 Proces upravljanja izdanjima

Cilj je u isporuci, distribuciji i praćenju jedne ili više promena, njenom puštanju u radno

okruženje. Status frekvencija politike izdanja i tip izdanja mora biti dokumentovan i prihvaćen.

Pružaoci usluga moraju planirati puštanje servisa, sistema, softvera i hardvera. Planovi o tome

kako treba voditi puštanje moraju biti usvojeni i autorizovani od strane svih bitnih učesnika, kao

što su kupci, korisnici, osoblje operative i podrške. Proces mora uključiti način na koji će

puštanje biti vraćeno ili ukinuto ukoliko je neuspešno. Planovi treba da snime datume puštanja i

dostavljanja i u odnosu na pušteni zahtev za promenom, poznate greške i probleme. Proces

upravljanja izdanjima treba da dostavi odgovarajuću informaciju procesu upravljanja

incidentima. Zahtev za promenom treba da bude procenjen za svoj uticaj na planove izdanja

(puštanja). Procedure upravljanja izdanjima moraju uključiti obnavljanje i promene informacija

konfiguracije i snimaka promena. Urgentna izdanja moraju biti vođena prema definisanom

procesu koji je ulaz u proces upravljanja urgentnim promenama. Izdanje i distribucija moraju biti

dizajnirani i implementirani tako da je integritet hardvera i softvera održavan tokom instalacije,

obrade, pakovanja i isporuke. Treba meriti uspehe i neuspehe izdanja. Merenje treba da uključi

incidente koji se odnose na izdanja u periodu u kojem se prate izdanja. Analize treba da uključe


V01.2012 strana 67

procenu uticaja na poslove, IT operacije i resurse osoblja podrške, i treba da obezbede ulaz u

plan za poboljšanje usluga.

Slika 17- Internacionalni standard ISO/IEC 20000-1


V01.2012 strana 68

7.2 ISO/IEC 20000-2 - Dobra praksa za upravljanje IT uslugama

Sadržaj ISO/IEC 20000-2

Kao i ISO/IEC 20000-1, standard ISO/IEC 20000-2 sastoji se od deset istih sekcija:



3. Upravljanje sistemom,

4. Planiranje i implementacija upravljanja uslugama,

5. Planiranje i implementacija novim ili izmijenjenim uslugama,




9. Kontrolni procesi, i

10. Procesi puštanja usluge

1. Predmet i područje primene

ISO/IEC 20000 -2 predstavlja industrijsku jednoglasnost u kvalitetu standarda za procese

upravljanja IT uslugama. Ovi procesi upravljanja uslugama daju najbolje usluge kojima će se

zadovoljiti poslovne potrebe korisnika u dogovorenim nivoima resursa, tj. usluga koja je

profesionalna, isplativa i sa rizikom koji je razumljiv i upravljan.

ISO/IEC 20000 -2 preporučuje da pružaoci usluge treba da usvoje opštu terminologiju i više

saglasan pristup upravljanju uslugama. On daje opštu osnovu za poboljšanje usluga. Takođe,

obezbeđuje okosnicu za upotrebu dobavljačima predmeta upravljanja uslugama.

ISO/IEC 20000 -2 obezbeđuje vodič revizorima i nudi pomoć pružaocima usluga u planiranju

poboljšanja usluga.

2. Termini i definicije

Termini i definicije su dati u ISO/IEC 20000 -1.

3. Upravljanje sistemom

3.1. Odgovornost menadžmenta

Uloga u upravljanju je usvajanje procesa za osiguranje najbolje prakse i to je osnova za bilo kog

pružaoca usluge radi zadovoljenja zahteva u ISO/IEC 20000 -1. Da bi se osiguralo izvršenje

izvršilac na višem nivou mora biti indentifikovan kao odgovoran za planove upravljanja

uslugama. Ovaj izvršilac mora biti odgovoran za kranje izvršenje plana za upravljanje uslugama.

Izvršilac na višem nivou mora biti podržan od strane grupe koja donosi odluke sa dovoljnim

autoritetom da definiše politiku i nametne njihove odluke.

3.2. Zahtevi dokumentacije

Izvršilac na višem nivou mora osigurati da su dostupni za pregled politike, planovi i procedure

upravljanja uslugama, i bilo koja aktivnost koja se odnosi na to. Mnogo dokaza planiranja i

izvršenja upravljanja uslugama mora postojati u formi dokumentacije, koja može biti bilo koji

tip, forma ili medijum pogodan za njihovu upotrebu.

Dokumentacija mora biti zaštićena od oštećenja, kao na primer, loših uslova okruženja i

kompjuterske greške.


V01.2012 strana 69

3.3. Sposobnost, svesnost i trening

Cilj je u osiguranju da osoblje upravljanja uslugama bude kompetentno da zauzme svoju ulogu.

Osoblje koji obavlja posao u upravljanju uslugama mora biti kompetentno na osnovu

odgovarajuće obuke, treninga, sposobnosti i iskustva. Osoblje treba da bude trenirano u bitnim

aspektima upravljanja usluga (tj. kroz trening kurseve, samoobrazovanje, mentorski rad i

treniranje na poslu) i njihove sposobnosti timskog rada i vođenja bi trebalo razvijati. Hronološki

zapisi treninga bi trebalo da se održavaju za svakog ponaosob, zajedno sa opisima održanog

treninga. Za svo osoblje, pružalac usluge treba da pregleda svako individualno ostvarenje barem

godišnje i da preduzima odgovarajuće akcije.

4. Planiranje i implementacija upravljanja uslugama

4.1. Plan upravljanja uslugama

Cilj je u planiranju implementacije i isporuke upravljanja uslugama. Predmet i područje primene

upravljanja uslugama bi trebalo da bude definisano kao deo plana upravljanja uslugama. Složeni

planovi upravljanja uslugama mogu biti korišćeni kao deo jednog velikog plana ili programa.

Tamo gde je ovo slučaj podležući procesi upravljanja uslugama moraju biti konzistentni jedni sa

drugim.

4.2. Implementiranje upravljanja uslugama i pružanje usluga (Primena)

Cilj je u implementiranju ciljeva i planova upravljanja uslugama. Jednom implementirana usluga

i procesi upravljanja uslugama moraju biti održavani.

4.3. Praćenje, merenje i pregled (Provera)

Cilj je u praćenju, merenju i pregledu dostignuća ciljeva i planova upravljanja uslugama.

Pružalac usluge mora da planira i primenjuje praćenje, merenje, analize i preglede usluga,

procesa upravljanja uslugama i povezene sisteme.

4.4. Kontinuirano poboljšanje (Delovanje)

Cilj je u poboljšanju efektivnosti i efikasnosti isporuke u upravljanja uslugama.

4.4.1. Politika

Ispručioci usluga moraju razumeti da uvek postoji potencijal za efektivniju i ekikasniju isporuku

usluga. Mora postojati objavljena politika za kvalitet i poboljšanje usluga. Svi koji su uključeni u

upravljanje uslugama i poboljšanje usluga moraju biti svesni politike kvaliteta usluga i njene

personalne uloge na dostignuće ciljeva stavljenih u ovu politiku. Mora postojati efektivna veza

sa strukturom upravljanja pružaoca usluga, korisnika i dobavljača pružaoca usluga po pitanjima

koja se odnose na kvalitet i zahteve korisnika.

4.4.2. Planiranje poboljšanja usluga

Pružaoci usluga treba da usvoje planski i koordinaisani prisup poboljšanju usluga da bi

zadovoljili zahteve politike, sa svoje i sa perspektive korisnika. Pre implementiranja plana za

poboljšanje usluga, nivoi i kvalitet usluga moraju biti snimljeni kao osnova sa kojom se

poboljšanja mogu meriti. Stvarna poboljšanja se moraju porediti sa predviđenim poboljšanjima

da bi se procenila efektivnost promena. Pružaoci usluge treba da ohrabre svoje osoblje i

korisnike da daju predloge za poboljšanje usluga. Poboljšanje usluga treba da bude merljivo,

povezano sa poslovnim ciljevima i dokumentovano u planu. Poboljšanje usluga treba aktivno

upravljati i napredak treba pratiti u odnosu na formalno dogovorene ciljeve.

5. Planiranje i implementacija novih ili izmijenjenih usluga

Planiranje novih ili izmenjenih usluga mora uključiti pregled budžeta, postojećeg osoblja, posojećeg nivoa usluga,

SLAs i drugih ciljeva ili obaveza, postojećih procesa, procedura i dokumentacije upravljanja


V01.2012 strana 70

uslugama, predmet i područje primene upravljanja usluga, uključujući implementaciju procesa

upravljanja usluga. Sve promene usluga bi trebalo da se reflektuju u zapise upravljanja

promenama.

6. Proces isporuke usluga

6.1. Service Level Management (Upravljanje nivoom usluge)

6.1.1. Katalog usluga

Katalog usluga treba da definiše sve usluge. Može biti referenciran od SLA i treba da bude

korišćen da drži materijal uzet u obzir iz samog SLA. Katalog usluga treba da se održava i drži

ažurno.

6.1.2. Sporazumi o nivou usluga (Service Level Agreements – SLAs).

Usluge moraju biti formalno dokumentovane u sporazumu o nivou usluga (SLA). SLA mora biti

formalno autorizovan od strane viših predstavnika korisnika i pružalaca usluga. SLA mora biti

predmet upravljanja promenama, kao što je i usluga koju opisuje.

Poslovne potrebe korisnika moraju biti definisana i moć za sastav, strukturu i ciljeve SLA.

Ciljevi, na osnovu kojih usluga isporuke mora biti merena, mora biti definisana iz perspektive

korisnika. SLAs moraju uključiti samo odgovarajući podskup ciljeva da bi fokusirali pažnju na

najvažnije aspekte usluge.

6.1.3. Proces upravljanja nivoom usluga (SLM)

Glavne poslovne promene kroz, na primer, razvoj, poslovnu reorganizaciju i promenu zahteva

korisnika, mogu zahtevati da nivoi usluga budu prilagođeni, redefinisani ili čak privremeno

suspendovani. Proces SLM mora biti fleksibilan da bi prilagodio ove promene.

Proces SLM mora osigurati da pružaoci usluge ostanu fokusirani na korisnike kroz planiranje,

implementiranje, i upravljanje isporukom usluga.

6.2. Izveštavanje o uslugama

6.2.1. Politika

Zahtevi za izveštavanje o uslugama moraju biti dozvoljeni i snimljeni za korisnike i interno

upravljanje. Ukoliko postoje višestruki pružaoci usluge, dobavljači i poddobavljači izveštaji

treba da reflektuju odnose između dobavljača.

6.2.2. Svrha i provera kvaliteta u izveštajima o uslugama

Izveštaji o uslugama moraju biti blagovremeni, jasni, pouzdani i koncizni.

Oni moraju biti odgovarajući potrebama primalaca i pogodni da se upotrebe kao alat za

donošenje odluka.

6.3. Upravljanje kontinuitetom i raspoloživošću usluga

Zahtevi za kontinuitetom i raspoloživošću usluga moraju biti indentifikovani na osnovu

poslovnih prioriteta korisnika, sporazuma o nivou usluge i procenjenog rizika.

Upravljanje kontinuitetom i raspoloživošću usluga mora biti u saglasnosti sa osiguravanjem

održavanja dogovorenih nivoa usluga. Ovi zahtevi moraju imati glavni uticaj na akcije, trud i

lokaciju resursa radi dostizanja raspoloživosti usluga koje podržavaju njih.

Procesi za osiguravanje tog održavanja raspoloživosti moraju uključiti one elemente isporuke

usluga koji su pod kontrolom korisnika ili drugih pružaoca usluga.

6.4. Budžet i račun za IT usluge


V01.2012 strana 71

U praksi, mnogi pružaoci usluga naplaćuju za ovakve usluge. Međutim, sobzirom da je

naplaćivanje opcionalna aktivnost, nije pokrivena standardom. Pružaocima usluge je

preporučeno da ukoliko postoji naplaćivanje, mehanizam o tome mora biti potpuno definisan i

razumljiv za sve strane.

6.5. Upravljanje kapacitetom

Postojeći i očekivani poslovni zahtevi za uslugama moraju biti razumljivi u smislu šta posao

zahteva da bi osigurao njihovu isporuku svojim korisnicima.

Upravljanje kapacitetom bi trebalo da bude centralna tačka za svo dostizanje izlaza i kapaciteta.

Proces bi trebalo da obezbedi direktnu podršku razvoju novih i promenjenih usluga

obezbeđivanjem značajnih usluga.

6.6. Upravljanje bezbednošću informacija

Bezbednost informacija je rezultat sistema polisa i procedura napravljanih da indentifikuju,

kontrolišu i zaštite informacije i bilo koju opremu korišćenu u vezi sa njhovim smeštanjem,

prenosom i upotrebom.

7. Veze između procesa

Veze između procesa opisuju dva povezana aspekta upravljanja dobavljačima i upravljanje

poslovnim vezama. Ovaj standard se odnosi na ulogu pružaoca usluge, koji logično ispunjava

ulogu između dobavljača, isporuke dobara ili usluge pružaocu usluge, i korisnika koji dobija

uslugu.

I dobavljači i korisnici mogu biti interni ili eksterni u organizaciji pružaoca usluge. Eksterne

veze će biti formalizovane kroz ugovor. Interne veze će biti formalizovane putem usluge ili

internih sporazuma koji se često odnose na sporazum o nivou operacija.

8. Odlučujući procesi

8.1. Osnova

Ciljevi za odlučivanje treba da budu zasnovani na prioritetu. Prioritet treba da bude zasnovan na

uticaju i hitnosti. Uticaj treba da bude zasnovan po skali stvarne ili potencijalne štete na poslove

korisnika. Hitnost treba da bude zasnovana na osnovu vremena između otkrivanja problema ili

incidenta i vremena koja trpe poslovi korisnika.

8.2. Upravljanje incidentima

Upravljanje incidentima mora biti i proaktivni i rekativni proces, koji odgovara na incidente koji

imaju uticaj, ili potencijalno mogu uticati na uslugu, koncentrisano na obnavljanje usluge

korisnika, ne na utvrđivanje uzroka incidenta.

Proces upravljanja incidentima treba da uključi prijem poziva, snimanje, dodeljivanje prioriteta,

klasifikaciju, prvu liniju odluke ili prosleđivanje, razmatranje ciljeva zaštite, praćenje incidenta i

upravljanje životnim ciklusom, verifikacija incidenta i zatvaranje, prva linija veze sa korisnikom,

eskalacija.

8.3. Upravljanje problemom

Proces upravljanja problemom treba da istraži pozadinu uzroka incidenata.

Upravljanje problemom treba proaktivno da spreči ponavljanje incidenata ili poznatih grešaka

prema poslovnim zahtevima. Incidenti treba da budu klasifikovani da bi pomogli u utvrđivanju

uzroka problema. Klasifikacija može da odredi postojanje problema i promena.


V01.2012 strana 72

Kada istraga u upravljanju problemom indentifikuje koren uzroka incidenta i metod za njegovo

rešavanje, problem treba klasifikovati kao poznatu grešku. Poznata greška treba da bude

zatvorena tek nakon uspešnog rešavanja. Kada je koren uzroka indentifikovan, i donešena odluka

za njegovo rešavanje, izvršenje treba da bude izvedeno kroz proces upravljanja promenama.

9. Proces kontrole

9.1. Upravljanje konfiguracijom

Upravljanje konfiguracijom treba da bude planirano i implementirano sa upravljanjem

promenama i izdanjima da bi osiguralo da pružalac usluge može da efektivno upravlja svojim IT

resursima i konfiguracijom. Tačne informacije o konfiguraciji treba da budu dostupne radi

podrške planiranju i kontroli promena kada su nove i poboljšane usluge i sistemi pušteni i

distribuirani. Rezultat treba da bude efikasan sistem koji integriše proces konfiguracije pružalaca

usluge i njihovih korisnika i dobavljača, gde to odgovara.

Svi glavni skupovi i konfiguracije treba da budu sračunati i da imaju odgovorne menadžere koji

će osigurati da se održava odgovarajuća zaštita i kontrola, tj. da promene budu autorizovane pre

implementacije.

9.2. Upravljanje promenama

Procesi i procedure upravljanja promenama treba da osiguraju da promene imaju jasno definisan

i dokumentovan predmet i područje primene, da budu odobrene samo promene koje obezbeđuju

poslovne beneficije, da su promene raspoređene na osnovu prioriteta i rizika, da promene

konfiguracije mogu biti verifikovane kroz implementaciju promena, da vreme implementiranja

promena bude praćeno i poboljšano tamo gde je potrebno. Sve promene treba da budu

pregledane radi uspešnosti ili neupešnosti nakon implementacije i bilo koje poboljšanje treba da

bude snimljeno.


V01.2012 strana 73

Slika 18 - Internacionalni standard ISO/IEC 20000-2

10. Proces izdanja (puštanja)

Upravljanje izdanjima treba da koordiniše aktivnosti pružaoca usluge, više dobavljača i posla da

planira i isporuči izdanje kroz distribuirano okruženje. Dobro planiranje i upravljanje su od bitne

važnosti za paket i uspešnu distribuciju izdanja, i za upravljanje povezanih uticaja i rizika za

posao i IT. Izdanje značajnog informacionog sistema, infrastrukture, usluga i dokumentacije

mora biti planirano sa poslovima. Sva povezana obnavljanja dokumentacije mora biti uključena

u izdanje, tj. poslovne procese, dokumente podrške i sporazume o nivou usluga. Pružalac usluge

mora da osigura da i tehnički i netehnički aspekt izdanja budu uzeta u obzir. Sva izdanja moraju

biti obradiva i zaštićena od modifikacije. Samo odgovarajuće testirano i dozvoljeno izdanje može

biti prihvaćeno u stvarnom okruženju.


V01.2012 strana 74

7.3 ISO/IEC i ITIL

Oba standarda (mada ITIL ne predstavlja standard u pravom smislu) nisu konkurentni jedan

drugom, već se dopunjuju. Dok ISO/IEC 20000 određuje potrebe za upravljanje IT uslugama,

ITIL dokumenta najbolje prakse određuju za svaki pojedinačni proces upravljanja IT uslugama.

Izašla je nova verzija ITIL-a, nazvana ITIL Version 3 (ITIL V3) koja se sastoji iz 5 knjiga:

Stretegije,

Dizajn,

Tranzicija,

Operacija,

Poboljšanje.

Slika 19 - Veza između ITIL i ISO 20000

7.3.1 ITIL, ISO 20000 i BS15000 Korisničke grupe

Važnost kvaliteta IT usluga upravljanja postaje sve vidljiviji. To je oblast koja u modernim

oblastima zahteva jasan fokus i pažnju. Iz tog razloga se poslednjih godina prepoznaje i

profesionalna struktura podržava: ITIL. ITIL, IT Infrastructure Library donosi niz pogodnosti, te

se globalno koristi i prati.

Nedugo zatim, počeo je sa razvojem i standard: ISO 20000. Posebno je posvećen IT uslugama za

upravljanje, a obuhvata dva dela: ISO 20000-1 i ISO 20000-2. Izvorno je objavljen od strane BSI

kao BS15000 (deo 1 i 2).

7.4 Zašto ISO/IEC 20000

Razlog za pravljenje standarda ISO/IEC 20000 je bila mogućnost setrifikovanja Upravljanja IT

uslugama u kompanijama.

Relationship between ITIL and ISO 20000


V01.2012 strana 75

Cilj standarda ISO/IEC 20000 je u obezbeđivanju opštih preporuka za IT organizacije, koje

isporučuju interne ili eksterne usluge korisnicima.

Krajnji cilj ISO/IEC 20000 je da:

smanji operativnu izloženost riziku,

zadovolji ugovorene zahteve, i da

demonstrira kvalitet usluga.

Serija ISO/IEC 20000 ocrtava razliku između procesa najbolje prakse, koji su nezavisni od

organizacione forme ili veličine i imena i strukture organizacije. Serija ISO/IEC 20000 se odnosi

i na male i na velike pružaoce usluga, i zahtevi za procese najbolje prakse upravljanja uslugama

su nezavisni od organizacione forme pružaoca usluga.

Ovi procesi upravljanja uslugama daju najbolju uslugu za zadovoljenje poslovnih potreba

korisnika sa dogovorenim nivoom resursa, tj. usluga koja je profesionalna, jeftinija i sa rizikom

koji je razumljiv i upravljan.

7.4.1 Kako ISO/IEC 20000 sertifikuje procese u organizaciji

Slika 20 - ISO/IEC 20000 ček lista

Pregled ISO/IEC 15000 ili 20000 je skoro isti. Prvo postoji predpregled gde je diskutovano o

predmetu i području primene sertifikaije i sadašnjeg sistema. Sledeći korak je provera

dokumentacije, gde je slaganje sa standardom dokazano. Sledeće, u pregledu sertifikaicje su

dokumentovani procesi upravljanja uslugama. Ako su svi nalazi pozitivni za tri godine biće

izložen sertifikaciji. Svake godine inspekcija dokazuje pridržavanje definisanih procesa. Na

kraju sve tri godine zahtevanih pregleda bivaju ispunjeni.


V01.2012 strana 76

7.4.2 Ček lista

ISO 20000 Implementation Checklist

Area and

Phase Document Status Notes

Requirements for Management System

Management Responsibility

Documentation Requirements

Competence, Awareness and Training

Planning and Implementing Service management

Plan Service Management (Plan)

Implement Service Management and Provide the Services (Do)

Monitoring, measuring and reviewing (Check)

Continual Improvement (Act)

Policy

Management of Improvements

Activities

Planning and Implementing New or Changed Services

Service Delivery Process

Service Level Management

Service Reporting

Service Continuity and Availability Managemnet

Budgeting and Accounting for IT Services

Capacity Management

Relationship Process

General

Business Relationship Management

Supplier Management

Resolution Processes

Background

Incident Management

Problem Management

Control Processes

Configuration Management

Change Management

Release

Process

Release Management PRocess


V01.2012 strana 77

Slika 21 - Izgled Sertifikata


V01.2012 strana 78

7.5 Prednosti implementacije ISO/IEC 20000

Implemetacija ISO/IEC 20000 donosi sa sobom mnogo prednosti i beneficija. Ovo je naravno

različito od organizacije do organizacije. Međutim, sledeća lista je dobar primer opštih rezultata:

svrstavanje poslovne i strategije usluga informacionih tehnologija,

pravljenje opšteg okvira za postojeće projekte poboljšanja usluga,

obezbeđuje tip poređenja sa najboljom praksom,

pravi prednost poređenja kroz promociju postojećih usluga,

zahtevajući posedovanje i odgovornosti pravi progresivnu kulturu,

podržava unutrašnje promene pružaoca usluga i osoblja kroz prednost kreiranja internih

operativnih procesa,

smanjenje rizika i troškova eksternih primaoca usluge,

kroz kreiranje pristupa posojećeg standarda, nameće glavne organizacione promene,

pojačava reputaciju i percepciju,

fundamantalna promena na proaktivni pre nego reaktivni proces,

poboljšane veze između različitih odseka kroz bolju definiciju i jasnije termine

odgovornosti i ciljeva,

pravljenje stabilnog okvira i za treniranje resursa i za automatsko upravljanje uslugama.

7.6 Nadgradnja standarda ISO/IEC 20000 ISO/IEC TC 1/SC 7/WG 25

Godine 1989 britanski odbor Instituta za standarde (BSI) za potrebe industrije, prvi je objavio

pravila ponašanja u oblasti upravljanja uslugama. A uskoro su pokazali da su postojeći standardi

usklađeni sa najboljom praksom saveta u Velikoj Britaniji, prikupljenih u knjizi najboljih praksi

IT, više poznat kao ITIL (IT Infrastructure Library), koja se nalazi u sklopu prakse za upravljanje

usluga informacionih tehnologija. Koordinacija je razvoj na području IT usluge, ISO/IEC 20000,

Informatika - Upravljanje uslugama, uticaj.

Godine 2000 Britanski Institut za standarde izdao je prvi specifikaciju za certifikaciju revizije

upravljanja IT uslugama, BS 15000. Na osnovu podataka dobijenih od autora dobitak od prvih

korisnika, sledi specifikacija izdavanja drugog dokumenta, ovog puta standardni IT service

management system.

Uskoro sledi brzo ispitivanje oba dela BS 15000, te je u decembru 2005, odbor ISO / IEC SC 7

(Slika 14.) izdao je prva dva dela međunarodnog standarda ISO / IEC 20000-1 i ISO / IEC

20000-2.


V01.2012 strana 79

Slika 22 - Gde spada ISO / IEC 20000?

7.7 Veze između standarda?

ITIL je okvir i najboljih praksi se najčešće koristi za pristup upravljanju IT uslugama na svet.

Pripremili Kancelarija Vlade Velike Britanije Commerce (OGC). Danas se koristi uglavnom u

privatnom sektoru u preko 40 zemalja širom sveta. Često čujemo mišljenje da standard ISO /

IEC 20000-1 predstavlja suštinu "obaveze" ITIL prakse. Primeri su pozivnice tender, koji u

prošlosti uključuje preporuke za korišćenje ITIL najbolje prakse, danas umesto toga, sadrže

zahteve za izdavanje certifikata, u skladu sa ISO / IEC 20000. ITIL i ISO / IEC prikazane su na

slici 15.

Slika 23 - Veze između standarda

1. deo – Specifikacija obaveznih zahteva

2. deo – Saveti o pravilima ponašanja iz

prvog dela standarda

Detaljne informacije stručnjaka o

najboljim praksama

Koristiti

Unutrašnja politika, procesi i procedure


V01.2012 strana 80

Standard ISO / IEC 20000 iz zbirke ITIL - Verzija 2 nije u potpunosti usklađena, naročito, ISO/

IEC 20000-1:2005, Informatika - Upravljanje uslugama - 1 deo: Specifikacija (ISO / IEC 20000-

1:2005 Information technology - Service management - Part 1: Specification) zapravo

specifikaciji koja pruža najbolju praksu, tj. što će biti postignuto, a ITIL komplet daje smernice o

tome kako doći do željenog cilja.

Uprkos nekim drugim razlikama koje su posledica prirode pripreme dokumenata i uslovi

njihovog objavljivanja, između korisnika ISO / IEC 20000 standarda se odnosi na ITIL komplet.

Standard ISO / IEC 20000 je pripremljen tako da je manje obavezujuć po pitanju, KAKO do

željenog cilja. Kao dokument ostaje koristan za široki spektar organizacija bez obzira na njihovu

vrstu ili veličinu.

7.7.1 Certifikacija revizije

Kao odgovor na potrebe i zahteve industrije, Forum za upravljanje IT uslugama (IT Service

Management Forum - itSMF) je 2003. godine, napravio šemu za registraciju akreditovanih

certifikacionih tela koja sprovode reviziju u skladu sa British Standard BS 15000-1. Danas se

certifikacione kuće u kontekstu sa tom šemom ocenjuju po međunarodnom standardu ISO / IEC

20000-1.

itSMF je globalna, nezavisna, međunarodno priznata neprofitna organizacija koja brine za

područje upravljanja IT uslugama. Ona se sastoji od više 40 lokalnih službi, koje deluju pod

okriljem međunarodnih organizacija itSMF International. ItSMF članovi foruma su aktivno

uključeni u razvijanje i promovisanje najbolje prakse i standarda u upravljanju IT uslugama, kao

što su već pomenute zbirke ITIL i ISO/IEC 20000.

ItSMF program je takođe kompatibilan sa smernicama za procenu sistema upravljanja u okviru

Međunarodne akreditacije Forum (IAF). Ove smernice su napravljene na osnovu Vodiča 62, ali

njihovo prilagođavanje je ka standardu ISO/IEC 17021:2006, ocenjivanje usklađenosti - Zahtevi

za tela koja procenjivanje i certifikaciju sistema upravljanja (ISO/IEC 17021:2006 ocenjivanje

usklađenosti - Zahtevi organa za reviziju i certifikaciju sistema upravljanja). Šemom je

registrovano više od 20 certifikacionih tela koju vode revizori i konsultanti obučeni za itSMF

forum.

Članovi Foruma itSMF aktivno podržavaju proveru i overu akreditovanja svojih registrovanih

vlasti prema nacionalnim akreditacionim organima, kao što su British Accreditation Usluga

UKAS. Članovi Foruma učestvuju u razgovorima sa Međunarodnim akreditacije Forum (IAF).

7.7.2 Uticaj ISO / IEC 20000

Upravljanje uslugama (i ISO / IEC 20000) pokriva područje pružanja usluga, kao i obim usluge

podrške, koji čine najveći deo ukupnog troška vlasništva (ukupni trošak Ounership - TCO).

Dakle, odluku o primeni najbolje prakse upravljanja, usluge poboljšanja poslovnih performansi,

a ne samo na nivou pojedinačnih organizacija, nego na celu državu, jer to može značajno da

utiče na bruto domaći proizvod, što je presedan privredne aktivnosti neke zemlje.

Ovo dodatno naglašava važnost poboljšanja u upravljanju uslugama, koji može biti i 50% niži na

troškove jedinice u aktivnostima kao što je spašavanje i otklanjanje, uvođenje greške ili

promene.

To je potencijal za poboljšanje usluga, a smanjenje troškova su ubrzani porast usvajanja ISO/IEC

20000.

U većini organizacija, koje su ranije procenile British Standard BS 15000, tranzicija u

ISO/IEC 20000 odvija se u kontekstu redovne recenzije. Takođe, ISO/IEC 20000 je usvojila niz


V01.2012 strana 81

novih organizacija. Neki od standarda za upravljanje IT usluga zainteresovani su za rezultat

pravila ili propisa koje čekaju na međunarodnom standardu.

Od nastanka BS 15000 je uvek na listi najbolje prodaje BSI British Standards, do danas, u skladu

sa ISO/IEC 20000 certifikovano je oko 300 organizacija.

Certifikacija itSMF foruma ili bilo koje druge šeme, široko je rasprostranjena u celom svetu.

Neke organizacije su odabrale diskreciju u "proširiti obim ISO 9001:2000" (za proširenje obima

ISO 9001:2000), u obim upisa se primenjuje na organizacije u skladu sa ISO/IEC 20000.

Standard ISO/IEC 20000 je konstanta na listi najbolje prodajne norme u obe Međunarodne

organizacije za standardizaciju (ISO) kao i u mnogim nacionalnim standardima. Prve godine

nakon objavljivanja u Engleskoj je prodato oko 3.000 primeraka ISO/IEC 20000-1. Čak je i

prodaja Drugog dela standardna, ISO/IEC 20000-2, Informacije Tehnologija - Upravljanje

uslugama - 2 deo: Kodeks ponašanja (ISO/IEC 20000-2 Informatika - Service management - Part

2: Code of practice), na istom nivou. Veliki broj izdanja i prodaje su još uvek nacionalno

vlasništvo, prevodi standarda mogu se opravdano očekivati u budućnosti.

U velikoj meri popularnost može biti, sertifikovanje revizija, obrazovanja i osposobljavanja

odnosa na međuodnos između standardna i zbirke ITIL. U stvari, činjenica je da su itSMF i ITIL

maksimalno doprinijeli da je sada standard ISO/IEC 20000, čak veće tržište od svog rethodnika,

nekad BS 15000.

Popularnost standarda je pokrenula razvoj obrazovanja i programa obuke za revizore,

konsultanata i stručnjaka koji aktivno pripremaju organizacije širom sveta. Među najaktivnijima

u ovom području su i Zavod za ispitivanje Informacionih Nauka (EXIM), Information Systems

Ispitni odbor (ISEB), Grupa APM, Međunarodni registar ovlašćenih auditora (IRCA) i neke

druge komercijalne obrazovne organizacije. Obrazovanje, obuka i ispiti osim engleskog su već

dostupne u drugim jezicima. Na primer, IRCA je pokrenula program za sertifikovanje revizora

za ISO/IEC 20000 u saradnji sa japanskom organizacijom Japan Information Processing

Development Corporation (JIPDEC).

Brzi razvoj u odnosu na standard ISO/IEC 20000 u budućnosti možemo očekivati veću

ravnotežu između perioda stabilnosti za korisnike i standardne, predanost prevodioca poboljšanju

standarda.

7.7.3 Novi ISO/IEC 20000-3

Radna grupa WG 25 pripremila je nacrt za novi standard ISO/IEC 20000-3, koji je trenutno na

odobravanju kod poslanika u pododboru SC 7. U ovom trećem delu je standard ISO/IEC 20000,

smernice davaoca usluga u vezi sa zahtevom, određivanje i postavljanje izjave o aplikacija.

Radna grupa je pripremila standardni set dokumenata iz serije BS 15000, na osnovu praktičnih

iskustava stečenih tokom sprovođenja programa i poboljšanja usluga, certifikacije revizija, i na

osnovu materijala i informacija navedenih od strane itSMF.

Standard ISO/IEC 20000-3 uglavnom sadrži praktične primere koji pokazuju korisnost,

određivanje oblasti i izjave u vezi određivanja oblasti. Neki jednostavni primeri prikazani su na

slici 16.


V01.2012 strana 82

Slika 24 - Primeri podešavanja opsega

Za pripremu tih novih pravila ponašanja pokreću se grupe pitanja, koje su više nego u vezi sa

bilo kojim drugim aspektom standarda ISO/IEC 20000 koji je u vezi sa zahtevima, određivanjem

oblasti, korišćenjem usluge upravljanja u odnosu na obim izveštaja. Uloga svakog dela standarda

ISO/IEC 20000 je prikazano na slici 17.

Glavni dobavljač Dobavljač

Dobavljač Vodeći dobavljač

Podizvođač Podizvođač Podizvođač

Podizvođač Podizvođač Podizvođač

Strana A

Spoljnih usluga

(certifikovan po ISO/IEC

20000)

Internih usluga (certifikovan

po ISO/IEC 20000)

Strana B


V01.2012 strana 83

Slika 25 - Gde spada ISO/IEC 20000-3

Članovi radne grupe WG 25 trenutno ne planiraju standardnu šemu certifikacije, odnosno

smernice za ocenu i razmatranje da se podaci u ISO / IEC 20000-3 ne bi duplirati sa sadržajem

publikacije Međunarodne akreditacije Forum (IAF), ili ISO Odbora za ocenjivanje usklađenosti

(CASCO).

Grupa 25 WG je odlučila da Forum IAF pomogne u sprovođenju revizije standarda ISO/IEC

20000-1. IAF članovi takođe su članovi radne grupe WG 25.

7.7.4 Treće izdanje ITILa

Program razvoja novog ITIL-a temelji se na osnovu mišljenja prikupljenih sa konsultacija o

upravljanju usluga u mnogim zemljama sveta. Povezanost između prakse ITIL podržava

standarde OGC. Treće izdanje zbirke pod uslovom da se poštuje sporazum o bezbednosti

informacija, javno otkriva pet koraka životnog ciklusa upravljanja uslugama:

Strategija za uslugu (usluga strategija),

Planiranje usluga (usluga oblikovanje),

Prodiranje usluga (usluga tranzicije),

Operation usluge (service operation)

Kontinuirano unapređivanje usluga (kontinuiranih poboljšanja usluga).

1. deo

2. deo 3. deo

Instrukcija na osnovu uslova

Interpretacija

prvog dela

Korisnost -

područja

IAF Uputstvo za

ISO/IEC vodeći GZ

ISO/IEC

vodeći

Zahtevi


V01.2012 strana 84

Treće izdanje ITIL pokriva angažman manadžementa, odgovornosti, prioriteta, politike i tekućih

poboljšanja, koje su od ključnog značaja za sve standarde za upravljanje sistemom. Od ovog

izdanja se ne očekuje da značajno utiče na tumačenje i primenu ISO/IEC 20000 ili u vezi

uverenja, sertifikacionih šema ili obuka i kvalifikacije. Međutim, prema brojnim korisnicima

ITIL praksi se očekuje da razlika između dva seta dokumenata bude u budućnosti predmet

rasprave živo.

7.7.5 Poboljšanja prvog i drugog dela standardna ISO/IEC 20000

Budući da je standard BS 15000 od 2002 godini, u skladu sa standardom ISO 9001, tako da je

razumevanje da ono što je potrebno za efikasan sistem upravljanja znatno promenjeno. Prednosti

integrisanog sistema upravljanja su početne korekcije ISO/IEC 20000-1, što je važno jer je

većina revizije sprovedena u kombinaciji sa procenom ISO 9001 ili ISO/IEC 27001.

Sva poboljšanja u ISO/IEC 20000-2 su sačuvana za kasniji period, kada bude jasno koje

promene su potrebne ISO/IEC 20000-1.

7.7.6 Usklađivanje normi i ISO/IEC 20000

Većina prepiski, koja se odvija između članova radne grupe WG 25, povezana je sa programom

pododbora SC 7 za usklađivanje serije ISO/IEC 20000. Iako je jasno da je generalno

koordinirano lečenje IT standardima, imaju prednosti celokupnog IT sektora, ali za sada ne

postoji konsenzus o tome šta zapravo, to znači za ISO/IEC 20000. Polja koordinacije koja su

trenutno predmet pregovora, prikazane su na slici 18. To uključuje aproksimaciju ISO/IEC

20000 i ISO 9000 koji su u vezi sa standardom ISO/IEC 20000 i niz bezbedonosnih IT

koordinacija terminologije u standardima i dokumenata najboljih praksi i koordinacija ISO/IEC

20000 i standarda za tehnologiju i softverskih sistema, pripremljen od strane pododbora SC 7.

Radna grupa WG 25, bavi se rezultatima studije pododbora SC 7, standardima upravljanja

informacija i telekomunikacionih tehnologija. Usklađivanje normi pod SC 7 je najbolje opisao

predavač pododbora Francois Coallier, koji je izjavio: "... koordinaciju procesa, koja je počela

sa ISO/IEC 20000, je dvosmerna ulica u /.../ Nadamo se saradnji i pomoći svih koji rade u

oblasti IKT i njihovog doprinosa standardizacije našeg rada - kao što mi kao stručnjaci

pomažemo drugim projektima".

Iz njegovih reči, vidi se izazov suočavanja pododbora SC 7 pri koordinaciji standarda za

originalno odvojena područja tehnologije i planiranja sistema. To takođe odražava kompleksnost

koordinacije standarda, koji se razlikuju u pristupima, kao ISO/IEC 20000 u odnosu na ISO/IEC

12207, ISO/IEC 15288 i ISO/IEC 15504.


V01.2012 strana 85

Slika 26 - Koordinacija: veliki potencijal i pregled

Budući da je ISO/IEC 20000 i ISO 9001 u skladu jedno sa drugim, na sličan način rešavaju

odgovornosti vođstva i kontinuirana poboljšanja. ISO/IEC 20000 takođe sadrži i principe

određujući šta treba postići, a daje relativno malo zahteva o tome kako je usluga učinjena.

Pronalazači su za ovaj pristup, dakle, odlučili kako bi davaocima usluga dali priliku da se

prilagode njihovim najboljim praksama, okolnostima i potrebama. Fleksibilnost na pitanje kako

bi se postigla usklađenost sa ISO/IEC 20000, takođe znači da je reč o primeni standardna.

Nasuprot tome, u nekim standardima pod pokroviteljstvom SC 7, na primer, u ISO/IEC 12207 i

ISO/IEC 15288, isporučivanje zahteva više krutosti. Ovi standardi, na primer, pažljivo polažu

broj aktivnosti / zadataka za svaki postupak. Zahtevi se uglavnom odnose na pitanje, kako / na

koji način, za svaki postupak, a koliko / kako značajno više propisan kao u ISO / IEC 20000.

Razvoj ISO/IEC 20000 je takođe važan uticaj na terminologiju u standardima i drugim

dokumentima najbolje prakse. BS 15000 pronalažači su namerno izbegavali korišćenje

specifičnih izraza; oba standardna sadrže samo 15 specifičnim uslovima, što je neobično za ovu

vrstu dokumenta.

Umesto specifičnih tehničkih uslova pripremaju ISO/IEC 20000 pojmove koji se koriste, čije

značenje se lako može naći u opštem Engleskom softveru. Analizom brzog „lečenja” BS 15000

pokazala je da je razlika u izrađu ISO/IEC 20000 i ostalih standarda relativno mala. Međutim,

ipak postoje neke odredbe za koje se veruje da impliciraju značajne razlike između dokumenata.

Zadaci radne grupe WG 25 je takođe jedna modernizacija mapiranja pojmova u ISO/IEC 20000 i

ostalih standarda koje je razvio pododbor SC 7 i serija ISO 9000 i ISO/IEC 27000.

Mapiranje je takođe privremena promena stope pre stvarne promene u standardima pod

pokroviteljstvom SC 7, kartiranje može takođe postati deo standarda ISO/IEC 20000.

Tehnologija softvera i usluga


V01.2012 strana 86

8 Zaključak

U ovoj skripti nalaze se odabrane tehnike i standardi ITSM.

Neka poglavlja su obavezna literatura za polaganje prednemeta „Upravlčjanje IT Uslugama“ na

specijalistilkim studijama, smer Informatika, Visoke tehničke škole u Kragujevcu, dok su ostala

poglavlja prikazana kao dodatno štivo i praktični saveti profesionalcima u praktičnom radu.

Bilo koja aktivnost u organizaciji mora biti u skladu sa kompletnom strategijom korporacije i

upravljanje servisima nije izuzetak. Unutar upravljanja servisa, sedam različitih disciplina

moraju se sumarizovati

Slika 27 - Menadžment servisa

Stateško upravljanje servisima obezbeđuje važnu povratnu vezu za korporativnu strategiju i za

više tehnički fokusirane servisne sredine nazad do IT strategije. Ova veza je bidirekciona, npr.

korporativna strategija je glavni upravljač dizajna servisnih strategija. Štaviše, može se takođe

videti neverovatne mogućnosti servisa koji inspirišu revizije korporativne strategije. (npr

potencijal za globalizaciju tržišta) i dovesti do novih poslovnih servisno orijentisanih modela.

Servisna arhitektura može biti viđena kao sumari korporativne delatnosti. Kao takva obezbeđuje

esencijalnu vezu između artikulisane strategije i detaljnijih usluga. Servisne arhitekture se

moraju uključiti u veće enterprajz arhitekture. Strateško upravljanje servisima definiše ambicije

za servisno baziranim pristupom za organizovanje. Takođe uključuje strateško posmatranje

svakog servisa, što obezbeđuje vrednosne ulaze u upravljanje servisima i identifikaciju servisa

koje bi trebalo gasiti (ili bi takođe trebalo integrisati). Strateški pristup zahteva adresiranje

prolaz i strateško sinhronizovanje servisa baziranih na poslovnom modelu.

Upravljanje servisima je posao definisanja rola, odgovornosti, polisa i posle svega upravljanje

odlukama kao deo upravljanja poslovnim servisima. Odgovornosti mogu da se izvedu iz

zadataka kako evolviraju kao deo životnog ciklusa servisa Ovi zadaci moraju biti alocirani


V01.2012 strana 87

rolama baziranih na sličnosti i zahtevanim znanjima i iskustvima. Takve role će proširiti već

familijarne role, ali će takođe dodati i nekoliko novih rola organizaciji (npr. servisni arhitekta,

servisni bibliotekar...) Zahtevi svake role se konsolidišu i formiraju esencijalni ulaz za opise

poslova. Procesno orijentisana definicija odgovornosti definiše upravljanje odlukama koji utišu

na sve servisne managment poslove. Usluga upravljanja treba takođe i da obezbedi nadležna

organizaciona tela u skladu sa definisanim procesima donošenja odluka.

Upravljajnje obuhvata i podsticajne nagrade koje su od značaja da se ohrabri na primer servis

koji se može ponovo upotrebiti.

Esencijalna komponenta strateške srane poslovnog managementa servisa je portfolio servisni

menadžment. Servisni portfolio se sastoji od dobro definisanog skupa usluga (npr HR usluge ili

sve usluge koje se nude određenoj Portfolio menadžment u servisima explicitno uzima u obzir

sve zahteve upravljanja velikog seta servisa. Jednom kad se relevantni servisi konsoliduju u

jednom portfoliu. Portfolio servisni managment podržava kanalisanje servisno baziranih

investicija kroz komarativnu analizu servisa i baziranu na definisanim normativnim strategijama.

Ultimativno vizuelizovano u formi dvo ili tro dimenzionih servisnih portfolia, kao što bi analiza

mogla, na primer da identifikuje servise od visokog strateškog značaja ali slabih performansi.

Servisni portfolio bi takođe uključio servise koji još nisu urađeni već samo postoje kao ideje.

Sve u svemu, servisni portfolio menadžment je poravnat sa delovima aktivnosti iz faze servisne

analize kao deo životnog ciklusa servisa. Izvodljivosti od inicijalnih ideja za servise moraju se

anlizirati da bi se donela odluka o alociranju resursa da se te ideje mogu realizovati u okviru

celokupnog servisnog portfolia. Zajedno sa uvođenjem menadžmenta portfolia servisa kao

discipline, vidimo potrebu nove uloge Servisnog Portfolio menadžera. Ključna disciplina

Servisnog portfolio menadžmenta je menadžment "pakovanja! servisa koji se bavi

problematikom identifikovanja servisa koji bi se mogli zajedno upakovati u servisne celine.

Pored tehničkih i konceptualnih izazova menadžerski poslovi postoje zbog prepoznavanjea i

identifikovanja paketa usluga koji će dovesti do efikasnije i strateški balansiranijih novih

agregacija. Ovo zahteva novu generaciju "mogao bi biti servis paket" bazirano na zajedničkim

svojstvima servisa. Npr treba razmisliti o spajanju servisa koji se daju istoj grupi kupaca ili na

istoj lokaciji). Ovi tako generisani kandidati za nove servisne grupe (pakete) moraju da se ocene

kroz razne dimenzije (ekonomske, rizici, tehničke) tako da se kandidati za servisne pakete mogu

izvesti.

Menadžment mogućnosti servisa pretstavlja dopunu menadžmentu portfolia. Dok servisni

portfolio menadžment se fokusira na postojećim i ne postojećim servisima, menadžment

mogućnosti servisa se fokusira na mogućnosti koje su potrebne da se obezbedi i koriste trenutni i

budući servisi, servisne vrednosne mogućnosti, mogućnosti konstuisanja servisa, organizaciona

kulura, metode, veštine... Različiti nivoi zrelosti mogu se identifikovati za svaki od mogućih

nivoa što vodi do modela zrelosti servisnih mogućnosti. Kao deo menadžmenta mogućnosti

servisa različite strategije vezane za specifične nivoe zrelosti moraju biti definisane. Svako

povećanje zrelosti mora biti poravnato sa faktorom mogućnosti da bi se obezbedio ekonomski

značaj. Takve normativne strategije moraju voditi organizaciju u dosezanju sledećeg nivoa

zrelosti.

Menadžment servisnih inovacija pokriva sve aktivnosti vezene za kreaciju sasvim novih

servisa ili radikalno unapređivanje postojećih servisa. Ova aktivnost je blisko vezana za

menadžment portfolia servisa, gde su potrebe i mogućnosti za inovacije identifikovane i

komparativno proverene. Inovacije u servisima takođe uključuju angažovanje trećih lica bilo u

formi intenzivnog i veoma selektivnog partnerstva ili u formi otvorenih inovacija sa velikim

skupom nepoznatih lica (Web 2.0) U dotaku ovom "spolja-ka unutra pogledu", menadžment

inovacija u servisima može takođe uključiti i pogled "iznutra ka van" koji je u službi ideja koje

se prodaju trećim licima (komercijalizacija servisa).


V01.2012 strana 88

Upravljanje performansama servisa stara se o analitičkoj strani Upravljanja Servisom

Poslovanja. U upravljanju performansama servisa svi relevantni kvantitativni i kvalitativni

podaci koji opisuju servise performansi iz više aspekata se konsoliduju, agregiraju, vrednuju i

distribuiraju. U ovoj slučaju pruža značajan doprinos za usluge strategije poslovanja, upravljanje

servisom portfolia i upravljanje kvalitetom usluga. Agregatni podaci su takodje imtegrisani

ukupnim korporativnim performansama sistema. Na osnovu pokazatelja i zvučnog razumevanja

uzročno-posledične veze, rana upozorenja se mogu generisati. Operativni servis faza sa životnim

ciklusom servisa je najvažniji provajder relevantnih informacija za poslove upravljanja

performansama. Upravljanje kvalitetom usluga pruža vazne servisne atribute koji zaslužuju da se

mere u pogledu karakteristika kvaliteta usluga.

Servis poštovanja i upravljanja rizicima obuhvata sve poslove u vezi sa zahtevom za

projektovanje, isporuku i potrošnju usluga nije vodjen samo performansama ciljeva ali takodje

ima u skladu sa zakonskim zahtevima i dalja ograničenja. Kao takva, relevantna ograničenja

moraju da budu identifikovana i upravljanje servisima treba da se procenjuje u skladu sa

definisanim zahtevima. Posebni izazovi korišćenja upravljanja saglasnostima su skalabilnost i

heterogenost koji proizilaze iz potencijalno globalnih pružanja usluga.

Upravljanje servisom relacija

Upravljanje poslovnim servisom u većini slučajeva nije čisto unutrašnje upravljenje disciplinama

ali se oslanja na efikasnost odnosa sa spoljim partnerima, uglavnom kupcima i dobavljačima

(slika 5). Bitno je kada su organizacije struktuirane kao uslužne jedinice potrošnje i pružanja

servisa od drugog, takodje se odnosi na upravljanje odnosima sa kupcima i dobavljačima.

Upravljanje servisom dobavljača obuhvata sve poslove dobavljača koji se odnose na

provajdere usluga. Dok će operacione aktivnosti biti pokrivene u velikoj meri kao deo službe

upravljanja životnim ciklusom, upravljanje servisom dobavljača uglavnom će se baviti

strateškim pitanjima kao što su strateška partnerstva i pravljenje ili kupovina odluka. postoji jaka

veza izmedju upravljanja servisom životnog ciklusa i servisom kupovine.

Upravljanje korisničkim servisom je odgovarajuća aktivnost na strani tražnje.

Slika 28 - Uspostavljanje servisa

Efektivno upravljanje životnim ciklusom servisa je zavisno od tri sledeće discipline:


V01.2012 strana 89

Upravljanje servisom kvaliteta posvećen je pouzdanoj definiciji perceptualnog ili

sadašnjegservisa kvaliteta (pogledati SERVQUAL). Zasnovan na spoljašnim i unutrašnjim

potrebama kvaliteta, odgovarajuće definicije kvaliteta moraju da budu izvedene i njihov značaj

mora biti potvrdjen uključujući servise potrošača. Shodno tome Service quality management

zahteva sposobnost da prevede zahteve u metriku kvaliteta. Ove metrike moraju da budu

redovno merene, ocenjivane. Postoji jaka veza sa Service Innovation Managemet i service

Analysis ind Design kao uslugom kvaliteta koja zahteva reviziju

Upravljanje servisom glavnih podataka je posvećen upravljanju opisa usluga u vidu usluga

master zapisa koji se pravilno čuvaju u bazi podataka kao i sva organizaciona sredstva. Atributi

servisa glavnih zapisa moraju da pokrivaju širok spektar poslovnih i tehničkih kriterijuma a

može biti grupisan u grupe atributa. U odsustvu široko prihvaćenog standarda za specifikaciju

usluga, mnoge organizacije su trenutno su razvile njihove lični servise za opis framework-a.

Referentna tačka za takav opis servisa je obezbedjen od Universal Service Description

Language (USDL). Ukratko, Service Master Data Management se bavi svim zahtevima podataka

kroz ceo ciklus servisa.

Upravljanje tehnološkim servisima snima sve zahteve softverski uspešnog Business Service

Management. Ovo uključuje tehnološke zahteve kao što su standardizacija ili interfejs za

upravljanje uslugama, odnosno rešavanja pitanja interoperabilnosti. Service Technology

Management zahteva stalnu procenu relevantnog tržišta razvoja i evaluacije usluga i usvajanje

standarda. Kao takav Service Technology Management obezbeđuje tehničke mogućnosti koje su

potrebne za uspešno izvršenje Service Lifecycle Management

Upravljane poslovnim servisom je jak motiv za uspostavljanje zrele menadžment discipline u

vezi sa uslugama kao korporativne imovine kako bi se obezbedilo da tržišni potencijal i

tehnološke mogućnosti servisno usmerenog pristupa budu pretvorena u ekonomski održiv uspeh.


V01.2012 strana 90

Sveobuhvatnost Business Service Management Framework jasno artikuliše obim aktivnosti koje

treba da budu adresirane. Predloženi Business Service Management Framework može pružiti

referencu modela za razvoj mogućnosti iskorišćenja zajedničkog odnosa izmedju biznis

usmerenog i više tehnički usmerenog koncepta usluga. Predloženi okvir ima potencijal da vodi

identifikaciju onih disciplina koje treba rešiti za sholističku i sveobuhvatnu uslugu upravljanja.

Trenutni i budući rad na projektu Business Service Management će biti posvećen razvoju

detaljnih i empirijski potvrđenih metodologija, alata i tehnika za odabrane discipline unutar ovog

okvira.


V01.2012 strana 91

9 Literatura

[1.] HP, ITIL Service Manager for Service Delivery, student guide, Hewlett Packard, 2007

[2.] HP, ITIL Service Manager for Service Support, student guide, Hewlett Packard, 2007

[3.] HP, ITIL V3, student guide, Hewlett Packard, 2007

[4.] Klosterboer L., ITIL Capacity Management, IBM Press, Boston, 2011.

[5.] OGC, Service Design, The Stationery Office, London, 2007.

[6.] OGC, The Official Intorduction to the ITIL Service Lifecycle, The Stationery Office,

London, 2007.

[7.] Rene Bakker, Hauke Botcher, OTRS::ITSM 2.0 – Basic, OTRS AG, 2009.

[8.] Rene Bakker, Stefan Bedorf, Michiel Beijen, OTRS 3.0 – Admin Manual, OTRS AG,

2011.

[9.] Rob Addy, The Effective IT Service Management, Springer, New York, 2010.

[10.] Ryan R., Raducha-Grace T., The Business of IT: How to Improve Service and Lower

Cost, IBM, Boston, 2010.

[11.] The Art of Service, Exam Prep Study Guide: ITIL v3 Foundation, Brisbane, Australia

[12.] The Art of Service, How to Develop, Implement and Enforce ITIL V3 Best Practices,

Brisbane, 2008.


V01.2012 strana 92


V01.2012 strana 93

10 Dodatak

10.1 Slike

Slika 1 - Područja pokrivena sa ITIL V3 [The art of Service – The Exam Preparation Book,

2007. str.13] ................................................................................................................ 25

Slika 2 - Životni ciklus usluge prema ITIL konceptu [OGC, The Official Intorduction to the

ITIL Service Lifecycle, 2007, str. 19] ........................................................................ 26

Slika 3 - Petlja povratnih veza [OCG, The Official Intorduction to the ITIL Service Lifecycle,

2007, str. 21] ............................................................................................................... 27

Slika 4 - Model kontinuiranog unapređenja usluge [OGC, The Official Intorduction to the

ITIL Service Lifecycle, 2007, str. 125] ...................................................................... 29

Slika 5 - Pozicija Dizajna IT usluga u čitavom modelu unapređenja usluge [OGC, The

Official Intorduction to the ITIL Service Lifecycle, 2007, str. 125] ......................... 30

Slika 6 - 4P faktori .................................................................................................................... 32

Slika 7 - Elementi poslovnog i tehničkog kataloga uslug ......... Error! Bookmark not defined.

Slika 8 - Elementi kataloga servisa [OGC, The Official Intorduction to the ITIL Service

Lifecycle, 2007, str. 51] .............................................................................................. 34

Slika 9 - Upravljanje nivoama usluga [OGC, Service Design, 2007, str. 62] .......................... 35

Slika 10 - Proces upravljanja nivoima usluga [OGC, Service Design, 2007, str. 68] ................ 39

Slika 11 - Višerazinski SLA [OGC, Service Design, 2007, str. 69] ........................................... 40

Slika 12 - Proces upravljanja kapacitetima [OGC, Service Design, 2007, str. 82] .................... 51

Slika 13 - Odnos između nivoa raspoloživosti i ukupnih troškova [OGC, The Official

Intorduction to the ITIL Service Lifecycle, 2007, str. 62] ......................................... 52

Slika 14 - Proces upravljanja raspoloživošću [OGC, The Official Intorduction to the ITIL

Service Lifecycle, 2007, str. 62] ................................................................................. 53

Slika 15 - Ciklus upravljanja kontinuitetom [OGC, The Official Intorduction to the ITIL

Service Lifecycle, 2007, str. 66] ................................................................................. 54

Slika 16 - Ciklus upravljanja raspoloživošću [OGC, The Official Intorduction to the ITIL Service

Lifecycle, 2007, str. 69] .............................................................................................. 55

Slika 17- Internacionalni standard ISO/IEC 20000-1 ................................................................ 67

Slika 18 - Internacionalni standard ISO/IEC 20000-2 ................................................................ 73

Slika 19 - Veza između ITIL i ISO 20000 .................................................................................. 74

Slika 20 - ISO/IEC 20000 ček lista ............................................................................................. 75

Slika 21 - Izgled Sertifikata ........................................................................................................ 77

Slika 22 - Gde spada ISO / IEC 20000? ..................................................................................... 79

Slika 23 - Veze između standarda ............................................................................................... 79

Slika 24 - Primeri podešavanja opsega ....................................................................................... 82

Slika 25 - Gde spada ISO/IEC 20000-3 ...................................................................................... 83


V01.2012 strana 94

Slika 26 - Koordinacija: veliki potencijal i pregled .................................................................... 85

Slika 27 - Menadžment servisa ................................................................................................... 86

Slika 28 - Uspostavljanje servisa ................................................................................................ 88

10.2 Tabele

10.3 No table of figures entries found.Grafovi

No table of figures entries found.

ANEX 1. Računarske mreže - osnovni pojmovi

ANEX 1. Računarske mreže - osnovni pojmovi ...................................................................................... 1

1 Podsećanje: Računarske mreže .......................................................................................................... 1

1.1 Uvod ........................................................................................................................................... 2

1.1. Vrste mreža................................................................................................................................. 3

1.1.1 Prema površini na kojoj se nalaze računari u mreži, mreže se dele na: .............................. 3

1.1.2 Po arhitekturi (funkcionalnom odnosu članova mreže) računarske mreže mogu biti: ....... 4

1.2 Topologija mreže ........................................................................................................................ 4

1.2.1 Bus Topology – topologija magistrale ................................................................................. 5

1.2.2 Star Network Topology – topologija zvezde ...................................................................... 6

1.2.3 Ring network – topologija prstena ...................................................................................... 7

1.2.4 Hibridna topologija ............................................................................................................. 7

1.2.5 Bežična topologija............................................................................................................... 8

1.3 Komunikacija u mreži (protokoli) .............................................................................................. 9

1.3.1 Drugi sloj po OSI modelu - Data Link (sloj podataka) ..................................................... 12

1.4 Mrežni hardver ......................................................................................................................... 13

1.5 Mrežni softver .......................................................................................................................... 19

1.6 Različiti aspekti zaštite računarskih mreža .............................................................................. 21

1.6.1 Zaštita router-a .................................................................................................................. 21

1.6.2 Zaštita switch-eva ............................................................................................................. 22

1.6.3 Zaštita mreže korišćenjem firewall-a ................................................................................ 22

1.6.4 Zaštita mreže uvođenjem demilitarizovane zone (DMZ) ................................................. 23

1.7 Administracija mreze ............................................................................................................... 24

1 Podsećanje: Računarske mreže

Osnovni pojmovi

OSI model

Uređaji računarske mreže

Mrežni softver

Principi zaštite

2

1.1 Uvod

Računarska mreža (computer network, ili samo network) je skup međusobno povezanih računara,

perifernih uređaja i drugih resursa. Svaki uređaj koji komunicira sa drugim uređajima u mreži, naziva

se mrežni host. Svaki host, u principu, mora biti opremljen mrežnim adapterom (karticom) kao

hardverskom komponentom koja mu omogućava rad u mreži, kao i odgovarajućim mrežnim

operativnim sistemom.

Razlozi naglog širenja i primene računarskih mreža su izuzetno brojni i apsolutno opravdavaju

orijentaciju i pojedinačnih korisnika i preduzeća na razvoj ovog koncepta. Najvažnije prednosti

mrežnog rada su:

bolje iskorišćenje postojećih računarskih resursa (štampača, skenera, diskova, modema, ..),

pristup i deljenje informacija u skladu sa savremenim konceptima njihove distribucije,

mogućnosti jeftinije nabavke licenciranog softvera (vreme piratskog kopiranja i korišćenja

softvera bespovratno prolazi, na sceni je međunarodno kompjutersko i informaciono pravo),

znatno veća efikasnost rada u mreži.

Svaki računar ili drugi uređaj priključen u mrežu, naziva se čvor.

Kao primer, na slici Slika 1 je prikazana jedna računarska mreža sa relativno jednostavnom

arhitekturom:

Slika 1 Primer računarske mreže

Ova računarska mreža povezuje tri računara označenih kao host A, host B i host C, za svaki od

njih je povezana neka periferija a odgovarajućim interfejsima oni su povezani u jedinstveno mrežno

okruženje.

Tri vrste servisa je vrlo lako ostvariti u ovakvom okruženju i to:

virtuelne terminalske sesije,

3

prenos podataka i

razmenu elektronske poste.

Ova tri servisa imaju poseban značaj u razvoju računarskih mreža jer su prve mreže projektovane

upravo sa ciljem njihovog obezbeđivanja.

1.1. Vrste mreža

Računarske mreže se mogu podeliti na razne načine, u zavisnosti od toga da li se posmatra:

površina koju pokriva mreža,

način povezivanja računara u mreži (topologiji),

način komunikacije računara u mreži (logističkoj organizaciji),

odnos među čvorovima u mreži.

1.1.1 Prema površini na kojoj se nalaze računari u mreži, mreže se dele na:

PAN mreže (Personal Area Network)

LAN mreže, koje pokrivaju ograničena (uža) geografska područja (obično nekoliko kilometara),

MAN mreže, (Metropolitan Area Network), koje pokrivaju gradska područja. Ovu mrežu čine

računari iz različitih zgrada u velikoj gradskoj oblasti, prečnika od 5 do 50 km.

WAN mreže (Wide Area Network), koje pokrivaju šira geografska područja.

Internet (Global Network).

Računari su u komunikacionim mrežama hardverski povezani (različitim vrstama kablova ili

bežično) tako da je zbog otpora u provodnicima brzina prenosa podataka obrnuto proporcionalna

udaljenosti između računara (ukupnoj dužini mrežnog kabla). Tako se u lokalnoj računarskoj mreži

podaci prenose brzinom od oko 100 megabita u sekundi, dok je u WAN mreži brzina transfera

nekoliko megabita u sekundi ili manje (interkontinentalne mreže).

Mreže lokalnog tipa imaju vrlo jednostavnu strukturu i koriste mali broj različite hardverske

opreme. Pre svega, ove mreže se odlikuju time da povezuju računare sa užeg prostornog područja.

Takve su na primer mreže u okviru jedne zgrade. Poznate su pod imenom LAN (Local Area Networks)

a na sledećoj slici je prikazana jednostavna mreža ovog tipa.

Za razliku od lokalnih mreža, WAN (Wide Area Networks) povezuju računare sa šireg

prostornog područja. Obično se sastoje od više podmreža tipa LAN koje su integrisane u jedinstvenu

celinu. Takve su, na primer, mreže na nivou gradova ili nacionalne računarske mreže. S obzirom da

rastojanje između pojedinih podmreža može biti značajno veliko, mreže tipa WAN za vezu sa

udaljenim računarima obično koriste javne komunikacione linje (PTT, x.25, ISDN, Frame Relay). Na

sledeđoj slici je prikazan primer jedne ovakve mreže. Lokalne mreže su i ovde povezane routerima.

4

Slika 2 WAN

1.1.2 Po arhitekturi (funkcionalnom odnosu članova mreže) računarske mreže mogu

biti:

Klijent-server što podrazumeva dve vrste čvorova – klijente i servere. Klijent je računar koji

koristi resurse mreže, server koji ima resurse i stavlja ih na raspolaganje klijentima (Serveri

datoteka i serveri za štampanje, Server baze podataka, Serveri aplikacija, Serveri elektronske

pošte, Faks serveri i komunikacioni serveri, Audio i video serveri, Serveri za ćaskanje, FTP

serveri, Serveri za diskusione grupe, Serveri mrežnih prolaza, Web serveri).

Peer-to-peer (P2P) gde su svi čvorovi ravnopravni. Svaki računar funkcioniše i kao server i kao

klijent. To znači da svaki računar u ovoj mreži može da koristi resurse drugih računara, kao i da

koristi svoje resurse zajednički s drugim računarima. Međutim, ova mreža može i da se

konfiguriše da neki računari samo dele svoje resurse s drugim računarima, dok drugi samo

koriste resurse drugih računara. Ipak, čak i u ovakvoj situaciji mreža ostaje ravnopravna, jer se

svaki računar u mreži individualno administrira.

1.2 Topologija mreže

Topologija mreže je način uređenja računara, kablova i ostalih komponenata u okviru mreže.

Nastaje geometrijskim uređenjem veza i čvorova koji čine mrežu. Veza (linija, kanal) je

komunikacioni put između dva čvora. Čvor se u topologiji definiše kao krajnja tačka neke grane mreže

ili kao zajednički priključak na dve ili više grana u mreži. Hardver i softver svakog čvora određeni su

funkcijama i učešćem tog čvora u mreži. Čvorovi međusobno komuniciraju na osnovu nekih fizičkih i

logičkih veza.

Fizičku vezu čini neki komunikacioni medijum (najčešće kabl). Logička veza znači da dva čvora mogu

da komuniciraju bez obzira da li među njima postoji fizička veza.

Topologija moze da bude i fizička i logička:

Fizička topologija opisuje kako su fizičke komponente mreze spojene,

Logička topologija opisuje način protoka podataka kroz mrežu.

5

Mreže se mogu podeliti u 2 osnovne grupe:

1) Mreže od tačke do tačke i

2) Difuzne mreže.

1) Mreže od tačke do tačke omogućavaju najveću pouzdanost zbog toga što daju izbor jednog od

više raznih puteva za prenos podataka iz jednog čvora u drugi.

U okviru ove grupe postoje 2 vrste topologija:

topologija sa potpunim povezivanjem i

topologija sa nepotpunim povezivanjem (mesh networks).

2) Osnovna karakteristika difuznih mreža je da postoji samo jedan komunikacioni put koji koriste

svi računari u mreži. Problem je u pristupu mediju – kojoj stanici dozvoliti da emituje kada više

stanica želi da šalje podatke.

Osnovne difuzne topologije su:

Sabirnička mreža (Bus Topology),

Zvezdasta mreža (Star Network Topology),

Prstenasta mreža (Ring Topology).

U praksi se često sreću hibridne mreže nastale kombinacijom 2 ili više topologija (npr. Star-bus

network).

1.2.1 Bus Topology – topologija magistrale

Računari su povezani preko zajedničke magistrale koja predstavlja glavni vod. Magistrala je

jedinstveni komunikacioni kanal kojim se obavlja saobraćaj i zajednički je svim čvorovima.

Ova topologija se smatra pasivnom jer računari povezani na magistralu samo osluškuju šta se

dešava na njoj. Kad posredstvom mrežne kartice primete da su podaci na magistrali upućeni njima,

prihvataju ih. Kad je računar spreman za predaju podataka, on se prvo uveri da ni jedan računar ne

šalje podatke na magistralu, pa tek onda šalje svoje podatke u paketu informacija. Kod ovog tipa

topologije najčešće se koriste kablovi sa T-konektorom.

6

Slika 3 Bus Topology

Prednosti:

Lako se realizuje i proširuje,

Jeftine.

Mane:

Teško se održavaju.

Ako se javi problem na magistrali cela mreža pada.

Performanse mreže opadaju dodavanjem novih računara. Novi računar opterećuje magistralu

preko koje se odvija komunikacija.

Niska sigurnost (svi računari na magistrali vide sve podatke koji se prenose)

Ako jedan računar u mreži otkaže to se reflektuje na celu mrežu, cela mreža pada.

Ako je mnogo računara zakačeno na istu magistralu performanse mreže padaju.

1.2.2 Star Network Topology – topologija zvezde

Topologija zvezde koristi centralni uređaj za povezivanje, koji se zove razvodnik (ranije hub ili

repeater, danas uglavnom switch). Lako se dodaje novi čvor ali otkaz razvodnika znači otkaz cele

mreže. Svaki računar je sa zasebnim kablom povezan na razvodnik. Koristi se kabl sa upredenim

paricama. Razvodnik propušta sve signale koji ulaze kroz jedan priključak, na sve ostale priključke

(hub ili repeater,) a switch logički razvrstava saobraćaj..

Takođe, ako jedan računar otkaže, ostali računari bez obzira na to, nastavljaju da komuniciraju

među sobom. Najosetljivija tačka ove topologije je centralni razvodnik i ako se on pokvari, prekida se

cela mreža.

Slika 4 Star Network Topology

7

1.2.3 Ring network – topologija prstena

Svaki čvor je povezan sa 2 druga čvora. Svaki čvor mora biti u mogućnosti da primi i pošalje

poruku. Prenos se vrši uvek u jednom smeru. Poruke, najčešće, idu samo u jednom smeru da se ne bi

sudarile.

Ova topologija liči na topologiju magistrale, jer je svaki računar povezan sa susednim. Razlika

je što su krajevi spojeni i čine prsten. Signali putuju u krug, od računara do računara. Ako dođe do

prekida jednog linka cela mreža ispada iz rada. Token ring koriste posebnu vrstu razvodnika, koja se

zove pristupna jedinica za više stanica. Ova stanica prima sve ulazne signale kroz jedan priključak i

prosleđuje ih na ostale priključke.

Slika 5 Ring network

Prednost mreže je manja kompleksnost, pošto su putevi poruka određeni konfiguracijom mreže,

tj. poruka automatski putuje do sledećeg čvora u mreži.

Nedostaci su teško dodavanje novih čvorova (prilikom dodavanja novog čvora koji mora da bude

povezan s dva susedna čvora, neophodno je da se prekine rad mreže), kvar na svakom čvoru, aktivnoj

komponenti ili bilo koji drugi prekid konfiguracije prstena uvek dovodi do prekida rada cele mreže.

1.2.4 Hibridna topologija

Na ovaj način se proširuje lokalna mreža koja ima topologiju zvezde. Svi računari lokalne mreže

mogu da komuniciraju. Mreža je nespecifična i njen oblik može u velikoj meri da varira od jedne do

druge konfiguracije. Kod ove topologije, osim veza karakterističnih za druge topologije, postoje i

dodatne veze među nekim čvorovima.

8

Slika 6 Hibridna topologija

Ove dodatne veze su obično determinisane ekonomskim razlozima. Danas se koristi u lokalnim

mrežama, kod nas, najčešće kombinacija topologije magistrale i zvezdaste topologije. Kod ove

kombinacije, čvorovi koji su direktno vezani na magistralu (kičmu) koriste se kao zvezdišta (centralni

čvorovi), na koja se vezuju drugi čvorovi prema topologiji zvezde.

1.2.5 Bežična topologija

Početkom dvadesetog veka Nikola Tesla je demonstrirao princip bežične komunikacije između

broda i obale, koristeći Morzeovu azbuku. Performansa kod savremenih digitalnih bežičnih sistema je

bolja, ali je osnovna ideja ostala ista.

Bežične mreže mogu se podeliti u tri grupe:

Mreže za povezivanje sistema

Bežične lokalne mreže

Bežične regionalne mreže

Postoje dva stanja u kojima bežična mreža može da radi:

BSS - Base Service Set ili infrastructure i

IBSS - Independent Base Service Set odnosno ad-hoc ili peer-to-peer.

Ad-hoc ili peer-to-peer bežična mreža sastoji se od manjeg ili većeg broja računara opremljenih

bežičnom opremom. Svaki računar komunicira sa drugim direktno, bez posrednika tj. bez dela

hardvera koji se zove AP - Access Point (pristupna tačka). Ukoliko je neki od računara deo neke mreže

(LAN-a), svi ostali neće moći koristiti resurse LAN-a osim ako taj računar ne predstavlja "bridge" ka

LAN-u koristeći sprecijalizovani softver (ovo se naziva "bridging").

9

Slika 7 Bežična topologija

Infrastructura bežične mreže koristi jedan ili više AP-ova odnosno baznih stanica, koji posreduju

izmedju računara međusobno ili računara i LAN-a. Znači svaki od bežičnih klijenata spaja se na neki

od AP-ova, u čijem je dometu, preko koga međusobno komuniciraju. Tako postavljanjem AP-a na

neko istaknuto mjesto omogućava se pristup većem broju klijenata koji nemaju optičku vidljivost

između sebe. Ovaj način je veoma popularan, i mnoge Wireless zajednice realizovane su na ovaj način.

1.3 Komunikacija u mreži (protokoli)

Svaka mreža sadrži različite uredjaje. Velike mreže sadrže obično veliki broj računara i drugih

uredja ja različitih proizvođača, koji rade s različitim programima i operativnim sistemima. Da bi se

ostvarila uspešna komunikacija ovih uredjaja i mreže svi elementi mreže moraju da se koriste nekim

zajedničkim skupom pravila (''da govore istim jezikom''). Drugim rečima, mreže zahtevaju standarde

za komunikaciju:

standardne protokole i interfejse koji će obezbediti zajedničke mehanizme za komunikaciju

među različitim sistemima,

standardni pristup projektovanju mreže – mrežnu arhitekturu, što definiše relacije i interakcije

medju servisima mreže i funkcijama preko zajedničkih interfejsa i protokola.

ISO/OSI referentni model Međunarodna organizacija za standarde (International Standards

Organization – ISO) sagledala je važnosti i potrebu univerzalnosti u razmeni informacija među

mrežama i unutar njih, kao i među geografskim područjima, i 1978. godine donela

preporuku kojom se omogućava lakše projektovanje mreža. Ova preporuka je široko prihvaćena. Njom

se definiše model mrežne arhitekture sa sedam slojeva poznat kao referentni model za otvorenu

međusobnu komunikaciju (Open Systems Interconnection). Ovim modelom se u mrežnoj arhitekturi

specifira hijerarhija nezavisnih nivoa, koji sadrže module koji izvode definisane funkcije. Arhitektura

10

specifira funkciju modula i veze među njima. Time se u zajednički skup pravila prevodi način na koji

mrežni čvorovi moraju da

komuniciraju i razmenjuju informacije.

Arhitektura definiše sledeće relacije medju funkcionalnim modulima:

interfejse – relacije među različitim modulima koji obično operišu unutar mrežnog čvora.

Tipično je da se modul jednog nivoa povezuje s modulom u nivou ispod njega da bi primio

uslugu. Interfejs se nalazi između svaka dva susedna sloja i određuje osnovne operacije i usluge

koje donji sloj nudi gornjem;

Protokol (protocol) predstavlja dogovor između dve jedinke o tome kako treba da teče njihova

komunikacija. Sloj n na jednom računaru komunicira sa slojem n na drugom po određenim

pravilima tj. protokolima. Jedan sloj nikada direktno ne prenosi podatke drugom računaru, već se

radi prosledjivanje do najnižeg sloja. Protokol je skup pravila o formatu i značenju paketa ili

poruka koji se razmenjuju između procesa istog sloja. Proces može da menja protokole.

Usluge (service) je skup osnovnih operacija koje sloj obezbeđuje sloju iznad sebe. One se

odnose na interfejse između slojeva.

Slika 8 Odnos između usluge i protokola

Network architecture predstavlja skup slojeva i protokola. Realizator mora da ima dovoljno

informacija kako bi mogao da napiše program koji će slediti pravila odgovarajućeg protokola.

U ISO/OSI modelu ima sedam slojeva. Svaki sloj izvršava neke funkcije ili usluge, potrebne nivou

(sloju) koji je iznad njega. Viši slojevi su rasterećeni funkcija koje obavljaju slojevi na nižem nivou.

U mreže može biti povezan veliki broj različitih računara. Da bi se omogućila komunikacija

neophodno je da svi računari prepoznaju podatke koje primaju od drugih računara. Zato se uvode

standardi kojima se definišu pravila kako se formatiraju i prepoznaju podaci tokom komunikacije. Ovi

standardi se zovu protokoli.

U svetu postoji više organizacija koje se bave donošenjem ovakvih standarda.

Najvažniji su sledeći:

Udruženje inženjera elektrotehnike i elektronike (IEEE - Institute of Electrical and Electronics

Engineers),

Udruženje elektronske industrije (EIA – Electronic Industries Association),

11

Međunarodni savetodavni komitet za telefoniju i telegrafiju (CCITT - International Consultive

Committee on Telephone and Telegraph) i

Međunarodna organizacija za standarde (ISO - International Standards Organization).

Podaci koji se prenose kroz mrežu organizuju se u strogo definisane celine koje zovemo

paketima. U nekim mrežama (npr. Ethernetu) ovakvi paketi se zovu datagrami (datagram). U

standardu se propisuje izgled paketa. Obično paket ima sledeću strukturu:

identifikator paketa,

adresa odredišta (primaoca),

adresa izvora (pošiljaoca),

definisanje tipa podataka,

polje podataka,

provera ispravnosti podataka.

Identifikator paketa omogućava razlikovanje paketa. Kada se prenose velike količine podataka

organizuje se veći broj paketa. Adresa primaoca i pošiljaoca ima svrhu kao i u svakoj drugoj

komunikaciji. Definisanje tipa podataka ukazuje na vrstu podataka u polju karaktera (npr. ASCII

karakteri ili binarni sadržaji). Polje podataka sadrži podatke koji se prenose. Ovo polje može imati

različitu dužinu u različitim standardima. Najčešće dužina ovog polja iznosi od nekoliko bajtova do

nekoliko hiljada bajtova. Polje za proveru ispravnosti služi za proveru ispravnosti prenosa u mestu

prijema. Za ovo se mogu koristiti različiti metodi.

U prenosu podataka postoje različiti problemi. Jedan problem je organizacija podataka u paket i

fizički prenos paketa. Drugi problem može biti pouzdanost prenosa itd.

Po ISO standardu svi problemi prenosa podataka u računarskim mrežama razvrstavaju se u sedam OSI

nivoa:

Fizički nivo (Physical layer) odgovoran je za prenos binarnih sardžaja kroz komunikacioni kanal.

Podatkovni nivo (Data link layer) raspoznaje podatke i kontrolne signale i oslobađa ih

eventualnih grešaka pri prenosu.

Mrežni nivo (Network layer) odnosi se na izbor puteva pri prenosu paketa sa podacima.

Transportni nivo (Transport layer) obezbenuje deljenje složenih poruka u manje jedinice koje

predstavljaju pakete podataka u mrežnom nivou.

Sesioni nivo (Session layer) upravlja razmenom između pojedinih čvorova. Ako se veza izgubi

pokušava da je uspostavi bez intervencije korisnika.

Prezentacioni nivo (Presentation layer) priprema različite načine prezentacije podataka na

sesionom nivou u smislu kompresije i šifriranja.

Aplikacioni nivo (Application layer) omogućuje korisničkom programu generisanje podataka za

razmenu. Svi drugi nivoi moraju biti podređeni ovom nivou.

12

Mnogi postojeći standardi se odnose samo na neke od navedenih nivoa. Međutim, svaki nivo

koji postoji na mestu pošiljaoca mora postojati i na mestu prijema.

Slika 9 Sedam nivoa OSI – standarda

Za korisnike mreža je najznačajniji aplikacioni nivo. Na tom nivou se organizuju različiti aspekti

rada korisnika u mreži, kao što su elektronska pošta, prenos podataka, pretraživanje datoteka.

1.3.1 Drugi sloj po OSI modelu - Data Link (sloj podataka)

Protokoli sloja veze podataka omogućavaju vezu između fizičkog uređaja i skupa protokola na

računaru. Sastoji se od tri elementa:

format okvira,

mehanizam koji reguliše pristup deljenim resursuma mreže i

specifikacije fizičkog sloja mreže.

Logička organizacija mreže

Eternet (Ethernet) tehnika namenjena je za kontrolu saobraćaja u topologiji magistrale i zvezde.

U ovim mrežama, kao i kod prstena sa žetonom, u svakom trenutku komunikacioni kanal može da

koristi samo jedan čvor. Komunikacioni linija ima specijalni signal, zvani nosilac (carrier), koji je

prisutan na liniji i kada nema prenosa podataka. Čvor koji želi da pošalje podatke osluškuje da li je

linija slobodna i ako jeste, šalje paket. Može da se dogodi, zbog vremena potrebnog da signal putuje

kroz mrežu,da dva čvora ustanove da je magistrala slobodna u isto (ili približno isto) vreme i da oba

pošalju svoje pakete. U takvom slučaju dolazi do sudara dve poruke (kolizija). Kada čvorovi detektuju

sudar, prekidaju postupak slanja poruke i ponavljaju sve od početka. Što je na mreži manji broj sudara,

to je mreža efikasnija.

13

Prsten sa žetonom (token ring) je protokol sloja veze podataka. Ovo je najčešće način

upravljanja komunikacijom kod prstenaste topologije mreže, a koristi se i kod magistralnih topologija.

Žeton (token) je mehanizam kojim se kontrolišu redosled i pravo računara da koriste komunikacioni

kanal.

Žeton je specijalni niz bitova koji cirkuliše u prstenu od čvora do čvora kada nema prenosa

poruka. Posedovanje žetona omogućava računaru koji ga poseduje ekskluzivni pristup mreži za

prenošenje njegovih poruka, čime se izbegava mogućnost konflikta poruka različitih računara. Čvor

koji želi da pošalje poruku zadržava žeton i šalje poruku. Čvorovi u mreži proveravaju poruku kada ih

ona prolazi. Oni su odgovorni za prihvatanje paketa koji je upućen njima, odnosno za proslenivanje

paketa upućenih drugim čvorovima. Paket obično mora da obine ceo krug dok se ne vrati do pošiljaoca

s potvrdom prijema od prijemnog čvora. Kada čvor završi slanje poruke, on mora da vrati žeton nazad

u cirkulaciju, čime označava završetak operacije i daje drugim čvorovima priliku da koriste kanal. Isti

čvor ne može da pošalje uzastopce dve poruke da bi se sprečilo zauzimanje kanala od strane jednog

korisnika. Ako čvor ne želi da šalje poruku, kada žeton dođe do njega on ga prosleđuje sledećem čvoru

u prstenu.

1.4 Mrežni hardver

Repetitori (repeater) su uređaji koji omogućavaju prenošenje signala na veće daljine. Signali

podležu pogoršanju i izobličavanju, dok putuju kroz kabl. Ovaj efekat se naziva slabljenje

(attenuation). Kada je kabl predugačak, signal se toliko izobliči da dolazi do grešaka u prenosu

podataka kroz mrežu. Uloga repetitora je da kada se postavi nasred dugačkih kablova obnavlja signal i

prosleđuje ga dalje.

Repetitori su obični pojačivači signala koji se prevode, niti filtriraju mrežne signale iz jednog

kabla u drugi, već samo pojačavaju signal koji dobiju na svom ulazu. Oba kabla koja su spojena

repetitorom moraju imati isti okvir, logički protokol i metode pristupa.

14

Slika 10 Reapeater

Repetitori spadaju u tzv. glupe uređaje, jer nemaju složenu logiku. Oni samo prosleđuju podatke,

nemaju sposobnost filtriranja i na mestima gde se očekuje intenzivan mrežni saobraćaj treba ih

izbegavati.

Razvodnik (hub) je centralni uređaj za povezivanje računara u zvezdanu topologiju. Razvodnik

je i uređaj koji se koristi za pristup većem broju radnih stanica (Multistation Access Unit, MAU). Oni

se dele na pasivne i na aktivne:

Pasivni razvodnici ne obrađuje podatke - on je obična razvodna kutija.

Aktivni razvodnici obavljaju signal podataka i održavaju potrebnu snagu signala.

Slika 11 HUB sistem

Sistemi sa razvodnicima su prilagodljivi i imaju određene prednosti nad sistemom bez razvodnika.

Razvodnici imaju ulogu kao i repetitori, tj. obnavljaju i prosleđuju signale na isti način. Oni obično

imaju od 8 do 12 priključaka i tada ih nazivaju repetitori s više priključaka (multiport repeaters). Da bi

aktivni razvodnici raditi potrebno je i električno napajanje. Hibridni razvodnici podržavaju više vrsta

kablova.

15

Mrežni mostovi (bridge) se postavljaju kod opterećenih mreža. Oni imaju ulogu repetitora, koji

produžava efektivan domet mrežnog kabla i može da izdeli mrežu da bi izolovao zagušeni deo mreže.

Nedostatak je što nemaju sposobnost razlikovanja protokola, odnosno prosleđuju sve protokole kroz

mrežu.

Karakteristike mrežnih mostova:

Usmeravanje podataka - mrežni mostovi proveravaju izvornu, odredišnu adresu i formiraju

tabele usmeravanja, da bi mogli da prosleđuju podatke odgovarajućim delovima mreže. Oni

imaju sposobnost učenja kako treba prosleđivati podatke.

Smanjenje opterećenja mreže - Upotrebom mrežnih mostova za ''parcelisanje'' velikih mreža u

više manjih segmenata, moguće je smanjiti gužvu u mrežnom saobraćaju, čime se poboljšavaju

ukupne performanse mreže.

Daljinske veze - Mrežni mostovi se koriste za spajanje manjih, međusobno vrlo udaljenih mreža.

Dve zasebne lokalne mreže koje su udaljene jedna od druge, mogu se povezati u jednu mrežu

korišćenjem dva udaljena mrežna mosta. Oni se povezuju pomoću sinhronih modema preko

iznajmljene telefonske linije.

Preklopnici (switch) su uređaji koji se koriste za spajanje više računara u jednu centralnu tačku.

Ako računari i mrežni uređaji predstavljaju vrhove zvezde, preklopnik predstavlja njenu sredinu.

Preklopnici su uređaji koji mrežu segmentiraju na drugom sloju OSI/ISO 7-segmentnog modela. Uloga

preklopnika je, zapravo, stvaranje posebnog segmenta za svaki par uređaja koji međusobno komunicira.

Usmerivač (router) je uređaj koji zna adrese svakog segmenta, vrši izbor najbolje putanje za

slanje, filtriranje i usmeravanje podataka ka odgovarajućim segmentima. Primenjuje se kod složenih

mreža gde mrežni mostovi ne mogu da daju efikasne rezultate.

Statičko usmeravanje je ručno usmeravanje, jer administrator mreže ručno podešava putanju.Tabele

usmeravanja su fiksne, tako da se koristi uvek ista putanja.

Dinamički usmerivači se inicijalno podešavaju, ali se posle prilagođavaju promenama stanja mreže. Za

putanju koriste one koje su jeftinije, raspoložive i manje opterećene.

Slika 12 Router

16

Mostovi usmerivači (b-ruter) mogu da se ponašaju za jedan protokol kao usmerivač, a za drugi

kao mrežni most. U određenim situacijama, upotreba ovog uređaja može biti efikasnija i jeftinija, u

odnosu na dva posebna uređaja. S napretkom tehnologije gubi se funkcionalna razlika između mrežnih

mostova i usmerivača.

Mrežni prolaz (gateway) je namenjem za povezivanje dijametralno različitih mreža. On

omogućava složene radnje, iako je sporiji od usmerivača i mrežnog mosta. Posrednik je između mreža

koje pričaju različitim jezicima. Pored toga što omogućavaju komunikaciju između različitih okruženja,

oni prepakuju i pretvaraju podatke koji se razmenjuju između različitih mreža. Svaka mreža može da

razume podatke koje je dobila. Mrežni prolazi su namenski, predviđeni za određenu vrstu prenosa.

Često nose naziv zadatka koji obavljaju ('' Mrežni prolaz Windows NT Server ka SNA mreži '').

Slika 13 Uloga gateway interfejsa

Mrežne kartice (mrežni adapter) obrazuju fizičku vezu između računara i mrežnog kabla.

Postavljaju se u posebne slotove na svakom računaru i serveru na mreži. Podaci prolaze kablom do

mrežnog adaptera gde se transformišu se u pakete. Paket je logičko grupisanje informacija koje sadrži

zaglavlje. Zaglavlje sadrži adresna polja koja uključuju informacije o podacima, tj. njihovom poreklu i

odredištu. Mrežni adapter čita adresu odredišta da odredi da li je paket namenjen tom računaru. Ako

jeste, mrežni adapter propušta paket operativnom sistemu na obradu. Ako nije, adapter odbacuje paket.

Svaki mrežni adapter ima jedinstvenu adresu sadržanu na čipovima na kartici. Ova adresa se naziva

fizička ili MAC (Media Access Control) adresa. Dakle, možemo reći da mrežni adapter ima sledeću

ulogu: prima podatke od OS računara i pretvara ih u električne signale koji se prenose na kabl, prima

električne signale sa kabla i i prevodi ih u podatke koje OS računara može da razume odredjuje da li su

podaci primljeni sa kabla namenjeni računaru kontrolise protok podataka izmedju računara i kablova.

Da bi se osigurala kompatibilnost izmedju računara i mreže, mrežni adapter mora da ispuni sledeći

kriterijum: da bude podržan od strane OS na računaru.

17

Mrežna kartica ima malu količinu memorije koja se koristi kao skladište za deo dolaznih podataka s

mreže dok ih računar obrađuje. Neke novije mrežne kartice imaju čak i sopstveni procesor koji pomaže

u obavljanju mrežnog saobraćaja.

Slika 14 Mrežna kartica

Modem je najčešći medijum za povezivanje računara sa telefonskim linijama. Pri tome se, u

najvećem broju slučajeva, radi o linijama sa biranjem (dial up), a ređe o iznajmljenim telefonskim

linijama (poprečna veza). Iznajmljivanje telefonskih linija je skupo i zbog toga se ovo koristi samo u

retkim slučajevima kada je saobraćaj između dva čvora toliki da opravdava cenu plaćenu za

iznajmljivanje. Većina postojećih telefonskih linija prenosi kontinualne (analogne) signale kojima se

predstavlja govorna informacija (telefonski razgovor). S druge strane, podaci u računarima su digitalni

(diskretni). Da bi se ove informacije, koje se inače predstavljaju diskretnim (digitalnim) signalima,

prenele preko telefonske linije moraju se prvo na predajnoj strani konvertovati u analogne signale.

Podaci primljeni na drugoj strani moraju se ponovo konvertovati u digitalni oblik.

Uređaj koji vrši konverziju digitalnih u analogne signale (modulacija) i obrnuto (demodulacija)

zove se modem (modulator-demodulator).

Modem može biti interni (koji se ugraćuje u računar) i spoljni (koji se spolja priključuje na

računar).

Kod savremenih modema obično je s modemom integrisana i faks kartica i govorna mašina

(telefonska sekretarica). Takva kartica se naziva FMV (Fax, Modem, Voice) kartica. Eksterni modemi

se priključuju na serijski ili na USB port na poleđini kućišta. Interni modemi prema vrsti slota na koji

se ugrađuju na matičnoj ploči mogu biti ISA, PCI ili AMR (Audio Modem Raiser).

Druga podela internih modema bila bi na hardverske i softverske.

Hardverski modemi funkcionišu bez korišćenja procesorke moći računara dok sofverski modemi

koriste resurse računara jer nemaju sve neophodne elekronske komponente da bih funkcionisali

samostalno. Za korišćenje softverskih modema neophodan je računar sa MMX procesorom.

18

Slika 15 Blok šema modemske komunikacije računara

Kablovi fizički povezuju računare i uređaje pa se na njima zasnivaju mreže svih konfiguracija i

veličina. Zahtevi koje moraju ispuniti mrežni kablovi su:

otpornost na prisluškivanje (crosstalk), smetnje u vidu elektromagnetne indukcije

signala iz žice;

otpornost na smetnje zbog uticaja spoljnih elektromagnetnih polja;

lakoća postavljanja.

Oni se razlikuju po mogućnostima i kriterijum za njihovu podelu je mogućnost da prenose podatke na

različitim brzinama, sa različitom vrednošću greške. Tri osnovne kategorije kablova u mrežama su TP

(twisted Pair), koaksijalni i optički kablovi.

TP kablovi sastoje se od 2 izolovana snopa bakarnih žica, koji su uvijeni jedan oko drugog.

Imamo dva tipa ovih kablova: Unshielded Twisted pair (UTP) i Shielded Twisted Pair (TP).

Ovi kablovi se najviše koriste u mrežama i mogu da provode signal oko 100 metara. Utp je

najpopularniji. TP kablovi koriste RJ-45 konektore za povezivanje na računar.

Koaksijalni kablovi sastoje se od jezgra od bakarne žice koje je okruženo izolacijom i

spoljnim pokrivačem. Jezgro koaksijalnog kabla nosi elektronske signale koji čine podatke.

Ovo jezgro može biti ili jedna žica ili pramen žica. Povezivanje koaksijalnim kablovima je

dobar izbor kada se podaci prenose na velike daljine Postoje dva tipa ovih kablova: ThinNet -

prenosi signal na 185 metara, i ThickNet - prenosi signal na 500 metara. Oba ova tipa koriste

BNC konektor.

Slika 16 UTP kabl

Optički kablovi koriste optička vlakna za prenos digitalnih podataka u formi svetlosnih

impulsa. Zato što ovaj kabl prenosi svetlosne impulse a ne električne, signal ne može biti

19

praćen i podaci ne mogu biti ukradeni. Optički kabl je dobar za brz prenos velike količine

podataka, jer se signal prenosi brzo i sa vrlo malo smetnji. Mana optičkog kabla je to što je

njegova instalacija komplikovana i što se lako lomi prilikom povezivanja, što zahteva posebnu

opremu i što je skup.

Kablovi koji su otporni na preslušavanje i interferenciju omogućavaju veći domet i brži prenos.

1.5 Mrežni softver

Mrežni (komunikacioni) softver čine programi koji omogućavaju komunikaciju dva uređaja

korišćenjem datog komunikacionog uređaja i medijuma.

Tu treba razlikovati dve vrste programa:

veznike (drajvere),

aplikacione programe.

Veznici (drajveri) omogućavaju da komunikacioni uređaj prihvata i izvršava komande koje su

zadate u skladu sa određenim standardom za tu vrstu uređaja. Oni se dobijaju kupovinom

komunikacionog uređaja na CD-u (ili disketama). Ovi programi najčešće zavise od operativnog

sistema na računaru, pa proizvođač daje različite verzije veznika za različite operativne sisteme. To

znači da izmenom operativnog sistema na računaru moraju da se zamene i veznici (drajveri) za

postojeće uređaje.

Aplikacioni programi omogućavaju različite vrste komunikacija među računarima ili između

računara i drugog udaljenog uređaja (na primer, štampača ili faksa). Proizvođač komunikacionog

uređaja, pored veznika (drajvera), obično daje i osnovni aplikativni softver da bi njegov uređaj mogao

da se koristi. Međutim, program za korišćenje komunikacionog uređaja može biti i deo operativnog

sistema (na primer, u Windows-u), a mnogo češće postoji veći broj programa na tržištu s različitim

mogućnostima.

Kolekcija programa koji podržavaju rad računara u mreži zove se komunikacioni softver. Sve

funkcije značajne za korisnike mreže ostvaruju se posredstvom odgovarajućih programa. Zato je

raspolaganje dobrim komunikacionim softverom presudno za rad korisnika u mreži. Komunikacioni

softver obezbeđuje sledeće funkcije:

Postavljanje parametara za rad u mreži,

Uključivanje računara u mrežu,

Rad korisnika u mreži,

Sigurnosne mere,

Administrativni poslovi,

Pomoć korisniku.

20

Komunikacioni softver se može naći u formi:

vlasničkog,

javnog ili

deljenog softvera.

Za profesionalnu upotrebu najbolje je raspolagati vlasničkim softverom iza kojeg stoji

proizvođač sa svim garancijama i drugim pogodnostima pri unapređenju softverskog paketa. Naravno,

za amaterske primene može se koristiti i softver koji se daje besplatno za javnu upotrebu. Ovaj softver

se nalazi u računarskim mrežama i može se koristiti od strane svih korisnika mreže.

Mrežne aplikacije su aplikacije koje su pokrenute od strane različitih računara spojenih na

mrežu. Među najčešće korišćene mrežne aplikacije spada korišćenje web pretraživača kako bi se

pronašli sadržaji na World Wide Web-u (WWW-u), korišćenje e-mail aplikacije za slanje e-mailova

putem WWW-a (web-bazirani e-mail servisi, npr. GMail, Yahoo Mail i sl.) Svaka aplikacija ima

direktnu vezu sa protokolom koji koristi. Primeri su:

WWW koristi HTTP (HyperText Transfer Protocol). HTTP je komunikacijski protokol koji se koristi

kako bi se uspostavila veza između WWW servera i prosledile se HTML stranice direktno do

klijentskog pretraživača.

Mnogi programi za elektronsku poštu (e-mail) koriste POP3 i IMAPv4 (Post Office Protocol verzije 3

i Internet Message Access Protocol verzije 4) protokole, što su aplikacijski protokoli (prema OSI

klasifikaciji).

POP3 je standardni e-mail server koji se koristi na Internetu, a omogućava skladištenje pristiglih e-

mailova do trenutka kada se korisnik ne prijavi na mrežu i prihvati pristigle e-mailove na svoj lokalni

računar.

IMAPv4, s druge strane, omogućava korisniku da svi e-mailovi budu sačuvani na serveru, bez obaveze

da ih prihvati na svoj lokalni računar. Na taj način korisnik može da pregleda svoje e-mailove sa bilo

kog računara na mreži, u bilo kom trenutku.

Aplikacije za prenos datoteka najčešće koriste FTP (File Transfer Protocol) za prenos datoteka između

udaljenih računara.

Programi za udaljeni pristup koriste Telnet/SSH (Secure Shell) protokol za pristup na udaljene

računare. Aplikacije za upravljanje mrežom koriste SNMP (Simple Network Management Protocol) za

nadzor statusa i aktivnosti mrežnih uređaja. Vrlo je bitno naglasiti da je aplikacijski sloj samo jedan od

slojeva prema OSI i TCP/IP referentnim modelima.

21

E-mail klijenti (među najpopularnijima Mozilla Thunderbird, Outlook Express, Outlook, Evolution...)

funkcionišu putem POP3/IMAPv4 protokola. Web pretraživači takođe, po istom principu, funkcionišu

putem HTTP protokola - među najpopularnijim pretraživačima danas su Mozilla Firefox, Internet

Explorer, Opera, Mozilla Browser...

1.6 Različiti aspekti zaštite računarskih mreža

Nivoi zaštite u odnosu na položaj mehanizama zaštite su:

Zaštita na nivou aplikacije, obuhvata: softversku zaštitu aplikacije, izolovanje bitnih aplikacija.

Zaštita na nivou operativnog sistema, obuhvata vezu operativnog sistema - aplikacija i odnos

prema mrežnoj arhitekturi tj. vezama sa drugim sistemima.

Zaštita na nivou mrežne infrastrukture, obuhvata primenu mrežnih barijera, blokiranje

nepotrebnih portova, šifrovanje putanje.

Procedura i operaciona zaštita, obuhvata definisanje i sprovođenje pravila zaštite, detekciju

napada, proaktivno delovanje.

Šta je potrebno da bi se projektovao sistem za zaštitu?

Prilikom projektovanja sistema zaštite potrebno je:

lice odgovorno za projekat;

metode identifikacije korisnika i terminala;

strukture šema ovlašćenja;

načini detekcije nedozvoljenih pristupa;

načini integrisanja zaštite u sistemske programe;

postupci oporavka zbog oštećanja datoteka;

postupci oporavka zbog otkaza sistema;

da li treba koristiti kriptografiju ili ne;

koje kontrole treba ugraditi radi analize i pregledanje datoteka.

Dobar security ne podrazumeva samo primenu najnovijih sigurnosnih zakrpa i update-ovanje

serverskog softvera; pri projektovanju svakog mrežnog rešenja potrebno je voditi računa i o arhitekturi

LAN-a a posebno o smanjivanju rizika hakerskih upada spolja. To podrazumeva uvođenje posebnih

mera kada su u pitanju uređaji koji su vidljivi spolja, sa interneta.

1.6.1 Zaštita router-a

Ruteri kontrolišu pristup LAN-a prema internetu i samim tim su prva meta hakera. Probojem

rutera haker može da sazna mnogo o samoj strukturi LAN-a i na taj način izvrši i dalji prodor ka

22

serverima, radnim stanicama i ostalim mrežnim uređajima. Sigurnost rutera predstavlja kritični

element zaštite svake mreže. Osnovne tehnike zaštite rutera su:

zabrana pristupa telnet protokolom na ruter - uvek treba koristiti kriptovan protokole za

pristup, napr. ssh

isključivanje SMTP protokola na ruteru

isključivanje svih nepotrebnih servisa na ruteru - routing protokola koji se ne koriste, web

pristupa i sl.

kontrola pristupa ruteru - korišćenjem ACL lista ili TACACS-a

pristup ruteru sa odgovarajućim stepenom privilegija - ukoliko nije neophodan pristup u

administratorskom modu, recimo u slučaju testiranja konekcije, uređaju treba pristupati kao

korisnik sa ograničenim privilegijama

autentifikacija i provera update-ova

1.6.2 Zaštita switch-eva

I kod switch-eva (i layer 2 i layer 3), slično kao kod rutera, treba uvesti dodatne mere zaštite.

Switch-evi se obično podešavaju tako da radi segmentaciju saobraćaju na layer-u 2 korišćenjem

VLAN-ova. Većina postupaka koji su se odnosili na zaštitu rutera odnose se i na zaštitu switch-eva, a

osim toga standardno se preduzimaju i dodatne mere zaštite:

deaktiviranje svih neupotebljenih portova na switch-u - ovo sprečava hakere da se priključe

na nekorišćene portove/mrežne utičnice i tako ostvare komunikaciju sa ostatkom mreže.

portove koji ne rade u trunking modu treba eksplicitno setovati tako da ne koriste

trunking (ne ostavljati na auto) - ovim se sprečava da neki od hostova iskoristi trunking i

prima mrežni saobraćaj koji njemu nije namenjen.

portovi koji rade trunking treba da budu u posebnim VLAN-ovima - posebno treba voditi

računa da trunking portovi ne ostani u default-nom VLAN-u.

limitiranje pristupa portovima switch-a po MAC adresama (max 2-3 MAC adrese) - čime

se sprečava MAC flooding i ostali tipovi napada iznutra.

pažljivo dizajniranje i implementacija VLAN-ova - LAN podeljen na VLAN-ove i u

sadejstvu sa firewall-om daje in-depth sigurnost.

korišćenje autentifikacionih mehanizama ukoliko to switch-evi podržavaju - uz pomoć

802.11 standardna i Radius servera.

1.6.3 Zaštita mreže korišćenjem firewall-a

Firewall je uređaj koji vrši filtriranje mrežnog saobraćaja ka/od interneta, mada se u nekim

slučajevima koristi i unutar samog LAN-a za obezbeđivanje servera sa posebno osetljivim podacima

(database server, aplikativni server i sl.). U principu svaka lokalna računarska mreža sa izlazom na

internet, bez obzira koje veličine i stepena složenosti, mora da poseduje firewall. Firewall je kritična

23

komponenta mrežne sigurnosti - dobro podešen firewall u ogromnoj meri smanjuje rizike upada u

mrežu kao i mogućnost zaraze radnih stanica malicioznim programima (virusi, trojanci i sl.). Još jedna

bitna osobina firewall-a je mogućnost ograničavanja protoka (peer-to-peer, http, ftp i sl.). Po default-u

firewall se setuje sa izuetno striktnim pravilima filtriranja, što znači da se sav saobraćaj zabranjuje, a

onda se po potrebi otvaraju određeni portovi pojedinim računarima ili grupi računara u LAN-u.

Slika 17 Primer jednostavnog LAN-a sa firewall-om

1.6.4 Zaštita mreže uvođenjem demilitarizovane zone (DMZ)

Radi dizanja sigurnosti lokalne mreže uveden je koncept demilitarizovane zone (DMZ). DMZ je

poseban mrežni segment gde se nalaze tzv. bastion hostovi tj. računari koji su vidljivi sa interneta i

kojima se stoga ne može bezrezervno verovati - ma koliko mala bila uvek postoji verovatnoća da je na

neki od ovih servera izvršen hakerski upad. Bastion hostovi su najčešće serveri - mail server, web

server, proxy server i sl.

Lajt motiv uvođenja DMZ-a je - mora postojati barijera kojom se ostatak računara u LAN-u štiti i od

samih bastion hostova. Treba strogo na firewall-u definisati saobraćaj ka/od radnih stanica ka internetu,

ka/od interneta do bastion hostova i ka/od radnih stanica u LAN-u ka bastion hostovima.

Konfiguracija DMZ-a sa dva firewall-a predstavlja mnogo sigurnije rešenje - ukoliko padne prvi

firewall potencijalni napadač mora da savlada i sledeći firewall da bi uspeo da prodre u LAN gde se

nalaze najosetljiviji i najkritičniji podaci koje treba zaštititi. To iziskuje dodatni napor i vreme

napadaču i daje određenu prednost administratorima mreža koji imaju dovoljno vremena da reaguju,

otklone probleme i eliminišu uljeza. Preporučljivo je da se za firewall-ove biraju 2 različita proizvoda

da se ne bi desilo da zbog nekog sigurnosnog propusta oba budu kompromitovana u isto vreme.

Nedostatak ove konfiguracije je cena i razmerno uvećano vreme konfigurisanja i održavanja.

24

1.7 Administracija mreze

Administriranje mreža je presudno za neprestano funkcionisanje i bezbedan rad IT sistema. Pri

tom, administriranje računarskih mreža podrazumeva odgovornost i obavezu održavanja

funkcionalnosti, dijagnostike i praćenja rada sistema u realnom vremenu 24 sata dnevno, 7 dana u

nedelji.

Centralizovano administriranje omogućava i nadgledanje sistema sprovođenja bezbednosnih

mera s jednog mesta. U mreži se informacije mogu lakše sačuvati i zaštiti. Sistemi na mreži mogu

automatski slati rezervne kopije na mrežni server. U klasičnoj mreži ravnopravnih korisnika ne postoji

sistem administrator koji opslužuje celu mrežu, odnosno nadgleda funkcionisanje svih komponenti

mreže. Umesto toga, svaki korisnik sam opslužuje svoj računar.

Administriranje mreže obuhvata sledeće poslove:

upravljanje korisnicima i bezbednošću,

dostupnost resursa,

opsluživanje aplikacija i podataka i

instaliranje i nadogradnju aplikativnog softvera

administriranje svih domena i radnih stanica.

kontrola korisničkih naloga.

manipulacija share-ovanih datoteka

kontrola registara

kontrola nad dokumentima i datotekama

upravljanje procesima, servisima i uređajima

upravljanje nalozima korisnika i grupa.

kontrola servisa, registara i procesa.

instalacija i konfiguracija na daljinu.

podešavanje grupa računara.

daljinsko instaliranje i deinstaliranje softvera

tačni i detaljni izveštaji procesa.

Kod neumreženih računara svaki korisnik je odgovoran za performanse svog računara. U

umreženom okruženju, upravljanje, održavanje mreže obavlja obučeno profesionalno osoblje. Ovo su

radna mesta od kojih zavisi funkcionisanje ne samo mreža, već i čitavog informacionog sistema:

Administratori mreža su obučena, stručna i osposobljena lica koji su odgovorni za rad mreže..

Administrator bezbednosti u dnevnicima rada analizira bezbednosne stavke, uvodi lozinke,

fizički pristupa hardveru, istražuje upade u sistem,...

Administrator baze podataka je odgovoran za programiranje i održavanje velikih relacionih baza

podataka u mrežnom okruženju.

http://www.ucf.so.ac.yu/xampp/joomla/docs/katedre/informaticka/solesa/radovi/racmreze/sigurnost.htm

http://www.ucf.so.ac.yu/xampp/joomla/docs/katedre/informaticka/solesa/radovi/racmreze/sigurnost.htm

ANEX 2. “Nagios Core” kao ITSM alat

Sadržaj 1 ANEX 2. “Nagios Core” kao ITSM alat .............................................................................................................. 1

Softverski paket “Nagios Core” kao ITSM alat ......................................................................................................... 8

1.1 O Nagiosu ................................................................................................................................................ 8

1.2 Nagios koncept: “Plug-in” arhitektura ..................................................................................................... 8

1.3 Konfiguracija NAGIOSa .......................................................................................................................... 10

1.4 Funkcije jezgra - Nagios Core ................................................................................................................. 12

1.4.1 Određivanje statusa hostova ......................................................................................................... 12

1.4.2 Lokalni i udalјeni hostovi ............................................................................................................... 12

1.4.3 Nadgledanje lokalnih i udalјenih hostova ..................................................................................... 12

1.4.4 Virtuelni hostovi ............................................................................................................................ 13

1.5 Vrste statusa .......................................................................................................................................... 13

1.6 Tipovi stanja ........................................................................................................................................... 14

1.6.1 “Soft” stanje................................................................................................................................... 14

1.6.2 “Hard” stanje ................................................................................................................................. 14

1.6.3 Promene “hard” stanja .................................................................................................................. 15

1.6.4 Događaji u “hard” stanju ............................................................................................................... 15

1.7 Raspoređivanje provera servisa u vremenu .......................................................................................... 16

1.7.1 Konfiguracione direktive................................................................................................................ 16

1.7.2 Raspoređivanje provera u problematičnim situacijama ............................................................... 16

1.7.3 Validni period provera ................................................................................................................... 17

1.7.4 Učešlјavanje servisa (“interleaving”) ............................................................................................. 17

1.7.5 Maksimalni broj paralelnih provera servisa .................................................................................. 19

1.7.6 Provere hostova ............................................................................................................................. 20

1.7.7 Kašnjenje ....................................................................................................................................... 21

1.7.8 Detekcija flapovanja servisa .......................................................................................................... 21

1.7.9 Detekcija flapovanja za hostove .................................................................................................... 22

1.7.10 Granice detektovanja flapovanja ................................................................................................... 22

1.7.11 Upravlјanje flapovanjem ............................................................................................................... 23

1.7.12 Primer raspoređivanja provere servisa ......................................................................................... 23

1.8 Vremenski intervali ................................................................................................................................ 24

1.8.1 Kako vremenski periodi utiču na provere servisa .......................................................................... 24

2

1.8.2 Potencijalni problemi sa vremenskim periodima .......................................................................... 24

1.8.3 Kako vremenski periodi utiču na obaveštavanje kontakata .......................................................... 25

1.8.4 Potencijalni problemi sa obaveštavanjem kontakata .................................................................... 25

1.8.5 Zaklјučak ........................................................................................................................................ 25

1.9 Obaveštavanje ....................................................................................................................................... 26

1.9.1 Kada se podiže alarm ..................................................................................................................... 26

1.9.2 Ko se obaveštava ........................................................................................................................... 26

1.9.3 Filteri obaveštenja ......................................................................................................................... 26

1.9.4 Konfigurisanje notifikacija ............................................................................................................. 26

1.9.5 Filteri obaveštenja kontakata ........................................................................................................ 28

1.9.6 Metoda obaveštavanja koje nisu direktno ugrađene u Nagios ..................................................... 28

1.10 Eskalacije obaveštenja ........................................................................................................................... 29

1.10.1 Kada dolazi do eskalacije obaveštenja .......................................................................................... 29

1.10.2 Grupe kontakata ............................................................................................................................ 30

1.10.3 Preklapanje opsega eskalacija ....................................................................................................... 31

1.10.4 Obaveštenja o oporavku ................................................................................................................ 31

1.10.5 Intervali obaveštavanja ................................................................................................................. 32

1.11 Indirektne provere statusa hostova i servisa ........................................................................................ 33

1.11.1 Indirektne provere servisa ............................................................................................................. 34

1.11.2 Višestruke indirektne provere servisa ........................................................................................... 35

1.11.3 Indirektne provere hostova ........................................................................................................... 36

1.11.4 Aktivne provere ............................................................................................................................. 37

1.11.5 Pasivne provere ............................................................................................................................. 38

1.11.6 Način na koji eksterne aplikacije podnose rezultate provere servisa ........................................... 39

1.11.7 Način na koji eksterne aplikacije podnose rezultate provere hostova.......................................... 39

1.11.8 Određivanje statusa i dostupnosti mrežnih hostova .................................................................... 39

1.11.9 Pasivne provere i stanje hostova ................................................................................................... 43

1.11.10 Prevođenje pasivne provere hosta u tačno stanje .................................................................... 43

1.11.11 Podnošenje rezultata pasivnih provera servisa sa udalјenih hostova ....................................... 44

1.12 “Osvežavanje” provera hostova i servisa .............................................................................................. 44

1.12.1 Kombinovanje oba tipa provera servisa ........................................................................................ 45

1.13 Distribuiran način monitoringa .............................................................................................................. 46

1.13.1 Konfigurisanje instanci Nagiosa ..................................................................................................... 47

1.14 Zavisnosti hostova i servisa ................................................................................................................... 48

1.14.1 Pregled zavisnosti servisa .............................................................................................................. 48

3

1.14.2 Definisanje zavisnosti servisa ........................................................................................................ 48

1.14.3 Kako se testiraju zavisnosti servisa ................................................................................................ 50

1.14.4 Zavisnosti izvršavanja servisa ........................................................................................................ 50

1.14.5 Zavisnosti obaveštavanja o servisu ................................................................................................ 50

1.14.6 Nasleđivanje zavisnosti servisa ...................................................................................................... 50

1.14.7 Zavisnosti hostova ......................................................................................................................... 50

1.14.8 Intuitive provere zavisnosti ........................................................................................................... 51

1.14.9 Sačuvane provere .......................................................................................................................... 52

1.15 Praćenje stanja (“state stalking”) .......................................................................................................... 53

1.15.1 Princip rada .................................................................................................................................... 54

1.16 “Event” hendleri .................................................................................................................................... 55

1.16.1 Tipovi “event” hendlera................................................................................................................. 55

1.17 Eksterne komande ................................................................................................................................. 56

2 Najčešće korišćeni plaginovi .......................................................................................................................... 58

2.1.1 “check_dns” ................................................................................................................................... 58

2.1.2 “check_dig” .................................................................................................................................... 58

2.1.3 “check_disk” .................................................................................................................................. 59

2.1.4 “check_dummy” ............................................................................................................................ 59

2.1.5 “check_ftp” .................................................................................................................................... 59

2.1.6 “check_hpjd” ................................................................................................................................. 60

2.1.7 “check_load” ................................................................................................................................. 60

2.1.8 “check_nagios” .............................................................................................................................. 60

2.1.9 “check_nrpe” ................................................................................................................................. 60

2.1.10 “check_ping”.................................................................................................................................. 61

2.1.11 “check_pop” .................................................................................................................................. 61

2.1.12 “check_procs” ................................................................................................................................ 62

2.1.13 “check_smtp” ................................................................................................................................ 62

2.1.14 “check_snmp” ................................................................................................................................ 62

2.1.15 “check_spop” ................................................................................................................................. 64

2.1.16 “check_swap” ................................................................................................................................ 64

2.1.17 “check_users” ................................................................................................................................ 65

2.1.18 “check_tcp” ................................................................................................................................... 65

2.1.19 “check_ups” ................................................................................................................................... 65

2.2 Konfiguracija .......................................................................................................................................... 65

2.2.1 Glavna konfiguraciona datoteka – “nagios.cfg” ............................................................................ 65

4

2.2.2 Definisanje log datoteke ................................................................................................................ 66

2.2.3 Imena i putanje konfiguracionih datoteka objekata ..................................................................... 66

2.2.4 Direktorijum sa konfiguracionim datotekama objekta ................................................................. 66

2.2.5 Fajl sačuvanih objekata.................................................................................................................. 66

2.2.6 Definisanje “resource” datoteke ................................................................................................... 67

2.2.7 Definisanje “temp” datoteke ......................................................................................................... 67

2.2.8 Putanja “temp” datoteke .............................................................................................................. 67

2.2.9 Definisanje statusne datoteke ....................................................................................................... 67

2.2.10 Vremenski interval ažuriranja statusne datoteke ......................................................................... 67

2.2.11 Korisničko ime pod kojim se izvršava Nagios ................................................................................ 68

2.2.12 Grupa korisnika kojoj pripada korisnik Nagios .............................................................................. 68

2.2.13 Kontrola obaveštavanja ................................................................................................................. 68

2.2.14 Kontrola provere servisa................................................................................................................ 68

2.2.15 Kontrola prihvatanja pasivnih provera servisa .............................................................................. 69

2.2.16 Kontrola provere hostova .............................................................................................................. 69

2.2.17 Kontrola prihvatanja pasivnih provera hostova ............................................................................ 69

2.2.18 Kontrola rukovanja događajima (“event handling”) ...................................................................... 69

2.2.19 Metod rotacije log datoteka .......................................................................................................... 70

2.2.20 Putanja arhive logova .................................................................................................................... 70

2.2.21 Kontrola provere eksternih komandi ............................................................................................ 70

2.2.22 Kontrola intervala između provera datoteke eksternih komandi ................................................. 70

2.2.23 Definisanje datoteke eksternih komandi ...................................................................................... 71

2.2.24 “Buffer” slotovi eksternih komandi ............................................................................................... 71

2.2.25 Provere ažuriranja verzije .............................................................................................................. 71

2.2.26 “Lock” datoteka ............................................................................................................................. 71

2.2.27 Opcija pamćenja stanja hostova i servisa ...................................................................................... 72

2.2.28 “State retention” datoteka ............................................................................................................ 72

2.2.29 Kontrola učestalosti automatskog ažuriranja “state retention” datoteke .................................... 72

2.2.30 Kontrola čuvanja stanja programa ................................................................................................ 72

2.2.31 Kontrola logovanja u sistemsku log datoteku (“syslog”) ............................................................... 73

2.2.32 Kontrola logovanja notifikacija ...................................................................................................... 73

2.2.33 Kontrola logovanja ponovnih pokušaja provere servisa ............................................................... 73

2.2.34 Kontrola logovanja ponovnih pokušaja provere hostova .............................................................. 74

2.2.35 Kontrola logovanja “event” hendlera ............................................................................................ 74

2.2.36 Kontrola logovanja inicijalnih stanja .............................................................................................. 74

5

2.2.37 Kontrola logovanja eksternih komandi .......................................................................................... 74

2.2.38 Kontrola logovanja pasivnih provera servisa ................................................................................. 75

2.2.39 Definisanje globalnog “event” hendlera hostova .......................................................................... 75

2.2.40 Definisanje globalnog “event” hendlera servisa ........................................................................... 75

2.2.41 Definisanje intervala sna između provera ..................................................................................... 76

2.2.42 Metod vremenskog raspoređivanja izvršavanja provera .............................................................. 76

2.2.43 Definisanje faktora učešlјavanja servisa (“service interleave factor”) .......................................... 76

2.2.44 Definisanje maksimalnog broja paralelnih provera servisa ........................................................... 77

2.2.45 Definisanje učestalosti obrade rezultata provera ......................................................................... 77

2.2.46 Dozvolјeno vreme učestalosti obrade rezultata provera .............................................................. 77

2.2.47 Kontrola agresivne provere hostova ............................................................................................. 77

2.2.48 Kontrola detekcije “flapovanja” .................................................................................................... 77

2.2.49 Definisanje donjeg praga “flapovanja” servisa .............................................................................. 78

2.2.50 Definisanje gornjeg praga “flapovanja” servisa ............................................................................ 78

2.2.51 Definisanje donjeg praga “flapovanja” hosta ............................................................................... 78

2.2.52 Definisanje gornjeg praga “flapovanja” hosta .............................................................................. 78

2.2.53 Kontrola provere zavisnost servisa u “SOFT” stanju ..................................................................... 78

2.2.54 Vremenska kontrola provere servisa (“service check timeout”) ................................................... 79

2.2.55 Vremenska kontrola provere hosta (“host check timeout”) ......................................................... 79

2.2.56 Vremenska kontrola event hendlera (“event handler check timeout”) ........................................ 79

2.2.57 Vremenska kontrola opsesivno kompulsivne komande procesora servisa ................................... 80

2.2.58 Vremenska kontrola komande procesora podataka o performansama ....................................... 80

2.2.59 Direktiva “Obsess Over Services” .................................................................................................. 80

2.2.60 Definisanje komande opsesivno kompulsivnog procesora servisa ............................................... 80

2.2.61 Direktiva “Obsess Over Hosts” ...................................................................................................... 80

2.2.62 Definisanje komande opsesivno kompulsivnog procesora hosta ................................................. 81

2.2.63 Direktiva procesora podataka o performansama .......................................................................... 81

2.2.64 Kontrola napuštenih provera servisa (“Orphaned service checks”) .............................................. 81

2.2.65 Kontrola napuštenih provera hostova (“Orphaned host checks”) ................................................ 82

2.2.66 Kontrola “svežine” rezulta provera servisa ................................................................................... 82

2.2.67 Definisanje intervala provere svežine servisa ............................................................................... 82

2.2.68 Kontrola “svežine” rezulta provera hostova.................................................................................. 82

2.2.69 Definisanje intervala provere svežine servisa ............................................................................... 83

2.2.70 Definisanje ilegalnih karaktera imena objekata ............................................................................ 83

2.2.71 Definisanje ilegalnih karaktera izlaza makroa ............................................................................... 83

6

2.2.72 Definisanje email adrese administratora Nagiosa ......................................................................... 83

2.3 Konfiguraciona datoteka “CGI” skriptova – “cgi.cfg” ............................................................................ 84

2.3.1 Lokacija glavne konfiguracione datoteke ...................................................................................... 84

2.3.2 Fizička “HTML” putanja ................................................................................................................. 84

2.3.3 “URL HTML” putanja ...................................................................................................................... 84

2.3.4 Kontrola autentifikacije korisnika .................................................................................................. 84

2.3.5 Definisanje default korisničkog imena .......................................................................................... 85

2.3.6 Kontrola pristupa informacijama o sistemu/procesu .................................................................... 85

2.3.7 Kontrola pristupa komandama sistem/procesa ............................................................................ 85

2.3.8 Kontrola pristupu konfiguracionim informacijama ....................................................................... 85

2.3.9 Kontrola pristupa globalnim informacijama o hostovima ............................................................. 86

2.3.10 Kontrola pristupa globalnim komandama za hostove ................................................................... 86

2.3.11 Kontrola pristupa globalnim informacijama o servisima ............................................................... 86

2.3.12 Kontrola pristupa globalnim komandama za servise .................................................................... 86

2.3.13 Definisanje pozadine za “statusmap CGI script” ........................................................................... 86

2.3.14 Definisanje podrazumevanog stila prikaza statusmape ................................................................ 87

2.3.15 Kontrola uklјučenja korisničkih objekata pomoću “statuswrl CGI-a” ............................................ 87

2.3.16 Definisanje podrazumevanog stila prikaza “statuswrl CGI” skriptom ........................................... 87

2.3.17 Kontrola brzina osvežavanja stranica generisanih “CGI” skriptovima ........................................... 88

2.3.18 Definisanje zvučnih alarma ............................................................................................................ 88

2.3.19 Definisanje sintakse komande ping preko “WAP” interfejsa ........................................................ 88

2.4 “Resource” konfiguraciona datoteka – “resource.cfg” ......................................................................... 89

2.4.1 Makroi na zahtev (“On-demand macros”) .................................................................................... 89

2.4.2 Grupni makroi na zahtev (“On-demand group macros”) .............................................................. 89

2.4.3 Definisanje proizvolјnih promenlјivi makroa ................................................................................. 89

2.4.4 Proizvolјne promenlјive kao makroi .............................................................................................. 90

2.4.5 Definisanje “$USERn$” korisničkih makroa ................................................................................... 91

2.4.6 Konfiguracione datoteke objekata ................................................................................................ 92

2.5 Formati definicija objekata .................................................................................................................... 92

2.5.1 Definicija objekta komande (“checkcommands”) ......................................................................... 92

2.5.2 Definicija objekta nadležnog kontakta (“contact”) ....................................................................... 92

2.5.3 Definicija objekta grupe kontakata (“contact groups”) ................................................................. 94

2.5.4 Definicija objekta zavisnosti servisa (“service dependency”) ....................................................... 94

2.5.5 Definicija objekta zavisnosti hosta (“host dependency”) .............................................................. 95

2.5.6 Definicija objekta eskalacije servisa (“service escalation”) ........................................................... 95

7

2.5.7 Definicija objekta eskalacije hosta (“host escalation”) ................................................................. 96

2.5.8 Definicija objekta hosta (“host”) ................................................................................................... 97

2.5.9 Definicija objekta grupe hostova (“host group”) ........................................................................... 98

2.5.10 Definicija objekta servisa (“service”) ............................................................................................. 99

2.5.11 Definicija objekta vremenskog perioda (“time period”) ............................................................. 101

2.6 Nasleđivanje objekata ......................................................................................................................... 101

2.6.1 Lokalne promenlјive i nasleđene promenlјive............................................................................. 102

2.6.2 Lančano nasleđivanje .................................................................................................................. 103

2.6.3 Korišćenje nepotpunih definicija objekta kao šablon (“template”) ............................................ 104

2.6.4 Proizvolјne promenlјive objekata ................................................................................................ 105

2.6.5 Otkazivanje nasleđivanja “string” vrednosti ............................................................................... 106

2.6.6 “Dodatno” nasleđivanje “string” vrednosti ................................................................................. 107

2.6.7 Automatsko nasleđivanje vrednosti ............................................................................................ 108

2.6.8 Višestruki izvori nasleđivanja....................................................................................................... 108

2.6.9 Prvenstvenost promenlјivih iz višestrukih izvora nasleđivanja ................................................... 110

3 Bezbednosna razmatranja ........................................................................................................................... 111

3.1 Najbolјe prakse .................................................................................................................................... 111

3.2 Podaci o performansama .................................................................................................................... 113

3.2.1 Procesiranje podataka o performansama ................................................................................... 114

3.3 Konfigurisanje Nagiosa za postizanje maksimalnih performansi ........................................................ 115

3.4 Zaklјučak .............................................................................................................................................. 117

8

1 Softverski paket “Nagios Core” kao ITSM alat

1.1 O Nagiosu

Nagios je popularno “open source” resenje za sistemski monitoring, mrežni monitoring i monitoring

infrastrukture.

Prvi projekat je započet pod imenom “Netsaint”, a njegova poslednja zvanična verzija je 0.0.7.

“N.A.G.I.O.S.” je skracenica od "Nagios Ain't Gonna Insist On Sainthood". "Sainthood" je referenca

za originalno ime “NetSaint”, koje je promenjeno da bi se izbegli potencijalni pravni problemi zbog

sličnog zaštitnog znaka druge kompanije. Inače, novo ime je ostalo u istom duhu potičući od grčke reči

“agios” koja znači svetac (engl. “saint” = svetac) i prefiksa “n” koje je prvo slovo engleske reči

“network” (mreža).

Nagios je originalno razvijen za rad pod “Linux” platformom, ali može raditi pod skoro svim ostalim

“Unix” kompatibilnim platformama. Licenciran je pod uslovima “GNU GPL V2” licence koju je

objavila “Free Software Foundation”. Ovim se pod uslovima pomenute licence daje legalna dozvola

za neograničeno kopiranje, distribuiranje i/ili menjanje izvornog koda Nagiosa.

Neke od najbitnijih mogućnosti Nagiosa su:

nadgledanje mrežnih servisa (“SMTP, POP3, HTTP, NNTP, ICMP,SNMP,FTP,SSH”)

nadgledanje lokalnih resursa hostova (opterećenje procesora, iskorišćenost memorije hard

diskova)

monitoring uređaja kao što su sonde (temperatura,alarm, pritisak) koje imaju spobnost da

skuplјaju podatke preko mreže koristeći posebne plaginove

jednostavni plagin koncept koji omogućava korisniku da razvija sopstvene plug-inove za

nadgledanje specifičnih servisa

paralelno nadgledanje servisa

otkrivanje i razlikovanje hostova koji su nedostupni od onih koji su pali

pomoću ugrađenog koncepta roditelјskih hostova i mrežne hijerarhije

obaveštavanje u slučaju pojave neregularnog rada hostova ili servisa i njihovog oporavka (putem

e-maila, pejdžera, SMS-a ili nekom drugom korisnički definisanom metodom)

mogućnost da se definišu hendleri događaja (“event handlers”) koji su aktivni za vreme

izvršavanja servisa ili dešavanja događaja na hostu i koji mogu da rešavaju probleme proaktivno

automatsku rotaciju “log-a”

podršku za implementaciju redundantnih servera za nadgledanje mreže

podršku za implementaciju distribuiranog nadgledanja mreže

opcioni veb interfejs za uvid u tekući status mreže, obaveštavanje i uvid u istoriju problema, log

datoteka itd.

Verzija “Nagios Core™” koja je opisana u ovom radu je 3.3.1 objavlјenja 25/07/2011 godine

sa ispravlјenim “bagovima” i novim funkcionalnostima. Najnovija verzija je 3.4.1 koja je izdata

početkom maja ove godine.

1.2 Nagios koncept: “Plug-in” arhitektura

Programski paket Nagios zasnovan je na jednostavnoj “plug-in” arhitekturi čiji koncept podrazumeva

funkcionalnu podelu paketa na jezgro programa i eksterne programe koji se nazivaju “plaginovima”

9

(engl. plug-in). Jezgro Nagiosa, koje čini centralni proces, u dokumentaciji još označavan kao “Nagios

Process” ili “Core Logic”, ne poseduje nikakve interne mehanizme provere statusa nadgledanih

objekata. Umesto toga, ono se u potpunosti oslanja na plaginove koji obavlјaju celokupni posao

nadgledanja. Samim tim, Nagios jezgro je beskorisno bez svojih plaginova. Princip rada Nagiosa se

ukratko može opisati na sledeći način. Nagios izvršava plagin kad god se stvori potreba za proverom

statusa određenog servisa ili hosta koji se nadgleda. Plagin radi “nešto” da bi izvršio proveru i

jednostavno Nagiosu vraća rezultate te provere. Primlјeni rezultati se obrađuju i preduzimaju se

neophodne akcije ako je tako nešto potrebno i, naravno, definisano u konfiguracionim

datotekama(pokretanje “event” hendlera, slanje obaveštenja). Plaginovi se ponasaju kao abstraktni sloj

između logike monitoringa i servisa/hostova koji se nadgledaju.

Slika 1 Plagin arhitektura Nagiosa

Slika 1 prikazuje način na koji su plaginovi odvojeni od jezgra programa. Nagios pokreće plaginove

koji potom proveravaju lokalne ili udalјene resurse ili servise nekog tipa. Kada plaginovi završe

proveru resursa ili servisa, prosto predaju rezultate provere nazad Nagiosu na obradu.

Dobra strana plagin arhitekture je što pruža praktično neograničene mogućnosti nadgledanja. Ako se

proces provere nečega može automatizovati, onda se to može nadgledati pomoću Nagiosa. Uz Nagios

distribuciju dolazi određeni broj standardnih plaginova koji pokrivaju provere gotovo svih uobičajenih

mrežnih servisa i resursa kao što su dostupnost “TCP/UDP” portova, “FTP”, opterećenje procesora,

popunjenost particija hard diska, brzina odziva pinga, “SNMP” promenlјive, itd. U slučaju potrebe

nadgledanja nekog specifičnog servisa, korisnik veoma lako može da napiše sopstveni plagin, budući

da za to nije potrebno poznavanje izvornog koda jezgra i da postoje dokumentovane smernice za

razvijanje sopstvenih plaginova, koje su dosta jednostavne.

Loša strana plagin arhitekture jeste činjenica da Nagios apsolutno nije “svestan” onoga što se nadgleda.

Nadgledani objekat može biti napon na procesoru, brzina nekog ventilatora, popunjenost hard diska,

statistika mrežnog saobraćaja, temperatura u mašinskoj sali, ili nešto sasvim drugo. Kao takav, Nagios

ne može da generiše grafike promena osim za egzaktne vrednosti statusa resursa tokom vremena.

Dakle, on može da prati samo promene statusa tih resursa. S druge strane, plaginovi su specijalizovani

programi koji tačno “znaju” šta nadgledaju i kako da izvedu proveru za koju su specijalizovani.

Takođe, oni mogu opciono da vraćaju i podatke o performansama zajedno sa statusnim informacijama.

Ovi podaci o performansama se potom mogu predati nekoj eksternoj aplikaciji koja bi mogla da

generiše grafike informacija specifičnih za servis (iskorišćenost diska, opterećenje procesora, saobraćaj

određenog interfejsa rutera, itd).

10

1.3 Konfiguracija NAGIOSa

Nagios čuva svoju konfiguraciju u određenom broju tekstualnih datoteka ili u “MySQL” bazi podataka

koja sadrži tabele analogne konfiguracionim datotekama. Datoteke generalno mogu biti smeštene bilo

gde na sistemu, ali dobra praksa je da sve budu smeštene u “/etc/nagios/” direktorijumu.

Definisanje organizacije i strukture konfiguracionih datoteka objekata je većim delom prepušteno

korisniku što zahteva nešto više truda pri planiranju inicijalne konfiguracije, ali istovremeno pruža

mogućnost potpunog prilagođavanja programa specifičnostima nadgledane mreže. Osnovne

konfiguracione datoteke su “nagios.cfg, cgi.cfg, resource.cfg” i konfiguraciona datoteka objekta

(“Object Configuration File”).

Glavna konfiguraciona datoteka “nagios.cfg”, sadrži brojne direktive kojim se globalno utiče na rad

jezgra programa. U njoj se definišu imena I putanje do svih ostalih konfiguracionih datoteka

uklјučujući i tzv. konfiguracione datoteke objekata. Na sličan način, “cgi.cfg” svojim direktivama

kontroliše način rada “CGI” skriptova, dok je osnovna “resource.cfg”, čuvanje korisnički definisanih

makroa koji obezbeđuju poverlјive informacije (imena korisničkih naloga, lozinke ili parametri za

pristup bazi podataka) od neautorizovanog pristupa. Konfiguraciona datoteka objekta (Object

Configuration File) se koristi za definisanje hostova, servisa, grupe hostova, kontakta, grupe kontakta,

komandi, vremenskih perioda itd. Slika 2 dat je prikaz konfiguracionih datoteka.

Slika 2 Prikaz konfiguracionih datoteka

Pomenute konfiguracione datoteke objekata sadrže definicije objekata pri čemu se termin “objekat”

koristi kao zajednički izraz za sve relevantne podatke koji Nagiosu opisuju nadgledanu mrežu. U ovim

datotekama se čuvaju definicije svih servisa i hostova od interesa, definicije procedura kojim će se

nadgledanje izvršavati, kao i definicije kontakata koji će se obaveštavati u slučaju neregularnosti.

Pregled svih tipova objekata koji se koriste u Nagiosu i kratak opis dati su u tabeli 1.

Generalno postoje dva načina da se definišu objekti u Nagiosu. Prvi način, koji je koristio i “Netsaint”,

podržan je samo zbog kompatibilnosti unazad. Ovaj metod podrazumeva unošenje potpunih definicija

svih objekata u konfiguracione datoteke. Obzirom da broj objekata u konfiguraciji može biti jako

veliki (od nekoliko desetina do više hilјada), ovaj način se ne preporučuje. Sa cilјem da se izbegnu

glomazne i nepregledne konfiguracione datoteke i omogući fleksibilno i lako definisanje objekata,

(samim tim i održavanje Nagiosa) objektima je ugrađena mogućnost nasleđivanja osobina nekog

drugog objekta koji objektu “nasledniku” služi kao obrazac i još neke zgodne osobine koje će kasnije

biti objašnjene. Odatle se drugi način definisanja objekata naziva metod na bazi obrazaca (“template

11

based method”). Mogućnosti i detalјno razrađeni primeri ovog preporučenog metoda, dati su u okviru

glave sa pregledom svih Nagiosovih konfiguracioih datoteka.

Tabela 1Tipovi objekata u Nagiosu

Tip objekta Opis

host (host) Opisuje hardverski uređaj ili komponentu koja puža neki servis(server, radna stanica, ruter, svič, mrežni štampač itd.)

servis (service) Opisuje servis koji pruža neka hardverski uređaj ili server (“HTTP”,

“DNS”, email itd.)

grupa hostova

(host group)

Individualni hostovi se mogu grupisati u grupe hostova. Pri tom

host može biti član više grupa. Ovo pojednostavlјuje pridruživanje servisa čitavoj grupi hostova.

kontakt (contact) Opisuje kontakte koje će Nagios da alrmira u slučaju

neregularnog ponašanja servisa ili hostova u mreži

grupa kontakata

(contact group)

Individualni kontakti se mogu grupisati u grupe kontakata pri

čemu jedan kontakt može biti član više grupa kontakata. Ovim se

pojednostavlјuje pridruživanje servisa ili hosta grupi nadležnih

kontakata.

komanda (command) Opisuje način izvršavanja plaginova ili eksternih programa

vremenski period

(time period)

Opisuje dnevni i/ili nedelјni vremenski interval u toku kog je

dozvolјeno izvršavanje provera hosta ili servisa i/ili obaveštavanje

kontakata o statusu istih

eskalacija servisa

(service escalation)

Opisuje metod eskalacije obaveštenja za dati servis

zavisnosti servisa

(service dependencies)

Opisuje zavisnost određenog servisa od statusa drugih hostova

i/ili servisa

eskalacije hosta

(host escalations)

Opisuje metod eskalacije obaveštenja za određeni host

zavisnosti hosta

(host dependencies)

Opisuje zavisnost statusa određenog hosta od statusa drugih

hostova

eskalcije grupe hostova

(hostgroup escalations)

Opisuje metod eskalacije obaveštenja za određenu grupu hostova

Inače, funkcionalnost Nagiosa se može proširiti korišćenjem brojnih Nagiosovih dodataka. Najvažniji

od njih su “nrpe” (Nagios Remote Plug-in Executor) i “nsca” (Nagios Service Check Acceptor). Ovi

dodaci poseduju zasebne konfiguracione datoteke koje kontrolišu njihov rad.

12

1.4 Funkcije jezgra - Nagios Core

U ovom delu su opisane neke funkcije jezgra Nagiosa koje su bitne za razumevanje logike rada

programa.

1.4.1 Određivanje statusa hostova

Glavna svrha Nagiosa je da nadgleda status servisa koji se izvršavaju na hostovima i mrežnim

uređajima, tj. koji su obezbeđeni fizičkim hostovima ili uređajima na mreži. Jasno je da ako host ili

uređaj na mreži padne (status “DOWN”), svi servisi koje on nudi će pasti zajedno sa njim. Slično, ako

host postane nedostupan zbog pada nekog hosta čijim se posredstvom obavlјa komunikacija između

njega i Nagios servera (status “UNREACHABLE”), Nagios neće biti u mogućnosti da nadgleda

servise pridružene tom hostu.

Jezgro Nagiosa “ume” da prepozna ovakvu situaciju i uvek pokušava da proveri ovaj scenario kada se

pojave problemi sa nekim servisom. Kad god provera servisa rezultuje tzv. “non-OK” statusom,

Nagios će pokušati da proveri da li je host na kome se izvršava servis “živ”. Tipično, to se vrši

pingovanjem hosta i posmatranjem da li se prima bilo kakav odgovor. Ako i provera hosta vrati “non-

OK” status, Nagios će zaklјučiti da postoji problem sa hostom. U toj situaciji Nagios će prigušiti sva

potencijalna obaveštenja za servise koji se izvršavaju na tom hostu i jedino će obavestiti odgovarajuće

kontakte da je host pao ili da je nedostupan. Ako provera hosta vrati “OK” status, Nagios će zaklјučiti

da je host živ i poslaće obaveštenje da se posmatrani servis ne ponaša na očekivan način. Da bi opisani

mehanizam ispravno funkcionisao, pri definisanju hostova u konfiguraciji Nagiosa potrebno je jasno

definisati hijerarhiju hostova u mreži u odnosu na Nagios.

1.4.2 Lokalni i udalјeni hostovi

Računar koji hostuje Nagios je uvek na vrhu u hijerarhiji hostova. Svi ostali hostovi se prema njemu

odnose ili kao lokalni ili kao udalјeni hostovi. “Lokalni hostovi” (za Nagios) su hostovi na istom

mrežnom segmentu na kom se nalazi računar koji hostuje Nagios tako da između njih nema rutera ili

“firewall-ova”.

1.4.3 Nadgledanje lokalnih i udalјenih hostova

Provera lokalnih hostova na mreži je veoma jednostavna. Slučajno (ili namerno) isklјučivanje mrežnog

kabla iz jednog ostalih hostova ne može da ugrozi nadgledanje ostalih hostova u mreži pošto ne

postoje ruteri ili eksterne mreže između hosta koji vrši nadzor i drugih hostova na lokalnom segmentu.

Ako Nagios želi da proveri da li lokalni host radi, prosto će izvršiti komandu provere ka tom hostu.

Ako komanda vrati “OK” status Nagios tumači da je host živ (status “UP”). Ako komanda vrati bilo

koje drugo stanje, Nagios tumači da je host pao (status “DOWN”). Provera statusa udalјenih hostova je

malo komplikovanija od provere lokalnih. Ako Nagios ne uspeva da izvrši proveru nekog servisa na

udalјenom hostu, on će prvo da utvrdi da li je host koji pruža taj servis pao ili je nedostupan.

Postojanje hijerarhije hostova omogućava Nagiosu da razlikuje ova dva slučaja. Ako komanda provere

udalјenog hosta vrati “non-OK” status, Nagios će proveravati uređaje i servise između njih sve dok se

ne vrati “OK” status. Na ovaj način Nagios utvrđuje da li je problem servisa nastao padom hosta,

padom mrežnog linka (dakle, zbog nedostupnosti) ili se zaista radi samo o padu servisa.

Tabela ispod opisuje kako plagin vraća kod predstavlјajući stanje hosta. “WARNING” obično znači da

je host “UP”, međutim ako je opciji “Aggressive Host Checking Option” dodelјena vrednost

“use_agressive_host_checking=1”, to će rezultovati “DOWN” statusom hosta.

13

Tabela 2 Predstavlјanje stanja hosta

Plugin result Preliminary host result

OK UP

Warning UP or DOWN

UKNOWN UKNOWN

CRITICAL DOWN

1.4.4 Virtuelni hostovi

U hijerarhiju hostova se mogu uklјučiti i virtuelni hostovi (“dummy hosts”) koji fizički ne postoje.

Motivacija za definisanje ovakvih hostova se javlјa zato virtualne mašine čine veoma važnu ulogu u

današnjoj IT infrastrukturi. Virtuelni host najčešće predstavlјa neku virtualnu mašinu koja pripada

fizičkom računaru.

1.5 Vrste statusa

Trenutno stanje nekog servisa ili hosta u Nagiosu određeno je dvema komponentama: statusom i

stanjem. Nagios razlikuje tri vrste statusa hostova.

Host može imati jedan od sledeća tri statusa:

“UP” – regularni status kada je host operativan,

“DOWN” – neregularni status kada host nije operativan i

“UNREACHABLE” – neodređeni status hosta koji je nedostupan procesu nadgledanja i koji

treba da reflektuje nemogućnost Nagiosa da utvrdi pravi status hosta.

Na isti način, u Nagiosu servis može biti u jednom od četiri definisana statusa:

1. “OK” – regularni status servisa kada se servis ponaša na očekivan način,

2. “WARNING” – status upozorenja koji signalizira pogoršani status servisa, koji pri tom još uvek

funkcioniše,

3. “CRITICAL” – neregularni status servisa koji signalizira grešku ili neregularno ponašanje

servisa i

4. “UNKNOWN” – neodređeni status servisa koji signalizira da iz nepoznatih razloga status servisa

nije mogao biti određen.

Ovde treba primetiti da su iznad data samo uopštena tumačenja statusa hostova i servisa sa kojima

jezgro operiše. Pravo tumačenje statusa hostova i servisa zavisi od konkretnog slučaja kao i načina

provere. Uobičajeni način provere statusa hostova je ispitivanje pomoću komande “check_command”

koja će pingovati host. Ako host ne odgovori na ping tj. ne vrati status OK (0) imaće status “DOWN” i

smatraće se neoperativnim. Međutim, u slučaju hosta sa više mrežnih interfejsa u istoj situaciji, može

se zaklјučiti da je dati interfejs hosta van funkcije.

14

1.6 Tipovi stanja

Tipovi stanja su klјučni deo Nagiosovog jezgra jer se njima kontroliše pokretanje “event” hendlera i

alarmiranje nadležnih kontakata. Nagios razlikuje dva tipa stanja – “SOFT” i “HARD” stanje.

Tokom rada programa, iako je nadgledani servis ili host u ispravnom stanju, usled izvesnih problema

na mreži moguće je da za određeni servis ili host Nagios dobije negativan rezultat provere “non-OK”

status. Da bi se sprečili lažni alarmi, Nagios omogućava da se definiše broj ponovnih pokušaja provere

servisa ili hosta pre nego što se zaklјuči da postoji realan problem. Maksimalni broj ovih pokušaja se

kontroliše max_checks_attempts direktivom u definicijama hostova i servisa. Pod predpostavkom da je

definisani broj provera 1, sve promene će istovremeno biti tretirane kao “HARD” stanje. Sledeća slika

prikazuje promenu iz “SOFT” stanja u “HARD” stanje, gde je definisani broj provera servisa 3.

Slika 3 Promena iz “SOFT” stanja u “HARD” stanje

1.6.1 “Soft” stanje

Da bi se sprečile lažne uzbune zbog trenutnih problema, Nagios omogućava da se definiše koliko puta

će se proveravati servis ili host pre nego što će se poslati notifikacija za “pravi” problem. Ova situacija

se kontroliše pomoću “max_check_attempts” opcije u objektima hostova i servisa.

Servisi i hostovi ulaze u SOFT stanje u sledećim situacijama:

kada provera hosta ili servisa rezultuje “non-OK” statusom, a da pri tom još nije pokušana

ponovna provera određeni broj puta. Ovaj broj je definisan “max_check_attempts” direktivom

u definicijama servisa i hostova. Ovo se naziva “SOFT” stanjem greške.

Kada se servis ili host oporavi iz “SOFT” stanja greške. Ovo se naziva “SOFT” oporavkom.

Događaji u “soft” stanju

Kada servis ili host uđe u “SOFT” stanje greške ili doživi “SOFT” oporavak dešava se sledeće:

SOFT greška ili oporavak se loguju ako je to omogućeno “log_service_retries” ili

“log_host_retries” direktivom u glavnom konfiguracionom datoteci.

Izvršavaju se “event” hendleri (ako su definisani) i hendluju “SOFT” grešku ili oporavak servisa

ili hosta. (Pre nego što se izvrši bilo koji hendler, “$HOSTSTATETYPE$” ili

“$SERVICESTATETYPE$” makro uzima vrednost “SOFT” koji daje informaciju hendler

skripti da li treba da preuzme korektivnu akciju ).

Nagios ne šalјe obaveštenja ni jednom kontaktu jer ne postoji realni problem sa servisom ili

hostom.

Kao što se može videti, jedina važna stvar tokom “SOFT” stanja je izvršavanje “event” hendlera.

Korišćenje “event” hendlera može biti posebno korisno ako želimo da pokušamo da rešimo problem

pre nego što host ili servis pređu u “HARD” stanje.

1.6.2 “Hard” stanje

Servisi ulaze u “HARD” stanje u sledećim situacijama:

15

kada provera servisa ili hosta vrati “non-OK” status pri čemu je prethodno pokušan određeni broj

ponovnih provera definisan u definiciji servisa. Tada je servis ili host u “HARD” stanju greške.

kada se servis ili host oporavi iz “HARD”stanja greške. To se naziva “HARD” oporavkom.

kada provera servisa rezultuje non-OK statusom pri čemu je odgovarajući host ili “DOWN” ili

“UNREACHABLE”. Ovo je odstupanje od opšte logike nadgledanja, ali ima savršenog smisla.

Ako host nije živ, onda nema smisla pokušavati ponovnu proveru servisa.

kada servis ili host prelazi iz jednog “HARD” statusa u drugo (”WARNING” u “CRITICAL”)

Kada je je “passive_host_check” primlјen pasivna provera hostova će biti definisana kao greška

ukoliko se u glavnom konfiguracionom fajlu “nagios.cfg” opciji “Passive Service Check

Acceptance Option” ne dodeli vrednost “accept_passive_service_checks=1”.

1.6.3 Promene “hard” stanja

Promene “HARD” stanja se dešavaju kada se:

“OK” status u “HARD” stanju promeni u “non-OK” status u “HARD”stanju.

“non-OK” status u “HARD”stanju promeni u OK status u “HARD”stanju.

“non-OK” status neke vrste u “HARD”stanju promeni u “non-OK” status druge vrste u

“HARD”stanju (npr. iz “WARNING” statusa u “UKNOWN” status)

1.6.4 Događaji u “hard” stanju

Šta se dešava kad servis ili host uđe u “HARD” stanje greške ili doživi “HARD” oporavak zavisi od

toga da li se dogodila promena “HARD” stanja (opisano iznad). Ako se dogodila promena “HARD”

stanja i servis ili host je u “non-OK” status dogodiće se sledeće:

problem servisa ili hosta se loguje

izvršavaju se “event” hendleri (ako su definisani) koji hendluju “HARD” problem servisa ili

hosta. (Pre nego što se izvrši bilo koji hendler, “$SERVICESTATETYPE$” ili

“$HOSTSTATETYPE$” makro uzima vrednost ”HARD”).

kontakti će biti obavešteni o problemu hosta ili servisa (ako logika obaveštenja to dozvoli)

Ako se dogodila promena hard stanja i servis ili host je u “OK” statusu, dogodiće se sledeće:

hard oporavak servisa ili hosta se loguje

izvršavaju se “event” hendleri (ako su definisani) koji hendluju “HARD” oporavak servisa ili

hosta. (Pre nego što se izvrši bilo koji hendler, “$HOSTSTATETYPE$” ili

“$SERVICESTATETYPE$” makro uzima vrednost ”HARD”).

kontakti će biti obavešteni o oporavku hosta ili servisa (ako logika obaveštenja to dozvoli)

Ako se ne dogodi promena “HARD” stanja, a pri tom je servis ili host u “non-OK” statusu, dogodiće

se sledeće:

kontakti će biti ponovno obavešteni o problemu hosta ili servisa (ako logika obaveštenja to

dozvoli).

Ako se ne dogodi promena “HARD” stanja, a pri tom je host ili servis u “OK” statusu, ništa se neće

dogoditi zato što je host ili servis u “OK” statusu kao što je bio i pre provere.

16

1.7 Raspoređivanje provera servisa u vremenu

1.7.1 Konfiguracione direktive

Način na koji jezgro Nagiosa raspoređuje provere servisa u vremenu, izvršava ih i obrađuje, kontroliše

se pomoću nekoliko globalnih i nekoliko lokalnih konfiguracionih direktiva. Svaka definicija servisa

obavezno sadrži 2 direktive ali postoje više direktiva kojim se lokalno, za posmatrani servis, definišu

uobičajeni period provere servisa, period provere servisa kada se nađe u “SOFT” stanju, validni period

u toku kog je dozvolјeno izvršavanje provera i dozvolјeni broj provera servisa:

”check_period”

“retry_interval”

“check_interval”

“max_check_attempts”

Pored navedenih direktiva, postoje još četiri direktive u glavnoj konfiguracionoj datoteci koje globalno

utiču na način izvršavanja provera servisa. To su:

“service_inter_check_delay_method” (ova opcija omogućava podešavanje prosečnog intervala

provere i pomeranje provere svih servisa za taj prosecan interval čime se postiže optimalno

korišćenje resursa “CPU-a”).

“max_concurrent_checks” (ova opcija dozvolјava da se definiše maksimalni broj provera servisa

koji može biti izvršen paralelno u bilo koje vreme).

“service_interleave_factor” (ova promenlјiva definiše kako će se provere servisa međusobno

“ukrštati”. Ovaj način se koristi da bi se izjednačila raspodela provere servisa, smanjilo

opterećenje na udalјenim hostovima i brže detektovanje problema na svim hostovima).

“check_result_reaper_frequency” (ova promenlјiva definiše koliko često će Nagios proveravati

rezultate provere hostova i servisa koje treba obraditi).

Uobičajeni period provere servisa

Dokle god je određeni servis u “HARD” stanju, njegove provere se normalno raspoređuju sa

učestalošću definisanom “check_interval” direktivom.

1.7.2 Raspoređivanje provera u problematičnim situacijama

Kada nastupe problemi sa određenim servisom, jedna od stvari koja će se dogoditi je preraspoređivanje

narednih provera. Ako “max_check_attempts” parametar u definiciji servisa ima vrednost veću od 1,

Nagios će ponoviti proveru servisa pre nego što zaklјuči da problem zaista postoji. Dok se servis

ponovno proverava on je u “SOFT” stanju, a provere servisa se raspoređuju u skladu sa učestalošću

definisanom “retry_interval” direktivom u definiciji servisa, što može biti brže ili sporije u odnosu na

“check_interval” direktivu.

Ako se za “max_check_attempts” parametar zada vrednost 1, servis se nikad neće proveravati u

intervalima definisanim “retry_interval” direktivom. Umesto toga, servis odmah dobija “non-OK”

status, ali ostaje u “HARD” stanju i njegove provere će se i nadalјe raspoređivati nepromenjenom

učestanošću.

Ako definisani broj ponovnih provera servisa opet vrati “non-OK” status servisa, on prelazi u

“HARD” stanje, šalјe se obaveštenje nadležnim kontaktima, i vrši se preraspoređivanje njegovih

budućih provera u skladu sa učestanošću definisanom “check_interval” direktivom.

17

Opisana procedura se ne primenjuje u sledećim situacijama. Kada provera servisa vrati “non-OK”

status, Nagios će odmah zatim proveriti status hosta kome je taj servis pridružen. Ako host ne bude

imao “UP” status (već “DOWN” ili “UNREACHABLE”), Nagios će servisu odmah pridružiti

“HARD” “non-OK” status i resetovaće trenutni broj pokušaja provera na 1. Pošto je servis u “HARD”

stanju, naredne provere ovog servisa će biti preraspoređena u skladu sa normalnom učestalošću

provera definisanom “check_interval” direktivom umesto “retry_interval” direktivom.

1.7.3 Validni period provera

Direktiva “check_period” u definiciji servisa definiše validan vremenski period tokom kog Nagios

dozvolјava izvršavanje provera za taj servis. Bez obzira na status u kom se određeni servis nalazi, ako

se vremenski trenutak za koji je predviđeno izvršavanje provere ne nalazi unutar definisanog validnog

perioda provera, provera se neće izvršiti. Umesto toga Nagios će prerasporediti sledeću proveru servisa

za prvi sledeći validni period.

Ovde treba naglasiti da su raspoređivanje i izvršavanje provera dve jasno razgraničene (iako povezane)

stvari. Iako provera servisa možda neće moći da se izvrši u zadato vreme, Nagios može da je rasporedi

za to vreme. Ovo se najčešće dešava tokom inicijalnog raspoređivanja van validnog perioda provera.

Kada dođe vreme za izvršavanje provere, Nagios će proveriti da li ona zaista može da se pokrene u to

vreme. Ako ne može, Nagios ne izvršava proveru već je samo preraspoređuje za neki kasniji trenutak.

1.7.4 Učešlјavanje servisa (“interleaving”)

Ujednačavanje opterećenja nadgledanih hostova je naročito važno kod paralelizacije provera servisa.

Ako se nadgleda ogroman broj servisa na udalјenom hostu i provere nisu raspoređene u vremenu,

udalјeni host bi mogao “pomisliti” da je žrtva sinhronizovanog napada jer bi postojalo mnogo

otvorenih konekcija na istom portu. Učešlјavanje omogućava ravnomernu distribuciju provera servisa,

smanjenje opterećenja na udalјenim hostovima, i povećava brzinu detektovanja problema svih hostova.

Ideja ove optimizacije je da svi istovremeno proveravani servisi budu pridruženi različitiim

hostovima. U tu svrhu u Nagiosu je uveden faktor učešlјavanja. Na način izračunavanja ovog faktora

utiče se pomoću “service_interleave_factor” direktive u glavnoj konfiguracionoj datoteci. Sledeća

formula ilustruje princip rada “smart” izračunavanja faktora učešlјavanja provera pošto je to opcija

koja se obično koristi u normalnom radu.

faktor učešlјavanja = (ukupan br. servisa) / (ukupan br. hostova)

Na primer, predpostavimo da nadgledamo ukupno 1000 servisa na 150 hostova. Nagios će izračunati

da faktor učešlјavanja iznosi 7. To znači da će redosled inicijalnih provera servisa podrazumevati

uzastopno raspoređivanje svakog sedmog servisa na listi od svih 1000 servisa. Ovaj proces se ponavlјa

dok sve provere servisa ne dobiju svoj raspored. Pošto su svi servisi sortirani po imenu hosta kome su

pridruženi, ovo će pomoći ujednačavanju opterećenja kojem su izloženi nadgledani hostovi.

Slika 3. opisuje raspoređivanje inicijalnih provera servisa sa učešlјavanjem, odnosno sa vrednostima

faktora interlivinga 4, dok slika 4. opisuje raspoređivanje provera bez učešlјavanja tj. faktor

učešlјavanja je 1.

18

Slika 4 Raspoređivanje provera sa faktorom učešlјavanja 4

19

Slika 5 Raspoređivanje provera bez učešlјavanja. Faktor učešlјavanja = 1

1.7.5 Maksimalni broj paralelnih provera servisa

Da bi se Nagios sprečio da zauzme više od zadatog dozvolјenog procesorskog vremena računara, može

se zadati maksimalan broj paralelnih provera servisa tj. broj provera koje mogu simultano da se

izvršavaju. Ovo je kontrolisano “max_concurrent_checks” direktivom u glavnoj konfiguracionoj

datoteci.

Ideja je da se na neki način Nagiosu limitira opterećenje procesora. Pogrešno setovanje ove direktive je

potencijalno opasno ako se zada previše niska vrednost ove opcije za sve pretpostavlјene provere

20

servisa. Kada nastupi trenutak da se izvrši određena provera, Nagios će se prvo uveriti da ne postoji

više od “n” provera servisa koje se trenutno izvršavaju ili čekaju da se njihovi rezultati obrade (gde je

“n” broj provera zadat u “max_concurrent_checks” direktivi). Ako je granica dostignuta, Nagios će

odložiti izvršavanje provera dok se predhodne provere ne završe. Stoga je važno da se odredi razumna

vrednost za ovu opciju. Pre svega mora da se zna sledeće:

vrednost “host_inter_check_delay_metod” koje Nagios koristi za inicijalno raspoređivanje

provera servisa (ovo saznajemo pokretanjem Nagiosa sa “–s” opcijom).

učestalost (u sekundama) obrade prikuplјenih rezultata provera što je

definisano ”check_result_reaper_frequency” promenlјivom u glavnoj konfiguracionoj datoteci.

približno prosečno vreme potrebno proveri servisa da se izvrši (većina plaginova se nasilno

prekida nakon 10 sekundi, tako da je prosek verovatno ispod ove vrednosti).

Sledeća formula ilustruje princip na osnovu kog Nagios računa maksimalan broja konkurentnih

provera:

“max_concurrent_checks = [max (check_result_reaper_frequency) / (host_inter_check_delay_metod)]”

Broj dobijen ovom formulom bi trebalo da bude razumna polazna vrednost za

“max_concurrent_checks” parametar. Ovu vrednost je potrebno malo povećati ako se primeti da

provere servisa i dalјe kasne u odnosu na vremena za koja su raspoređene ili malo smanjiti ako Nagios

i dalјe uzima previše procesorskog vremena.

Na primer, pretpostavimo da se nadgleda 950 servisa sa prosečnim intervalom provere od 3 minuta.

Interval između dve uzastopne provere će biti 0,189. Ako se frekvencija obrade rezultata provera

postavi na 10s, vrednost “max_concurrent_checks” parametra se može grubo proceniti na sledeći

način (podrazumevano je da je prosečno vreme izvršavanja provere servisa manje od 10s):

maks. br. paralelnih provera = ceo deo (10 / 0,189)

U ovom slučaju izračunata vrednost je 53. To ima smisla pošto će Nagios (u proseku) izvršavati više

od 5 novih provera servisa u sekundi pri čemu se obrada rezultata izvršava tokom 10 sek. To znači da

je moguće istovremeno postojanje nešto više od 50 procesa (“treads”) provera servisa koje se

izvršavaju ili čekaju da njihovi rezultati budu obrađeni. U ovom slučaju, savetuje se povećanje

vrednosti “max_concurrent_checks” parametra na 60 pošto će uvek postojati neka kašnjenja kada

Nagios bude obrađivao rezultate provera i u isto vreme bude vršio još neke poslove. Očigledno, da bi

se uverili da na sistemu sve radi glatko potrebno je izvršiti testiranje sa nekoliko vrednosti ove

promenlјive, pri čemu bi ovaj proračun trebalo da da grubu procenu tražene vrednosti.

1.7.6 Provere hostova

Za razliku od provera servisa, provere hostova se ne vrše periodično. Umesto toga one se izvršavaju

samo u slučaju kada provera servisa koji je pridružen tom hostu vrati “non-OK” status. Nagios

proverava host da bi zaklјučio da li je “UP”, “DOWN” ili “UNREACHABLE”. Ako prva provera

hosta vrati “non-OK” status, Nagios će nastaviti sa proverom hosta:

dok se ne dostigne maksimalni broj ponovnih pokušaja provera hosta (definisano

“max_check_attempts” direktivom u definiciji hosta) ili

dok provera hosta ne rezultuje “OK” statusom.

21

Takođe, kada Nagios proveri status hosta privremeno se obustavlјaju izvršavanja novih provera

servisa, obrada rezultata drugih provera servisa, itd. Ovo može malo da uspori odvijanje procesa

nadgledanja i da izazove mali zastoj provera servisa, međutim da bi Nagios nastavio sa dalјim

proverama problematičnog servisa, neophodno je da se utvrdi status hosta.

1.7.7 Kašnjenje

Raspoređivanje i izvršavanje provera servisa u Nagiosu funkcioniše na “best effort” bazi. Individualne

provere servisa se tretiraju kao događaji niskog prioriteta te one mogu da budu odložene ako postoji

potreba za izvršavanjem događaja višeg prioriteta. Primeri događaja visokog prioriteta su: rotacija

“log-a”, provere eksternih komandi i obrada rezultata provera. Izvršavanje i obradu provera servisa

dodatno usporavaju provere hostova.

1.7.8 Detekcija flapovanja servisa

Nagios podržava dodatnu detekciju statusa hostova i servisa koji „flapuju“. Flapovanje se dešava kada

se status servisa ili hosta brzo menja, što rezultuje problemima i notifikacijama o oporavku. Flapovanje

ukazuje na lošu konfiguraciju ili prave mrežne probleme.

Svakog puta kada Nagios proverava status hosta ili servisa, proveriće da li je flapovanje započeto ili

završeno tako što:

Čuva rezultate poslednjih 21. provera hostova ili servisa

Analizira istoriju rezultata provera i određuje gde su se promene stanja dogodile

Koristi promene stanja da utvrdi procenat promene stanja za hostove ili servise

Upoređuje procenat promene stanja između niske i visoke granice flapovanja

Host ili servis su u flaping stanju kada procenat promene stanja prevazilazi visoku granicu flapovanja,

a izlaze iz flaping stanja kada je procenat promene stanja ispod niske granice flapovanja. Na sledećoj

slici je prikazan način na koji detekcija flapovanja funkcioniše.

Slika 6 Način funkcionisanja stanja flapovanja

Istorijska provera servisa treba da odluči gde se promena tačno dogodila. Promena stanja se dešava

kada je sačuvan status različit od sačuvanog statusa koje je ispred njega hronološki gledano. Pošto se

čuva 21. promena u nizu, moguće je imati maksimalno 20 promena statusa. U ovom primeru postoji 7

promena, koje su označene plavim strelicama.

Logika detektovanja flapovanja koristi promenu stanja da definiše ukupan procenat promene stanja za

servis. Ovo je mera promene/promenlјivosti servisa. Servisi koji nikada ne menjaju status imaće 0%

promene stanja, dok servisi koji uvek menjaju status nakon provere će imati 100% promene stanja.

Većina servisa će imati procenat promene statusa koji je negde između ove dve vrednosti.

Prilikom određivanja procenta promene stanja za servis, algoritam detekcije flapovanja će dati veći

značaj novim stanjima promene nego starim stanjima promene. Konkretno, način detektovanja

22

flapovanja je napravlјen tako najnovije promene stanja imaju 50% veći značaj nego predhodne

promene stanja. Na slici iznad postoje 7 promena stanja ( t3, t4, t5, t9, t12, t16, t19 ). Bez bilo kojeg

davanja značaja promenama stanja tokom vremena, ukupan procenat promene stanja bi bio 35%:

( 7 promena / 20 mogućih promena ) * 100 = 35 %

Pošto će logika detektovanja flapovanja uvek dati veći značaj novoj nego starijoj proveri stanja,

stvaran procenat promene stanja bi bio malo manji od 35% u ovom primeru. Recimo da bi negde oko

31%. Izračunata vrednost promene stanja bi bila upoređena sa granicama flapovanja:

Ako servis predhodno nije flapovao i 31% je jednak ili veći nego gornja granica flapovanja,

Nagios će smatrati da je servis počeo da flapuje.

Ako je servis predhodno flapovao i 31% je manji od donje granice flapovanja, Nagios će

smatrati da je servis prestao da flapuje.

Ako nije ispunjen ni jedan od ovih uslova, logika detektovanja flapovanja neće uraditi ništa sa

servisom, zato što još uvek flapuje ili ne flapuje. Nagios će uvek proveriti da li servis flapuje prilikom

proveravanja servisa ( aktivna ili pasivna provera ). Logika detektovanja flapovanja za servise je

opisana u primeru iznad.

1.7.9 Detekcija flapovanja za hostove

Flapovanje hostova radi na sličan način kao i flapovanje servisa, sa jednom veoma bitnom razlikom –

Nagios će uvek pokušati da proveri da li host flapuje:

Kada se proverava host ( aktivno ili pasivno )

Kada je servis koji pridružen tom hostu proveren. Tačnije, kada je najmanje x vremena prošlo od

izvršavanja detektovanja flapovanja, gde je x prosečan vremenski interval provere svih servisa

pridruženih tom hostu.

Kod servisa minimalan vremenski intervarl između uzastopnih detekcija flapovanja će biti jednak

vremenskom intervalu provere servisa. Ali, možda se hostovi ne prate na redovnoj osnovi, tako da ne

postoji interval provere hosta koji može biti upotreblјen u logici detektovanja flapovanja. Takođe ima

smisla da proveravanje servisa bude ispred detekcije flapovanja hosta. Ipak su servisi atributi koji su

povezani sa hostom.

1.7.10 Granice detektovanja flapovanja

Nagios koristi nekoliko promenlјivi da bi utvrdio granice promene stanja izražene u procentima koje

su neophodne za detektovanje flapovanja. I za hostove i servise postoje globalne visoke i niske granice.

Takođe postoje granice hostova i servisa koje se mogu konfigurisati. Nagios će koristiti globalne

granice za detekciju flapovanja ako se posebno ne definišu za hostove i servise.

Tabela 3Promenlјive za definisanje granica flapovanja

Tip objekta

Globalne promenljive Promenljive unutar definicija objekta

Host low_host_flap_threshold high_host_flap_threshold

low_flap_threshold high_flap_threshold

Servis low_servise_flap_threshold high_service_flap_threshold

low_flap_threshold high_flap_threshold

http://nagios.sourceforge.net/docs/3_0/configmain.html#low_host_flap_threshold

http://nagios.sourceforge.net/docs/3_0/configmain.html#high_host_flap_threshold

http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#host

http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#host

http://nagios.sourceforge.net/docs/3_0/configmain.html#low_host_flap_threshold

http://nagios.sourceforge.net/docs/3_0/configmain.html#high_host_flap_threshold

http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#service

http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#service

23

Naravno, Nagios će pratiti rezultate poslednjih 21. provera hostova i servisa, bez obzira na rezultat

provere.

1.7.11 Upravlјanje flapovanjem

Kada se detektuje flapovanje hostova ili servisa Nagios će:

Sačuvati poruku koja ukazuje da host ili servis flapuje

Dodati komentar hostu ili servisu koji ukazuje da host ili servis flapuju

Poslati "flapping start" notifikaciju za hostove i servise odgovarajućim kontaktima

Zabraniti druge notifikacije za hostove ili servise koji flapuju

Kada host ili servis prestanu sa flapovanjem Nagios će:

Sačuvati poruku koja ukazuje da je host ili servis prestao da flapuje

Obrisaće komentar koji je dodat hostu ili servisu kada je počelo flapovanje

Poslaće "flapping stop" notifikaciju za hostove i servise odgovarajućim kontaktima

Dozvoliće sve notifikacije za hostove i servise

Omogućavanje detekcije Flapovanja

Da bi se omogućila detekcija flapovanja u Nagiosu neophodno je:

Direktivi “enable_flap_detection” u glavnoj konfiguracionoj datoteci dodeliti vrednost 1

Direktivama “flap_detection_enabled” u definicijama hostova i servisa dodeliti vrednost 1

Isklјučivanje detekcije flapovanja na globalnom nivou se vrši tako što se direktivi

“enable_flap_detection” u glavnoj konfiguracionoj datoteci dodeliti vrednost 0. Po želјi se može

isklјučiti i detektovanje flapovanje za određene hostove i servise koristeći direktivu

“flap_detection_enabled”.

1.7.12 Primer raspoređivanja provere servisa

Princip raspoređivanje provera servisa, njihovo izvršavanje i obrada njihovih rezultata je ilustrovan

sledećim prostim primerom. Na slici 5, sa “xn” su označeni trenuci u kojima se vrši prikuplјanje i

obrada rezultata provera. Oni su periodično raspoređeni sa učestalošću definisanom

“check_result_reaper_frequency” direktivom u glavnoj konfiguracionoj datoteci. U ovim trenucima

jezgro Nagiosa obrađuje rezultate provera koje prikuplјaju plaginovi, i po potrebi generiše zahteve za

proverom hostova, izvršavanjem “event” hendlera ili obaveštavanjem.

Slika 7 Raspoređivanje provera servisa u vremenu

http://nagios.sourceforge.net/docs/3_0/configmain.html#enable_flap_detection

http://nagios.sourceforge.net/docs/3_0/configmain.html#enable_flap_detection

24

U ovom primeru provera nekog servisa je raspoređena za izvršavanje u trenutku “A”. Međutim,

Nagios se vratio svom “event” redu za čekanje, te provera zapravo počinje da se izvršava u trenutku

“B”. Provera se završava u trenutku “C”, tako da je interval između trenutaka “B” i “C” istinito vreme

izvršavanja provere.

Rezultati provere servisa se ne obrađuju odmah nakon okončanja provere, već se čuvaju do momenta

kada jezgro prikuplјa i obrađuje zatečene rezultate svih provera. Sledeći ovakav događaj se dešava u

trenutku “D” tako da je to približno trenutak u kome počinje obrada rezultata (pravo vreme obrade

može biti nešto posle trenutka “D” pošto je moguće da se prethodno obrađuju rezultati drugih provera

servisa). U trenutku kada jezgro obrađuje rezultate provere posmatranog servisa, vrši se raspoređivanje

njegove sledeće provere i smešta u red za čekanje. Ako pretpostavimo da je provera servisa vratila

“OK” status, sledeća provera će biti raspoređena za trenutak “E” koji je udalјen od prethodno

raspoređenog trenutka “A” tačno za normalni interval provere servisa. Ovde je važno uočiti da sledeća

provera (trenutak “E”) nije preraspoređena na bazi trenutka u kom je stvarno (tj. sa zakašnjenjem)

počela da se izvršava!

Izuzetno, ako se trenutak u kom započinje stvarno izvršavanje provere (trenutak “B”) desi posle

trenutka sledeće provere servisa (trenutak “E”), Nagios će to kompenzovati raspoređivanjem sledećeg

trenutka provere za još jedan normalni interval. Ovome se pribegava da Nagios ne bi uzaludno

pokušavao da drži tempo sa proverama u slučaju da postane preopterećen.

1.8 Vremenski intervali

Mogućnost definisanja vremenskih intervala obezbeđuje veću kontrolu nad trenucima kada provere

servisa mogu da se izvršavaju, kada obaveštenja o hostovima ili servisima mogu da se šalјu i kada

kontakti mogu da primaju obaveštenja. Sa ovim opcijama dolaze i potencijalni problemi o kojima će

više reči biti kasnije.

1.8.1 Kako vremenski periodi utiču na provere servisa

Bez implementacije vremenskih perioda Nagios bi nadgledao sve definisane servise 24 časa dnevno, 7

dana u nedelјi (24x7). Dok je to odgovarajuće za mnoge potrebe nadgledanja, postoje servisi kojima to

nije neophodno. Primera radi, ne postoji potreba za celodnevnim nadgledanjem štampača koji se inače

koriste samo tokom radnog vremena. Takođe, status nekih razvojnih servera na mreži obično nije

kritičan i nadgledanje njihovog statusa nije od značaja tokom vikenda. Iz ovakvih razloga u Nagios je

implementirana mogućnost definisanja vremenskih intervala i perioda koji omogućavaju kontrolu nad

vremenom kada će koji servisi moći da se nadgledaju.

U svakoj definiciji servisa, argument direktive “check_period” omogućava da se definiše vremenski

period u kome je Nagiosu dozvolјeno da nadgleda posmatrani servis. Pre nego što Nagios pokuša da

prerasporedi proveru servisa, on će se prvo uveriti da li sledeća provera upada u definisani period. Ako

ne, Nagios će rasporediti sledeću proveru na početak sledećeg validnog perioda. To znači da servisi

možda neće biti proveravani tokom narednog časa, dana ili nedelјe, itd.

1.8.2 Potencijalni problemi sa vremenskim periodima

Pri korišćenju perioda koji ne pokrivaju čitav 24x7 period, mogući su izvesni problemi, naročito ako

servis (ili njegov odgovarajući host) postane neoperativan u situaciji kada je sledeća provera servisa

odložena za sledeći validni period provera. Evo nekih problema koji se mogu javiti:

kontakti se ne obaveštavaju ponovno o problemima sa servisom do izvršavanja sledeće provere,

ako se servis oporavi tokom perioda van validnog perioda za provere, kontakti neće biti

obavešteni o tom oporavku,

status servisa će se na veb interfejsu i u status log datoteci prikazivati kao nepromenjen do

sledeće provere,

25

ako su svi servisi pridruženi određenom hostu podešeni na isti period provere, problemi sa

hostom ili oporavci neće biti registrovani dok se ne izvrši jedna provera servisa (i stoga

obaveštenja mogu da kasne ili da uopšte ne budu poslata).

Očigledno, potencijalni problemi se uglavnom sastoje u nepouzdanom prikazu podataka, te je na

korisniku da odluči da li mu je bitnije da ima pouzdane informacije o stanju nekih manje važnih

hostova ili servisa na mreži, ili da umanji opterećenje sistema sprečavanjem izvršavanja provera tokom

časova van radnog vremena, vikendom i sl.

1.8.3 Kako vremenski periodi utiču na obaveštavanje kontakata

Verovatno najkorisnija stvar kod vremenskih perioda je kontrola trenutka kada će obaveštenje biti

poslato nadležnim kontaktima. Pomoću “service_notification_period” i “host_notification_period”

direktiva u definicijama kontakata može se definisati period u toku kog je dozvolјeno obaveštavanje

kontakta. Ovde treba primetiti da je omogućeno zasebno definisanje različitih periode za obaveštenja o

hostovima i servisima. Ovo je, na primer, od koristi ako se želi da svakodnevno budemo obaveštavani

o hostovima, a da obavešavanje o statusu servisa bude omogućeno samo radnim danima. Važno je

napomenuti da bi ova dva perioda obaveštavanja trebalo da pokriju sve raspoloživo vreme tokom kog

kontakt može biti obavešten. Takođe, kontrola perioda obaveštavanja može da se definiše za svaki

servis i host ponaosob.

Pomoću “notification_period” direktive u definiciji hosta može se kontrolisati kada je Nagiosu

dozvolјeno da šalјe obaveštenje o problemima ili oporavcima hosta. Kada Nagios kreira obaveštenje

on će se pre slanja uveriti da li tekući trenutak ulazi u validni period definisan “notification_period”

direktivom. Ako je trenutak validan, Nagios će pokušati da obavesti sve kontakte o problemu sa

hostom. Neki od kontakata možda neće primiti ovo obaveštenje ako njihov lokalno definisani (u

definiciji kontakta) “host_notification_period” u datom trenutku to ne dozvolјava. Ako dati trenutak

ne ulazi u “notification_period”, niko se ne obaveštava.

Periodi obaveštavanja o servisima kontrolišu se na isti način. Definisanjem “notification_period”

direktive u definiciji servisa, kontroliše se period u kome Nagios može da obaveštava kontakte o

problemima ili oporavcima tog servisa. Kada Nagios kreira obaveštenje on će se pre slanja uveriti da li

tekući trenutak ulazi u validni period definisan “notification_period” direktivom. Ako je trenutak

validan, Nagios će pokušati da obavesti sve kontakte o problemu sa servisom. Neki kontakti možda

neće biti obavešteni ako njihov lokalno definisani (u definiciji kontakta) “service_notification_period”

to ne dozvolјava u datom trenutku. Ako dati trenutak ne ulazi u “notification_period”, niko se ne

obaveštava.

1.8.4 Potencijalni problemi sa obaveštavanjem kontakata

Kada se radi o obaveštavanju kontakata, ne može se pojaviti nijedan značajniji problem usled

proizvolјnog definisanja perioda obaveštavanja kontakata. Jedino što se može desiti jeste da kontakti

možda neće uvek biti obavešteni o problemima hostova ili servisa, ili o njihovim oporavcima. Ako

tekući trenutak ne ulazi ni u period obaveštavanja servisa ili hosta, niti period obaveštavanja kontakta,

obaveštenje se briše.

1.8.5 Zaklјučak

Vremenski periodi omogućavaju zaista preciznu kontrolu nad trenucima izvršavanja funkcija

nadgledanja i obaveštavanja. S druge strane, ova funkcionalnost jezgra može da donese izvesne

probleme. U slučaju pojavlјivanja problema sa tekućom implemetacijom, korisnik uvek može da se

vrati korišćenju standardnog “24x7” perioda za sve provere i sva obaveštenja.

Korišćenje validnih perioda obaveštavanja kontakata bi bilo jako važno ako bi se obaveštavanje

realizovalo pomoću SMS ili pejdžing poruka. Pošto je u ovoj implementaciji Nagiosa korišćeno

26

obaveštavanje putem elektronske pošte, konfigurisanju validnih perioda nije posvećena naročita pažnja.

Validni vremenski periodi za sve provere i sva obaveštenja su standardni “24x7” period.

1.9 Obaveštavanje

Jedna od jako važnih funkcija ugrađenih u jezgro Nagiosa je funkcija alarmiranja ili obaveštavanja

nadležnih kontakata u slučaju da određeni servis ili host dobije problematičan status.

1.9.1 Kada se podiže alarm

Odluka o slanju obaveštenja donosi se logikom provere servisa i provere hostova. Obaveštenja o hostu

i servisu dešavaju se u sledećim slučajevima:

promena “HARD” stanja.

ostanak servisa ili hosta u “HARD” “non-OK” statusu tokom vremenskog intervala definisanog

“notification_interval” direktivom u definiciji hosta ili servisa od trenutka slanja poslednjeg

obaveštenja. Ovo se odnosi na specificirani host ili servis. Ako se ne želi periodično

ponavlјanje obaveštavanja, u “notification_interval” direktivi definicije hosta ili servisa treba

postaviti vrednost 0 što onemogućava obaveštavanje više od jednog puta za zadati problem.

1.9.2 Ko se obaveštava

Svaka definicija servisa ima opciju “contact_groups” koja definiše koje grupe kontakata primaju

obaveštenja o tom servisu. Svaka grupa kontakata može da sadrži jedan ili više individualnih kontakata.

Kada Nagios šalјe obaveštenje o servisu, on će obavestiti svaki kontakt koji je član definisanih grupa

kontakata u pomenutoj opciji definicije servisa. Nagios je svestan da bilo koji dati kontakt može biti

član više grupa te stoga uklanja duplirana obaveštenja kontaktima pre nego što alarmira bilo koga.

Svaki host može da pripada jednoj ili više grupa hostova. Takođe, svaka grupa hostova ima opciju

“contact_groups” koja definiše grupe kontakata koji primaju obaveštenja o hostovima iz date grupe

hostova. Kada Nagios šalјe obaveštenje o nekom hostu, on će obavestiti kontakte koji su članovi bilo

koje

grupe kontakata koji treba da budu obavešteni o bilo kom hostu te grupe hostova čiji je dati host član.

Problem duplikata se rešava na isti način kao što je objašnjeno u prethodnom pasusu.

1.9.3 Filteri obaveštenja

Ako postoji potreba da se pošalјe obaveštenje o nekom hostu ili servisu, to ne znači da će bilo koji

kontakt biti odmah obavešten. Postoji nekoliko filtera koje potencijalno obaveštenje mora da prođe pre

nego što bude smatrano za dovolјno važno da bi zaista bilo poslato. Čak i tad, određeni kontakti možda

neće biti obavešteni ako lokalno definisani filteri obaveštenja (u definiciji kontakta) ne dozvolјavaju da

im se pošalјe obaveštenje.

1.9.4 Konfigurisanje notifikacija

Osnovni filter koji obaveštenja moraju da prođu jeste opšta provera da li je opcija obaveštavanja

omogućena na nivou čitave konfiguracije. To je inicijalno određeno direktivom ”enable_notifications”

u glavnoj konfiguracionoj datoteci, ali može biti promenjeno tokom rada programa putem web

interfejsa. Direktivi ”enable_notifications” treba dodeliti vrednost 1 da bi notifikacije bile omogućene.

Vrednost 0 će isklјučiti notifikacije. Ako su obaveštenja onemogućena na nivou čitave konfiguracije,

niko neće biti obavešten. U suprotnom potencijalna obaveštenja se dalјe obrađuju manje opštim

filtrima.

27

Sledeći filter je selektovanje stanja hosta koje će biti poslato kao notifikacija. Moguće je

kombinovanje više tipova notifikacija korišćenjem direktive “notification_options” u objektu hosta

tako što se ovoj direktivi proslede neki od sledećih filtera [“D”,”U”,”R”,”F”,”S”,”N”]. Svi ovi filteri

šalјu određenu vrstu notifikacije:

“D” kada host ima “DOWN” stanje

“U” označava “UNREACHABLE” stanje

“R” prilikom oporavka (OK stanje)

“F” kada servis flapuje (brza promena stanja “UP” i “DOWN”)

“S” kada planirani „DOWNTIME“ hostova i servisa počinje tj. Završava

“N” isklјučuje notifikacije za sve hostove

Primera radi, ako postavimo filtere “D”,”R” primaćemo notifikacije samo kada host bude “DOWN” i

oporavi iz “DOWN” stanja. Ako nisu potrebne notifikacije za host koji se nadgleda, može se isklјučiti

slanje notifikacija tako što se direktivi notifications_enabled u definiciji hosta dodeli vrednost 0.

Pomoću narednog filtera definišemo situacije u kojima će se poslati notifikacija za servise koje

nadgledamo. Način definisanja ovih situacija je identičan kao kod hostova. Moguće je kombinovanje

više tipova notifikacija korišćenjem direktive notification_options u objektu servisa tako što se ovoj

direktivi proslede neki od sledećih filtera [“W”,”U”,”C”,”R”,”F”,”N”]. Svi ovi filteri salјu određenu

vrstu notifikacije:

“W” označava “WARNING”stanje

“U” označava “UKNOWN” stanje

“C” označava “CRITICAL” stanje

“R” prilikom oporavka (OK stanje)

“F” kada servis flapuje (brza promena stanja “UP” i “DOWN”)

“N”isklјučuje notifikacije za sve servise

Recimo, ako postavimo filtere w,r primaćemo notifikacije samo kada servis bude u “WARNING”

stanju i oporavi se iz “WARNING” stanja. Ako ne prosledimo ni jedan filter, primaćemo notifikacije

za sva moguća stanja. Ako nisu potrebne notifikacije za servis koji se nadgleda, može se isklјučiti

slanje notifikacija tako što se direktivi notifications_enabled dodeli vrednost 0.

Obaveštenja o oporavku hosta ili servisa se šalјu samo ako je poslato obaveštenje o

originalnom problemu. Slanje obaveštenja o oporavku nečega što nikad nije bilo u problemu nema

smisla, te se ono i ne šalјe.

Naredni filter je provera da li je u datom trenutku dozvolјeno slanje obaveštenja, tj. da li dati trenutak

pripada validnom vremenskom intervalu u kom je dozvolјeno slati obaveštenja. Svaka definicija hosta

ili servisa sadrži opciju “notification_period” koja definiše vremenski period u kome je dozvolјeno

slati obaveštenja. Ako trenutak kreiranja obaveštenja ne ulazi u validni perod za slanje obaveštenja,

niko se ne obaveštava. U suprotnom obaveštenje se predaje sledećem filtru.

Da li će se nad potencijalnim obaveštenjima izvršiti i poslednji skup filtera zavisi od dve stvari:

1. obaveštenje o problemu sa hostom ili servisom je već poslato u nekom trenutku u prošlosti,

2. host ili servis je ostao u istom “non-OK” statusu u kom je bio prilikom slanja poslednjeg

obaveštenja.

Ako su zadovolјena oba kriterijuma, Nagios će se uveriti da je od poslednjeg obaveštavanja prošlo više

od onoliko vremena koliko je specificirano “notification_interval” opcijom u definiciji hosta ili servisa.

Ako nije prošlo dovolјno vremena niko se ne obaveštava. Ako je pak prošlo ili neki od dva navedena

28

kriterijuma ovog filtra ispunjen, obaveštenje će biti poslato. Da li se obaveštenje šalјe individualnim

kontaktima, stvar je filtera kojim se definišu kontakti koji će primiti notifikacije.

1.9.5 Filteri obaveštenja kontakata

Da bi smo obavestili kontakte tj. određenu grupu kontakta o problemu, prvo ih moramo definisati u

definiciji hosta da bi Nagios znao kojim kontaktima treba da pošalјe notifikacije. Te direktive su

“contacts” i “contacts_groups”. Zatim, pomoću filtera u definiciji kontakta definišemo koji će

kontakti biti obavešteni i u kojim slučajevima će primati notifikacije.

Kada obaveštenje prođe sve ove filtre, Nagios kreće da obaveštava sve one koji treba da saznaju za

problem. To ne znači da će svaki kontakt zaista i primiti obaveštenje. Svaki kontakt ima svoj lokalni

skup filtera koje obaveštenje mora da prođe pre nego što bude poslato. Pri tom ovi filtri su definisani

zasebno za svaki kontakt i ne utiču na obaveštavanje drugih kontakata.

Prvi filter koji mora da se prođe za svaki kontakt su opcije obaveštavanja. Svaka definicija kontakta

sadrži opciju koja definiše tipove obaveštenja o servisu (“WARNINg”, “UKNOWN”, “CRITICAL”,

“RECOVERY”, “FLAPPING” i “NONE”) pomoću direktive “service_notification_options” za koje je

dozvolјeno slanje obaveštenja. Takođe, svaka definicija kontakta sadrži opciju kojom se definišu tipovi

obaveštenja o hostu (“DOWN”, “UNREACHABLE” i “RECOVERY”) pomoću

“host_notification_options” direktive za koje je dozvolјeno obaveštavanje. Ako obaveštenje o hostu ili

servisu ne prođe ove filtre, kontakt neće biti obavešten. U suprotnom obaveštenje se predaje sledećem

filtru.

Obaveštenja o oporavku hosta ili servisa se šalјu samo ako su prethodno poslata obaveštenja o

originalnom problemu. Poslednji filter koji mora da se prođe je provera da li trenutak kreiranja

obaveštenja pripada vremenskom intervalu u kom je dozvolјeno obaveštavanje datog kontakta. Svaka

definicija kontakta sadrži opcije “host_notification_options” i “service_notification_options” koja

definiše ovaj vremenski period. Ako trenutak kreiranja obaveštenja ne ulazi u validni interval za

obaveštavanje, kontakt neće biti obavešten. U suprotnom, kontaktu se šalјe obaveštenje.

Neophodno je i defisati koje komande će se koristiti prilikom obaveštavanja kontakta o problemu hosta

ili oporavku hosta korišćenjem direktive “host_notification_commands”. Naravno, ove komande će se

izvršiti kada kontakt treba da bude obavešten. Takođe, treba i definisati komande koje će se koristiti

prilikom obaveštavanja kontakta o problemima nadgledanih servisa korišćenjem direktive

“service_notification_options” .

Treba i obratiti pažnju na direktivu “notification_timeout” u glavnoj konfiguracionoj datoteci jer ona

utiče na vreme izvršavanja notifikacije. Ako istekne definisani vremenski interval, notifikacija će biti

obustavlјenja a upozorenje će biti zabeleženo tj “logovano”.

1.9.6 Metoda obaveštavanja koje nisu direktno ugrađene u Nagios

Shodno svojoj plagin arhitekturi, nijedna metoda obaveštavanja nije ugrađena u jezgro Nagiosa i posao

obaveštavanja je prepušten spolјašnjem entitetu. Jezgro zahteva jedino da mu se u konfiguraciji

definiše ime i putanja programa ili skripta kome se prosleđuju obaveštenja. Kada bi, primera radi,

provere servisa bile ugrađene u jezgro Nagiosa, korisniku bi bilo jako teško da dodaje nove metode

obaveštavanja, modifikuje postojeće, itd. Ovako, svaki korisnik može da u svoj sistem za nadgledanje

integriše za njega najpodesniji način obaveštavanja, kako u smislu lakoće korišćenja, tako i u smislu

platforme koju koristi i nivoa pouzdanosti koji želi da ostvari. Postoji zaista mnogo različitih načina da

se realizuje obaveštavanje i na internetu se može naći mnogo rešenja i paketa koji to obavlјaju.

Koji će se metod koristiti zavisi od konkretnog okruženja u kom se implementira Nagios. Kada se

donese odluka o izabranom metodu, potrebno je da se instalira odogovarajući dodatni softver i

29

iskonfigurišu komande obaveštavanja u konfiguracionim fajlovima. Ovo je lista samo nekoliko

mogućih načina pomoću kojih Nagios može da šalјe obaveštenja:

Elektronska pošta (email)

SMS (Short Message Service) ili MMS (Multimedia Message Service)

Pejdžer

Instant mesindžeri poput “Yahoo, ICQ, MSN, Jabber” i sl.

Audio signali

Za alternativno korišćenje elektronske pošte za obaveštavanje preko pejdžere ili mobilnih telefona

mogu se koristiti neki od sledećih paketa. Oni se mogu koristiti u kombinaciji sa Nagiosom za

obaveštavanje preko modema o nastalim problemima. Pri tom ne treba se u potpunosti oslanjati na

ovakvo rešenje jer i sam email servis može da otkaže ako postoje problemi u mreži.

“Gnoki” (SMS softver za kontaktiranje “Nokia GMS” telefona)

“QuickPage” (softver za alfanumeričke pejdžere)

“SendPage” (softver za pejdžing)

“SMS Client” (program sa komandnim interfejsom za slanje poruka na pejdžere ili mobilne

telefone)

Zvučno obaveštavanje je jedna od nestandardnih metoda koja se takođe može korisititi. Za zvučno

obaveštavanje na nadgledajućem serveru (sa sintetizovanim govornim porukama) preporučuje se

programski paket Festival. Za zvučno obaveštavanje na udalјenim mašinama na kojima se ne izvršava

nadgledanje vredi pogledati “Network Audio System” (NAS) i “replay” projekte.

1.10 Eskalacije obaveštenja

Nagios sadrži mogućnost definisanja eskalacije obaveštavanja kontakata za hostove i servise. Pod

eskalacijom obaveštenja se podrazumeva definisanje scenarija obaveštavanja nadležnih kontakata u

slučaju da problem sa servisom, hostom ili grupom hostova nastavi da perzistira. U okviru takvog

jednog scenarija, posle određenog broja poslatih obaveštenja moguće je uklјučivanje ili isklјučivanje

određene grupe kontakata sa liste kontakata koji se obaveštavaju, kao i promena dužine intervala

između dva obaveštenja.

Eskalacija obaveštenja mogu se definisati za servis, host ili hostgrupu. Konfigurisanje eskalacija se

vrši definisanjem odgovarajućih objekata za dati servis, host ili grupu hostova u konfiguracionoj

datoteci “escalations.cfg”. U dalјem tekstu kroz jednostavne primere ilustrativan je princip rada

eskalacija.

1.10.1 Kada dolazi do eskalacije obaveštenja

Obaveštenja se eskaliraju ako i samo ako se jedna ili više definicija eskalacija podudari sa tekućim

obaveštenjem koje se šalјe. Ako se za servis, host ili grupu hostova za koje se šalјe obaveštenje ne

pronađe nijedna validna definicija eskalacije koja odgovara tekućem obaveštenju, Nagios će obavestiti

redovne grupe kontakata koje su specificirane u definiciji servisa, hosta ili grupe hostova. Ako pak za

tekuće obaveštenje pronađe validna definicija eskalacije obaveštavanje se vrši na osnovu te definicije.

Definisanje eskalacije je moguća za hostove i servise koji se nadgledaju. Struktura ovih objekta je

identična, i jedina razlika između njih je u tome što se kod eskalacije servisa definiše servis koji se

nadgleda direktivom “service_description”. U sledećem primeru date su dve definicije eskalacije za

nadgledani “HTTP”servis koji se hostuje na računaru “webserver”:

30

“define serviceescalation {

host_name webserver

service_description HTTP

first_notification 3

last_notification 5

notification_interval 90

contact_groups nagios-admins,linux-admins

}

define serviceescalation {

host_name webserver



last_notification 10



}”

Odmah se može primetiti da postoje “rupe” u datim definicijama eskalacija obaveštenja. Konkretno,

prvo i drugo obaveštenje nisu obuhvaćena eskalacijama niti sva preostala posle desetog. Za sva ona

obaveštenja koja nisu obuhvaćena u definicijama eskalacija, Nagios koristi “default” grupe kontakata

definisane u definiciji servisa. U svim primerima pretpostavlјeno je da je ta predefinisana grupa

kontakata “nagios-admins”.

Ako bi se htelo da definicija eskalacije pokrije beskonačan opseg obaveštenja, u smislu od određenog

obaveštenja pa nadalјe, u direktivi “last_notification” treba zadati vrednost 0.

Pomoću direktive “escalation_options” izvršiće se eskalacija ako je stanje hosta ili servisa u unapred

definisanom stanju. Ako ova direktiva nije definisana u “serviceescalation” objektu, eskalacija će biti

validna prilikom svih stanja servisa i hostova. Postoji i “escalation_period” direktiva pomoću koje se

definiše validno vreme eskalacije. Ako ova direktiva nije definisana, eskalacija će biti validna sve

vreme.

1.10.2 Grupe kontakata

Kada se definišu eskalacije obaveštenja, važno je imati na umu da bilo koja grupa kontakata koja je

bila član “nižih” eskalacija (onih sa nižim rednim brojevima obaveštenja) bi trebalo da budu uklјučene

u definicije “viših” eskalacija, da bi bili sigurni da će svako ko bude obavešten o problemu nastaviti da

biva obaveštavan kako problem bude eskalirao.

U prethodno datom primeru, prvi (ili najniži) nivo eskalacije uklјučuje grupe kontakata “nagios-

admins” i “linux-admins”. Poslednji (ili najviši) nivo eskalacije uklјučuje “nagios-admins”, “linux-

admins” i “everyone” grupu kontakata.

Ovde treba uočiti da je predefinisana grupa kontakata nagios-admins uklјučena i u obe definicije

eskalacije kako bi kontakti iz ove grupe bili i dalјe obaveštavani ako problem nastavi da postoji posle

prva dva obaveštenja o servisu. Grupa kontakata “linux-admins” se prvo pojavlјuje u “nižoj“ definiciji

eskalacije – oni se prvi put obaveštavaju kada se pošalјe treće obaveštenje o problemu sa servisom.

31

Kada bi u konfiguraciji postojala samo prva definicija eskalacije servisa, poslednje obaveštenje koje bi

primili u slučaju opstanka problema, bilo bi peto obaveštenje. Pošto se u primeru želi da ova grupa

kontakata (pored grupe “everyone”) bude obaveštavana i nadalјe tokom narednih 5 obaveštenja, ona je

takođe uklјučena i u „višu“ definiciju eskalacije.

1.10.3 Preklapanje opsega eskalacija

Definicije eskalacije obaveštenja mogu imati opsege obaveštenja koji se preklapaju. Primer:

“define serviceescalation {

host_name webserver



last_notification 5



}

define serviceescalation{

host_name webserver



last_notification 0


contact_groups support

}”

U primeru iznad, opisan je sledeći scenario obaveštavanja:

predefinisana grupa kontakata “nagios-admins” se obaveštava prvim i drugim obaveštenjem,

grupe kontakata “nagios-admins” i “linux-admins” se obaveštavaju trećim obaveštenjem,

zbog preklapanja definicija, sve tri grupe kontakata se obaveštavaju četvrtim i petim

obaveštenjem,

šestim i svim dalјim obaveštenjima obaveštava se samo grupa kontakata support.

1.10.4 Obaveštenja o oporavku

Obaveštenja o oporavku su nešto drugačija za razliku o obaveštenja o problemu kada dođe do

eskalacije. Recimo da se u prethodnom primeru oporavak “HTTP” servisa dogodio nakon slanja trećeg

obaveštenja definisanim kontaktima. Obaveštenje o oporavku servisa bilo bi zapravo četvrto poslato

obaveštenje.

32

Međutim, mehanizam eskalacije je dovolјno inteligentan da zaklјuči da obaveštenje o oporavku treba

da pošalјe samo onim kontaktima koji su prethodno obavešteni o problemu zaklјučno sa trećim

obaveštenjem. U ovom slučaju, o oporavku će biti obaveštene grupe kontakata “nagios-admins” i

“linux-admins”, ali ne i support iz već pomenutog razloga.

1.10.5 Intervali obaveštavanja

Korišćenjem “notification_interval” direktive u definiciji eskalacije servisa, hosta ili grupe hostova

može se podešavati učestalost slanja eskaliranih obaveštenja.

Neka je u prvom navedenom primeru predefinisani interval slanja ponovnih obaveštenja za servise 240

min. (ova vrednost je zadata u definiciji servisa). Kada obaveštenje o servisu eskalira prilikom 3., 4. i 5.

obaveštenja, interval između obaveštenja će se promeniti i iznosiće 90 min. Od 6. do 10. obaveštenja,

interval između obaveštenja će iznositi 60 min. kao što je definisano u drugoj definiciji eskalacije, a od

11. obaveštenja pa nadalјe, sva obaveštenja će se ponovo slati u predefinisanom intervalu od 240 min.

Kako je moguće preklapanje definicija eskalacija, kao i činjenice da host može biti član više grupa

hostova, Nagios mora da se odluči za jednu od preklapajućih definicija. U slučaju kada postoji više

validnih definicija eskalacija za određeno obaveštenje, Nagios će “poslušati” onu sa najkraćim

intervalom obaveštenja.

U poslednjem navedenom primeru vidi se da se definicije eskalacija preklapaju, tj. obe (različito)

definišu učestalost obaveštavanja prilikom slanja 4. I 5. obaveštenja. Za “prekloplјena” obaveštenja

Nagios će koristiti interval od 45 min, pošto je to manji prisutni interval u validnim derfinicijama

eskalacija za ova obaveštenja. U opštem slučaju više od dve definicije eskalacije, koristio bi se

najmanji interval. Na kraju još treba objasniti intervale obaveštenja čija je vrednost 0. Kada se zada

interval dužine 0, Nagios će poslati samo jedno obaveštenje, i to ono prvo. Sva naredna obaveštenja za

ovaj servis, host ili grupu hostova biće potisnuta.

Primer:

”define serviceescalation {

host_name webserver



last_notification 7



}


host_name webserver



last_notification 8


contact_groups nagios-admins,linux-admins,everyone

}

33


host_name webserver



last_notification 0


contact_groups support

}”

U poslednjem primeru, maksimalni broj obaveštenja o problemu koji se može poslati u vezi sa

posmatranim servisom jeste 4. Ovo je slučaj zbog zadatog intervala obaveštenja od 0 u drugoj

definiciji eskalacije koja znači da će se slati samo jedno obaveštenje (počev i uklјučujući 4-to

obaveštenje) dok će sva naredna obaveštenja biti potisnuta. Zbog toga ni vrednost zadata u direktivi

“last_notification” u drugoj definiciji, ni čitava treća definicija, nemaju nikakvog efekta.

1.11 Indirektne provere statusa hostova i servisa

Najveći broj servisa i hostova na mreži može se nadgledati pomoću direktnog korišćenja plaginova sa

računara koji hostuje Nagios. Primeri ovih direktno proverivih servisa su dostupnost veb, email, ili

“FTP” servera, i oni se mogu direktno proveravati Nagiosovim plaginovima jer su javno dostupni

resursi. Međutim, postoji mnogo servisa koje je interesantno nadgledati, ali koji nisu javno dostupni

kao ostali servisi. Stanje ovakvih privatnih resursa ne može se pratiti bez korišćenja posrednog

programa tzv. agenta. Ovi “privatni” resursi ili servisi uklјučuju informacije kao što su iskorišćenost

diska, opterećenje procesora i slično, na nadgledanim hostovima.

Indirektne provere predstavlјaju način da se nadgledaju svi oni servisi i hostovi koji nisu direktno

dostupni plaginovima na nadgledajućem serveru. Provere servisa koje zahtevaju neku vrstu agenta

posrednika koji se izvršava na udalјenom nadgledanom računaru nazivamo indirektnim proverama.

Indirektne provere su korisne za:

nadgledanje lokalnih resursa na udalјenim hostovima

nadgledanje servisa i hostova iza “firewall-a”

dobijanje realističnijih rezultata iz provera servisa osetlјivih na vremensko kašnjenje između

udalјenih hostova (npr. vreme ping odziva između dva udalјena hosta)

Postoji više načina za izvršavanje indirektnih provera. Međutim, najpopularnije rešenje je korišćenje

“nrpe” agentskog programa, dodatka za Nagios koji je razvio autor Nagiosa, Ethan Galstad. Ovaj

dodatak je napisan sa cilјem da obezbedi način za izvršavanje plaginova na udalјenom hostu. Ime

“nrpe” je skraćeno od “Nagios Remote Plugin Executor”.

Ako bi se svi mrežni servisi nadgledali direktno preko “firewall-a”, morali bi svi portovi da budu

otvoreni. Dovolјno je da provere koje se izvršavaju indirektno sa računara koji se nalazi iza “firewall-

a” imaju otvoren port na “firewall-u” za “nrpe” (“TCP” port 5666). Dokle god su ove provere

konfigurisane pomoću “nrpe”, “NRPE” server može da izvrši bilo koju promenu. Slika br.6 ilustruje

indirektnu proveru pomoću “NPRE” plagina.

34

Slika 8 Indirektna provera pomoću “NRPE” plagina

Sam program “NRPE” predstavlјa samo serverski deo klijent/server programskog para za indirektne

provere koji se izvršava na nadgledanom hostu. Može da se izvršava bilo kao samostalni demon, ili

kao servis pod inetd ili xinetd demonom. Klijentski deo aplikacije čini “check_nrpe” plagin pomoću

kog Nagios jezgro komunicira sa “NRPE” agentom.

Funkcionisanje indirektnih provera bi se ukratko moglo opisati na sledeći način. Na strani

nadgledajućeg računara, Nagios pokreće “check_nrpe” plagin koji se koristi da pošalјe zahteve nrpe

agentu za izvršavanje određenih plaginova na udalјenom hostu. Agent nrpe prima zahteve, pokreće

zahtevane plaginove i vraća rezultate provera “check_nrpe” plaginu na nadgledajućem hostu. Plagin

“check_nrpe” preuzima izlazne rezultate udalјenih plaginova i šalјe ih nazad Nagiosu kao da su

njegovi. Ovim se omogućava transparentni način izvršavanja plaginova na udalјenim hostovima.

Što se tiče sigurnosti, kada se izvršava u modu daemona, “NRPE” agent vrši autentifikaciju zahteva za

izvršavanjem plaginova prostim upoređivanjem “IP” adrese pozivajućeg hosta sa listom dozvolјenih

“IP” adresa koja se nalazi u njegovoj konfiguracionoj datoteteci “nrpe.cfg”. Kada se izvršava pod

“inetd-om” daemonom, koji upravlјa internet servisima na “UNIX” sistemima, pristup “NRPE” agentu

se vrši pomoću “TCP” “Wrapper-a”. “TCP Wrapper-a” je “ACL”(Access control list) sistem, koji se

koristi da filtrira mrežni pristup ka internet protokolu servera baziran na “UNIX” “OS”.

1.11.1 Indirektne provere servisa

Slika 8. ilustruje princip rada indirektnih provera servisa. Ako se serveri koji se nagledaju nalaze iza

iza “firewall-a”, provera servisa na tim mašinama može biti komplikovana.

35

Slika 9 Indirektna provera servisa

U konkretnom slučaju, između nadgledajućeg hosta “Central Monitoring Host” i pojedinih

nadgledanih hostova (u ovom primeru su dati “host #2”, “host #3” i “host #4”) nalazi se “firewall”

koji ne pušta “ICMP” saobraćaj i onemogućava proveru odziva ovih hostova na ping. Da bi se odziv

na ping ovih hostova ipak proveravao, na posredničkom hostu “host #1”, koji se takođe nalazi sa druge

strane “firewall-a”, podignut je “nrpe” daemon i instalirani su Nagiosovi plaginovi. U ovoj situaciji

neophodno je bilo instalirati samo odgovarajući plagin za proveru ping servisa, “check_ping”.

Kada Nagios želi da proveri status ping servisa na nekom od tri prikazana hosta, preko “check_nrpe”

plagina “nrpe” agentu se upućuje zahtev za izvršavanjem “check_ping” plagina. Agent “nrpe”

izvršava plagin i dobijene rezultate provere vraća “check_nrpe” plaginu koji ih potom prosleđuje

Nagiosu, čime se ovaj ciklus indirektne provere ping servisa završava.

Na isti način, preko “nrpe” demona Nagios pokreće lokalne Nagiosove plaginove (instalirane na

“host #1”) i nadgleda status privatnih resursa hosta “host #1”. Za razliku od provera javno dostupnih

servisa, za provere privatnih servisa i resursa nekog hosta neophodno je prisustvo agenta posrednika.

1.11.2 Višestruke indirektne provere servisa

Kada se vrši nadgledanje hostova koji su smešteni iza “firewall-a” u odnosu na računar koji hostuje

Nagios, provere servisa na ovim mašinama mogu biti po malo komplikovane jer je obično blokirana

većina dolaznog saobraćaja koji je neophodan za funkciju nadgledanja. Jedno rešenje za izvršavanje

provera na hostovima iza “firewall-a” bilo bi ostavlјanje “uskog” prolaza u filtrima “firewall-a” koji

bi Nagiosu omogućili da izdaje zahteve nrpe demonu na hostu zaštićenom“firewall-om”. Host unutar

“firewall-a” bi potom mogao da bude korišćen kao posrednik u izvršavanju provera svih ostalih

servera zaštićenih “firewall-om”.

36

Pomoću “nrpe” daemon-a i “check_nrpe” plagina moguće je višestruko ulančavanje indirektnih

provera servisa. Iako je definisanje ovakvih provera servisa nešto komplikovanije, korisniku je

ostavlјena i ovakva mogućnost u slučaju da se za tako nešto ukaže potreba.

Slika 8. prikazuje princip rada višestrukih indirektnih provera servisa. Agentski program “NRPE” se

izvršava na hostovima “host #1” i “host #2”. Kopija koja se izvršava na “host #2 omogućuje “NRPE”

agentu na “host #1” da izvršava provere privatnih servisa na “host #2”. Privatni servisi podrazumevaju

broj procesa koji se trenutno izvršavaju na hostu, opterećenje procesora, iskorišćenost diska, itd. koji

nisu direktno izloženi kao “SMTP”, “FTP”, ili “HTTP” servis. Podrazumeva se da su na hostovima

“host #1” i “host #2” ispravno prevedeni i instalirani potrebni plaginovi.

Slika 10 Indirektne provere hostova

1.11.3 Indirektne provere hostova

Indirektne provere hostova rade na istom principu kao i indirektne provere servisa. U osnovi, plagin

koji se koristi u komandi provere hosta zahteva od agenta posrednika da izvrši proveru hosta.

Indirektne provere hostova su korisne kada se udalјeni hostovi nalaza iza “firewall-a” ili kada se želi

zabrana dolaznog saobraćaja nadgledanja za dotičnu mašinu. Ta mašina (udalјeni “host #1” na

dijagramu ispod) će izvršiti proveru hosta i vratiti rezultate nazad najstarijem “check_nrpe” plaginu

(na centralnom serveru). Treba primetiti da sa ovakvom postavkom dolaze potencijalni problemi.

Ako udalјeni “host #1” padne, “check_nrpe” plagin neće biti u mogućnosti da kontaktira “NRPE”

demona i Nagios će “verovati” da su udalјeni “host #2, host #3, host #4” takođe pali iako to ne mora

da bude slučaj. Ako je “host #1” iza “firewall-a”, tada problem nije realan jer će Nagios detektovati da

je on pao i obeležiti “host #2, host #3, host #4” kao nedostupne.

Slika 11 prikazuje primenu “NRPE” daemona i “check_ping” plagina u izvršavanju indirektne

provere hosta.

37

Slika 11 Indirektne provere hostova

1.11.4 Aktivne provere

Pomoću Nagiosa se nadgledanje hostova i servisa može obavlјati na 2 načina: aktivno i pasivno.

Aktivne provere se najčešče koriste za monitoring hostova i servisa. Glavne karakteristike aktivnih

provera su:

Aktivne provere su inicijalizovane od strane procesa u Nagiosu (Nagios Process)

Aktivne provere se redovno izvšavaju prema definisanom rasporedu

Slika 12 Aktivna provera hostova i servisa

38

Aktivne provere su inicijalizovane od strane “Check Logic” koji se nalazi u Nagios daemonu. Kada

Nagios treba da proveri status hosta ili servisa izvršiće plagin i proslediće informacije o proveri koja

treba biti izvršena. Zatim će plagin proveriti stanje hostova ili servisa i vratiti rezultate nazad Nagios

daemonu. Nagios će procesuirati rezultate provere hosta ili servisa i izvršiti neophodne akcije ako je to

neophodno. (poslati notifikacije, pokrenuti “event” handlere, itd.) Aktivne provere se izvršavaju:

U regularnim intervalima, definisan direktivama “check_interval” i ”retry_interval” u

definicijama hostova i servisa

Na zahtev ako je neophodno

Regularno planirane provere se dešavaju u intervalima koji su definisani pomoću “check_interval”

i ”retry_interval” u definicijama hostova i servisa, u zavisnosti od stanja u kome se nalazi host ili

servis. Ako je host ili servis u “HARD” stanju, biće aktivno proveravan pomoću ”check_interval”

direktive. Ako je u “SOFT” stanju, biće proveravan u intervalima koji su definisani u ”retry_interval”

direktivi.

Provere na zahtev se izvršavaju kada god Nagios vidi potrebu da preuzme poslednju informaciju o

stanju odredjenog hosta ili servisa. Na primer, kada Nagios odlučuje dostupnost hosta, on će često

izvršiti provere na zahtev parent i child hosta da bi definisao status određenog segmenta mreže.

Takođe, provere na zahtev se mogu izvršiti prilikom logike zavisnosti hostova (predictive dependency

check logic) da bi se osigurale sto ažurnije informacije.

1.11.5 Pasivne provere

Jedina prava razlika između aktivnih i pasivnih provera u Nagiosu je što aktivne provere inicira Nagios

dok pasivne provere izvršavaju eksterne aplikacije. Na slici br.10 je prikazan način izvođenja pasivnih

provera.

Slika 13 Način izvođenja aktivnih provera

Pasivne provere su korisne za nadgledanje servisa koji su:

locirani iza “firewall-a” i stoga ne mogu da se proveravaju aktivno sa Nagios hosta

asinhrone po prirodi i stoga ne mogu da se aktivno proveravaju na pouzdan način (npr. “SNMP”

trapovi, sigurnosni alarmi, itd).

Kada eksterna aplikacija izvrši proveru servisa (bilo aktivno, bilo prijemom sinhronog događaja kao

što je “SNMP” trap ili sigurnosni alarm) ona podnosi rezultate provere Nagiosu upisujući ih u

datoteku eksternih komandi u propisanom formatu.

Kada Nagios sledeći put obradi sadržaj datoteke eksternih komandi, rezultati svih pasivnih provera

servisa se smeštaju u red za čekanje za kasniju obradu. Red za čekanje koji se ovde koristi potpuno je

isti kao onaj za smeštanje rezultata aktivnih provera.

http://nagios.sourceforge.net/docs/3_0/dependencychecks.html

http://nagios.sourceforge.net/docs/3_0/dependencychecks.html

39

Nagios će periodično prikuplјa podnete rezultate provera servisa i uvrštava ih u red za čekanje na

obradu. Svaki rezultat provere, bez obzira da li je provera bila aktivna ili pasivna, obrađuje se na isti

način. Logika provere servisa je potpuno ista za obe vrste provera. Ovo obezbeđuje sličan metod

rukovanja rezultatima i aktivnih i pasivnih provera servisa.

Da bi omogućilo korišćenje aktivnih provera na globalnom nivou neophodno je u glavnoj

konfiguracionoj datoteci direktivi “accept_passive_service_checks” dodeliti vrednost 1. Ako želimo

da omogućimo pasivnu proveru za određene hostove i servise, direktivi “passive_cheks_enabled” u

definiciji objekta trebamo dodeliti vrednost 1.

1.11.6 Način na koji eksterne aplikacije podnose rezultate provere servisa

Eksterne aplikacije mogu da podnesu rezultate provere servisa Nagiosu upisom

“PROCESS_SERVICE_CHECK_RESULT” eksterne komande u datoteku eksternih komandi.

Propisani format podnešenih rezultata provere je sledeći:

[<timestamp>] PROCESS_SERVICE_CHECK_RESULT; <host_name>;

<description>; <return_code>; <plugin_output>

gde je:

“timestamp” – trenutak izvršenja (ili podnošenja) provere servisa u time_t formatu. Jedan blanko

karakter posle desne zagrade se ne sme izostaviti!

“host name” – kratko ime hosta pridruženog servisu u definiciji servisa.

“description” – opis servisa koji stoji u definiciji servisa

“return code” – povratni kod provere (0 = “OK”, 1= “WARNING”, 2 = “CRITICAL”, 3= “UKNOWN”)

“plugion_output” – tekstualni izlaz provere servisa

1.11.7 Način na koji eksterne aplikacije podnose rezultate provere hostova

Način na koji eksterne aplikacije podnose rezultate provere hostova je sličan kao kod načina

podnošenja rezultata provere servisa. Eksterne aplikacije podnose rezultate provere hostova Nagiosu

upisom “PROCESS_HOST_CHECK_RESULT” eksterne komande u datoteku eksternih komandi.

Propisani format podnešenih rezultata provere je sledeći:

“[<timestamp>] PROCESS_HOST_CHECK_RESULT;<host_name>;<host_status>;<plugin_output>”

Gde je:

“timestamp” – trenutak izvršenja (ili podnošenja) provere hosta u time_t formatu. Jedan blanko

karakter posle desne zagrade se ne sme izostaviti!

“host name” – ime hosta

“return code” – povratni kod provere (0=UP, 1=DOWN, 2=UNREACHABLE)

“plugin_output” – tekstualni izlaz provere hosta

1.11.8 Određivanje statusa i dostupnosti mrežnih hostova

Nagios može da odredi da li je host koji se nagleda u “DOWN” ili “UNREACHABLE” stanju. Ovo su

veoma različita stanja i mogu da pomognu u otkrivanju izvora problema. Na sledećem primeru je

prikazan način na koji logika dostupnosti razlikuje ova dva stanja.

40

Slika 14 Određivanje dostupnosti hostova u mrežnom segmentu

Predpostavimo da se na ovom primeru prate svi hostovi (serveri, ruteri, svičevi, itd). Nagios

je instaliran i radi na hostu “Nagios”. Da bi Nagios napravio razliku između “DOWN” i

“UNREACHABLE” stanja za hostove koji se nagledaju, mora se “reći” Nagiosu kako su ovi hostovi

međusobno povezani od stanovišta hosta na kojem se nalazi Nagios. Da bi se ovo realizovalo,

neophodno je pratiti putanju koju paket podataka pravi od hosta na kome se nalazi Nagios do

invidualnog hosta. Za svaki svič, ruter i server se moraju definisati “parent/child” odnosi u Nagiosu.

Sledeći primer ilustruje kako “parent/child” relacije izgledaju sa stanovišta hosta na kome se nalazi

Nagios.

Slika 15 Parent/child” relacija

Ovo su primeri definicija hostova sa “parent/child” relacijama:

define host{

host_name Nagios ; <-- The local host has no parent - it is the topmost host

}

define host{

host_name Switch1

parents Nagios

}

41

define host{

host_name Web

parents Switch1

}

define host{

host_name FTP

parents Switch1

}

define host{

host_name Router1

parents Switch1

}

define host{

host_name Switch2

parents Router1

}

define host{

host_name Wkstn1

parents Switch2

}

define host{

host_name HPLJ2605

parents Switch2

}

define host{

host_name Router2

parents Router1

}

define host{

host_name somewebsite.com

parents Router2

}

42

Sledeći primer će ilustrovati situaciju u kojoj su se pojavili par problema. Predpostavimo da su dva

hosta – “Web” i “Router1” postanu “offline”:

Slika 16 Paralelna provera “parent/child” relacija

Kada host promeni stanje (iz “UP” u “DOWN”) logika dostupnosti hostova stupa na scenu. Logika

dostupnosti će započeti paralelnu proveru “roditelјa” i “dece” kada god dođe do promene stanja hosta.

Ovo omogućava Nagiosu da brzo definiše trenutni status mrežne infrastrukture kada se promena

dogodi.

Slika 17 Određivanje nedostupnih hostova

U ovom primeru, Nagios će odrediti da su hostovi “Web” i “Router1” u “DOWN” stanju

zato što “putanja” ka tim hostovima nije blokirana. Takođe, Nagios će odrediti da su svi hostovi koji se

nalaze ispod „Router1“ u “UNREACHABLE” stanju zato što Nagios ne može da im pristupi.

“Router1” je “DOWN” i blokira “putanju” ka ostalim hostovima. Ti hostovi možda rade savršeno

dobro, ili su “offline”, ali Nagios to ne zna zato što ne može da im pristupi. Zato ih Nagios smatra

“UNREACHABLE” umesto “DOWN”.

Podrazumeva se da će Nagios obavestiti kontakte o “DOWN” i “UNREACHABLE” stanju

hostova. Admini verovatno ne žele da primaju notifikacije o hostovima koji su “ UNREACHABLE”

zato što prilikom obaveštavanja da je ruter ili “Firewall” “DOWN” podrazumeva se da je sve “ispod”

njih nedostupno.

43

1.11.9 Pasivne provere i stanje hostova

Za razliku od aktivnih provera, Nagios ne pokušava da odredi da li je host “DOWN” ili

“UNREACHABLE” pomoću pasivnih provera. Rezultati pasivnih provera se uzimaju kao trenutno

stanje hostova i ne pokusava da odredi pravo stanje hosta koristeći logiku dostupnosti (reachability

logic).

Ovo može da izazove probleme ako se pasivne provere šalјu sa udalјenih hostova ili je konfiguracija

distribuiranog monitoringa drugačija gde su “parent/child” relacije između hostova različite. Može se

narediti Nagiosu da prevede “DOWN/UNREACHABLE” pasivnu proveru u odgovarajući rezultat

koristeći direktivu “translate_passive_host_checks” tako što joj se dodeli vrednost 1 u glavnoj

konfiguracionoj datoteci.

1.11.10 Prevođenje pasivne provere hosta u tačno stanje

Kada Nagios primi pasivnu proveru hosta sa udalјenog izvora stanje hosta koje je prijavlјeno od strane

udalјenog izvora možda ne prikazuje tačno stanje hosta kod Nagiosa. Distribuirane i “FAILOVER”

monitoring instalacije su veoma slične i zato je veoma bitno obezbediti mehanizam koji će osigurati

tačna stanja između različitih instanci Nagiosa.

Na slici ispod je prikazana jednostavna struktura “FAILOVER” monitoring instalacije:

“Nagios-A” je primarni monitoring server, i aktivno nagleda sve svičeve i rutere

“Nagios-B” i “Nagios-C” su backup monitoring server, i primaju pasivne provere od Nagiosa

Oba rutera “Router-C” i “Router-D” su “offline”

Slika 18 Struktura “FAILOVER” monitoring instalacije

U kojim stanjima su “Router-C” i “Router-D”? To zavisi od instance Nagiosa koja je upitana.

“Nagios-A” vidi “Router-D”kao “DOWN” i “Router-C” kao “UNREACHABLE”

“Nagios-B” vidi “Router-D” kao “UNREACHABLE” i “Router-C” kao “DOWN”

“Nagios-C” vidi “Router-D” i “Router-C” kao “DOWN”

Svaka instanca Nagiosa ima drugačiji pogled na mrežu. Backup monitoring serveri ne bi trebali da

slepo primaju pasivne provere hostova od primarnog monitoring servera, ili će imati pogrešnu

informaciju o trenutnom stanju mreže.

Bez prevođenja pasivnih provera hostova sa primarnog monitoring servera Nagiosa rezultati bi bili

drugačiji. “Nagios-C” bi video “Router-D” kao “UNREACHABLE” kada bi bio u “DOWN” stanju.

Slično, “DOWN/UNREACHABLE” stanja (sa tačke gledišta “Nagios-A”) za “Router-C” i “Router-D”

bi bila prikazana kao flipovana (brza promena stanja) sa tačke gledišta “Nagios-B”.

http://nagios.sourceforge.net/docs/3_0/networkreachability.html

http://nagios.sourceforge.net/docs/3_0/networkreachability.html

http://nagios.sourceforge.net/docs/3_0/configmain.html#translate_passive_host_checks

44

1.11.11 Podnošenje rezultata pasivnih provera servisa sa udalјenih hostova

Ako neka aplikacija koja se hostuje na istom računaru gde i Nagios podnosi rezultate pasivnih provera

servisa, upisivanje rezultata provera u datoteku eksternih komandi je prilično jednostavno. Međutim,

aplikacije na udalјenim hostovima ne mogu to da urade tako lako. Da bi se udalјenim hostovima

omogućilo da šalјu rezultate pasivnih provera servisa Nagios hostu, koristi se “Nagios Service Check

Acceptor (nsca)”.

Ovaj program se sastoji od daemon-a koji se izvršava na Nagios hostu po imenu “nsca”, i klijenta koji

se izvršava na udalјenim hostovima, po imenu “send_nsca”. Demon osluškuje konekcije od udalјenih

klijenata, vrši proveru autentičnosti poslatih rezultata i potom ih direktno upisuje u datoteku eksternih

komandi. Ako na sistemu postoje instalirane “mcrypt3” biblioteke, komunikacija između klijenta i

daemon-a može se kriptovati različitim algoritmima (“DES, 3DES, CAST” itd.).

Korišćenjem opisanog dodatka podnošenje rezultata provera je veoma jednostavno i sa udalјenog hosta.

U osnovi, jedino što eksterna aplikacija na udalјenom hostu treba da uradi jeste da klijentskom

programu prenese argumente u odgovarajućem formatu. Na slici br.10 je prikazan način

funkcionisanja “nsca”.

Slika 19 Način funkcionisanja “nsca”

1.12 “Osvežavanje” provera hostova i servisa

Nagios podržava opciju koja “osvežava” provere hostova i servisa. Svrha “osvežavanja” provera je ta

da se obezbedi da se provere hostova i servisa izvršavaju pasivno na regularnoj osnovi. “Osvežavanje”

provera je veoma korisno kada je potrebno da se pasivne provere izvršavaju onoliko često koliko je i

potrebno. Nagios periodično proverava “svežinu” rezultata svih hostova i servisa za koje je omogućena

“svežina” provere:

Granica “svežine” se izračunava za svaki host ili servis

Za svaki host ili servis, starost poslednje provere se upoređuje sa granicom “svežine”

Ako je starost poslednje provere veća od granice “svežine”, provera se smatra da je nepouzdana

Ako je provera nepouzdana, Nagios će izvršiti aktivnu proveru hostova ili servisa

Aktivna provera će se izvršiti čak i ako su aktivne provere onemogućene na globalnom nivou ili u

definiciji hostova ili servisa.

Da bi se omogućilo “osvežavanje” provera neophodno je:

Omogućiti osvežavanje provera hostova i servisa na globalnom nivou tako što direktivama

“check_servise_freshness” i “check_host_freshness” u glavnoj konfiguracionoj datoteci zadati

vrednost 1

Definisati period “osvežavanja” provera direktivama “service_freshness_check_interval” i

“host_freshness_check_interval”

U definicijama hostova i servisa opciji “check_freshness” dati vrednost 1

Definisati granice “svežine” pomoću “freshness_threshold” opcije u definiciji hostova i servisa

http://nagios.sourceforge.net/docs/3_0/configmain.html#check_service_freshness

http://nagios.sourceforge.net/docs/3_0/configmain.html#check_service_freshness

45

Konfigurisati “check_command” opciju u definiciji hostova i servisa koja će predstavlјati

aktivnu proveru koja će se izvršiti kada se provera hosta ili servisa smatra nepouzdanom

Opcija “check_period” u definiciji hostova ili servisa se koristi kada Nagios treba da odredi da li

će se host ili servis proveriti zbog “svežine”, tako da vremenski period provere treba biti

validan

1.12.1 Kombinovanje oba tipa provera servisa

Obzirom da su na raspolaganju i pasivne i aktivne provere servisa, prirodno je očekivati da se najbolјi

rezultati dobijaju kombinovanjem prednosti obadva tipa provera. Ovo jedino nije slučaj kada se

implementira distribuirano monitoring okruženje sa centralnim serverom koji prima samo pasivne

provere servisa (bez ijedne aktivne provere).

Aktivne provere su mnogo pogodnije za servise podložne periodičnim proverama (dostupnost nekog

“HTTP” ili “FTP” servera i sl.), dok su pasivne provere zgodnije za rukovanje asinhronim događajima

kao što su “SNMP” trapovi, napadi na sistem i slično.

Na slici 14. ilustrovan je primer kombinovane upotrebe aktivnih i pasivnih provera servisa.

Narandžasti oblačići na desnoj strani slike su eksterne aplikacije (Third-Party Software) koje podnose

rezultate pasivnih provera upisujući ih u Nagiosovu datoteku eksternih komandi (External Command

File). Eksterne aplikacije predstavlјene u gornjem oblačiću izvršavaju se na “Monitoring Host” gde je i

Nagios, te one mogu direktno da upisuju svoje rezultate u komandnu datoteku.

Slika 20 Kombinovanje oba tipa servisa

Eksterne aplikacije predstavlјene donjim oblačićem izvršavaju se na udalјenom hostu “Remote Host 2”

i koriste “nsca” server/klijent programski par za prenos rezultata pasivnih promena Nagiosu.

Oblačići na levoj strani slike predstavlјaju aktivne provere servisa koje izvršava Nagios. Prikazan je

način provere lokalnih resursa (popunjenost diska na “Monitoring Host” itd.), javno dostupnih resursa

46

na udalјenim hostovima (“HTTP” server, “FTP” server, itd.) i “privatnih” resursa na “Remote Host

#2” (iskorišćenost diska, opterećenje procesora, broj trenutno logovanih korisnika, trenutni broj zombie

procesa, itd.). U ovom primeru, privatni resursi na udalјenim hostovima se zapravo proveravaju

korišćenjem “nrpe” programa koji olakšava izvršavanje plaginova na udalјenim hostovima.

1.13 Distribuiran način monitoringa

Postoje mnogo situacija u kojima je neophodno imatei više od jedne instance Nagiosa pomoću koje se

prati stanje IT infrastrukture. Jedan od razloga može biti “firewall” koji blokira sve sem par mašina u

kompaniji. Drugi razlog bi bio optimizacija svih provera tako da one ne zahtevaju enterprise-class

server. Takođe, mašine koje moraju biti u procesu monitoring se nalaze na različitim fizičkim

lokacijama, tako da se formiraju više grana i svaka od njih ima svoj lokalni Nagios server, u slučaju

ako link ka centralnom serveru bude “DOWN”.

Na sledećem primeru se nalazi primer jednostavne organizacije koja ima četiri lokalne instance

Nagiosa i glavni Nagios server. Tipičan scenario je da lokalna instanca Nagiosa prati stanje svih

mašina i rutera u grani. Rezultati se šalјu glavnom Nagios serveru pomoću “NSCA” protokola. Kada je

konekcija jedne grane ka glavnom serveru prekinuta, lokalni administratori će moći da prate stanje

lokalnih mašina. Ova informacija neće biti dostavlјena glavnom Nagios serveru. Podešavanje servisa

na glavnom Nagios serveru da izvršava provere u određenim vremenskim intervalima će rezultovati

generisanju uzbune ako se rezultati provere ne dobiju u definisanom vremenskom intervalu. Ovakav

način konfiguracije omogućava da se utvrdi tačan uzrok problema. Sledeći dijagram prikazuje tipičnu

arhitekturu distribuiranog monitoringa.

Slika 21 Primer arhitekture distribuiranog načina monitoringa

U ovom primeru, svaka grana ima lokalni Nagios server na kojem se čuvaju “log” informacije. Kasnije

se ove informacije šalјu glavnom Nagios serveru.

47

Pasivne provere hostova i servisa se mogu iskoristiti da se napravi scenario u kojem nekoliko “ne-

centralnih” instanci Nagiosa šalјu rezultate centralnom serveru pomoću “NSCA” protokola.

Mehanizam koji nedostaje priprema svaki rezultat provere “ne-centralne” instance Nagiosa koja će biti

poslata preko “NSCA”. U ovim situacijama se koriste “opsesivne” komande, “OCSP”(Obsessive

Compulsive Service Processor) i “OCHP”(Obsessive Compulsive Host Processor). Ovo su dve

komande koje su posebno napravlјenje za distribuiran način monitoringa.

Slika 22 Disturibuiran način monitoringa

Da bi se “OCSP” i “OCHP” komande izvršavale, neophodno je izvršiti nekoliko koraka. Mehanizam je

u startu uklјučen na ne-centralnim Nagios serverima u glavnoj konfiguracionoj datoteci gde su

globalne komande za hostove (OCHP) i servise (OCSP) definisane. Ovo rezultuje slanjem svake

notifikacije sa “ne-centralne” instance Nagiosa glavnom serveru.

U definicijama servisa i hostova se može dodatno podesiti da li će servis ili host koristiti ovaj

mehanizam ili ne. Da bi glavni server Nagiosa mogao da koristi ove rezultate, svaki servis ili host se

mora opet pravilno definisati.

Neophodno je definisati samo dve opcije “Obsess Over Services Option” i “Obsess Over Hosts

Option” u glavnoj konfiguracionoj datoteci tako što će se parametrima “obsess_over_services” i

“obsess_over_hosts” dodeliti vrednost 1. Ove komande će se jedino izvršiti ako su globalno

omogućene ove dve opcije i ako su sledeće direktive u definicijama hostova i servisa uklјučene:

“obsess_over_hosts”

“obsess_over_services”

Moguće je i definisati komande koje će se izvršavati posle svakog “event-handlera” ili

notifikacije.Maksimalno vreme izvršavanje ovih komandi se reguliše pomoću “ochp_timeout” i

“ocsp_timeout “opcija. Komande se definišu tako što se “ochp_command” i “ocsp_command”

parametrima u glavnoj konfiguracionoj datoteci dodeli odgovarajuća vrednost.

1.13.1 Konfigurisanje instanci Nagiosa

Distribuiran način monitoringa zahteva ozbilјnu kontrolu i istu verziju Nagiosa na svim mašinama.

Ovo je neophodno zato sto centralni server Nagiosa i ostale instance da moraju delimičnu ili

kompletnu dostupnu konfiguraciju, i one moraju biti sinhronizovane na svim mašinama.

Preporučuje se da ne-centralne instance prate stanje servisa i hostova. Takođe, preporučuje se da se

provere servisa isklјuče na centralnom serveru, ali da provere hostova budu omogućene. Razlog za

ovakav način konfiguracije je zato što se provere hostova ne izvršavaju u unapred definisanom

rasporedu, nego se izvršavaju samo kada provera servisa vrati sledeće statuse: “WARNING,

CRITICAL, UKNOWN”. Neophodni resursi mašine za proveru stanja hostova su mnogo manji za

razliku od izvršavanja regularnih provera servisa. U nekim slučajevima, neophodno je i isklјučiti i

48

provere hostova. Provere hostova se trebaju pravilno izvršiti ili će bezbednosna politika zabraniti

provere izvršene od strane centralnog servera.

Preporuka za održavanje Nagios konfiguracija je instaliranje softvera kao što je “CVS” (Concurrent

Versions System — http://www.cvshome.org/) koji se koristi za konfigurisanje verzija. Pomoću ovog

softvera se mogu pratiti sve promene na Nagios instancama, ali i mnogo lakše izvršiti rekonfiguraciju

na više mašina.Hostovi, servisi, i odgovarajuće grupe se trebaju čuvati u folderima, posebno za svaku

instancu Nagiosa – npr. “hosts/branch1” i “services/branch1”. Svi drugi tipovi objekata, kao što su

kontakti, vremenski periodi, i komandne provere se mogu čuvati u globalnom direktorijumu i mogu

upotrebiti za sve grane.

Dobra praksa je napraviti mali sistem za ažuriranje svih konfiguracija sa jedne mašine, sa mogućnošću

da se napravi nova konfiguracija pre nego što se pusti u produkciju. Radeći sve ručno na mnogo

različitih mašina i lokacija je veoma teško i može postati veoma problematično na duge staze.

Upravlјanje sistemom će biti neizvodlјivo, a to može dovesti do grešaka u proverama zbog ne-

sinhronizovanih konfiguracija između “ne-centralnih” instanci i centralnog servera Nagiosa. Veoma

popularan alat za ovu namenu je “cfengine” (http://www.cfengine.org/). Omogućava automatizaciju

ažuriranja konfiguracija i osigurava da je Nagios aktuelan na svim mašinama. Takođe omogućava

i prilagođavanje – npr. Različiti fajlovi se mogu distribuirati na “ne-centralnim” serverima za razliku

od centralnog servera.

Glavna razlika između Nagiosa koji je definisan kao centralni server i ostalih instanci je u tome što

podešavanje centralnog servera se vrši u glavnom Nagios konfiguracionom fajlu – nagios.cfg. Ovaj

fajl treba da sadrži “cfg_dir” direktive za objekte koji su povezani sa svim ostalim instancama Nagiosa.

U suprotnom, centralni server Nagiosa će ignorisati izveštaje dobijene od nepoznatih hostova.

1.14 Zavisnosti hostova i servisa

Zavisnosti hostova i servisa su napredna pogodnost koja korisniku omogućava da kontroliše ponašanje

hostova i servisa na osnovu statusa jednog ili više drugih hostova i servisa. Ovde će biti objašnjeno

kako zavisnosti funkcionišu, zajedno sa razlikama između zavisnosti hostova i zavisnosti servisa.

1.14.1 Pregled zavisnosti servisa

Slika ispod prikazuje primer logičkog prikaza zavisnosti servisa. Treba uočiti nekoliko stvari:

servis može biti zavistan od jednog ili više drugih servisa

servis može biti zavistan od servisa koji nisu pridruženi istom hostu

zavisnosti servisa se ne nasleđuju (osim ako nisu tako konfigurisane)

zavisnosti servisa se mogu koristiti za iniciranje izvršavanja servisa i potiskivanje obaveštenja o

servisu pod različitim okolnostima (“OK”, “WARNING”, “UKNOWN” i/ili “CRITICAL”

status).

1.14.2 Definisanje zavisnosti servisa

Zavisnosti servisa se definišu dodavanjem definicija zavisnosti servisa u objektni konfiguracioni fajl.

U svakoj definiciji se definiše ime zavisnog servisa (dependent), ime servisa od koga zavisi

(depending-on) i kriterijum (ako uopšte postoji) koji treba da se zadovolјi da bi se sprečilo izvršavanje

određenih provera ili potisnula obaveštenja o određenim servisima ili hostovima. Moguće je kreirati

nekoliko zavisnosti za dati servis, ali potrebno je dodati zasebnu definiciju zavisnosti servisa za svaku

zavisnost.

49

Slika 23 Zavisnost servisa

“define servicedependency{

host_name Host B

service_description Service D

dependent_host_name Host C

dependent_service_description Service F

execution_failure_criteria o

notification_failure_criteria w,u

}

define servicedependency{

host_name Host B

service_description Service E



execution_failure_criteria n

notification_failure_criteria w,u,c

}

define servicedependency{

host_name Host B

service_description Service C



execution_failure_criteria w

notification_failure_criteria c

}”

50

1.14.3 Kako se testiraju zavisnosti servisa

Pre nego što Nagios izvrši proveru servisa ili o njemu pošalјe obaveštenje, prvo će proveriti da li taj

servis zavisi od nekog drugog servisa. Ako ne, provera se ili se šalјe obaveštenje kao što bi normalno i

trebalo da bude. Ali ako servis ima jednu ili više zavisnosti, Nagios će proveriti svaku zavisnost na

sledeći način:

proverava se tekući status servisa od koga dati servis zavisi

tekući status servisa od kog zavisi posmatrani servis se upoređuje sa zadatim kriterijumima

sprečavanja izvršavanja ili obaveštavanja u definiciji zavisnosti (koja god da je relevantna u

tom trenutku)

ako tekući status servisa od koga zavisi posmatrani servis zadovolјava jedan od

kriterijuma sprečavanja, kaže se da zavisnost nije prošla i provera dalјih zavisnosti se obustavlјa

ako tekući status servisa od koga zavisi posmatrani servis ne zadovolјava ni jedan od kriterijuma

sprečavanja, kaže se da je zavisnost prošla i provera sledećih zavisnosti (ako ih ima) će se

nastaviti.

Ovaj ciklus provera zavisnosti se nastavlјa dok se ne provere sve zavisnosti ili do prve neuspele

provere.

1.14.4 Zavisnosti izvršavanja servisa

Ako se svi testovi zavisnosti izvršavanja za određeni servis uspešno prođu, Nagios će izvršiti proveru

servisa kao što je normalno predviđeno. Ako jedan od testova zavisnosti izvršavanja servisa ne prođe,

Nagios će privremeno sprečiti izvršavanje provere ovog (zavisnog) servisa. U nekom trenutku u

budućnosti testovi zavisnosti izvršavanja servisa će se uspešno proći. Ako se to dogodi, Nagios će

ponovo započeti proveru servisa kao što je i ranije normalno činio. U prethodno pomenutom primeru,

servis E ne bi prošao test zavisnosti izvršavanja ako bi servis B imao “WARNING” ili “UNKNOWN

status”. Ako bi to bio slučaj, provera servisa se ne bi izvršila i bila bi preraspoređena za potencijalno

izvršavanje u nekom kasnijem trenutku.

1.14.5 Zavisnosti obaveštavanja o servisu

U primeru iznad, , servis “F” ne bi prošao test zavisnosti izvršavanja ako bi servis “C” imao

“CRITICAL” status i/ili servis “D” bio u “WARNING” ili “UKNOWN” stanju i/ili servis “E” je u

“WARNING”, “CRITICAL” ili “UKNOWN” stanju. U ovoj slučaju, notifikacija ne bi bila poslana.

1.14.6 Nasleđivanje zavisnosti servisa

Zavisnosti servisa se ne nasleđuju po “default-u”. U primeru iznad, servis “F” zavisi od servisa “E”.

Ali, servis “F” automatski ne nasleđuje zavisnosnosti servisa “E” prema servisu “B” i servisu “C”. Da

bi servis “F” bio zavistan od servisa “C” morali bi da napravimo jos jednu definiciju zavisnosti servisa.

Ne postoji deficija zavisnosti za servis “B”, tako da servis “F” ne zavisi od servisa “B”.

Da bi zavisnosti servisa mogle da se nasleđuju, direktivi “inherits_parent” treba dodeliti

vrednost 1 u definiciji zavinosti servisa. Kada je ova direktiva omogućena, pokazuje da zavisnost

servisa nasleđuje zavisnosti servisa od kojih zavisi.

1.14.7 Zavisnosti hostova

Zavisnosti hostova funkcionišu na isti način kao zavisnosti servisa. Razlika je samo u tome što se radi

o hostovima. Druga razlika je što zavisnosti hostova vršesamo potiskivanje obaveštenja, ali ne i

sprečavanje izvršavanja provera hostova. Na ovoj slici, definicije zavisnosti za host “C” bi izgledala na

sledeći način:

51

“define hostdependency { “define hostdependency {

host_name Host A host_name Host B

dependent_host_name Host C dependent_host_name Host

C

notification_failure_criteria d notification_failure_criteria d,u

}” }”

Slika 24 Zavisnosti hostova

Kao kod zavisnosti servisa, zavisnosti hostova se ne nasleđuju. Može se videti da host “C” ne

nasleđuje zavisnosti hosta “B”. Da bi host “C” zavisio od hosta “A”, mora se dodati nova definicija

zavisnosti. Zavisnosti obaveštenja hostu funkcionišu slično kao zavisnosti servisa. Ako se prođu svi

testovi zavisnosti za određeni host, Nagios normalno šalјe obaveštenje o hostu. Ako se jedan od

kriterijuma ne zadovolјi, privremeno se potiskuju obaveštenja o zavisnom hostu. U nekom trenutku u

budućnosti testovi zavisnosti će možda biti zadovolјeni. Ako se to dogodi, ponovo će početi normalno

obaveštavanje o ovom hostu.

1.14.8 Intuitive provere zavisnosti

Zavisnosti hostova i servisa se definišu da bi koristik imao veću kontrolu prilikom izvršavanja provera

i slanjem notifikacija. Zavisnosti se koriste za kontrolu osnovnih aspekata procesa monitoringa, i

veoma je važno da sve informacije budu što “svežije”. Nagios dozvoljava definisanje intuitivnih

provera zavisnosti za hostove i servise da bi logika zavisnosti bila što ažurnija zbog odlučivanja

između slanja notifikacije ili dozvoljavanja aktivnih provera hostova i servisa.

Slika ispod pokazuje osnovni dijagram hostova koji se nagledaju od strane Nagiosa, uporedo sa

“parent/child” relacijama i zavisnostima. Host “Switch 2” u ovom primeru je promenio stanje iz “UP”

u problematično stanje. Nagios treba da odluči da li je “DOWN” ili “UNREACHABLE”, tako da

pokreće paralelne provere “roditelja”(Firewall 1) i “dece”(Comp1, Comp2, Comp3) hosta “Switch 2”.

Ovo je normalna funkcija određivanja dostupnosti hostova.

Takođe, “Switch 2” zavisi od “Monitor 1” i “File 1” zbog izvršavanja provera ili notifikacija. Ako je

intuitivna provera zavisnosti omogućena, Nagios će izvršiti paralelnu proveru “Monitor 1” i “File 1” u

isto vreme kada počinje neposredna provera “roditelja” i “dece”.Nagios ovo radi zato sto će morati da

testira logiku zavisnosti u bliskoj budućnosti (zbog notifikacija) i želi da bude siguran da ima sto bolje

informacije koje opisuju realno stanje hostova.

52

Slika 25 Intuitivne provere zavisnosti

Omogućavanje intuitivnih provera zavisnosti je veoma jednostavno, u glavnoj konfiguracionoj datoteci

treba uključiti sledeće opcije:

“enable_predictive_service_dependency_checks”

“enable_predictive_host_dependency_checks”

1.14.9 Sačuvane provere

Performanse monitoring logike Nagiosa se mogu značajno povećati korišćenjem sačuvanih provera.

One omogućavaju Nagiosu da se odrekne izvršavanja provere hosta ili servisa ako će relativno brzo

izvršiti provera. Regularno planirane provere hostova i servisa neće imati nikakve koristi od sačuvanih

provera. Sačuvane provere su jedino korisne za pobolјšavanje performansi provera hostova i servisa

koje se izvršavaju na zahtev korisnika. Planirane provere osiguravaju da su stanja hostova i servisa

ažurirana, što može rezultovati mogušću da se rezultati planiranih provera upotrebe kao sačuvane

provere.

Provere hostova na zahtev se dešavaju u sledećim situacijama:

kada servis pridružen hostu promeni stanje

kada je neophodan deo logike određivanja dostupnosti hostova

i kada je zahtev neophodan za intuitivne provere zavisnosti hostova

Provere servisa na zahtev će se desiti samo kada postoji potreba za izvršavanjem intuitivne provere

zavisnosti servisa.

Kada Nagios treba da izvrši proveru hosta ili servisa na zahtev, mora da odluči da li će

upotrebiti rezultat sačuvane provere ili treba da izvrši proveru izvršavanjem plagina. Ovo radi tako što

proverava vreme poslednje provere hosta ili servisa koja se desila predhodnih “X” minuta, gde “X”

predstavlјa vremenski interval sačuvane provere hosta ili servisa. Ako je zadnja provera izvršena u

definisanom vremenskom intervalu od strane sačuvane provere, Nagios će upotrebiti poslednji rezultat

provere hosta ili servisa i neće izvršiti novu proveru. Ako host i servis nisu jos uvek provereni, ili

poslednja provera nije u izvršena u definisanom vremenskom intervalu, Nagios će izvršiti novu

proveru hosta ili servisa pomoću plagina.

53

Slika 26 Logika izvršavanja sačuvanih promena

Nagios izvšava provere na zahtev zato što mora da zna trenutno stanje hosta ili servisa u tom trenutku.

Korišćenje sačuvanih provera omogućava da Nagios misli da su skorašnje provere dovolјno dobre za

definisanje stanja hosta ili servisa, i da ne mora opet da proverava stanje hosta ili servisa.

Vremenski interval sačuvane provere govori Nagiosu koliko rezultati provere moraju biti “sveži“ da bi

mogli da definišu trenutno stanje hosta ili servisa. Naprimer, ako je vremenski interval sačuvane

provere je 30 sekundi, Nagios će uzeti u obzir one informacije o hostovima i servisima koji su

provereni u zadnjih 30 sekundi. Broj rezultata sačuvanih provera koji Nagios može koristiti naspram

broja provera na zahtev koje će se izvršiti se naziva “hit” stopa. Povećavanjem vremenskog interval

sačuvane provere na vremenski interval koji je jednak regularnoj proveri, može dovesti do “hit” stope

od 100%. U tom slučaju sve provere na zahtev tog hosta bi koristile rezultate sačuvane provere. Ovo je

veoma loša praksa.

Pouzdanost rezultata sačuvanih provera opada vremenom. Visoka “hit” stopa sačuvanih provera

zahteva da se predhodni rezultati provere smatraju validnim duži vremenski interval. Situacija se može

veoma brzo promeniti u bilo kojem mrežnom scenariju, i nema garancija da je server radio ispravno 30

sekundi. Zato postoji kompromis između pouzdanosti i brzine. Ako je vremenski interval sačuvane

provere veliki, postoji rizik od nepouzdanih rezultata provere koji se koriste u logici monitoringa.

Nagios će pokušati da odredi trenutno stanje svih hostova i servisa, tako da ako su rezultati sačuvane

provere nepouzdani, Nagios će raditi sa neispravnim informacijama kratak vremenski interval. Čak i

kratki periodi sa nepouzdanim informacijama o stanju hostova i servisa mogu biti veoma nepogodni za

admine, jer će primiti notifikacije o problemima koje više ne postoje.

Ne postoji standardni vremenski interval sačuvanih provera ili “hit” stopa koja će odgovarati svim

korisnicima Nagiosa. Neki korisnici će želeti kratak vremenski interval sačuvane provere i nisku “hit”

stopu sačuvanih provera, dok će drugi želeti veliki vremenski interval sačuvane provere sa većom “hit”

stopom (i malom stopom pouzdanosti). Takođe, neki korisnici će isklјučiti sačuvane provere da bi

obezbedili 100% pouzdane informacije. Testiranjem različitih vremenskih intervala, i njihov efekat na

pouzdanost informacija je jedina mogućnost da korisnik nađe “pravu” vrednost.

Pomoću sledećih parametara u glavnoj konfiguracionoj datoteci se definiše vremenski interval u kojem

predhodna provera hosta ili servisa se smatra validnom:

“cached_host_check_horizon”

“cached_service_check_horizon”

1.15 Praćenje stanja (“state stalking”)

Praćenje stanja je pogodnost koju većina korisnika verovatno neće koristiti. Ako se uklјuči, ona će

omogućiti logovanje promena kroz koje prolazi servis ili host čak i kada se stanje servisa ili hosta ne

menja. Tada Nagios pažlјivo posmatra dati servis i loguje svaku promenu koju vidi. Kao što se može

pretpostaviti, ovo može biti od velike koristi kod naknadne analize log-a.

http://nagios.sourceforge.net/docs/3_0/configmain.html#cached_host_check_horizon

http://nagios.sourceforge.net/docs/3_0/configmain.html#cached_host_check_horizon

54

1.15.1 Princip rada

Pod normalnim okolnostima, rezultati provera hosta ili servisa se loguju samo pri promeni stanja od

poslednje provere. Postoji nekoliko izuzetaka od ovog pravila, ali ono važi u većini slučajeva. Ako se

omogući praćenje jednog ili više stanja određenog hosta ili servisa, Nagios će logovati rezultate

provera ako se izlaz provere razlikuje od izlaza predhodne provere.

Pogledajte sledeći primer od 8 uzastopnih provera servisa:

Service check

Service status

Service check output Logged normally

Logged with stalking

x OK RAID array optimal

x+1 OK RAID array optimal

x+2 WARNING RAID array degraded (1 drive bad, 1 hot spare rebuilding)

x+3 CRITICAL RAID array degraded (2 drives bad, 1 host spare online, 1 hot spare rebuilding)

x+4 CRITICAL RAID array degraded (3 drives bad, 2 hot spares online)

x+5 CRITICAL RAID array failed



Iz date sekvence provera vidi se da bi normalno videli samo 2 unosa u logu za ovu katastrofu. Prvi bi

se dogodilo pri proveri servisa x+2 kada se stasus menja iz “OK” u “WARNING” (prelazak iz

“HARD” u “SOFT” stanje). Drugi unos bi se zabeležio kod x+3 provere servisa kada mu se status

menja iz “WARNING” u “CRITICAL”.

Bez obzira na razlog, korisnik bi svakako bilo od koristi da ima kompletnu istoriju ovakve katastrofe u

svojim log datotekama. Ako ništa drugo, možda da bi lakše objasnio svom menadžeru koliko brzo je

situacija izmakla kontroli i sl. Ako bi se opcija praćenja stanja ovog servisa omogućila za

“CRITICAL” stanja, u log datoteci bi imali logovane događaje kod x+4 i x+5 provere uz predhodne

x+2 i x+3.

Sličan primer bio bi praćenje stanja servisa koji proverava status “HTTP” servera. Ako “check_http”

plagin prvo vrati “WARNING” status zbog greške 404, a potom vrati ista stanja od naknadnih provera

zbog nepronalaženja određenog teksta (“pattern”) u vraćenoj strani, web administrator bi možda želeo

da zna za to. U slučaju kada ova opcija nije uklјučena za “WARNING” stanja servisa, bilo bi logovano

samo prvo stanje (greška 404) dok o ostalim ne bi bilo nikakvih tragova kao ni to da problem nije u

greški 404, već u nedostajućem “pattern-u” u vraćenoj “HTTP” stranici.

55

Da li treba omogućiti praćenje stanja

Prvo treba oceniti da li zaista postoji potrebu da se analiziraju arhivirani logovani podaci u cilјu

pronalaženja pravog uzroka problema. Obično, uvek se radi o nekolicini hostova i servisa. Nikada za

sve. Takođe, može se zahtevati praćenje samo nekih stanja hostova ili servisa. Na primer, može se

omogućiti praćenje samo “WARNING” i “CRITICAL” stanja servisa, a ne i OK i “UKNOWN” stanja.

Odluka da li omogućiti praćenje statusa odeđenog hosta ili servisa takođe zavisi od plagina koji se

koristi za njihovu proveru. Ako plagin uvek vraća isti tekstualni izlaz za određeno stanje, nema razloga

da se uklјučuje praćenje stanja ovakvog servisa.

Konfigurisanje praćenja

Ova opcija se omogućava pomoću “stalking_options” opcije u definicijama hostova i servisa.

Potencijalni problem

Trebalo bi se čuvati potencijalnih zamki koje dolaze sa uklјučivanjem praćenja stanja. Ovo je

povezano sa funkcijama sadržanim u različitim “CGI” skriptovima (“histogram, alertsummary”).

Zbog praćenja stanja koje izaziva dodatno logovanje “alert” stanja, izveštaji koje generišu ovi “CGI”

skriptovi će rezultovati nerealno povećanim brojem “alert” stanja. Generalno, uklјučivanje opcije

praćenja stanja se ne preporučuje pre nego što se dobro promisli o njegovim posledicama. Međutim,

ako je tako nešto ipak potrebno, ono je tu da pomogne.

1.16 “Event” hendleri

“Event” hendleri su opcione komande koje se izvršavaju kad god se dogodi promena stanja hosta ili

servisa. Očigledan primer upotrebe “event” hendlera (naročito kod servisa) je mogućnost proaktivnog

rešavanja problema pre nego što iko o tome bude obavešten. Druga potencijalna upotreba “event”

hendlera mogla bi da bude logovanje događaja (event) hostova ili servisa u centralnu eksternu bazu

podataka.

1.16.1 Tipovi “event” hendlera

Postoje nekoliko različitih opcionalnih event hendlera koji se mogu definisati prilikom promene stanja

hostova i servisa:

Globalni event hendleri hosta

Globalni event hendleri servisa

Lokalni event hendleri hosta

Lokalni event hendleri servisa

Dva glavna tipa “event” hendlera koja se mogu definisati su – “event” hendleri servisa i “event”

hendleri hostova. Komande “event” hendlera se opciono definišu u svakoj definiciji hosta ili servisa.

Pošto su ovi hendleri pridruženi samo određenim servisima ili hostovima možemo ih nazvati

“lokalnim” “event” hendlerima. Ako je lokali “event” hendler definisan za host ili servis, on će se

izvršavati kad god taj servis ili host promeni svoje stanje. Takođe, mogu se definisati i “globalni”

“event” hendleri koji se izvršavaju pri svakoj promeni stanja bilo kog hosta ili servisa. Oni se definišu

“global_host_event_handler” i “global_service_event_handler” direktivama u glavnoj

konfiguracionoj datoteci. Globalni hendleri se uvek izvršavaju neposredno pre lokalnih.

Kada se izvršavaju komande event hendlera

Komande event hendlera se izvršavaju kada servis ili host:

nađe se u “SOFT” stanju greške

po prvi put uđe u “HARD” stanje greške

56

oporavi se iz “SOFT” ili “HARD” stanja greške

Redosled izvršavanja “event” hendlera

Globalni hendleri se izvršavaju pre bilo kog lokalnog hendlera definisanog za odeđeni host ili servis.

Pisanje komandi “event” hendlera

U većini slučajeva, komande “event” hendlera će biti “shell“ ili “perl” skriptovi. U najmanju ruku,

skriptovi bi kao argumente trebalo da koriste sledeće makroe:

makroi “event” hendlera servisa: “$SERVICESTATE$, $STATETYPE$,

$SERVICEATTEMPT$”

makroi “event” hendlera hostova: “$HOSTSTATE$, $STATETYPE$, $HOSTATTEMPT$”

Skriptovi bi trebalo da ispitaju vrednosti zadatih argumenata i na osnovu njih preduzmu neophodne

akcije. Najbolјi način za razumevanje principa rada “event” hendlera je da se pogleda neki primer koji

se može naći u “/eventhandlers” poddirektorijumu distribucije Nagiosa. Neki od ovih primera

prikazuju upotrebu eksternih komandi pomoću kojih se implementiraju redundantni nadgledajući

serveri.

Privilegije korisnika koji izdaje komande “event” hendlera

Svaka komanda “event” hendlera koja se zada izvršavaće se sa istim dozvolama koje poseduje

korisnik pod čijim imenom se izvršava Nagios proces. Ovo predstavlјa problem onim skriptovima koji

pokušavaju da kontrolišu sistemske servise za čiji su pristup obično potrebne administratorske

privilegije. U idealnom slučaju trebalo bi odrediti sve tipove “event” hendlera koji će se

implementirati tako da se Nagios korisniku definišu samo neophodne dozvole kako bi mogao da

izvršava sve neophodne sistemske komande. Da bi se ovo obezbedilo može da se koristi “sudo”

komanda.

Debagovanje komandi “event” hendlera

Kada se vrši debagovanje neke komande event hendlera, toplo se preporučuje omogućavanje opcije

logovanja ponovnih pokušaja provera servisa, provera hostova i pokretanje hendlera pomoću

“log_service_retries”, “log_host_retries” i “log_event_handlers” direktiva u glavnoj konfiguracionoj

datoteci. Ovo omogućuje precizan uvid u vreme kada se i zašto izvršavaju određene komande “event”

hendlera.

Kada se proces debagovanja završi, poželјno je da se onemoguće pomenute opcije jer vrlo brzo mogu

da uvećaju log datoteku, što opet ne mora da bude problem ako je uklјučena rotacija logova.

1.17 Eksterne komande

Nagios može da izvršava komande eksternih aplikacija (uklјučujući i “CGI” skriptove) i da na različite

načine menja funkcije nadgledanja na osnovu primlјenih komandi. Eksterne aplikacije mogu da

proslede komande pomoću “command_file”, koji se periodično prosleđuje Nagiosu.

57

Slika 27 Prosleđivanje eksternih komandi Nagiosu

Omogućavanje eksternih komandi

Po “default” konfiguraciji, Nagios niti proverava, niti izvršava eksterne komande. Ako je to potrebno,

u glavnoj konfiguracionoj datoteci treba:

omogućiti “check_external_commands” opciju,

zadati odgovarajuću vrednost u “command_check_interval” opciji,

zadati lokaciju komandnog datoteke direktivom “command_file” i

postaviti odgovarajuće dozvole nad direktorijumom koji sadrži datoteku sa eksternim

komandama.

Kada Nagios proverava eksterne komande

U regularnim intervalima definisanim “command_check_interval” direktivom u glavnoj

konfiguracionoj datoteci.

Odmah po izvršavanju “event” hendlera. Ovo je dodatna provera regularnom ciklusu provera

eksternih komandi koja se vrši da bi se potencijalna akcija odmah preduzela, ako “event”

hendler zada komandu Nagiosu.

Upotreba eksternih komandi

Eksterne komande se mogu koristiti za završavanje različitih zadataka u vreme izvršavanja Nagiosa.

Primer mogu biti privremeno onemogućavanje obaveštenja o servisima i hostovima, privremeno

onemogućavanje provera servisa, forsiranje provera servisa u datom trenutku, dodavanje komentara

hostovima i servisima itd.

Format komande

Eksterne komande u komandnoj datoteci upisuju se u sledećem formatu:

“[time] command_id;command_arguments”

gde je vreme izraženo u “time_t” formatu i predstavlјa trenutak u kom eksterna aplikacija ili “CGI”

skript izvršavaju eksternu komandu iz datoteke eksternih komandi. Vrednosti za “command_id” i

“command_arguments” će zavisi od komandi koje će biti prosleđene Nagiosu.

58

2 Najčešće korišćeni plaginovi

Uz opis svakog plagina dati su format i primer upotrebe iz komandne linije. Obeležavanje

opcionih flegova razlikuje se od obaveznih po tome što su prvi dati u uglastim zagradama. Na primer,

sa “[-t timeout]” je označen jedan neobavezni fleg. Izbor između više opcija obeležen je uspravnom

crtom, “|”. Zbog veće preglednosti, u svim primerima korišćenja komandi plaginova podrazumevano

je da se one na ovaj način mogu pokretati iz njihovog matičnog direktorijuma “/usr/nagios/libexec/”.

Ispod se nalaze objašnjenja svih flegova koji su zajednički za sve ili bar većinu plaginova:

–H (--hostname) flegom zadaje se “IP” adresa hosta koji pruža proveravani servis. Opciono,

umesto “IP” adrese može se zadati ime hosta. Međutim, ovakva praksa nije dobra budući da

plagin pre provere mora prvo “DNS” upitom da razreši ime hosta u njegovu “IP” adresu. Ovim

se nepotrebno opterećuju “DNS” serveri i povećava mrežni saobraćaj, a provera servisa postaje

zavisna od statusa “DNS” servera i sporije se izvršava. Host se kao argument pojavlјuje u svim

plaginovima osim onih koji vrše provere servisa koji se hostuju na lokalnom računaru.

–t (--timeout) fleg predstavlјa maksimalno dozvolјeno vreme izvršavanja plagina. Ako se ovo

vreme prekorači, plagin obustavlјa proveru i vraća status “CRITICAL” sa tipičnim tekstualnim

izlazom “Plugin time out”. Izostavlјanjem ovog parametra, plagin koristi neku podrazumevanu

vrednost, tipično 10 sekundi.

–h (--help) fleg se koristi za prikaz minimalne dokumentacije i opis svih opcija plagina.

–V (--version) predstavlјa verziju plagina i verziju plagin distribucije u okviru koje je plagin

objavlјen.

–s (--server) je opcionalni “DNS” server koji će se koristiti za pretragu

–a (--expected-address) je opcionalna “IP” adresa koju “DNS” server treba da vrati. Host se

mora završiti sa tačkom (.). Ova opcija se može ponoviti nekoliko puta (vratiće OK status ako

postoje odgovarajuće vrednosti).

–p (--port) je broj porta (“default” vrednost porta je 53).

–l (--query_address) se koristi za traženje mašine pomoću njene adrese

2.1.1 “check_dns”

Format: “check_dns -H <host> [-s <server>] [-a <expected-address>] [-A<IP_Adress>] [-t <timeout>]

[-w warn] [-c crit]”

Plagin je baziran na programu nslookup koji za zadato ime hosta vraća “IP” adresu. Ako u mreži

postoji sekundarni “DNS” server, on se opciono može definisati pomoću “–s” flega. Ako se pak ne

definiše ni jedan “DNS” server, plagin koristi server ili servere definisane na nadgledajućem serveru,

tipično u “/etc/resolv.conf”. Plagin vraća “OK” status ako “DNS” uspešno odgovori na upit, status

“WARNING” u slučaju nepotpunog odgovora na upit, dok se u slučaju greške ili neodogovaranja

vraća “CRITICAL” status.

2.1.2 “check_dig”

Format: “check_dig -l <query_address> [-H <host>] [-p <server port>] [-T <query type>] [-w

<warning interval>] [-c <critical interval>] [-t <timeout>] [-a <expected answer address>] [-v]”

59

Plagin “check_dig” takođe služi za proveru ispravnosti rada jednog od najvažnijih servisa na mreži,

servisa koji pružaju “DNS” serveri. Za razliku od prethodnog, baziran je na programu dig. Plagin kao

argumente uzima “IP” adresu “DNS” servera i ime računara za koje “DNS” treba da vrati “IP” adresu.

Suštinska razlika u odnosu na prethodni plagin je u tome što se ovim plaginom direktno obraćamo

“DNS” serveru čija je adresa eksplicitno definisana.

2.1.3 “check_disk”

Format: “check_disk -w limit -c limit [-W limit] [-K limit] {-p path | -x device} [-C] [-E] [-e] [-g

group ] [-k] [-l] [-M] [-m] [-R path ] [-r path ] [-t timeout] [-u unit] [-v] [-X type]”

Plagin “check_disk” služi za proveru popunjenosti svih montiranih particija ili tačno zadate

particije hard diska na lokalnom sistemu. Plaginu se ili u procentima ili u kilobajtima zadaju vrednosti

pragova za status “WARNING” i “CRITICAL”. Vrednost pragova može biti zadata u procentima ili

celobrojnim vrednostima, kada označavaju kapacitet u kilobajtima. Kada slobodan memorijski prostor

padne ispod definisanih pragova, plagin će podići odgovarajući alarm. Ako se ne navede nijedna

particija, plagin će proveriti slobodan prostor na svim montiranim particijama. Opcioni flegovi “–x” i

“–e” pružaju mogućnost isklјučivanja određene particije i prikazivanje samo particija sa greškama.

Ovo je jedan od plaginova koji zahteva da bude instaliran na računaru čije stanje hard diskova

proverava.

2.1.4 “check_dummy”

Format: “check_dummy <integer state> [optional text]”

Ovaj plagin jednostavno vraća status koji odgovara brojnoj vrednosti njegovog jedinog argumenta.

Drugim rečima, “check_dummy” vrši veštačku proveru i vraća rezulat koji mu se zada. Uporedna

tabela brojnih vrednosti i odgovarajućih statusa je sledeća:

Number Status

0 OK

1 WARNING

2 CRITICAL

3 UKNOWN

2.1.5 “check_ftp”

Format: “check_ftp -H <host> -p <port> [-w <warning time>] [-c <critical time>] [-s <send string>] [-

e <expect string>] [-q <quit string>][-m <maximum bytes>] [-d <delay>] [-t <timeout seconds>] [-r

<refuse state>] [-M <mismatch state>] [-v] [-4|-6] [-j] [-D <warn days cert expire>[,<crit days cert

expire>]] [-S <use SSL>] [-E]”

Plagin “check_ftp” služi za proveru ispravnosti rada “FTP” servera na mreži. U osnovi ovog plagina

krije se check_tcp plagin. Iz formata komande se može videti da je podržano bogatstvo opcija.

Omogućeno je definisanje pragova za dozvolјena vremena odziva “FTP” servera u sekundama, koji za

dato prekoračenje podižu odgovarajući alarm. Takođe, podržano je i slanje definisanog stringa serveru

60

i upoređivanje odgovora sa očekivanim stringom odgovora. Opcionim flegom “–d” može se definisati

vreme čekanja u sekundama (“delay”) od trenutka slanja stringa do početka poliranja odziva. Opcija

“–m” definiše broj primlјenih bajtova nakon čega se smatra da je povera bila uspešna. Uklјučivanjem

flega “–r” omogućeno je vraćanje “OK” statusa servisa čak i za slučaj kada je očekivano da server

odbije pokušaj konekcije (slučaj “-r” ok).

2.1.6 “check_hpjd”

Format: “check_hpjd -H <host> [-C community]”

Plagin “check_hpjd” je napisan za proveru statusa veoma rasprostranjenih “Hewlett Packard-ovih”

mrežnih laserskih štampača sa “JetDirect” mrežnom kartom. Plagin se zasniva na “SNMP” protokolu

a od argumenata prima “community string” koji je podešen na štampaču. Ukoliko se plagin pozove bez

argumenata, koristi se “default community string” “public”. Plagin vraća status “OK” kada je štampač

operativan i dostupan preko mreže. U slučaju neke od niza mogućih grešaka štampača (Out of Paper,

Power Save On, Peripheral Error, Intervention Required, Toner Low, Insufficient Memory, Output

Tray is Full, Unknown Paper Error i sl.), plagin vraća “WARNING” status zajedno sa tekstualnom

porukom koja sadrži informacije o uzroku greške. Ukoliko je štampač nedostupan, plagin vraća status

“CRITICAL”.

2.1.7 “check_load”

Format: “check_load [-r] -w WLOAD1,WLOAD5,WLOAD15 -c CLOAD1,CLOAD5,CLOAD15”

Plagin “check_load” vrši proveru prosečnog opterećenja procesora tokom proteklih 1, 5 i 15 minuta.

Vrednosti koje vraća plagin su po formatu iste kao vrednosti koje vraćaju standardni Linux programski

alati “uptime” i “w”. Flegovima “–w” i “–c” definišu se pragovi za u formatu tripleta zapetom

razdvojenih realnih brojeva. Po prekoračenju bilo kog od prva tri praga, vraća se status “WARNING”,

a po prekoračenju bilo kog od druga tri praga, vraća se status “CRITICAL”.Ovo je još jedan iz grupe

plaginova kojim se mogu pratiti samo stanja privatnih lokalnih servisa na računaru na kom su

instalirani.

2.1.8 “check_nagios”

Format: “check_nagios -F <status log file> -e <expire_minutes> -C <process_string>”

Plagin “check_nagios” proverava da li se Nagios proces izvršava. Provera se vrši tako što se plagin

uverava da statusna datoteka Nagiosa, status.log, nije starija od zadatog broja minuta. Ova datoteka je

indikator izvršavanja Nagiosa jer u normalnim okolnostima postoji samo u toku njegovog izvršavanja.

Ako se nekom greškom dogodi da se statusna datoteka ne izbriše po zaustavlјanju Nagiosa, plagin

proverava i njegovu starost. Da bi bili potpuno “sigurni” da se Nagios izvršava, plagin koristi

standardni Linux program “ps” koji izlistava sve tekuće procese na sistemu. Ako u izlazu programa

“ps” pronađe očekivani string komande Nagiosa, plagin će zaklјučiti da se Nagios proces izvršava.

Flegom”–F” zadaje se ime Nagiosove statusne datoteke sa njenom apsolutnom putanjom.

Flegom -e zadaje se prag starosti statusne datoteke. Na kraju, flegom “–C” definiše se očekivani string

komande koji se javlјa u izlazu programa “ps”. Ako se bilo koji od ova dva kriterijuma ne zadovolјe,

plagin vraća “CRITICAL” status. Ukoliko se na standardnom izlazu za greške (“stderr”) pojavi bilo

kakav izlaz, plagin će vratiti “WARNING” status.

2.1.9 “check_nrpe”

Format: “check_nrpe -H <host> [-p <port>] -c <command> [-t <timeout >]”

61

Plagin “check_nrpe” je zapravo klijentski deo “nrpe” dodatka za Nagios koji se koristi za pokretanje

Nagiosovih plaginova na udalјenim računarima. Ovaj program je praktično jedan od načina

izvršavanja indirektnog provera. Kada Nagios izda komandu provere pomoću ovog plagina, plagin

prvo pokušava da preko određenog porta uspostavi konekciju sa “nrpe” daemon-om na definisanom

udalјenom računaru i izdaje mu zahtev za izvršavanjem određene komande provere. Demonski

program “nrpe” izvršava zadatu komandu i rezultate provere vraća check_”nrpe” plaginu, da bi ih on

konačno podneo Nagiosu. Ovim se omogućava da Nagios izvršava provere pomoću plaginova na

udalјenim hostovima kao da su lokalni.

Plagin za konekciju koristi podrazumevani port 5666, ali pomoću flega “–p” dozvolјeno je opciono

definisanje proizvolјnog neprivilegovanog porta (većeg od 1024) koji će se koristiti za komunikaciju.

Ova opcija može biti jako korisna ako se između nadgledajućeg hosta i udalјenog računara nalazi

“firewall”. Komanda provere se zadaje iza obligatornog flega “–C”, pri čemu je ona zapravo samo

kratko ime komande koja je u potpunosti definisana u konfiguraciji “nrpe” demona na udalјenom hostu.

2.1.10 “check_ping”

Format: “check_ping -H <host_address> -w <wrta>,<wpl>% -c <crta>,<cpl>% [-p packets] [-t

timeout] [-4|-6]”

Plagin “check_ping” pomoću “ICMP” eho zahteva proverava dostupnost mrežnih hostova i uređaja.

Takođe, meri prosek vremena u milisekundama za koje se “ICMP” paket vrati nazad (“RTT – round

trip time”) i procentualni gubitak poslatih paketa (“PL – packet loss”). Obaveznim flegovima “–H”, “–

w” i “–c” zadaju se “IP” adresa proveravanog hosta ili mrežnog interfejsa, vrednosti pragova za

“WARNING” i “CRITICAL” status, respektivno. Kada se neki prag prekorači, plagin vraća

odgovarajući status. Opcionim flegom “–p” definiše se broj “ICMP” paketa koji se šalјe prilikom

provere.

Plagin je dobio ime po programu ping koji je standardna alatka za proveru konektivnosti hosta u mreži.

Pored ovog, postoji i “check_fping” plagin iste namene koji je napisan tako da vrši brže provere

dostupnosti hosta u okruženjima sa ogromnog brojem hostova koji se proveravaju.

2.1.11 “check_pop”

Format: “check_pop -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>] [-e

<expect string>] [-q <quit string>][-m <maximum bytes>] [-d <delay>] [-t <timeout seconds>] [-r



Plagin “check_pop” služi za proveru ispravnosti rada “POP3” email servera na mreži. U osnovi ovog

plagina krije se “check_tcp” plagin koji otvara i zatvara konekciju na portu 110 udalјenog servera (ako

nije definisano drugačije). Iz formata komande se može videti da je podržano još nekoliko

interesantnih opcija. Omogućeno je definisanje pragova za dozvolјena vremena odziva “POP3” servera

u sekundama, koji za dato prekoračenje podižu odgovarajući alarm. Takođe, podržano je i slanje

definisanog stringa serveru i upoređivanje odgovora sa očekivanim stringom odogovora. Opcionim

flegom “–W” može se definisati vreme čekanja (“wait”) u sekundama od trenutka slanja stringa do

početka poliranja odziva.

62

2.1.12 “check_procs”

Format: “check_procs -w <range> -c <range> [-m metric] [-s state] [-p ppid] [-u user] [-r rss] [-z vsz]

[-P %cpu] [-a argument-array] [-C command] [-t timeout] [-v]”

Plagin “check_procs” služi za proveru broja tekućih procesa u određenom stanju na lokalnom sistemu.

Može se koristiti za nadgledanje ispravnosti rada nekog bitnog procesa na sistemu i u kombinaciji sa

odgovarajućim “event” hendlerom koji, primera radi, pre nego što podigne uzbunu, pokušava da

restartuje proces ili na neki drugi način reši problem.

Baziran je na standardnom Linux programu ps koji daje listu tekućih procesa na sistemu. Plagin radi

tako što parsira izlaz programa “ps” i prebrojava tekuće proces sa nekim zadatim osobinama. Kada taj

broj prevaziđe prag, iskoči iz zadatog opsega ili bude ispod zadatog minimuma procesa, plagin će

podići odgovarajući alarm. Opsezi se zadaju u formatu “ 'min:max' ili 'min:' ili ':max' “. Korišćenjem

opcionog flega “–s” mogu se posebno prebrojavati procesi u određenom stanju, gde se sa “R”

označava proces koji se izvršava (“running”), sa “S” proces koji je zaustavlјen (“stopped”), sa “Z”

proces koji se zaglavio (“zombie”), itd. Takođe, plagin daje mnoštvo mogućnosti obzirom da se mogu

filtrirati i prebrojavati tekući procesi nekog zadatog korisnika odnosno programa, procesi sa zadatim

“PID-om” ili sa zadatim stringom komande. Ovo je jedan od plaginova koji zahteva da bude instaliran

na računaru čije broj procesa proverava.

2.1.13 “check_smtp”

Format: “check_smtp -H host [-p port] [-4|-6] [-e expect] [-C command] [-R response] [-f from addr] [-

A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-q] [-F fqdn] [-S] [-D warn days

cert expire[,crit days cert expire]] [-v]“

Plagin “check_smtp” služi za proveru ispravnosti rada “SMPT” email servera na mreži. U osnovi ovog

plagina krije se “check_tcp” plagin koji otvara i zatvara konekciju na udalјenom serveru na

standardnom portu 25 (ako nije definisano drugačije). Iz formata se može videti da je podržano još

nekoliko interesantnih opcija provere. Omogućeno je definisanje pragova za dozvolјena vremena

odziva “SMTP” servera u sekundama, koja kada se prekorače podižu odgovarajući alarm. Takođe,

opcionim flegom “–e” podržana je provera slaganja povratnog stringa po uspostavi konekcije sa

očekivanim stringom odogovora. Ako se ovaj fleg ne navede, plagin podrazumevano očekuje da server

na “HELO” “SMTP” komandu odgovori stringom “220” (konekcija uspešna). Flegom “–f” zadaje se

adresa pozivajućeg računara koja se uklјučuje u “MAIL” komandu. Nјegova upotreba je obavezna

samo kod nadgledanja “MS Exchange email server”. Bez navođenja “–f” flega, vrednost ovog

argumenta je “NULL”.

2.1.14 “check_snmp”

Format: “check_snmp -H <ip_address> -o <OID> [-w warn_range] [-c crit_range] [-C community] [-s

string] [-r regex] [-R regexi] [-t timeout] [-e retries] [-l label] [-u units] [-p port-number] [-d delimiter]

[-D output-delimiter] [-m miblist] [-P snmp version] [-L seclevel] [-U secname] [-a authproto] [-A

authpasswd] [-x privproto] [-X privpasswd]”

Plagin “check_snmp” služi za nadgledanje sistemskih informacija na hostovima i mrežnim uređajima

pomoću “SNMP” protokola koji je prihvaćen kao osnovni metod upravlјanja i nagledanja u “TCP/IP”

mrežama. Zbog jako zgodnih mogućnosti koje pruža ovaj protokol, ovim plaginom se može pokriti

nadgledanje jako velikog broja različitih servisa. Praktično, može se nadgledati bilo koja promenlјiva u

63

“Management Information Base (MIB)” stablu nadgledanog uređaja. “MIB-ovi” su pak skupovi

statističkih i kontrolnih vrednosti organizovanih ustrukturu stabla.

Jedini uslov za nadgledanje ovim plaginom jeste da na nadgledanim hostovima ili mrežnim uređajima

postoji implementiran “SNMP” protokol. Takođe, plagin zahteva da se na nadgledajućem hostu

instalira programski alat iz “NET-SNMP” koji je zapravo jedna “open source” implementacija ovog

protokola. Plagin koristi program snmpget uklјučen u “NET-SNMP” paket kako bi dovukao vrednost

zadatog identifikatora promelјive (tzv. “Object Identifier – OID”) u “MIB” stablu i potom obrađuje

njen izlaz.

U okviru jedne komande plagina može da se dovuče do osam zapetom ili prazninom razdvojenih

“OID-a”. Jedan ili lista “OID-a” se navode iza flega “–o“ pri čemu se ravnopravno može koristiti

brojna ili tekstualna notacija.

Izlaskom dovučene ili dovučenih vrednosti “OID-a” van zadatih opsega celih brojeva (definisano

flegovima “–w” i “–c”), plagin vraća “non-OK” status. Opsezi se notiraju dvotačkom (npr. “min:max”),

dok se obični celi brojevi tumače kao gornje granice, odnosno pragovi. Beskonačna vrednost granice

opsega predstavlјa se izostavlјanjem vrednosti za tu granicu (npr. min: ). Ako je u komandi provere

zadata lista “OID-a”, kao u drugom primeru, iza flegova “–w” i “–c” je potrebno navesti liste zapetom

odvojenih opsega. Plagin vraća status “OK” samo ako se sve nadgledane vrednosti nalaze unutar

odgovarajućih definisanih opsega.

Flegom “–C” (veliko slovo ‘C‘!) definiše se “community” string koji predstavlјa bezbednosni

mehanizam korišćen u većini verzija “SNMP” protokola. Ovaj string predstavlјa neku vrstu lozinke

sadržane u “SNMP” poruci kojom program menadžer (u ovom slučaju program snmpget) zahteva neku

informaciju ili upravlјačku operaciju od agentskog programa na nadgledanom uređaju. Ukoliko zahtev

sadrži agentu poznati “community” string, na ovaj zahtev se odgovara. Ako se u plaginu ovaj fleg ne

navede, za “SNMP” upit se koristi podrazumevani “community” string “public”. To je obično

“default” vrednost stringa sa “read only” pravom pristupa u većini implementacija koja zadovolјava

potrebe nadgledanja. Iz sigurnosnih razloga, postavlјeni “community” stringovi na važnijim ruterima i

svičevima su obično tajni.

“SNMP” protokola koja se može koristiti za nadgledanje zavisi pre svega od verzije koju koristi agent

na nadgledanom hostu. Ovo se kontroliše flegom “–P”. “SNMPv3” protokol ima dobro razrađene

sigurnosne mehanizme. Ukoliko se ipak koristi samo ova ova verzija, na raspolaganju stoji nekoliko

flegova koji su posvećeni samo kontroli sigurnosnih mehanizama implementiranih u “SNMPv3”

protokol. Podrška za tzv. “User based Security Model for version 3 of SNMP” je sadržana u sledećim

opcijama:

“–L” ili “–seclevel” = “[noAuthNoPriv|authNoPriv|authPriv]” – kontroliše nivo sigurnosti u

smislu da li se “” komunikacija vrši bez enkripcije (“noAuthNoPriv”), samo sa autorizacijom

(“authNoPriv”) ili i sa autorizacijom i sa privatnošću (“authPriv”).

“–U” ili “–secname” = “USERNAME” – definiše korisničko ime za autentifikaciju

“–a” ili “–authproto” = “[MD5|SHA]” – definiše korišćeni algoritam enkripcije autentifikacije,

“MD5” ili “SHA”

“–A” ili “—authpassword” = “PASSWORD” – definiše korisničku lozinku za autentifikaciju

ukoliko se koristi samo autorizacija

“–X” ili “—privpasswd” = “PASSWORD” – definiše korisničku lozinku za autentifikaciju

ukoliko se koristi i autorizacija i privatnost (enkriptovano “DES” algoritmom).

Za komunikaciju “SNMP” protokolom obično se koristi standardni port 161, ali pomoću opcionog

flega “–p” sa udalјenim agentima moguće je ostvarivati komunikaciju na proizvojno definisanom portu.

Ako se ovaj fleg ne navede, plagin će podrazumevano koristiti standardni “SNMP” port 161.

64

Flegovima “–u” i “–l” omogućeno je definisanje jedinice za vraćenu vrednost plagina i labele koja će

se pojaviti na početku tekstulanog izlaza plagina.

Način obrade izlaza korišćenog “snmpget” programa takođe se može prilagoditi specifičnim

potrebama korišćenjem sledećih flegova:

“–d” ili “—delimiter” = “STRING” – definiše delimiter koji se koristi pri parsiranju tekstualnog

izlaza “snmpget” komande. U obzir se uzimaju sve vrednosti koje se nađu sa desne strane

znaka delimitera. Ako se fleg ne definiše, plagin kao delimiter koristi podrazumevano znak

jednakosti ("=").

“–D” ili “--output-delimiter” = “STRING” – definiše delimiter koji odvaja izlaz “snmpget”

komande kada se zahteva dovlačenje vrednosti više “OID-a”.

“–s” ili “—string” = “STRING” – definiše string za određeni “OID” koji se u tačno istom obliku

očekuje u izlazu provere i u tom slučaju (za taj “OID”) vraća “OK” status.

“–r” ili “—ereg” = “REGEX” – definiše regularni izraz (“regular expresion” ili skraćeno

“regex”) kojim se parsira izlaz provere i u slučaju uspeha (za taj “OID”) vraća “OK” status.

“–R” ili “—eregi” = “REGEX” – definiše takođe regularni izraz kao prethodni fleg s jedinom

razlikom da se u ovom slučaju ne razlikuju mala i velika slova (“case insensitive”).

Na kraju, flegom “–m” definiše se lista “MIB” stabala koje je potrebno učitati da bi “snmpget” mogao

da pronađe i vrati vrednost određene promenlјive “OID-a”. Ako se fleg ne navede, “snmpget” će se

izvršavati kao da je u plaginu navedeno “–m ALL”, odnosno kao da su učitane sve raspoložive “MIB”

liste.

2.1.15 “check_spop”

Format: “check_spop -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>] [-e




Plagin “check_spop” služi za proveru ispravnosti rada “Secure POP3 email” servera na mreži. Iz

formata komande se može videti da je podržano još nekoliko interesantnih opcija. Omogućeno je

definisanje pragova za dozvolјena vremena odziva “SPOP” servera u sekundama, koji za dato

prekoračenje podižu odgovarajući alarm. Takođe, podržano je i slanje definisanog stringa serveru,

upoređivanje odgovora sa očekivanim stringom odgovora i zadavanje stringa za čisto zatvaranje

konekcije sa serverom. Opcionim flegom “–d” može se definisati vreme čekanja (“delay”) u

sekundama od trenutka slanja stringa do početka poliranja odziva. Takođe, opcionim flegom “–m”

može se definisati broj bajtova nakon čijeg primanja plagin proglašava proveru uspešnom.

2.1.16 “check_swap”

Format: “check_swap [-av] -w <percent_free>% -c <percent_free>% check_swap [-av] -w

<bytes_free> -c <bytes_free>”

Plagin “check_swap” služi za proveru popunjenosti “swap” particija na lokalnoj Unix ili Linux

platformi. Vrednost pragova za status “WARNING” i “CRITICAL” može biti zadata u procentima

zauzetog memorijskog “swap” prostora ili celobrojnim vrednostima slobodnih bajtova. Kada slobodan

memorijski prostor padne ispod definisanih pragova, plagin će podići odgovarajući alarm. Ako se

navede opcioni plagin, plagin će sa zadatim pragovima uporediti svaku “swap” particiju ponaosob.

65

Ovo je jedan od plaginova koji zahteva da bude instaliran na računaru čije se swap particije

proveravaju.

2.1.17 “check_users”

Format: “check_users -w <users> -c <users>”

Plagin “check_users” služi za proveru broja logovanih korisnika na lokalnoj Unix ili Linux platformi.

Plagin je baziran na standardnoj Unix/Linux programskoj alatki who koji izlistava sve ulogovane

korisnike na sistemu. Vrednost pragova za status “WARNING” i “CRITICAL” se zadaje celim

brojevima logovanih korisnika. Kada broj logovanih korisnika pređe zadatu vrednost praga, plagin će

podići odgovarajući alarm. Ovo je jedan od plaginova koji zahteva da bude instaliran na računaru na

kome se nadgleda broj ulogovanih korisnika.

2.1.18 “check_tcp”

Format: “check_tcp -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>] [-e




Plagin “check_tcp” služi za proveru raposloživosti bilo kog “TCP” porta na nadgledanom hostu. Kao

što je ranije već napominjano, iz ovog plagina je izvedeno nekoliko specijalizovanih plaginova kao što

su “check_smtp, check_ftp, check_pop”, itd. Iz formata se može videti da je ovaj plagin takođe

opremlјen svim potrebnim opcijama koje poseduju “check_ftp, check_pop” i sl., tako da se provere

rada FTP, “POP3, HTTP” ili “HTTPS” servera mogu veoma lako da se realizuju i pomoću ovog

plagina.

2.1.19 “check_ups”

Format: “check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-t timeout]”

Ovaj plagin se koristi za određivanje statusa “UPS-a” (Uninterruptible Power Supply) na

lokalnom ili udalјenom hostu. Ako je “UPS” na mreži i baterija mu je napunjena iznad definisane

vrednosti koja je veća od“warn_value”, plagin će vratiti “OK” status. Ako je kapacitet baterije ispod

“warn_value” granice, rezultat plagina će biti “WARNING”. Ako je “UPS” isklјučen ili je kapacitet

baterije ispod “crit_value” granice, rezultat plagina će biti “CRITICAL”.

2.2 Konfiguracija

Prilikom pisanja konfiguracionih datoteka treba voditi računa o sledećim pravilima kako bi ih Nagios

pravilno isparsirao:

1. linije koje počinju karakterom “#” tumače se kao komentari i nemaju nikakav uticaj na

konfiguraciju

2. imena promenlјivih obavezno počinju od početka linije bez umetnutih belina ispred i

3. imena promenlјivih razlikuju mala i velika slova (“case sensitive”)

2.2.1 Glavna konfiguraciona datoteka – “nagios.cfg”

Podrazumevani naziv glavne konfiguracione datoteke je nagios.cfg i lociran je u

“ /usr/local/nagios/etc/” direktorijumu. U ovoj datoteci se definišu parametri kojim se globalno utiče

na rad jezgra programa.

66

2.2.2 Definisanje log datoteke

Format: log_file=<file_name >

Primer: log_file=/var/nagios/nagios.log

Ova direktiva određuje gde će Nagios da kreira svoju glavnu log datoteku. To bi ujedno trebalo da

bude i prva direktiva koja se definiše u konfiguracionoj datoteci, pošto će Nagios pokušati da u ovu

datoteku upiše sve greške na koje naiđe u preostalim konfiguracionim datotekama. Ako se omogući

rotacija logova, ova datoteka će automatski biti rotirana svakog časa, dana, nedelјe ili meseca.

2.2.3 Imena i putanje konfiguracionih datoteka objekata

Format: cfg_file=<file_name>

Primeri: cfg_file=/etc/nagios/hosts.cfg

cfg_file=/etc/nagios/aditional_hosts.cfg

cfg_file=/etc/nagios/services.cfg

cfg_file=/etc/nagios/commands.cfg

Ova direktiva se koristi za specifikaciju konfiguracionih datoteka objekata koje Nagios treba da koristi

za nadgledanje. Konfiguracione datoteke objekata sadrže definicije hostova, servisa, grupa hostova,

kotakata, grupa kontakata, komandi itd. Kada je broj objekata u konfiguraciji jako veliki,

konfiguracione daoteke se mogu podeliti u više datoteka korišćenjem više “cfg_file” = direktiva.

Nagios će ih sve pročitati. Primera radi, ovo može biti jako zgodno ukoliko postoji potreba za

isklјučivanjem ili uklјučivanjem u proces nadgledanja određene grupe objekata čije se definicije nalaze

u zasebnoj datoteci. U datom primeru, isklјučivanje čitave grupe hostova definisanih u datoteci

“aditional_hosts.cfg” iz procesa nadgledanja bi se jednostavno izvršilo dodavanjem znaka za komentar

‘#’ ispred njegove direktive i reinicijalizacijom programa.

2.2.4 Direktorijum sa konfiguracionim datotekama objekta

Format: cfg_dir=<directory_name>

Primeri: cfg_dir=/etc/nagios/hosts

cfg_dir=/etc/nagios/services

Ako je broj konfiguracionih datoteka toliko veliki da ni prethodno opisana direktiva nije zgodna za

upotrebu, onda se može koristiti “cfg_dir” direktiva. Povećanje preglednosti konfiguracije se postiže

definisanjem čitavog direktorijuma koji sadrži konfiguracione datoteke objekata. Direktiva primorava

Nagios da procesira sve konfiguracione datoteke u ovako navedenom direktorijumu sa ekstenzijom

“.cfg” bez eksplicitnog navođenja njihovih imena. Na ovaj način konfiguracione datoteke mogu da se

rasporede na želјeni način u različite direktorijume pri čemu se za svaki konfiguracioni direktorijum

ponaosob mora navesti direktiva “cfg_dir”.

2.2.5 Fajl sačuvanih objekata

Format: “object_cache_file=<file_name>”

Primer: “object_cache_file=/usr/local/nagios/var/objects.cache”

67

Ova direktiva se koristi da definiše fajl u kome će se čuvati kopija definicije objekata. Ovaj fajl će se

rekreirati svakog puta kada se Nagios restartuje. Nјegova svrha je da ubrza čuvanje konfiguracionih

fajlova u “CGI-u” i dozvoli izmenu izvornih konfiguracionih datoteka dok Nagios radi bez oštećenja

prikaza od strane “CGI-a”.

2.2.6 Definisanje “resource” datoteke

Format: “resource_file=<file_name>”

Primer: “resource_file=/etc/nagios/resource.cfg”

Ova direktiva se koristi za definisanje opcione risors datoteke koja može da sadrži “$USERn$”

definicije makroa. “$USER$” makroi se koriste za čuvanje korisničkih imena, lozinki i uopšte stvari

koje se često koriste u definicijama komandi (kao npr. putanje do direktorijuma plaginova ili “event”

hendlera). Pošto nije predviđeno da “CGI” skriptovi čitaju “resource” datoteke, iz sigurnosnih razloga

poželјno je da se nad ovakvim datotekama postave veoma restriktivne dozvole (na primer, 600 ili 660).

Moguće je definisati više “resource” datoteka višestrukim navođenjem “resource_file” direktive u

glavnoj konfiguracionoj datoteci. Nagios će sve da ih procesira.

2.2.7 Definisanje “temp” datoteke

Format: “temp_file=<file_name>”

Primer: “temp_file=/var/nagios/nagios.tmp”

Ovo je privremena (“temp”) datoteka koju Nagios povremeno kreira i upotreblјava prilikom

osvežavanja podataka o statusu, komentarima itd. Temp datoteka se briše kada više nije potrebna.

2.2.8 Putanja “temp” datoteke

Format: “temp_file = temp_path=<dir_name>”

Primer: “temp_path = /tmp”

Ovaj direktorijum Nagios može da koristi kao prazan prostor u kome će kreirati temp fajlovi tokom

procesa monitoringa. Treba pokrenuti tmpwatch ili sličnu opciju za ovaj direktorijum da bi se

povremeno brisali fajlovi koji su stariji od 24 sata.

2.2.9 Definisanje statusne datoteke

Format: “status_file=<ime_datoteke>”

Primer: “status_file=/var/nagios/status.log”

Ovu datoteku Nagios koristi za čuvanje informacija o statusu svih servisa koji se nadgledaju. Takođe,

ovde se čuvaju i statusne informacije o svim hostovima koji su pridruženi nadgledanim servisima. Ovu

datoteku koriste “CGI” skriptovi kako bi preko web interfejsa mogli da prikažu trenutni status

nadgledanih objekata. Iz tog razloga, “CGI” skriptovi moraju da imaju dozvole čitanja ove datoteke.

Inače, Nagios briše ovu datoteku kad god se zaustavi i ponovo je kreira pri (re)startovanju.

2.2.10 Vremenski interval ažuriranja statusne datoteke

Format: “status_update_interval=<seconds>”

Primer: “status_update_interval=15”

68

Pomoću ove direktive se definiše vremenski interval u kojem će Nagios ažurirati podatke o statusu

svih servisa koji se nadgledaju. Najmanji vremenski interval je 1 sekunda.

2.2.11 Korisničko ime pod kojim se izvršava Nagios

Format: “nagios_user = <username/UID>”

Primer: “nagios_user = nagios”

Ovde se podešava korisničko ime pod kojim će se Nagios proces izvršavati. Nakon inicijalnog

podizanja programa i pre početka bilo kakvog nadgledanja, Nagios će odbaciti dozvole pod kojim je

pokrenut i nastaviti rad pod ovim korisničkim nalogom i njemu pridruženim dozvolama. Opciono,

mogu se navesti ili korisničko ime ili korisnički “UID” broj. Sasvim je svejedno.

2.2.12 Grupa korisnika kojoj pripada korisnik Nagios

Format: “nagios_group=<groupname/GID>”

Primer: “nagios_group=nagios”

Potpuno analogni komentari kao o prethodno objašnjenoj direktivi za definisanje korisničkog imena

pod kojim se izvršava Nagios. Pre početka programa i vršena monitoringa, Nagios će dati privilegije

grupi. Opciono, mogu se navesti ili ime grupe ili korisnički “GID” broj. Sasvim je svejedno.

2.2.13 Kontrola obaveštavanja

Format: “enable_notifications=<0/1>”

Primer: “enable_notifications=1”

Ovom direktivom se na nivou čitavog programa kontroliše mogućnost da Nagios šalјe bilo kakva

obaveštenja. Ako se ova opcija isklјuči, Nagios neće poslati ni jedno obaveštenje ni za jedan host ili

servis. Opcije su:

0 = isklјučena opcija obaveštavanja na nivou čitave konfiguracije

1 = uklјučena opcija obaveštavanja na nivou čitave konfiguracije (“default”)

2.2.14 Kontrola provere servisa

Format: “execute_service_checks=<0/1>”

Primer: “execute_service_checks=1”

Ovom direktivom određuje se da li je Nagiosu dozvolјeno da izvršava provere servisa (service checks).

Ako je ova opcija deaktivirana, Nagios neće vršiti nikakve provere servisa i ostaće u nekoj vrsti

“uspavanog” stanja (pri čemu još uvek može da prima pasivne provere, ako i one nisu isklјučene). Ova

direktiva se najčešće koristi kada se konfigurišu redundantni “back up” monitoring serveri ili kada se

konfiguriše distribuirano monitoring okruženje. Opcije su sledeće:

0 = provere servisa zabranjene na nivou čitave konfiguracije

69

1 = provere servisa dozvolјene na nivou čitave konfiguracije (“default”)

2.2.15 Kontrola prihvatanja pasivnih provera servisa

Format: “accept_passive_service_checks=<0/1>”

Primer: “accept_passive_service_checks=1”

Ovom direktivom se kontroliše mogućnost Nagiosa da prihvata pasivne provere servisa na nivou

čitave konfiguracije. Ako je opcija isklјučena, Nagios neće prihvatiti nijednu pasivnu proveru servisa

bez obzira ako su, na primer, one omogućene lokalnim direktivama u definicijama servisa. Opcije su

sledeće:

0 = zabrana prihvatanja pasivnih provera servisa na nivou čitave konfiguracije

1 = dozvolјeno prihvatanja pasivnih provera servisa na nivou čitave konfiguracije (“default”)

2.2.16 Kontrola provere hostova

Format: “execute_host_checks=<0/1>”

Primer: “execute_host_checks=1”

Ovom direktivom određuje se da li je Nagiosu dozvolјeno da izvršava provere hostova (host checks).

Ako je ova opcija deaktivirana, Nagios neće vršiti nikakve provere hostova i ostaće u nekoj vrsti

“uspavanog” stanja (pri čemu još uvek može da prima pasivne provere, ako i one nisu isklјučene). Ova

direktiva se najčešće koristi kada se konfigurišu redundantni “back up” monitoring serveri ili kada se

konfiguriše distribuirano monitoring okruženje. Opcije su sledeće:

0 = provere hostova zabranjene na nivou čitave konfiguracije

1 = provere hostova dozvolјene na nivou čitave konfiguracije (“default”)

2.2.17 Kontrola prihvatanja pasivnih provera hostova

Format: “accept_passive_host_checks=<0/1>”

Primer: “accept_passive_host_checks=1”

Ovom direktivom se kontroliše mogućnost Nagiosa da prihvata pasivne provere hostova na nivou

čitave konfiguracije. Ako je opcija isklјučena, Nagios neće prihvatiti nijednu pasivnu proveru servisa

bez obzira ako su, na primer, one omogućene lokalnim direktivama u definicijama servisa. Opcije su

sledeće:

0 = zabrana prihvatanja pasivnih provera hostova na nivou čitave konfiguracije

1 = dozvolјeno prihvatanja pasivnih provera hostova na nivou čitave konfiguracije (default)

2.2.18 Kontrola rukovanja događajima (“event handling”)

Format: “enable_event_handlers=<0/1>”

Primer: “enable_event_handlers=1”

70

Ova direktiva globalno određuje da li se omogućava rukovanje događajima (“event handling”) na

nivou čitave konfiguracije. Ako se ova opcija isklјuči, Nagios neće pokretati ni jedan “event” hendler.

0 = zabranjeno pokretanje event hendlera na nivou čitave konfiguracije

1 = dozvolјeno pokretanje event hendlera na nivou čitave konfiguracije (“default”)

2.2.19 Metod rotacije log datoteka

Format: “log_rotation_method=<n/h/d/w/m>”

Primer: “log_rotation_method=d”

Nagios nudi nekoliko metoda za rotaciju log datoteke. Opcione vrednosti su:

“n” = bez rotacije (log datoteka se nikada ne rotira) (default)

“h” = na sat (log datoteka se rotira na početku svakog punog časa)

“d” = dnevno (log datoteka se rotira svakog dana u ponoć)

“w” = nedelјno (log datoteka se rotira subotom u ponoć)

“m” = mesečno (log datoteka se rotira u ponoć svakog poslednjeg dana u mesecu)

2.2.20 Putanja arhive logova

Format: “log_archive_path=<putanja>”

Primer: “log_archive_path=/var/nagios/archives/”

Ovom direktivom se definiše ime direktorijuma u koji će Nagios da odlaže rotirane log datoteke.

Direktiva se ignoriše ako nije odabran nikakav metod rotacije log , tj. “log_rotation_method=n”.

2.2.21 Kontrola provere eksternih komandi

Format: “check_external_commands=<0/1>”

Primer: “check_external_commands=1”

Ovom direktivom se kontroliše da li će Nagios proveravati sadržaj datoteke eksternih komandi. Ova

opcija treba da bude uklјučena ako se planira korišćenje komandnih “CGI” skriptova za izdavanje

komandi putem veb interfejsa. Isto je neophodno ukoliko treba dozvoliti da eksterne aplikacije (“third

party software”) budu u mogućnosti da izdaju komande Nagiosu upisivanjem u komandnu datoteku.

Treba imati na umu i to da omogućavanje ove opcije nosi izvesne sigurnosne rizike, budući da svako

ko može da upiše komandu u komandnu datoteku, može da kontroliše i čitav Nagios proces. S tim u

vezi, neophodno je obezbediti pravilno setovanje dozvola nad ovom datotekom.

0 = zabranjena provera datoteke eksternih komandi (“default”)

1 = dozvolјena provera datoteke eksternih komandi

2.2.22 Kontrola intervala između provera datoteke eksternih komandi

Format: “command_check_interval= <xxx>[s]”

71

Primer: “command_check_interval= -1”

Ovom direktivom se kontroliše dužina vremeskog intervala između dve provere sadržaja datoteke sa

eksternim komandama. Interval se zadaje celim brojem koji označava broj “vremenskih jedinica”.

Ukoliko nije menjana podrazumevana vrednost promenlјive “interval_lenght” (dužina “jediničnog”

intervala) od 60, ova vrednost podrazumeva minute. Ako se iza zadatog broja doda slovo “s” (npr. 30s),

Nagios će interval tumačiti kao interval u sekundama. Zadavanjem vrednosti -1, Nagios će vršiti

provere sadržaja datoteke eksternih komandi što je češće moguće. Svaki put kada izvrši proveru

eksterne komande, on će, pre nego što nastavi sa svojim ostalim zadacima, pročitati i obraditi sve

komande koje se nalaze u komandnoj datoteci.

2.2.23 Definisanje datoteke eksternih komandi

Format: “command_file=<ime_datoteke>”

Primer: “command_file=/var/nagios/rw/nagios.cmd”

Ovo je direktiva kojom se definiše putanja i ime datoetke eksternih komandi. Nagios će proveriti

sadržaj ovog datoteke u potrazi za eksternim komandama koje treba da se izvrše. Za upisivanje

komandi u ovu datoteku kroz web interfejs zadužen je “command” “CGI” skript. Ako su nad ovim

fajlom valјano definisane dozvole upisa, i ostali “third party” programi mogu u njega da upisuju svoje

komande. Datoteka sa eksternim komandama implementirna je kao “named pipe” (“FIFO”), koji se

kreira pri inicijalizaciji Nagiosa, i briše pri njegovom zaustavlјanju. Ako pri inicijalizaciji Nagiosa

datoteka već postoji, Nagios će se zaustaviti i vratiti poruku o greški.

2.2.24 “Buffer” slotovi eksternih komandi

Format: “external_command_buffer_slots=<#>”

Primer: “external_command_buffer_slots=512”

Pomoću ove opcije se definiše koliko će “buffer” slotova Nagios rezervisati za čuvanje eksternih

komandi koje su pročitane iz fajla eksternih komandi od strane “worker” niti, ali nisu još uvek

procesuirane od strane glavne niti u Nagios daemonu. Svaki slot može da sadrži jednu eksternu

komandu, tako da se pomoću ove opcije određuje koliko komandi može biti učitano.

2.2.25 Provere ažuriranja verzije

Format: “check_for_updates=<0/1>”

Primer: “check_for_updates=1”

Pomoću ove opcije se definiše da li će Nagios automatski proveravati da li postoje nove verzije ili

“patch-ovi”. Preporučuje se omogućavanje ove opcije kako bi Nagios bio potpuno ažuran najnovijim

“patch-ovima”.

2.2.26 “Lock” datoteka

Format: “lock_file=<file_name>”

Primer: “lock_file=/tmp/nagios/nagios.lock”

72

Ovom direktivom specificira se lokacija “lock” datoteke koju će Nagios kreirati ako se pokrene kao

daemon. Ova datoteka sadrži identifikacioni broj Nagios procesa (“PID”).

2.2.27 Opcija pamćenja stanja hostova i servisa

Format: “retain_state_information=<0/1>”

Primer: “retain_state_information=1”

Ova direktiva kontroliše da li će Nagios da sačuva informacije o stanjima hostova i servisa između

zaustavlјanja i reinicijalizcije programa. Ako se ova opcija omogući, još je neophodno definisati ime

“state retention” datoteke “state_retenton_file” direktivom. U tom slučaju, Nagios će sačuvati sve

informacije o stanjima hostova i servisa pre nego što se zaustavi ili reinicijalizuje, ili ako se ponovo

bude inicijlizovao, iz pomenute datoteke pročitaće prethodno sačuvane informacije o stanjima hostova

i servisa. Opcije su:

0 = onemogućeno pamćenje informacija o statusu hostova i servisa

1 = omogućeno pamćenje informacija o statusu hostova i servisa (“default”)

2.2.28 “State retention” datoteka

Format: “state_retention_file=<file_name>”

Primer: “state_retention_file=/usr/local/nagios/var/retention.dat”

U ovoj datoteci Nagios “pamti” informacije o stanjima servisa i hostova pre nego što se zaustavi.

Prilikom procesa reinicijalizacije pre nego što počne sa nadgledanjem, iskoristiće informacije sačuvane

u ovoj datoteci za inicijalizaciju svih tekućih stanja hostova i servisa. Kada Nagios pročita informacije

o inicijalnim stanjima, ova datoteka se briše. Da bi primorali Nagios da sačuva informacije o stanjima

do svog sledećeg pokretanja, potrebno je prethodno opisanom direktivom uklјučiti opciju pamćenja

stanja.

2.2.29 Kontrola učestalosti automatskog ažuriranja “state retention” datoteke

Format: “retention_update_interval=<minutes>”

Primer: “retention_update_interval=60”

Ovom direktivom se kontroliše koliko često (izraženo u minutima) će Nagios automatski ažurirati

datoteku sa sačuvanim informacijama o stanjima hostova i servisa tokom njegovog normalnog rada.

Ako se zada vrednost 0, Nagios neće čuvati ove informacije u regularnim intervalima, već samo

prilikom zaustavlјanja ili reinicijalizacije. Ako je opcija pamćenja stanja isklјučena, ova direktiva

nema efekta.

2.2.30 Kontrola čuvanja stanja programa

Format: “use_retained_program_state=<0/1>”

Primer: “use_retained_program_state=1”

73

Ovim se kontroliše da li će Nagios pri reinicijalizaciji koristiti vrednosti nekih globalnih

konfiguracionih parametara na osnovu njihovih vrednosti iz datoteke definisane “state_retention_file”

direktivom. Neki od ovih globalnih konfiguracionih parametara koji se obično čuvaju prilikom

reinicijalizacije programa su parametri zadati direktivama “enable_notifications,

enable_flap_detection, enable_event_handlers, execute_service_checks” i

“accept_passive_service_checks”. Ako je opcija pamćenja stanja onemogućena, ova direktiva nema

efekta. Opcije su:

0 = globalni konfiguracioni parametri se ne pamte u “state retention” datoteci

1 = globalni konfiguracioni parametri se pamte u “state retention” datoteci

2.2.31 Kontrola logovanja u sistemsku log datoteku (“syslog”)

Format: “use_syslog=<0/1>”

Primer: “use_syslog=1”

Ovom direktivom se definiše da li se poruke koje proizvodi Nagios upisuju u sistemsku log datoteku

na lokalnom hostu.

0 = ne koristi se sistemska log datoteka

1 = sistemska log datoteka je u upotrebi

2.2.32 Kontrola logovanja notifikacija

Format: “log_notifications=<0/1>”

Primer: “log_notifications=1”

Određuje da li se u Nagiosovoj log datoteci vodi evidencija o odaslatim obaveštenjima. Ako je

definisan veći broj kontakata ili se javlјa veći broj regularnih grešaka servisa, log datoteka može

relativno brzo da se uveća.

0 = obaveštenja se ne loguju

1 = obaveštenja se loguju

2.2.33 Kontrola logovanja ponovnih pokušaja provere servisa

Format: “log_service_retries=<0/1>”

Primer: “log_service_retries=1”

Određuje da li se loguju ponovni pokušaji provere servisa. Ponovna provera servisa dešava se kada

provera vrati “non-OK” status, a Nagios je konfigurisan tako da izvestan broj puta ponovi proveru pre

konačnog obaveštavanja o problemu. U ovoj situaciji se kaže da je servis u “SOFT” stanju greške.

Logovanje ponovnih provera servisa je najkorisnija kada se testira ispravost rada “event” hendlera

servisa. Opcije:

0 = ponovni pokušaji provere servisa se ne loguju

1 = ponovni pokušaji provere servisa se loguju

74

2.2.34 Kontrola logovanja ponovnih pokušaja provere hostova

Format: “log_host_retries=<0/1>”

Primer: “log_host_retries=1”

Određuje da li se loguju ponovni pokušaji provere hostova. Ponovna provera hostova dešava se kada

provera rezultuje “non-OK” statusom, a Nagios je konfigurisan tako da izvestan broj puta ponovi

proveru pre konačnog obaveštavanja o problemu sa hostom. U ovoj situaciji se kaže da je host u

“SOFT” stanju greške. Logovanje ponovnih provera hostova je najkorisnija kada se testira ispravost

rada “event” hendlera hostova.

0 = ponovni pokušaji provere hostova se ne loguju

1 = ponovni pokušaji provere hostova se loguju

2.2.35 Kontrola logovanja “event” hendlera

Format: “log_event_handlers=<0/1>”

Primer: “log_event_handlers=1”

“Event” hendleri su opcione komande koje se izvršavaju kad god servisi ili hostovi promene svoje

stanje. Logovanje event hendlera je najkorisnije kada se testira ispravnost rada skripta event hendler.

Ova opcija se kontroliše upravo ovom direktivom.

0 = izvršavanje event hendlera se ne loguje

1 = izvršavanje event hendlera se loguje

2.2.36 Kontrola logovanja inicijalnih stanja

Format: “log_initial_states=<0/1>”

Primer: “log_initial_states=0”

Ova direktiva određuje da li se Nagios primorava da loguje sva inicijalna stanja hostova i servisa, čak i

ako su u OK stanju. Inicijalna stanja servisa i hostova se normalno loguju samo kada postoji problem

kod prve provere. Uklјučivanje ove opcije je korisno ako se koristi neka aplikacija ili skript koji

skenira log datoteku i utvrđuje dugoročnu statistiku grešaka servisa i hostova.

0 = inicijalna stanja se ne loguju (default)

1 = inicijalna stanja se loguju

2.2.37 Kontrola logovanja eksternih komandi

Format: “log_external_commands=<0/1>”

Primer: “log_external_commands=1”

75

Ova direktiva određuje da li će Nagios zapisivati u svoju log datoteku svako izvršavanje eksternih

komandi, a koje prima kroz datoteku eksternih komandi. Ovde se mora napomenuti da ova direktiva ne

kontroliše logovanje pasivnih provere servisa (koje jesu tip eksterne komande). Logovanje pasivnih

provera se kontroliše narednom direktivom.

0 = izvršavanje eksternih komandi se ne loguje

1 = izvršavanje eksternih komandi se loguje (default)

2.2.38 Kontrola logovanja pasivnih provera servisa

Format: “log_passive_ checks=<0/1>”

Primer: “log_passive_ checks=1”

Ovom direktivom se određuje da li se u Nagiosov log zapisuju pasivne provere servisa i hostova koje

se primaju posredstvom datoteke eksternih komandi. Ako se konfiguriše distribuirano monitoring

okruženje ili se planira rukovanje ogromnim brojem pasivnih provera na regularnoj bazi, preporučuje

se isklјučivanje ove opcije kako log datoteka ne bi previše brzo narasla.

0 = pasivne provere se ne loguju

1 = pasivne provere se loguju (“default”)

2.2.39 Definisanje globalnog “event” hendlera hostova

Format: “global_host_event_handler=<command>”

Primer: “global_host_event_handler=log-host-event-to-db”

Ova direktiva dozvolјava da se definiše komanda globalnog “event” hendlera hostova koja treba da se

izvrši prilikom promene stanja svakog hosta. Globalni “event” hendler se izvršava neposredno pre

ostalih (lokalnih) “event” hendlera koji se (opciono) definišu u svakoj definiciji hosta ponaosob.

Argument direktive je kratko ime komande koja se u celini definiše u objektnoj konfiguracionom

datoteci “commands.cfg”. Maksimalno dozvolјeno vreme izvršavanja globalnog event hendlera

kontroliše se direktivom “event_handler_timeout”.

2.2.40 Definisanje globalnog “event” hendlera servisa

Format: “global_service_event_handler=<command>”

Primer: “global_service_event_handler=log-service-event-to-db”

Ova direktiva dozvolјava da se definiše komanda globalnog “event” hendlera servisa koja treba da se

izvrši prilikom svake promene stanja servisa. Globalni “event” hendler se izvršava neposredno pre

ostalih (lokalnih) “event” hendlera koji se (opciono) definišu u svakoj definiciji servisa ponaosob.

Argument direktive je kratko ime komande koja je definisana u objektnoj konfiguracionoj datoteci

“commands.cfg”. Maksimalno dozvolјeno vreme izvršavanja komande hendlera kotroliše se

direktivom “event_handler_timeout”.

76

2.2.41 Definisanje intervala sna između provera

Format: “sleep_time=<br_sekundi>”

Primer: “sleep_time=1”

Ovom direktivom definiše se broj sekundi tokom kojih Nagios “spava” (pravi pauzu) pre nego što

proveri da li u redu za čekanje postoji sledeća provera servisa za izvršavanje. Treba reći da će Nagios

da spava samo ako u redu za čekanje postoje zaostale provere servisa (ako red nije prazan).

2.2.42 Metod vremenskog raspoređivanja izvršavanja provera

Format: “service_inter_check_delay_method=<n/d/s/x.xx>”

Primer: “service_inter_check_delay_method=s”

Ova direktiva dozvolјava kontrolisanje načina inicijalnog vremenskog raspoređivanja provera servisa u

redu za njihovo izvršavanje. Upotrebom “pametnog” izračunavanja raspoređivanja (“default”), Nagios

će izračunati srednji interval između provera i ravnomerno rasporediti trenutke izvršavanja inicijalnih

provera svih servisa unutar tog intervala i tako će eliminisati neravnomerno opterećenje procesora

nadgledajućeg hosta. Nekorišćenje inicijalnog raspoređivanja provera je generalno loša ideja, osim ako

se ne testira funkcionalnost paralelizacije provera servisa. U tom slučaju, sve inicijalne provere će biti

raspoređene za izvršavanje u istom trenutku! Postojeće opcije su:

“n” = ne koristi se vremensko razmeštanje provera (sve se izvršavaju paralelno u vremenu)

“d” = koristi se “glupo” vremensko razmeštanje od 1s između provera nezavisno od broja provera i sl.

“c” = koristi se pametno rapoređivanje provera u vremenu (default)

“x.xx” = koristi se korisnički definisano raspoređivanje sa intervalom od x.xx sekundi između dve

susedne provere

2.2.43 Definisanje faktora učešlјavanja servisa (“service interleave factor”)

Format: “service_interleave_factor=<s/x>”

Primer: “service_interleave_factor=s”

Ovom direktivom se određuje način na koji se provere servisa učešlјavaju. Učešlјavanjem (tj.

interlivingom) se obezbeđuje mnogo ravnomerniji raspored provera servisa stim da se smanjuje

opterećenje udalјenih (nadgledanih) hostova i ubrzava ukupni proces detekcije problema na hostovima.

Postavlјanje vrednosti faktora na 1 jednako je isklјučenju opcije učešlјavanja provera. Korišćenje

paralelnih provera servisa sa isklјučenom opcijom učešlјavanja provera može dovesti do situacije da

hostovi budu bombardovani istovremenim proverama što kao rezultat može imati neuspele provere ili

dobijanje netačnih rezultata od hostova preopterećenih drugim zahtevima za proverom servisa.

Preporučuje se postavlјanje vrednosti na “s” (“smart”) za “pametno” izračunavanje faktora

učešlјavanja osim ako ne postoji dobar razlog za njegovu promenu. Ponuđene opcije su:

“x” = korisnički definisana vrednost faktora interlivinga servisa ( ≥1).

“s” = koristi se pametni interliving (default)

77

2.2.44 Definisanje maksimalnog broja paralelnih provera servisa

Format: “max_concurrent_checks=<max_checks>”

Primer: “max_concurrent_checks=20”

Ova direktiva omogućava definisanje maksimalnog broja provera servisa koje se mogu izvršavati

paralelno u vremenu. Postavlјanjem vrednosti na 1 mogućnost konkurentnog izvršavanja provera se

isklјučuje. Postavlјanjem vrednosti na 0 (“default”) daje se mogućnost neograničenog broja

konkurentnih provera. U zavisnosti od raspoloživih resursa ova promenlјiva se postavlјa na

odgovarajuću vrednost pošto direktno utiče na maksimalno opterećenje kojem će sistem na kome se

izvršava Nagios biti izložen.

2.2.45 Definisanje učestalosti obrade rezultata provera

Format: “check_result_reaper_frequency =<frequency_in_seconds>”

Primer: “check_result_reaper_frequency =5”

Ova direktiva definiše učestalost obrade rezultata provera u sekundama. U zadatom intervalu vremena

vrši se obrada rezultata izvršenih provera hostova i servisa.

2.2.46 Dozvolјeno vreme učestalosti obrade rezultata provera

Format: “max_check_result_reaper_time=<seconds>”

Primer: “max_check_result_reaper_time=30”

Ova direktiva se koristi za definisanje maksimalnog vremenskog intervala provere hostova i servisa

izraženog u sekundama. Procesuiraju se samo oni rezultati obrade hostova i servisa koji su završili sa

radom.

2.2.47 Kontrola agresivne provere hostova

Format: “use_aggressive_host_checks=<0/1>”

Primer: “use_aggressive_host_checks=0”

Ovom direktivom kontroliše se način provere statusa hostova. Nagios se trudi da pametno odabere

trenutak provere statusa hostova. Generalno, onemogućavanje opcije agresivnog proveravanja statusa

hostova dozvolјava Nagiosu da donosi pametnije odluke i proverava hostove nešto brže. S druge strane,

omogućavanjem ove opcije vreme potrebno za proveru hostova će se uvećati, ali će se pouzdanost

vraćenih podataka neznatno popraviti. Osim ako ne postoji problem prepoznavanja oporavka hostova,

preporučuje se onemogućavanje ove opcije.

0 = hostovi se ne proveravaju agresivno (“default”)

1 = hostovi se agresivno proveravaju

2.2.48 Kontrola detekcije “flapovanja”

Format: “eable_flap_detection=<0/1>”

78

Primer: “enable_flap_detection=0”

Ovim se određuje da li će Nagios pokušati da detektuje hostove i servise koji “flapuju” (engl.

“flapping”). Za neki host ili servis kažemo da “flapuje” kada menja status suviše često. Detekcija

flapovanja je bitna jer se na taj način izbegavaju baraži poslatih obaveštenja. Kada Nagios detektuje da

host ili servis flepuje, privremeno će isklјučiti opciju obaveštavanja za taj host ili servis dok flepovanje

ne prestane.

0 = isklјučena detekcija flepovanja (default)

1 = uklјučena detekcija flepovanja

2.2.49 Definisanje donjeg praga “flapovanja” servisa

Format: “low_service_flap_treshold=<procent>”

Primer: “low_service_flap_treshold=25.0”

Ovom direktivom se definiše donji prag za detekciju flepovanja servisa.

2.2.50 Definisanje gornjeg praga “flapovanja” servisa

Format: “high_service_flap_treshold=<procent>”

Primer: “high_service_flap_treshold=50.0”

Ovom direktivom se definiše gornji prag za detekciju flepovanja servisa.

2.2.51 Definisanje donjeg praga “flapovanja” hosta

Format: “low_host_flap_treshold=<procenat>”

Primer: “low_host_flap_treshold=25.0”

Ovom direktivom se definiše donji prag za detekciju flepovanja hosta.

2.2.52 Definisanje gornjeg praga “flapovanja” hosta

Format: “high_host_flap_treshold=<procenat>”

Primer: “high_host_flap_treshold=50.0”

Ovom direktivom se definiše gornji prag za detekciju flepovanja hosta.

2.2.53 Kontrola provere zavisnost servisa u “SOFT” stanju

Format: “soft_state_dependencies=<0/1>”

Primer: “soft_state_dependencies=0”

79

Ova direktiva određuje da li Nagios koristi informaciju o “SOFT” stanju servisa kada proverava

zavisnosti servisa. U normalnim uslovima Nagios će koristiti samo poslednje “HARD” stanje servisa

prilikom provere zavisnosti.

0 = ne koriste se “SOFT” stanja prilikom provere zavinosti (“default”)

1 = koriste se “SOFT” stanja prilikom provere zavinosti

2.2.54 Vremenska kontrola provere servisa (“service check timeout”)

Format: “service_check_timeout=<seconds>”

Primer: “service_check_timeout=60”

Ovom direktivom se definiše maksimalno dozvolјeno vreme u sekundama izvršavanja provera servisa.

Ako provera probije ovaj interval, ona se ubija, vraća se “CRITICAL” status servisa i loguje se poruka

o greški probijanja intervala. Često postoji velika konfuzija oko toga šta ova opcija zapravo radi.

Zamišlјena je kao mehanizam poslednjeg leka za otklanjanje plaginova koji se ne ponašaju kako bi

trebalo niti se završavaju u predviđenom roku. Ovaj parameter treba podesiti na neku visoku vrednost

(kao što je 60 ili više sekundi), tako da svaka provera servisa ima dovolјno vremena da se izvrši unutar

ovog intervala. Ako provera bude trajala duže, Nagios će je ubiti misleći da se radi o zaglavlјenom

procesu.

2.2.55 Vremenska kontrola provere hosta (“host check timeout”)

Format: “host_check_timeout=<seconds>”

Primer: “host_check_timeout=60”

Ovom direktivom se definiše maksimalno dozvolјeno vreme u sekundama izvršavanja provera hostova.

Ako provera probije ovaj interval, ona se “ubija” i vraća se “CRITICAL” status, a za host se

podrazumeva da je u “DOWN” statusu. Takođe, poruka greške o probijanju intervala će se logovati.

Ova opcija je zamišlјena je kao mehanizam poslednjeg rešenja za otklanjanje plaginova koji se ne

ponašaju kako bi trebalo niti se završavaju u predviđenom roku. Ovaj parametar treba podesiti na neku

visoku vrednost (kao što je 60 ili više sekundi), tako da svaka provera hosta ima dovolјno vremena da

se izvrši unutar ovog intervala. Ako provera bude trajala duže, Nagios će je ubiti podrazumevajući da

se radi o procesu koji se zaglavio.

2.2.56 Vremenska kontrola event hendlera (“event handler check timeout”)

Format: “event_handler_timeout=<seconds>”

Primer: “event_handler_timeout=60”

Ova direktiva definiše maksimalni dozvolјeni vremenski interval u sekundama izvršavanja “event”

hendlera. Ako bilo koji hendler probije ovaj interval, biće ubijen, a poruka o greški probijanja intervala

će biti logovana. Kao i kod vremenske kontrole provera hostova, ova opcija je zamišlјena kao

mehanizam poslednjeg rešenja za ubijanje komandi “event” hendlera koje se ne ponašaju kako bi

trebalo ili se ne završavaju u predviđenom roku. Ovu promenlјivu treba podesiti na neku visoku

vrednost (kao što je 60 ili više sekundi), tako da svaka komanda ima dovolјno vremena da se izvrši

unutar ovog intervala. Ako komanda bude trajala duže, Nagios će je ubiti misleći da se radi o

zaglavlјenom procesu.

80

2.2.57 Vremenska kontrola opsesivno kompulsivne komande procesora servisa

Format: “ocsp_timeout=<seconds>”

Primer: “ocsp_timeout=5”

Ova direktiva definiše maksimalnu dužinu intervala u sekundama koju će Nagios dati komandi

opsesivno kompulsivnog procesora provera servisa da se izvršava. Ako se interval prekorači, komanda

će biti ubijena, a upozorenje logovano.

2.2.58 Vremenska kontrola komande procesora podataka o performansama

Format: “perfdata_timeout=<seconds>”

Primer: “perfdata_timeout=5”

Podešava maksimalnu dužinu intervala u sekundama koju će Nagios dati komandi procesora podataka

o performansama da se izvršava. Ako se interval prekorači, komanda će biti ubijena, a upozorenje

logovano.

2.2.59 Direktiva “Obsess Over Services”

Format: “obsess_over_services=<0/1>”

Primer: “obsess_over_services=0”

Ova direktiva određuje da li će Nagios “opsesivno” proveravati rezultate provera servisa i pokretati

prethodno definisane komande opsesivno kompulsivne obrade servisa.. Uklјučivanje ove opcije je

korisno kod distribuiranog nadgledanja. Ako se ne vrši distribuirano nadgledanje, toplo se preporučuje

njeno isklјučivanje.

0 = ne vrši se opsesivna provera rezultata provera servisa (“default”)

1 = vrši se opsesivna provera rezultata provera servisa

2.2.60 Definisanje komande opsesivno kompulsivnog procesora servisa

Format: “ocsp_command=<command>”

Primer: “ocsp_command=obsessive_service_handler”

Ovim se definiše komanda koja koja se izvršava nakon svake provere servisa, što može biti koriso kod

distribuiranog monitoringa. Ova komanda izvršava se posle bilo koje komande event hendlera ili

obaveštavanja. Argument komande je krako ime komande definisane u objektnoj konfiguracionoj

datoteci. Maksimalna dužina intervala u kom je dozvolјeno izvršavanje ove komande zadato je

ocsp_timeout opcijom.

2.2.61 Direktiva “Obsess Over Hosts”

Format: “obsess_over_services=<0/1>”

Primer: “obsess_over_services=0”

81

Ova direktiva određuje da li će Nagios “opsesivno” proveravati rezultate provera hostova i pokretati

prethodno definisane komande opsesivno kompulsivne obrade servisa.. Uklјučivanje ove opcije je

korisno kod distribuiranog nadgledanja. Ako se ne vrši distribuirano nadgledanje, toplo se preporučuje

njeno isklјučivanje.

0 = ne vrši se opsesivna provera rezultata provera hostova (“default”)

1 = vrši se opsesivna provera rezultata provera hostova

2.2.62 Definisanje komande opsesivno kompulsivnog procesora hosta

Format: “ocsp_command=<command>”

Primer: “ocsp_command=obsessive_host_handler”

Ovim se definiše komanda koja koja se izvršava nakon svake provere hosta, što može biti korisno kod

distribuiranog monitoringa. Ova komanda izvršava se posle bilo koje komande “event” hendlera ili

obaveštavanja. Argument komande je krako ime komande definisane u objektnoj konfiguracionoj

datoteci. Maksimalna dužina intervala u kom je dozvolјeno izvršavanje ove komande zadato je

ocsp_timeout opcijom.

2.2.63 Direktiva procesora podataka o performansama

Format: “process_performance_data=<0/1>”

Primer: “process_performance_data=0”

Direktiva određuje da li se vrši obrada podataka o performansama izvršenih provera.

0 = ne (“default”)

1 = da

2.2.64 Kontrola napuštenih provera servisa (“Orphaned service checks”)

Format: “check_for_orphaned_services=<0/1>”

Primer: “check_for_orphaned_services=0”

Ova direktiva daje mogućnost detekcije napuštenih provera servisa. Napuštene provere servisa su one

provere koje su izvršene, ali tokom dužeg perioda nisu vratile nikakav rezultat. Pošto se nisu vratili

nikakvi rezultati, ovakva provera servisa će biti vraćena i preraspoređena u red za čekanje. Ovo može

da izazove zaustavlјanje izvršavanja provera servisa. U normalnim uslovima to će se jako retko

dešavati – može da se desi kada neki eksterni proces ili korisnik ubije proces čiji se servis u tom

trenutku proveravao. Ako se ova opcija uklјuči i utvrdi se da se rezultati za tu proveru nisu vratili,

generisaće se poruka greške i izvršiti preraspoređivanje provere servisa. Ako se primete provere

servisa za koje izgledada nikad nisu preraspoređene, treba omogućiti ovu opciju i pogledati da li

postoji neki zapis u log datoteci o napuštenim servisima.

0 = ne proverava se postojanje napuštenih provera servisa (“default”)

82

1 = proverava se postojanje napuštenih provera servisa

2.2.65 Kontrola napuštenih provera hostova (“Orphaned host checks”)

Format: “check_for_orphaned_hosts=<0/1>”

Primer: “check_for_orphaned_hosts=0”

Ova direktiva daje mogućnost detekcije napuštenih provera hostova. Napuštene provere hostova su

one provere koje su izvršene, ali tokom dužeg perioda nisu vratile nikakav rezultat. Pošto se nisu

vratili nikakvi rezultati, ovakva provera hostova će biti vraćena i preraspoređena u red za čekanje. Ovo

može da izazove zaustavlјanje izvršavanja provera hostova. U normalnim uslovima to će se jako retko

dešavati – može da se desi kada neki eksterni proces ili korisnik ubije process čiji se servis u tom

trenutku proveravao. Ako se ova opcija uklјuči i utvrdi se da se rezultati za tu proveru nisu vratili,

generisaće se poruka greške i izvršiti preraspoređivanje provere hostova. Ako se primete provere

hostova za koje izgledada nikad nisu preraspoređene, treba omogućiti ovu opciju i pogledati da li

postoji neki zapis u log datoteci o napuštenim hostovima.

2.2.66 Kontrola “svežine” rezulta provera servisa

Format: “check_service_freshness=<0/1>”

Primer: “check_service_freshness=1”

Ova direktiva kontroliše da li Nagios periodično proverava “svežinu” vraćenih rezultata provera

servisa. Ova opcija je korisna kada se želi da Nagios proverava da li su rezultati pasivnih provera

servisa primlјeni u zadatom vremenskom intervalu. Ukoliko to nije slučaj, rezultati se smatraju

zastarelim, a servis bez obzira na rezultat dobija “CRITICAL” status.

0 = svežina rezultata provera se ne proverava

1 = svežina rezultata provera se proverava (“default”)

2.2.67 Definisanje intervala provere svežine servisa

Format: “freshness_check_interval=<seconds>”

Primer: “freshness_check_interval=60”

Ovom direktivom podešava se učestalost proveravanja svežine rezultata provere servisa. Ako je

kontrola svežine rezultata provera onemogućena, ova direktiva nema efekta.

2.2.68 Kontrola “svežine” rezulta provera hostova

Format: host_service_freshness=<0/1>

Primer: host_service_freshness=1

Ova direktiva kontroliše da li Nagios periodično proverava “svežinu” vraćenih rezultata provera

hostova. Ova opcija je korisna kada se želi da Nagios proverava da li su rezultati pasivnih provera

servisa primlјeni u zadatom vremenskom intervalu.

0 = svežina rezultata provera se ne proverava

1 = svežina rezultata provera se proverava (“default”)

83

2.2.69 Definisanje intervala provere svežine servisa

Format: “freshness_check_interval=<seconds>”

Primer: “freshness_check_interval=60”

Ovom direktivom podešava se učestalost proveravanja svežine rezultata provere hostova. Ako je

kontrola svežine rezultata provera onemogućena, ova direktiva nema efekta.

2.2.70 Definisanje ilegalnih karaktera imena objekata

Format: “illegal_object_name_chars=<chars…>”

Primer: “illegal_object_name_chars=`~!$%^&*"|'<>?,()”

Ovom direktivom se dozvolјava definisanje ilegalnih karaktera tj. karaktera čije se korišćenje

zabranjuje u imenima hostova, opisima servisa ili imenima drugih tipova objekata. Nagios dozvolјava

većinu karaktera u definicijama objekta, ali upotreba karaktera iz prikazanog primera se ne

preporučuje zato što mogu da stvore probleme u veb interfejsu, komandama obaveštenja itd.

2.2.71 Definisanje ilegalnih karaktera izlaza makroa

Format: “illegal_macro_output_chars=<chars…>”

Primer: “illegal_macro_output_chars=`~$^&"|'<>”

Ova direktiva dozvolјava da se definišu ilegalni karakteri koji treba da se izbace iz makroa pre nego

što se iskoriste u obaveštenjima, “event” hendlerima i ostalim komandma. Ovo ne utiče na makroe

koji se koriste u komandama provere servisa ili hostova. Može se izabrati da se karakteri prikazani u

gornjem primeru ne izbacuju, ali se savetuje da se to ne čini. Neki od ovih karaktera se mogu

interpretirati u konzoli i predstavlјaju potencijalne siguronosne probleme. Sledeći makroi su

oslobođeni definisanih karaktera:

“$HOSTOUTPUT$, $HOSTPERFDATA$, $HOSTACKAUTHOR$, $HOSTACKCOMMENT$, $SE

RVICEOUTPUT$, $SERVICEPERFDATA$, $SERVICEACKAUTHOR$,

and$SERVICEACKCOMMENT$”

2.2.72 Definisanje email adrese administratora Nagiosa

Format: “admin_email=<email_address>”

Primer: “admin_email= [email protected]”

Ovom direktivom se definiše email adresa administratora Nagiosa, tj. lokalne mašine. Umesto

eksplicitnog navođenja u komandama za obaveštavanje, ova adresa se može koristiti pomoću

“$ADMINEMAIL$” makroa.

84

2.3 Konfiguraciona datoteka “CGI” skriptova – “cgi.cfg”

Podrazumevani naziv konfiguracione datoteke “CGI” skriptova je cgi.cfg. U ovoj datoteci se definišu

parametri kojim se utiče na rad “CGI” skriptova. Takođe sadrži reference ka glavnom

konfiguracionom fajlu, tako da “CGI” ima uvid u konfiguraciju Nagiosa i lokaciju definicija objekata.

Lokacija ove konfiguracione datoteke je “ /usr/local/nagios/etc/”.

2.3.1 Lokacija glavne konfiguracione datoteke

Format: “main_config_file=<file_name>”

Primer: “main_config_file=/etc/nagios/nagios.cfg”

Ova direktiva definiše lokaciju glavne konfiguracione datoteke. CGI skriptovi moraju da znaju gde se

nalazi ova datoteka kako bi došli do konfiguracionih informacija, tekućeg statusa hostova i servisa, itd.

2.3.2 Fizička “HTML” putanja

Format: “physical_html_path=<path>”

Primer: “physical_html_path=/usr/nagios/share”

Ova direktiva definiše fizičku putanju do direktorijuma na lokalnoj mašini u kome su smeštene

Nagiosove “HTML” stranice. Nagios podrazumeva da su dokumentacija i datoteke slika (koje koriste

“CGI” skriptovi) smešteni u poddirektorijumima ove putanje, “docs/” i “images/”.

2.3.3 “URL HTML” putanja

Format: “url_html_path=<path>”

Primer: “url_html_path=/nagios”

Ako se prilikom pristupanja Nagiosu preko web pretraživača zada URL adresa

http://imeračunara/nagios/ kao parametar HTML putanje u ovoj direktivi bi trebalo zadati putanju

/nagios. U osnovi,

2.3.4 Kontrola autentifikacije korisnika

Format: “use_authentication=<0/1>”

Primer: “use_authentication=1”

Ova direktiva kontroliše autorizovanu upotrebu “CGI” skriptova i funkcionalnost autorizacije kada se

određuje kojim informacijama i komandama korisnici imaju pravo da pristupe. Toplo se preporučuje

korišćenje autentifikacije za “CGI” skriptove. Ako se autentifikacija ipak isklјuči, obavezno treba

ukloniti “command CGI” skript kako bi se neautorizovani korisnici sprečili da izdaju komande

Nagiosu. “CGI” skriptovi neće izdavati komande Nagiosu ako je autentifikacija isklјučena, ali zbog

potpune sigurnosti savetuje se njihovo potpuno uklanjanje.

0=kontrola autetifikacije korisnika je onemogućena

85

1=kontrola autetifikacije korisnika je omogućena

2.3.5 Definisanje default korisničkog imena

Format: “default_user_name=<username>”

Primer: “default_user_name=guest”

Definisanjem ove direktive definiše se “default” korisnik sa pravom pristupa “CGI” skriptovima. Ovo

omogućava korisnicima iz sigurnog domena (npr. iza “firewall-a”) da pristupaju “CGI” skriptovima

bez neophodne autentifikacije kroz veb server. Ovo se može koristiti kako bi se izbegla bazična

autentifikacija u slučaju korišćenja neosiguranog servera, budući da ovaj način autentifikacije prenosi

lozinku kao običan tekst, bez enkripcije. Važno je napomenuti da se definisanje “default” korisnika ne

preporučuje osim ako se veb interfejsu ne pristupa sa sigurnog veb servera i ako je sigurno da su svi

koji imaju pristup “CGI” skriptovima prethodno autentifikovani na neki način! Definisanjem ove

direktive, svako ko nije autentifikovan kroz web server prosto će naslediti sva prava koja poseduje

ovaj korisnik!

2.3.6 Kontrola pristupa informacijama o sistemu/procesu

Format: “authorized_for_system_information=<user1>,...<usern>”

Primer: “authorized_for_system_information=nagiosadmin, the boss

Ovom direktivom se definiše lista zapetom razdvojenih imena korisnika koji po autentifikovanju krpz

web interfejs mogu da vide informacije o sistemu/procesu pomoću “Extended information” “CGI”

skripta. Korisnici na ovoj listi nisu automatski autorizovani za izdavanje sistem/proces komandi. Ako

se želi da ovi korisnici to mogu, neophodno je dodati ih u direktivi

“authorized_for_system_commands”.

2.3.7 Kontrola pristupa komandama sistem/procesa

Format: “authorized_for_system_commands=<user1>,...<usern>”

Primer: “authorized_for_system_command=nagiosadmin

Ovom direktivom se definiše lista zapetom razdvojenih imena korisnika koji mogu da izdaju komande

sistem/procesu putem “command CGI” skripta. Korisnici na ovoj listi nisu automatski autorizovani za

uvid u sistem/proces informacije. Ako se želi da im se to omogući neophodno je dodati ih na listu

prethodno objašnjene direktive.

2.3.8 Kontrola pristupu konfiguracionim informacijama

Format: “authorized_for_configuration_information=<user1>,...<usern>”

Primer: “authorized_for_configuration_information=nagiosadmin”

Ovom direktivom se definiše lista zapetom razdvojenih imena korisnika koji imaju pravo uvida u

konfiguracione informacije iz “configuration CGI” skripta. Korisnici sa ove liste mogu da pristupe

informacijama o svim konfigurisanim hostovima, grupama hostova, servisima, kontaktima, grupama

kontakta, periodima vremena i komandama.

86

2.3.9 Kontrola pristupa globalnim informacijama o hostovima

Format: “authorized_for_all_hosts=<user1>,...<usern>”

Primer: “authorized_for_all_hosts=nagiosadmin, theboss”

Ovom direktivom se definiše lista zapetom razdvojenih imena korisnika koji imaju uvid u status i

konfiguracione informacije svih hostova. Korisnici sa ove liste automatski su autorizovani za uvid u

informacije o svim servisima. Korisnici sa ove liste nemaju automatski pravo da izdaju komande za

sve hostove ili servise.

2.3.10 Kontrola pristupa globalnim komandama za hostove

Format: “authorized_for_all_host_commands=<user1>,...<usern>”

Primer: “authorized_for_all_host_commands=nagiosadmin”

Ovom direktivom se definiše lista zapetom razdvojenih imena korisnika koji mogu da izdaju komande

za sve hostove putem “command CGI” skripta. Korisnici sa ove liste su automatski autorizovani za

izdavanje komandi za sve servise. Pri tom nisu autorizovani za uvid u konfiguracione informacije za

sve servise ili hostove.

2.3.11 Kontrola pristupa globalnim informacijama o servisima

Format: “authorized_for_all_services=<user1>,...<usern>”

Primer: “authorized_for_all_services=nagiosadmin, theboss“


konfiguracione informacije svih hostova. Korisnici sa ove liste automatski su autorizovani za uvid u

informacije o svim servisima. Korisnici sa ove liste nemaju automatski pravo da izdaju komande za

sve servise.

2.3.12 Kontrola pristupa globalnim komandama za servise

Format: “authorized_for_all_services=<user1>,...<usern>”

Primer: “authorized_for_all_services=nagiosadmin, theboss”


konfiguracione informacije o svim servisima. Korisnici sa ove liste nisu automatski autorizovani za

uvid u status i konfiguracione informacije o svim hostovima.

2.3.13 Definisanje pozadine za “statusmap CGI script”

Format: “statusmap_background_image=<image_file>”

Primer: “statusmap_background_image= smbackground.gd2”

Ovom direktivom se omogućava definisanja datoteke slike koja se koristi kao pozadina u “statusmap

CGI” skriptu. Podrazumeva se da datoteka ove slike zaista postoji na putanji “HTML” slika (npr.

/usr/nagios/share/images). Putanja se automatski određuje dodavanjem “/images” putanji definisanoj

direktivom za definisanje fizičke putanje do “HTML” stranica. Ekstenzija slike može biti: “GIF, JPEG,

87

PNG ili GD2”. Preporučuje se da slika bide u “GD2” formatu (poželјno bez kompresije), zbog

korišćenja resursa “CPU-a” prilikom generisanja slike!

2.3.14 Definisanje podrazumevanog stila prikaza statusmape

Format: “default_statusmap_layout=<layout_number>”

Primer: “default_statusmap_layout=4”

Ova direktiva omogućava definisanje podrazumevanog (“default”) stila koji koristi “statusmap CGI”

skript. Važeće opcije su date u sledećoj tabeli:

vrednost

“<layout_number>”

stil prikaza

0 Korisnički definisane koordinate

1 nivoi dubine

2 nerazgranato drvo

3 razgranato drvo

4 cirkularno

5 cirkularno (“marked up”)

6 cirkularno (“baloon”)

2.3.15 Kontrola uklјučenja korisničkih objekata pomoću “statuswrl CGI-a”

Format: “statuswrl_include=<vrml_file>”

Primer: “statuswrl_include=myworld.vrl”

Ova direktiva omogućava uklјučivanje korisnički definisanih objekata u generisani “VRML” svet.

Podrazumeva se da zadata datoteka postoji na putanji definisanoj fizičkom “HTML” putanjom. Ovaj

datoteka mora da bude potpuno definisani “VRML” svet (koji se može videti pomoću “VRML”

brauzera).

2.3.16 Definisanje podrazumevanog stila prikaza “statuswrl CGI” skriptom

Format: “default_statuswrl_layout=<br_stila>”

Primer: “default_statuswrl_layout=4”

Ova direktiva omogućava definisanje podrazumevanog stila prikaza koji koristi statuswrl CGI skript.

Važeće opcije su date u sledećoj tabeli:

88

“<layout_number>” stil prikaza

0 Korisnički definisane koordinate

2 nerazgranato drvo

3 razgranato drvo

4 cirkularno

2.3.17 Kontrola brzina osvežavanja stranica generisanih “CGI” skriptovima

Format: “refresh_rate=<br_sekundi>”

Primer: “refresh_rate=90”

Ova direktiva definiše vremenski interval u sekundama nakon kog se stranica generisana “status,

statusmap” i “extinfo CGI” skriptovima ponovo učitava, tj. osvežava se.

2.3.18 Definisanje zvučnih alarma

Format: “host_unreachable_sound=<sound_file>

host_down_sound=<sound_file >

service_critical_sound=<sound_file >

service_warning_sound=<sound_file >

service_unknown_sound=<sound_file >”

Primer: “host_unreachable_sound=hostu.wav

host_down_sound=hostd.wav

service_critical_sound=critical.wav

service_warning_sound=warning.wav

service_unknown_sound=unknown.wav”

Predstavlјene direktive dozvolјavaju definisanje audio datoteka koje se interpretiraju u web brauzeru

ako se dogodi neki problem dok se posmatra stranica generisana pomoću “status CGI” skripta.

Podrzumeva se da su audio datoteke smeštene u “/media” poddirektorijumu na fizičkoj “HTML”

putanji (“/usr/local/nagios/share/media”).

2.3.19 Definisanje sintakse komande ping preko “WAP” interfejsa

Format: “ping_syntax=<komanda>”

Primer: “ping=/bin/ping –n –U –c 5 $HOSTADDRESS$”

Definiše sintaksu komande koja bi trebalo da se koristi pri pokušaju pingovanja hosta kroz “WAP”

interfejs (korišćenjem “statuswrml CGI” skripta neophodno je uklјučivanje potpune putanje do

izvršnog koda komande ping zajedno sa svim zahtevanim opcijama). $HOSTADRESS$ makro je

zamenjen adresom hosta izvršavanja komande.

89

2.4 “Resource” konfiguraciona datoteka – “resource.cfg”

Podrazumevani naziv “resource” konfiguracione datoteke je “resource.cfg”. U ovoj datoteci se čuvaju.

U glavnoj konfiguracionoj datoteci može se definisati i više njih ako je tako nešto potrebno. U

“resource” datoteci može se definisati do 32 korisnički definisana makroa (“$USER1$” do

“$USER32$”). Ovi makroi (“$USERn$”) se u konfiguracionim datotekama mogu koristiti za čuvanje

korisničkih naloga, lozinki i stavki koje se koriste u definicijama komandi. Može se definisati vise

“resource” konfiguracionih datoteka koristeći “resource_file” opciju u glavnoj konfiguracionoj

datoteci.

Jedna od glavnih opcija koju pruža Nagios je definisanje makroa u definicijama komandi. Makroi

omogućavaju referenciranje informacija o hostovima, servisima i drugih opcija. Pre nego što Nagios

izvrši komandu, zameniće bilo koji makro koji nađe u definiciji komandi sa odgovarajućim

vrednostima. Određeni makroi mogu da sadrže druge makroe. Makroi koji se mogu nalaziti unutar

drugih makroa su: “$HOSTNOTES$, $HOSTNOTESURL$, $HOSTACTIONURL$,

$SERVICENOTES$, $SERVICENOTESURL$” i “$SERVICEACTIONURL$”.

2.4.1 Makroi na zahtev (“On-demand macros”)

Prilikom korišćenja makroa hostova i servisa u definicijama komandi, one se odnose na vrednosti

hostova ili servisa za koje je komanda pokrenuta. Moguće je referencirati vrednosti za druge hostove

ili servise u komandi. Ovi makroi su potpuno isti kao standardni makroi, ali sadrže indetifikator hosta

ili servisa od kojeg bi trebalo da dobiju njihovu vrednost. Ovo je standardni format makroa na zahtev:

“$HOSTMACRONAME:host_name$”

“$SERVICEMACRONAME:host_name:service_description$”

“HOSTMACRONAME” i “SERVICEMACRONAME” treba zameniti nekim standardnim makroom.

Inače, makroi su odvojeni sa dve tačke (:). Kod makroa na zahtev servisa, identifikator servisa sadrži

ime hosta i opis servisa – i oni su razdvojeni sa dve tačke (:).

2.4.2 Grupni makroi na zahtev (“On-demand group macros”)

Postoji i mogućnost preuzimanja vrednosti makroa preko svih kontakta, servisa, hostova koji su

definisani u grupama koristeći poseban format makroa na zahtev. Može se referencirati specifična

grupa hostova, servisa, ili kontaka na sledeći način:

“$HOSTMACRONAME:hostgroup_name:delimiter$”

“$SERVICEMACRONAME:servicegroup_name:delimiter$”

“$CONTACTMACRONAME:contactgroup_name:delimiter$”

“HOSTMACRONAME, SERVICEMACRONAME” i “CONTACTMACRONAME” treba zameniti sa

standardnim makroima hostova,servisa i kontakta. Graničnik (“delimiter”) se koristi za odvajanje

vrednosti makroa za svaki član grupe.

2.4.3 Definisanje proizvolјnih promenlјivi makroa

Korisnici često zahtevaju nove promenlјive koje će biti dodate hostovima, servisima i kontaktima. To

mogu biti promenlјive za “MAC” adrese, “AIM” korisničko ime itd. Takođe, postoji i potreba za ovom

opcijom jer će ona olakšati adminima da lakše čuvaju informacije o komponentama njihove

90

infrastrukture u Nagiosovim konfiguracionim fajlovima. Proizvolјen promenlјive dozvolјavaju

dozvolјavaju korisniku dodatna svojstva u definicijama hostova, servisa i kontakta koristeći njihove

vrednosti u notifikacijama, “event” hendlerima i proverama hostova i servisa. Postoje nekoliko

nepisanih pravila koje treba uzeti u obzir prilikom definisanja proizvolјnih promenlјivi:

ime proizvolјne promenlјive mora sa donjom crtom (_) da bi se sprečio konflikt sa standardnim

promenlјivama

ime proizvolјne promenlјive su izvode iz šablona objekta kao standardne promenlјive

skripte mogu da referenciraju vrednosti proizvolјnih promenlјivi pomoću makroa

Proizvolјne promenlјive objekata koje se definišu u definicijama hostovima, servisa i kontakta su

takođe dostupni kao makroi. Definisanje proizvolјnih promenlјivi se vrši na sledeći način:

“$_HOSTvarname$”

“$_SERVICEvarname$”

“$_CONTACTvarname$”

2.4.4 Proizvolјne promenlјive kao makroi

Ispod su prikazani primeri makroa koji su definisani u različitim definicijama objekata:

“define host{

host_name linuxserver

_mac_address 00:06:5B:A6:AD:AA ; <-- Custom MAC_ADDRESS variable

_rack_number R32 ; <-- Custom RACK_NUMBER variable

}

define service{

host_name linuxserver

description Memory Usage

_SNMP_community public ; <-- Custom SNMP_COMMUNITY variable

_TechContact Jane Doe ; <-- Custom TECHCONTACT variable

}

define contact{

contact_name john

_AIM_username john16 ; <-- Custom AIM_USERNAME variable

_YahooID john32 ; <-- Custom YAHOOID variable

}”

Proizvolјne promenlјive mogu biti referencirane u skriptama ili komandama koje Nagios pokreće da bi

izvršio provere, slanje notifikacija itd. koristeći makro promenlјive. Da bi se sprečio konflikt sa

standardnim promenlјivama zbog imena proizvolјnih promenlјivi Nagios dodaje "_HOST",

91

"_SERVICE", ili "_CONTACT" početku promenlјive proizvolјnog hosta, servisa i kontakta. Tabela

ispod pokazuje imena odgovarajućih makro promenlјiva i “enviroment” promenlјiva koje su

definisane u primeru iznad.

Object Type

Variable Name Macro Name Environment Variable

Host MAC_ADDRESS $_HOSTMAC_ADDRESS$ NAGIOS__HOSTMAC_ADDRESS

Host RACK_NUMBER $_HOSTRACK_NUMBER$ NAGIOS__HOSTRACK_NUMBER

Service SNMP_COMMUNITY $_SERVICESNMP_COMMUNITY$ NAGIOS__SERVICESNMP_COMMUNITY

Service TECHCONTACT $_SERVICETECHCONTACT$ NAGIOS__SERVICETECHCONTACT

Contact AIM_USERNAME $_CONTACTAIM_USERNAME$ NAGIOS__CONTACTAIM_USERNAME

Contact YAHOOID $_CONTACTYAHOOID$ NAGIOS__CONTACTYAHOOID

2.4.5 Definisanje “$USERn$” korisničkih makroa

Format: “$USER<n>$=<macro_value>”

Primer: “$USER2$=/usr/nagios/libexec/eventhandlers

U sledećem primeru prikazan je makro “$USER2$” u definiciji objekata komandi umesto eksplicitnog

navođenja putanja do direktorijuma sa plaginovima ili “event” hendlerima. Umesto sledeće definicije

komande “event” hendlera “restart-httpd” koristi se definicija sa korisnički definisanim makroom

(boldovano u primeru)

“define command{

command_name restart-httpd

command_line /usr/nagios/libexec/eventhandlers/restart-httpd

$SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$

}

define command{

command_name restart-httpd

command_line $USER2$/restart-httpd

$SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$

}”

Međutim, pravi razlog za korišćenje ovih makroa nije kraća notacija komandi već zaštita osetlјivih

sistemskih informacija od neautorizovanog pristupa. Korisničkim makroima može se izbeći čuvanje

korisničkih imena i lozinki u konfiguracionim datotekama kojima “CGI” skriptovi imaju pravo

pristupa. Ovo je važno zato što za razliku od svih ostalih konfiguracionih datoteka, nije predviđeno da

“CGI” skriptovi pristupaju “resource” datoteci pa se nad njom mogu postaviti strožije dozvole pristupa.

Nagios neposredno pre izvršavanja komande sa makroom zamenjuje makro njegovom vrednošću iz

“resource” datoteke.

92

2.4.6 Konfiguracione datoteke objekata

Kao što je pomenuto u uvodnom pregledu konfiguracije Nagiosa, konfiguracione datoteke objekta se

koriste za definisanje hostova, servisa, kontakta, grupe hostova, grupe servisa, grupe kontakta,

komandi itd. Mogu se definisati više datoteka objekta koristeći “cfg_file” i “cfg_dir” direktive.

Format: cfg_file=<file_name> Format: cfg_dir=<directory_name

Primer: cfg_file=/usr/local/nagios/etc/hosts.cfg Primer:

cfg_dir=/usr/local/nagios/etc/commands

cfg_file=/usr/local/nagios/etc/services.cfg

cfg_dir=/usr/local/nagios/etc/services

cfg_file=/usr/local/nagios/etc/commands.cfg cfg_dir=/usr/local/nagios/etc/hosts”

2.5 Formati definicija objekata

2.5.1 Definicija objekta komande (“checkcommands”)

Format: “define command{

command_name <command_name>

command_line <command_line>

}”

Primer: “define command{

command_name check_pop3

command_line / usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$

}”

Definicijom objekta komande pojedinačno se definišu komande koje Nagios može da prepozna i

koristiti kao komande provere servisa, hostova ili komande “event” hendlera. U definicijama hostova i

servisa, komande se notiraju kratkim imenom objekta komande (“command_name”), a umesto njih

Nagios izvršava komande definisane “command_line” direktivom. Pre izvršavanja komandne linije,

svi validni makroi se zamenjuju odgovarajućom vrednošću.

2.5.2 Definicija objekta nadležnog kontakta (“contact”)

Format: “define contact{

contact_name contact_name

alias alias

contactgroups contactgroup_names

host_notifications_enabled [0/1]

93

service_notifications_enabled [0/1]

host_notification_period timeperiod_name

service_notification_period timeperiod_name

host_notification_options [d,u,r,f,s,n]

service_notification_options [w,u,c,r,f,s,n]

host_notification_commands command_name

service_notification_commands command_name

email email_address

pager pager_number or pager_email_gateway

address additional_contact_address

can_submit_commands [0/1]

retain_status_information [0/1]

retain_nonstatus_information [0/1]

}”

Primer: “define contact{

contact_name jdoe

alias John Doe

host_notifications_enabled 1

service_notifications_enabled 1

service_notification_period 24x7

host_notification_period 24x7

service_notification_options w,u,c,r

host_notification_options d,u,r

service_notification_commands notify-by-email

host_notification_commands host-notify-by-email

email [email protected]

pager [email protected]

address1 [email protected]

address2 555-555-5555

can_submit_commands 1

}”

Definicijom objekta kontakta se pojedinačno definišu nadležni kontakti koji će biti obaveštavani u

slučaju prelaska hostova ili servisa u određeni “non-OK” status. Iz formata i primera mogu se videti

značenja svih raspoloživih direktiva. Za svaki kontakt se posebno definišu filtri obaveštenja o

problemima u određenom statusu, filtri validnih perioda obaveštavanja, komande obaveštavanja, i sve

94

to, posebno za hostove, posebno za servise. Filtri obaveštenja se zadaju navođenjem početnih slova

statusa hosta ili servisa za koji obaveštenje može da se pošalјe.

2.5.3 Definicija objekta grupe kontakata (“contact groups”)

Format: “define contactgroup{

contactgroup_name contactgroup_name

alias alias

members contacts

contactgroup_members contactgroups

}”

Primer: “define contactgroup{

contactgroup_name novell-admins

alias Novell Administrators

members jdoe,rtobert,tzach

}”

Definicijom objekta grupe kontakta se definiše grupa nadležnih kontakata koji će biti obaveštavani u

slučaju prelaska hostova i servisa u “non-OK” status. Lista kontakata članova grupe se zadaje listom

zapetom odvojenih imena prethodno definisanih objekata kontakta. Ime ovako definisane grupe

kontakata se dalјe koristi u definicijama hostova i servisa.

2.5.4 Definicija objekta zavisnosti servisa (“service dependency”)

Format: “define servicedependency{

dependent_host_name host_name

dependent_hostgroup_name hostgroup_name

dependent_service_description service_description

host_name host_name

hostgroup_name hostgroup_name

service_description service_description

inherits_parent [0/1]

execution_failure_criteria [o,w,u,c,p,n]

notification_failure_criteria [o,w,u,c,p,n]

dependency_period timeperiod_name

}”

Primer: “define servicedependency{

host_name WWW1

95

service_description Apache Web Server

dependent_host_name WWW1

dependent_service_description Main Web Site

execution_failure_criteria n

notification_failure_criteria w,u,c

}”

Definicijom objekta zavisnosti servisa definiše se kontrola izvršavanja provere servisa i obaveštavanja

o tom servisu u zavisnosti od statusa servisa na nekom drugom hostu ili servisa na drugim hostovima.

Ovde je jako važno napomenuti da se u definiciji koristi isklјučivo ili “hostgroup_name” ili

“host_name” direktiva! Izvršavanje provera zavisnog servisa i/ili obaveštavanje o istom servisu se

obustavlјaju ukoliko se zadovolјe kriterijumi iz odgovarajućih direktiva. Označavanje kriterijuma je

identično kao kod definicije objekta kontakta.

2.5.5 Definicija objekta zavisnosti hosta (“host dependency”)

Format: “define hostdependency{

dependent_host_name host_name

dependent_hostgroup_name hostgroup_name

host_name host_name


inherits_parent [ 0/1]

execution_failure_criteria [o,d,u,p,n]

notification_failure_criteria [o,d,u,p,n]

dependency_period timeperiod_name

}”

Primer: “define hostdependency{

host_name WWW1

dependent_host_name DBASE1

notification_failure_criteria d,u

}”

Za razliku od oprethodno opisanog objekta, definicijom objekta zavisnosti hosta definiše se kontrola

obaveštavanja o hostu u zavisnosti od statusa nekog drugog hosta ili grupe hostova.

2.5.6 Definicija objekta eskalacije servisa (“service escalation”)

Format: “define serviceescalation{

host_name host_name



96

contacts contacts

contact_groups contactgroup_name

first_notification #

last_notification #

notification_interval #

escalation_period timeperiod_name

escalation_options [w,u,c,r]

}”

Primer: “define serviceescalation{

host_name nt-3

service_description Processor Load


last_notification 0


contact_groups all-nt-admins,themanagers

}”

Definicijom objekta eskalacije servisa definiše se kontrola eskaliranog obaveštavanja grupa kontakata.

2.5.7 Definicija objekta eskalacije hosta (“host escalation”)

Format: “define hostescalation{

host_name host_name


contacts contacts

contact_groups contactgroup_name

first_notification #

last_notification #


escalation_period timeperiod_name

escalation_options [d,u,r]

}”

Primer: “define hostescalation{

host_name router-34


97

last_notification 8


contact_groups all-router-admins

}”

2.5.8 Definicija objekta hosta (“host”)

Format: “define host{

host_name host_name

alias alias

display_name display_name

address address

parents host_names

hostgroups hostgroup_names

check_command command_name

initial_state [o,d,u]

max_check_attempts #

check_interval #

retry_interval #

active_checks_enabled [0/1]

passive_checks_enabled [0/1]

check_period timeperiod_name

obsess_over_host [0/1]

check_freshness [0/1]

freshness_threshold #

event_handler command_name

event_handler_enabled [0/1]

low_flap_threshold #

high_flap_threshold #

flap_detection_enabled [0/1]

flap_detection_options [o,d,u]

process_perf_data [0/1]



contacts contacts

contact_groups contact_groups

98


first_notification_delay #

notification_period timeperiod_name

notification_options [d,u,r,f,s]

notifications_enabled [0/1]

stalking_options [o,d,u]

notes note_string

notes_url url

action_url url

icon_image image_file

icon_image_alt alt_string

vrml_image image_file

statusmap_image image_file

2d_coords x_coord,y_coord

3d_coords x_coord,y_coord,z_coord

}”

Kako je objekat hosta jedan od centralnih Nagiosovih objekata, definicija hosta sadrži brojne direktive.

Direktive crvene boje se moraju obavezno definisati.

2.5.9 Definicija objekta grupe hostova (“host group”)

Format: “define hostgroup{


alias alias

members hosts

hostgroup_members hostgroups

notes note_string

notes_url url

action_url url

}”

Primer: “define hostgroup{

hostgroup_name novell-servers

alias Novell Servers

members netware1,netware2,netware3,netware4

}”

99

Definicijom objekta grupe hostova definiše se grupa mrežnih uređaja ili hosotva koji su slični po

nekim svojim odlikama. Definicija podrazumeva definisanje imena grupe, liste hostova članova grupe

i grupe/grupa kontakata koje se obaveštavaju u slučaju non-OK statusa nekog od članova grupe

hostova.

2.5.10 Definicija objekta servisa (“service”)

Format: “define service{

host_name host_name



display_name display_name

servicegroups servicegroup_names

is_volatile [0/1]

check_command command_name

initial_state [o,w,u,c]

max_check_attempts #

check_interval #

retry_interval #

active_checks_enabled [0/1]

passive_checks_enabled [0/1]

check_period timeperiod_name

obsess_over_service [0/1]

check_freshness [0/1]

freshness_threshold #

event_handler command_name

event_handler_enabled [0/1]

low_flap_threshold #

high_flap_threshold #

flap_detection_enabled [0/1]

flap_detection_options [o,w,c,u]

process_perf_data [0/1]




first_notification_delay #

notification_period timeperiod_name

notification_options [w,u,c,r,f,s]

100

notifications_enabled [0/1]

contacts contacts

contact_groups contact_groups

stalking_options [o,w,u,c]

notes note_string

notes_url url

action_url url

icon_image image_file

icon_image_alt alt_string

}”

Primer: “define service{

host_name linux-server

service_description check-disk-sda1

check_command check-disk!/dev/sda1

max_check_attempts 5

check_interval 5

retry_interval 3

check_period 24x7


notification_period 24x7

notification_options w,c,r

contact_groups linux-admins

}”

Objekat servisa je jednako važan kao objekat hosta i njegova definicija se sastoji od najviše direktiva.

Veliki broj ovih direktiva se ponavlјa iz definicije hosta i ima isto značenje te ću ovde objasniti samo

one direktive koje se ne pojavlјuju u definiciji hosta.

Direktivom “service_description” se zadaje ime objekta servisa koji je pridružen nekom hostu,

odnosno na njemu se izvršava. Obzirom da postoji potreba da se isti servis pridruži većem broju

hostova (npr. PING), iza “host_name” direktive se može navesti lista zapetom razdvojenih imena

hostova, a ako i to ne zadovolјava, servis se može pridružiti jednoj ili više grupa hostova pomoću

direktive “hostgroup_name”.

Direktiva “obsess_over_service” se koristi kod nadgledanja distribuiranim Nagios serverima i na

nivou definisanog servisa kontroliše podnošenje rezultata provera centralnom Nagios serveru.

Prethodno, u glavnoj konfiguracionoj datoteci mora biti omugućena ta ista direktiva kojom se ova

opcija kontroliše na nivou čitavog programa.

Ukoliko se koriste pasivne provere servisa na regularnoj vremenskoj bazi, direktivom

“check_freshness” se može uklјučiti provera zastarelosti rezultata provera servisa.

101

Na kraju, direktivom “is_volatile” određuje se da li je servis “nepostojan” ili ne. Ova opcija se koristi

samo kod nekih specifičnih servisa (napadi na sistem, zaglavlјivanje nekog važnog procesa na sistemu

i sl.) kod kojih se zahteva da se po ulasku u “non-OK” status odmah pređe u “HARD” stanje greške.

Smisao prelaska u “HARD” stanje greške je pozivanje odgovarajućeg “event” handlera koji je obično

komanda koja treba odmah da reaguje i pokuša da reši problem (npr. Privremeno zatvori neke portove

na sistemu, restartuje zaglavlјeni proces i sl.).

2.5.11 Definicija objekta vremenskog perioda (“time period”)

Format: “define timeperiod{

timeperiod_name timeperiod_name

alias alias

[weekday] timeranges

[exception] timeranges

exclude [timeperiod1,timeperiod2,...,timeperiodn]

}”

Primer: “define timeperiod{

timeperiod_name nonworkhours

alias Non-Work Hours

sunday 00:00-24:00 ; Every Sunday of every week

monday 00:00-09:00,17:00-24:00 ; Every Monday of every

week

tuesday 00:00-09:00,17:00-24:00 ; Every Tuesday of every

week

wednesday 00:00-09:00,17:00-24:00 ; Every Wednesday of every week

thursday 00:00-09:00,17:00-24:00 ; Every Thursday of every

week

friday 00:00-09:00,17:00-24:00 ; Every Friday of every week

saturday 00:00-24:00 ; Every Saturday of every week

}”

Definicija objekta vremenskog perioda sadrži direktive kojim se zadaju ime objekta vremenskog

perioda, njegov alias i opsezi validnih intervala svakog dana u nedelјi. Ime svakog dana predstavlјa

opcionu direktivu. U datim primerima predstavlјene su dve definicije perioda. Prva definiše period

“24x7” koji se javlјa u gotovo svim primerima defuinicija prethodno opisanih objekata, dok druga

definiše period bez validnih intervala. Ovakav interval bi mogao da se koristi u definiciji servisa koji

ne treba nikad da se proverava, a ovakav servis bi pak mogao da se pridruži nekom virtuelnom hostu

koji formalno zahteva da mu se pridruži bar jedan servis.

2.6 Nasleđivanje objekata

U “template-based” metodu konfigurisanja ugrađen je koncept nasleđivanja. Pod ovim se

podrazumeva nasleđivanje svih direktiva iz definicije nekog objekta pri definisanju nekog drugog,

102

novog objekta. Definicija objekta koja ne predstavlјa realan objekat već se koristi samo za prenošenje

osobina na druge objekte naziva se obrazac (“template”), pri čemu obrazac može da sadži i nepotpun

skup direktiva. Ova metoda je bazirana na rekurzivnom parsiranju konfiguracionih datoteka. U ovu

svrhu koriste se direktive “name, use” i “register”.

Ovom metodom se znatno olakšava inicijalno konfigurisanje i održavanje konfiguracije Nagiosa.

Primer objekta je prikazan ispod:

“define someobjecttype{

object-specific variables ...

name template_name

use name_of_template_to_use

register [0/1]

}”

Prva promenlјiva je ime šablona koje se koristi za referenciranje u drugim definicijama

objekata da bi oni mogli da naslede osobine i vrednosti. Ime šablona mora biti jedinstveno. Pomoću

druge promenlјive “use”, se definiše ime “template” objekta od kojeg će se nasleđivati osobine i

vrednosti. Treća promenlјiva register se koristi da bi se definicije objekata registrovale u Nagiosu. Po

“default-u” sve definicije objekata su registrovane. Ali, ako se koristi delimična definicija objekta,

treba onemogućiti njeno registrovanje u Nagiosu. Vrednosti su sledeće:

0 = onemogućiti registrovanje definicija objekata

1 = registrovanje definicija objekata je omogućeno

Ova promenlјiva se ne nasleđuje. Kod svake delimične definicije objekta koja se koristi kao šablon se

mora eksplicitno imati da onemogućiti registrovanje definicija objekata. Na ovaj način se sprečava

potreba za prepisivanjem nasleđene “register” direktive sa vrednošću 1 za svaki objekat koji se treba

registrovati.

2.6.1 Lokalne promenlјive i nasleđene promenlјive

Treba imati u vidu da “lokalne” promenlјive imaju veći prioret od promenlјivih koje su definisane u

šablon (template) objektu. U sledećem primeru se može videti upotreba lokalnih i nasleđenih

promenlјivi i konačan rezultat:

“define host{

host_name bighost1

check_command check-host-alive

notification_options d,u,r


name hosttemplate1

}

define host{

103

host_name bighost2


use hosttemplate1

}”

Host “bighost1” je definisan kao šablon (“template”) pomoću “name” direktive. Definicija objekta

“bighost2” pomoću direktive “use” koristi definiciju objekta “bighost1”. Kada Nagios obradi ove

podatke, konačna definicija objekta “bighost2” je sledeća:

“define host{

host_name bighost2




}”

“check_command” i “notification_options” promenlјive su nasleđene iz šablon (“template”) objekta.

Međutim, host_name i max_check_attempts promenlјive nisu nasleđene iz šablon (“template”) objekta

zato što su te promenlјive definisane “lokalno”. Veoma je važno imati u vidu da “lokalne” promenlјive

imaju veći prioritet u odnosu na na promenlјive koje bi trebalo da budu nasleđene iz šablon (template)

objekta.

2.6.2 Lančano nasleđivanje

Nasleđivanje osobina objekata se može vršiti i lančano, u više nivoa. Najpre se može definisati

najopštiji objekat sa osobinama koje su zajedničke za sve ili veliku većinu objekata. Potom se iz ovog

najopštijeg obrasca mogu izvesti manje opšti obrasci koji nasleđuju osobine opšteg obrasca i definišu

one direktive koje su karakteristične za određene kategorije objekata. Ove kategorije se dalјe mogu

deliti na potkategorije definisane specijalinijim obrascima dok se na kraju ne dođe do definicije samog

objekta. Definicija je tada jako kratka i jednostavana jer se većina direktiva nasleđuje kroz lanac

obrazaca. Ukoliko se želi promena neke od nasleđenih direktiva, dovolјno je u definiciju uneti tu

direktivu sa novom vrednošću i objekat će promeniti tu osobinu. Primeri:

“define host{

host_name bighost1




name hosttemplate1

}

104

define host{

host_name bighost2


use hosttemplate1

name hosttemplate2

}

define host{

host_name bighost3

use hosttemplate2

}”

Definicija hosta “bighost3” nasleđuje promenlјive od definicije hosta “bighost2”, dok definicija hosta

“bighost2” nasleđuje promenlјive od definicije hosta “bighost1” .

2.6.3 Korišćenje nepotpunih definicija objekta kao šablon (“template”)

Moguće je koristiti nepotpune definicije objekata kao šabloni (“templates”) koji će biti upotreblјeni u

drugim definicijama. “Nepotpuna” definicija objekata znači nisu definisane sve obavezne promenlјive.

Obično se “nepotpune” definicije objekata koriste za postavlјanje “default” vrednosti u drugim

definicijama objekata. Primeri:

“define host{




name generichosttemplate

register 0

}

define host{

host_name bighost1

address 192.168.1.3

use generichosttemplate

}

define host{

host_name bighost2

105

address 192.168.1.4


}”

Prva definicija hosta je nepotpuna zato što joj nedostaje obavezna “host_name” promenlјiva.

Ovaj objekat je definisan bez imena hosta da bi se koristio kao šablon (“template”) hostova. Definicije

hostova “bighost1” i “bighost2” nasleđuju vrednosti od šablona “generichosttemplate”. Promenlјive

koje su “lokalno” definisane su “host_name” i “adress” što rezultuje sledećim ishodom:

“define host{

host_name bighost1

address 192.168.1.3




}

define host{

host_name bighost2

address 192.168.1.4




}”

Nepotpune definicije objekata mogu da uštede dosta vremena koje će biti utrošeno na

definisanje objekata, ali mogu i da zadaju dosta problema za veliki broj hostova prilikom promena

“default” vrednosti promenlјivih.

2.6.4 Proizvolјne promenlјive objekata

Bilo koja proizvolјna promenlјiva definisana u objektima hostova, servisa i kontakta će biti

nasleđena kao i ostale standardne promenlјive. U sledećem primeru je prikazan način korišćenja

proizvolјnih promenlјiva:

“define host{

_customvar1 somevalue ; <-- Custom host variable

_snmp_community public ; <-- Custom host variable


106

register 0

}

define host{

host_name bighost1

address 192.168.1.3


}”

Host “bighost1” će nasledi proizvolјnu promenlјivu “_customvar1” i “_snmp_community” tj.

njihove vrednosti od šablona “generichosttemplate”. Rezultat obrade ovih definicija hostova je sledeći:

“define host{

host_name bighost1

address 192.168.1.3

_customvar1 somevalue

_snmp_community public

}”

2.6.5 Otkazivanje nasleđivanja “string” vrednosti

U nekim slučajevima je poželјno da definicije hostova, servisa i kontakta ne naslede vrednosti

string promenlјivih od referenciranih šablona. Zato se “lokalnim” promenlјivama dodelјuje vrednost

“null” u definicijama objekata. Sledeći primer ilustruje otkazivanje nasleđivanja “string” vrednosti:

“define host{

event_handler my-event-handler-command


register 0

}

define host{

host_name bighost1

address 192.168.1.3

event_handler null


}”

107

U ovom slučaju host “bighost1” neće naslediti promenlјivu event_handler koja je definisana u

generichosttemplate šablonu. Kada Nagios obradi ove podatke, konačna definicija objekta “bighost1”

je sledeća:

“define host{

host_name bighost1

address 192.168.1.3

}”

2.6.6 “Dodatno” nasleđivanje “string” vrednosti

U primerima iznad je opisan način na koji Nagios daje prednost “lokalnim” promenlјivama

umesto promenlјivama koje su definisane u šablonima objekta. U nekim slučajevima je poželјno da

Nagios koristi vrednosti nasleđenih i “lokalnih” promenlјivi zajedno. Dodatno nasleđivanje se može

realizovati ako se ispred imena “lokalne” promenlјive stavi znak (+). Ova opcija se može samo

koristiti za standardne (ne-proizvolјne) promenlјive koje sadrže string vrednosti. Primeri:

“define host{

hostgroups all-servers


register 0

}

define host{

host_name linuxserver1

hostgroups +linux-servers,web-servers


}”

U ovom slučaju host “linuxserver1” će dodati vrednosti hostgroups promenlјive iz definicije

šablona objekta “lokalnoj” hostgroup promenlјivi. Rezultati obrade ove definice su sledeći:

“define host{

host_name linuxserver1

hostgroups all-servers,linux-servers,web-servers

}”

108

2.6.7 Automatsko nasleđivanje vrednosti

Kao što je gore rečeno, mora se eksplicitno definisati vrednost obavezne promenlјive u

definiciji objekta ili je naslediti iz šablona. Ipak postoje par izuzetaka kod ovog pravila, gde Nagios

predpostavlјa da želјena vrednost dolazi iz srodnog objekta. Na primer, vrednosti promenlјivih nekog

servisa biće kopirane od hosta kojem je servis pridružen osim ako se eksplicitno ne definiše. U tabeli

ispod se nalaze promenlјive objekata koje će automatski biti nasleđene od srodnih hostova ako se

eksplicitno ne definiše njihove vrednost ili nasledi iz šablona.

Object Type Object Variable Implied Source

Services

contact_groups contact_groups in the associated host definition

notification_interval notification_interval in the associated host definition

notification_period notification_period in the associated host definition

Host Escalations




Service Escalations




2.6.8 Višestruki izvori nasleđivanja

Do sada su prikazane samo definicije objekata koje nasleđuju promenlјive i vrednosti od

jednog izvora. Moguće je nasleđivati promenlјive i vrednosti iz više izvora zbog kompleksnije

konfiguracije.

“# Generic host template”

“define host{name generic-host

active_checks_enabled 1

check_interval 10

...

register 0

}”

109

“# Development web server template”

“define host{

name development-server

check_interval 15


...

register 0

}”

“# Development web server”

define host{

use generic-host,development-server

host_name devweb1

...

}

U primeru iznad, “devweb1” nasleđuje promenlјive i vrednosti iz 2 izvora: “generic-host” i

“development-server”. Promenlјiva “check_interval” je definisana u oba izvora. Zato što je “generic-

host” naveden kao prvi šablon u direktivi “use” objekta hosta, njegova vrednost će se naslediti za

“check_interval” promenlјivu. Kada Nagios obradi ove podatke konačna definicija objekta je:

“#Development web server”

“define host{

host_name devweb1

active_checks_enabled 1

check_interval 10


...

}”

110

Slika 28 Način realizacije višestrukog nasleđivanja

2.6.9 Prvenstvenost promenlјivih iz višestrukih izvora nasleđivanja

Prilikom upotrebe višestrukih izvora koji se koriste za nasleđivanje , veoma je je važno

razumeti kako Nagios upravlјa promenlјivama koje su definisane u višestrukim izvorima. U ovim

slučajevima Nagios će koristiti promenlјivu/vrednost iz prvog izvora koji je definisan u “use” direktivi.

Pošto izvori nasleđivanja mogu sami da nasleđuju promenlјive i vrednosti iz jednog ili više izvora,

postaje veoma teško razumeti koja promenlјiva/vrednost ima prvenstvenost.

Slika 29 Prvenstvenost nasleđivanja

Ako neki od referenciranih šablona nasleđuje promenlјivu/vrednost od jednog ili više drugih

šablona prvenstvenost je prikazana na slici iznad. Testiranje, isprobavanje i proučavanje grešaka će

doprineti bolјem razumevanju definisanja kompleksnih situacija nasleđivanja.

111

3 Bezbednosna razmatranja

U velikom broju slučajeva, Nagios će imati pristup udalјenim hostovima koristeći “firewall-ove” da bi

izvršio provere. Takođe, moguće je upitati te udalјene hostove za različite informacije. Monitoring

serverima je uvek dat određen nivo poverenja u cilјu proveravanja udalјenih hostova. Potencijalnom

napadaču ovo predstavlјa primamlјiv ulaz u sistem. Napadač će možda lakse provaliti u sistem ako

prvo ugrozi monitoring server. Ovo je delimična istina ako se koriste “podelјeni” “SSH” klјučevi u

cilјu monitoringa udalјenih hostova.

Ako ulјez ima mogućnost da pošalјe rezultate provere ili eksterne komande Nagios demonu, on ima

mogućnost da pošalјe lažne monitoring podatke, izluđuje nadležne administratore lažnim

notifikacijama, ili aktivira “event” hendler skripte. Ako postoje “event” hendler skripte koje restartuju

servise i slično, ovo može biti veoma problematično.

Druga zabrinjavajuća okolnost je mogućnost ulјeza da prati rezultate monitoringa. Ako

komunikacionalni kanali nisu enkriptovani, napadač može steći veoma vredne informacije gledajući

monitoring informacije. Na primer: napadač stekne monitoring informacije tokom određenog

vremenskog perioda i analizira prosečno korišćenje “CPU-a” i diska, zajedno sa brojem logovanih

korisnika. Napadač može da odredi najbolјe vreme za napad na sistem i iskoristi resurse (“CPU”, itd.)

a da ne bude primećen.

3.1 Najbolјe prakse

1. Određene mašine koristiti samo za proces monitoringa.

Ove mašine treba zaštiti kao najbitnije servere na čitavoj mreži. Pristup ovim hostovima treba

omogućiti samo preko “firewall-a”.

Slika 30 Potencijalne mete napadača

2. Nagios se ne treba pokretati kao “Root”. Nagios se može definisati tako da “ispusti”

privilegije posle startovanja i radi pod drugim korisnikom/grupom. Ova opcija se definiše

koristeci “nagios_user” i “nagios_group” direktive u glavnoj konfiguracionoj datoteci. Ako je

neophodno izvršiti “event” hendlere ili plaginove koje zahtevaju “root” privilegije, predlaže se

korišćenje “sudo” komande.

3. Zaklјučati “Check result” direktorijum. Treba osigurati da samo “nagios” korisnik ima

mogućnost da čita i piše fajlove u definisanom “check_result_path” direktorijumu. Ako bilo

koji drugi korisnik osim “nagios-a” (ili “root-a”) ima mogućnost da piše fajlove u ovom

112

direktorijumu, on može poslati lažne rezultate provere hostova i servisa Nagios demonu. Ova

situacija može rezultovati neprijatnim notifikacijama ili bezbednosnim problemima.

4. Zaklјučati “External Command” datoteku. Ako su omogućene eksterne komande, treba

pravilno podesiti pristup “/usr/local/nagios/var/rw” direktorijumu. Samo korisnik Nagiosa

(obično “nagios”) i korisnici veb servera (“nobody, httpd, apache2”, ili “www-data”) trebaju

imati dozvolu da vrše zapis u komandnom fajlu.

5. Zahtevati autentifikaciju u “CGI-evima”. Ako se onemogući autentifikacija “CGI-a”

koristeći “use_autentification” direktivu u “CGI” konfiguraocionoj datoteci “command CGI”

će odbiti da zapiše bilo koju komandu u eksternom komandnom fajlu.

6. Implementirati pobolјšane mere bezbednosti “CGI-a”. Ove tehnike mogu osigurati da

korisničko ime i šifra koja se koristi za pristup Nagiosovom veb interfejsu neće biti

“presretnuta” od druge strane. Prvo treba obezbediti bolјu autentifikaciju koristeći “Digest”

autentifikaciju zato što “Apache” obično koristi standardnu autentifikaciju. Standardna

autentifikacija će poslati korisničko ime i šifru u “čistom” tekstu prilikom svakog “http”

zahteva. Zato treba primeniti “MD5 Digest” autentifikaciju jer će enkriptovati korisničko ime i

šifru. Takođe, treba koristiti “TLS” i “SSL” za svu internet komunikaciju. “Apache” pruža

“TLS” i “SSL” kroz “mod_ssl” modul. “TLS/SSL” bezbednu komunikaciju između klijenta i

servera koje sprečava prisluškivanje i ometanje koristeći princip kriptografije – javni klјuč i

privatni klјuč.

7. Koristiti punu putanju u definicijama komandi. Prilikom definisanja komandi preporučuje

se definisanje pune putanje (ne relativne) ka bilo kojoj skripti koja će se izvršavati.

8. Sakriti osetlјive informacije pomoću “$USERm$” makroa. “CGI” čita glavnu

konfiguracionu datotetu i objekte konfiguracionih fajlova tako da nije poželјno u njima čuvati

korisnička imena i šifre. Ali ako je to neophodno, ti parametric se mogu sakriti korišćenjem

“$USERn$” makroa. Ovi makroi su definisani u jednom ili više “resource” fajlu. “CGI” neće

pokušavati da pročita sadržaj “resource” fajlova.

9. Obezbediti pristup udalјenim agentima. Vrlo je bitno zaklјučati pristup agentima (NRPE,

NSClient, SNMP, itd.) koristeći “firewall”, liste pristupa itd.

Slika 31 Zaklјučan pristup udalјenim agentima

10. Osigurati komunikaocione kanale. Veoma je važno enkriptovati komunikacione kanale

između više instanci Nagiosa i agenta koji se koriste za process monitoringa.

http://nagios.sourceforge.net/docs/3_0/cgis.html#cmd_cgi

113

Slika 32 Osiguravanje komunikacionih kanala

3.2 Podaci o performansama

Nagios je dizajniran tako da dozvoli plaginovima da vrate opcionalne podatke o perfomansama

zajedno sa podacima o stanju, ali je dozvolјeno i prosleđivanje tih podataka eksternim aplikacijama

koje će te podatke procesuirati. Postoje dve osnovne kategorije podataka o performansama koje mogu

biti dobijene od strane Nagiosa:

1. Podaci o performansama provera

2. Podaci o performansama plaginova

Podaci o performansama provera su unutrašnji podaci koji su povezani sa izvršavanjem provera

hostova i servisa. Ovi podaci opisuju kašnjenje provera servisa i broj sekundi potreban za izvršavanje

provere hosta i servisa.Ovi tipovi podataka su omogućeni za sve vrste provera koje su izvršene.

“$HOSTEXECUTIONTIME$” i “$SERVICEEXECUTIONTIME$” makroi se koriste za definisanje

vremenskog intervala koji je neophodan za izvršavanje provera hostova ili

servisa. “$HOSTLATENCY$” i “$SERVICELATENCY$” makroi se koriste za određivanje

vremenskog intervala kašnjenja regularnih provera hostova i servisa.

Kod podataka o performansama plaginova, Nagios mora vratiti jednu liniju teksta koja je lako

razumlјiva i opisuje status nekog tipa u merlјivim jedinicama. Na primer, “check_ping” plagin može

vratiti jednu liniju teksta koja će imati sledeću formu:

“PING ok - Packet loss = 0%, RTA = 0.80 ms”

Sa ovim jednostavnim izlazom, čitava linija teksta je dostupana u $HOSTOUTPUT$ i

$SERVICEOUTPUT$ makroima (u zavisnosti od korisšćenog plagina). Plaginovi mogu da vrate

opcionalne podatke o performansama u njihovim izlazima slanjem lako razumlјivog teksta tj. niza

stringova iza karaktera (|) koji opisuju rezultate performansi. Primer jednostavnog izlaza iz plagina:

“PING ok - Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80”

Kada Nagios vidi ovakav format izlaza iz plagina, podeliće izlaz u dva dela:

1. Sve pre (|) karaktera se smatra normalnim izlazom iz plagina i biće sačuvano u

“$HOSTOUTPUT$” ili “$SERVICEOUTPUT$” makrou

http://nagios.sourceforge.net/docs/3_0/macrolist.html#hostexecutiontime

http://nagios.sourceforge.net/docs/3_0/macrolist.html#serviceexecutiontime

http://nagios.sourceforge.net/docs/3_0/macrolist.html#hostlatency

http://nagios.sourceforge.net/docs/3_0/macrolist.html#servicelatency

114

2. Sve posle (|) karaktera se smatra specifičnim plagin podacima o performansama koji će biti

sačuvani u “$HOSTPERFDATA$” ili “$SERVICEPERFDATA$” makrou

3.2.1 Procesiranje podataka o performansama

Da bi se procesirali podaci o performansama koji su dostupni od strane Nagiosa, neophodno je uraditi

sledeće:

Omogućiti „process_performance_data” opciju u glavnoj konfiguracionoj datoteci

Konfigurisati Nagios tako da su podaci o performansama zapisani u fajlovima i procesuirani od

strane izvršavajućih komandi

Procesranje podataka o performansama koristeći komande

Najfleksibilniji način za obradu podataka o performansama je taj da Nagios izvrši komande (koje

korisnik definiše) da bi obradio ili preusmerio podatke koji će se kasnije obraditi od strane eksternih

aplikacija. Komande koje Nagios izvršava da bi obradio podatke o performansama hostova i servisa su

definisani pomoću opcija “host_perfdata_command” i “service_perfdata_command”. Ispod je primer

komande koja prosleđuje podatke o performansi provere servisa koja će se obraditi kasnije od strane

druge aplikacije:

“define command{

command_name store-service-perfdata

command_line /bin/echo -e

"$LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICE

ATTEMPT$\t$SERVICESTATETYPE$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t

$SERVICEOUTPUT$\t$SERVICEPERFDATA$" >> /usr/local/nagios/var/service-perfdata.dat

}”

Iako je ova metoda veoma fleksibilna, koristi dosta resursa “CPU-a”. Ako se obrađuje velika količina

podataka o performansama za hostove i servise, dobra praksa sugeriše da se podaci o performansama

čuvaju u fajlovima.

Zapisivanje podataka o performansama u fajlove

Nagios se može konfigurisati tako da zapisuje sve podatke o performansama hostova i servisa u

tekstualne fajlove koristeći “host_perfdata_file” i “service_perfdata_file” opcije. Format u kojem će

se podaci o performansama zapisivati u gore navedene fajlove se definiše

pomoću “host_perfdata_file_template” i “service_perfdata_file_template”. Primer šablona za podatke

o performansama servisa je sledeći:

“service_perfdata_file_template=[SERVICEPERFDATA]\t$TIMET$\t$HOSTNAME$\t$SERVICED

ESC$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVIC

EPERFDATA$”

Po “default-u”, tekstualni fajlovi će biti otvoreni u “append” modu. Ako je neophodno

promeniti mod u "write" ili "non-blocking read/write" mod da bi se izvršila promena koriste

se “host_perfdata_file_mode” i “service_perfdata_file_mode” opcije.

http://nagios.sourceforge.net/docs/3_0/configmain.html#process_performance_data

http://nagios.sourceforge.net/docs/3_0/configmain.html#host_perfdata_command

http://nagios.sourceforge.net/docs/3_0/configmain.html#service_perfdata_command

http://nagios.sourceforge.net/docs/3_0/configmain.html#host_perfdata_file

http://nagios.sourceforge.net/docs/3_0/configmain.html#service_perfdata_file

http://nagios.sourceforge.net/docs/3_0/configmain.html#host_perfdata_file_template

http://nagios.sourceforge.net/docs/3_0/configmain.html#service_perfdata_file_template

http://nagios.sourceforge.net/docs/3_0/configmain.html#host_perfdata_file_mode

http://nagios.sourceforge.net/docs/3_0/configmain.html#service_perfdata_file_mode

115

Takođe, Nagios se može definisati da periodično izvršava komande koje će periodično obraditi

podatke o performansama. Interval u kojem će se ove komande izvršiti se definiše pomoću

“host_perfdata_file_processing_interval” i “service_perfdata_file_processing_interval”.

3.3 Konfigurisanje Nagiosa za postizanje maksimalnih performansi

Saveti za optimizaciju su sledeći:

1. Statistiku o performansama predstavlјati pomoću grafika koristeći “MRTG(Multi

Router Traffic Grapher)”. “MRTG” je besplatan softver za monitoring i merenje saobraćaja

na mrežnim linkovima. Dozvolјava korisniku da vidi opterećenje saobraćaja tokom vremena u

formi grafika. Mogu se imati informacije o tome kako Nagios podnosi opterećenje tokom

vremena i kako promena konfiguracije utiče na to opterećenje. Korišćenje “MRTG-a” je veoma

važno zato što može da osigura:

Da Nagios efikasno funkcioniše

Lociranje problematičnih oblasti u monitoring procesu

Postmatranje uticaja performansi prilikom promena Nagios konfiguracije

2. Podešavanje velikih instalacija pomoću “Tweaks” opcije. Opcija

“use_large_installation_tweaks” se koristi za definisanje da li će Nagios demon koristiti

nekoliko olakšica da bi pobolјšao performanse. Ove olakšice rezultuju u gubitku nekoliko

opcija, ali veće instalacije će imati velike koristi.

3. Isklјučiti “environment” promenlјive. Makroi se mogu koristiti u proverama, notifikacijama,

“event” hendlerima itd. Ovo može predstavlјati problem u velikim instalacijama Nagiosa zato

što se poprilično više memorije i resursa “CPU-a”. Ako skriptama nije potreban pristup

makroima kao “environment” promenlјivama, ova opcija je nepotrebna. Može se onemogućiti

da se makroi ne koriste kao “environment” promenlјive

koristeći “enable_environment_macros” opciju.

4. Defisanje učestalosti obrade rezultata provera. Ova promenlјiva definiše koliko često

Nagios treba da proverava rezultate hostova i servisa koji trebaju da budu procesuirani.

Maksimalni vremenski interval se definiše pomoću “max reaper time” opcije. Ako je učestalost

obrade rezultata visoka, dešavaće se kašnjenja za provere hostova i servisa.

5. Definisanje maksimalnog vremenskog intervala učestalosti provera.

“max_check_result_reaper_time” promenlјiva definiše maksimalni vremenski interval obrade

rezultata provera hostova i servisa. Visoka vrednost može rezultovati kašnjenjem obrade

rezultata, kao i kod niske vrednosti.

6. Proveriti kašnjenje servisa da bi se definisala najbolјa vrednost za maksimalan broj

paralelnih provera. Nagios može da ograniči maksimalni broj paralelnih provera servisa

pomoću opcije “max_concurrent_checks”. Ova opcija omogućava kontrolu opterećenja koja se

nameću monitoring hostu.

7. Koristiti pasivne provere kada je to moguće. Potreba za neophodnim resursima koji se

koriste za obradu rezultata koji su dobijeni od strane pasivnih promena je mnogo manja, nego

od potrebnih resursa koji se koriste za obradu aktivnih provera. Inače, pasivne provere su

jedino korisne ako eksterne aplikacije vrše neku vrstu monitoringa ili obaveštavanja, ali ako

Nagios obavlјa sav posao, ovaj savet je beskoristan.

8. Izbeći korišćenje “interpreted” plaginova. Jedna stvar koja će značajno smanjiti opterećenje

na monitoring hostu je upotreba kompajliranih (“C/C++”, itd) plaginova nego upotreba “script”

plaginova (“Perl”, itd). “Perl” skripte su veoma jednostavne za pisanje i rade veoma lepo, ali

one se komplajliraju prilikom svakog izvršavanja što značajno može da poveća teret

http://nagios.sourceforge.net/docs/3_0/configmain.html#host_perfdata_file_processing_interval

http://nagios.sourceforge.net/docs/3_0/configmain.html#service_perfdata_file_processing_interval

http://nagios.sourceforge.net/docs/3_0/configmain.html#enable_environment_macros

http://nagios.sourceforge.net/docs/3_0/configmain.html#max_check_result_reaper_time

http://nagios.sourceforge.net/docs/3_0/configmain.html#max_concurrent_checks

116

monitoring hostu. Ako postoji potreba za korišćenjem “Perl” plaginova, treba ih transformisati

u prave kompajlirane skripte koristeci “perlcc”, ili kompajlirati Nagios sa ugrađenim “Perl”

“tumačem” (“interpreter”).

9. Koristiti ugrađeni “Perl” “tumač” (“interpreter”). Ako Nagios koristi dosta “Perl” skripti,

korišćenje urađenog “Perl” “tumača” će poprilično ubrzati stvari.

10. Optimizovati provere hostova. Ako se stanje hosta provera koristeći “check_ping” plagin,

provere će se mnogo brže realizovati ako se provere “usitne”. Umesto dodelјivanja vrednosti 1

opciji “max_attempts” i slanja 10 “ICMP” paketa hostu, bilo bi mnogo brže podesiti

opciji “max_attempts” vrednost 10 i poslati joj samo 1 “ICMP” paket hostu. Nagios može da

odredi status hosta posle jednog izvršavanja plagina, tako da prvu proveru hosta treba što brže

realizovati.

11. Omogućiti sačuvane provere hostova. Provere na zahtev se uvek izvršavaju kada Nagios

detektuje promenu stanja servisa. Ove provere na zahtev se izvršavaju zato što Nagios želi da

zna da li je host koji je pridružen servisu promenio stanje. U nekim slučajevima Nagios može

da iskoristi staro/sačuvano stanje hosta umesto izvršavanja provere hosta. Ovim se ubrzavaju

stvari i smanjuje opterećenje na monitoring hostu.

12. Ne koristiti agresivno proveravanje hosta. Ne preporučuje se korišćenje ove opcije osim ako

ne postoji problem sa prepoznavanjem hostova. Kada je ova opcija isklјučena provere hostova

se izvršavaju mnogo brže, što rezultuje bržem procesuiranju rezultata provera servisa.

13. Optimizacija eksternih komandi. Ako se izvršava veliki broj eksternih komandi, vrednost

“command_check_interval” promenlјive treba biti “-1” što znači da će Nagios proveravati

eksterne komande što je češće moguće. Takođe treba povećati broj slobodnih “buffera”

koristeći opciju “external command buffer slots”. “Buffer” slotovi se koriste zaa čuvanje

eksternih komandi nego što se obrade od strane Nagios demona. Takođe treba treba paziti da

“buffer-i” ne budu uvek puni zbog primanja dosta pasivnih provera ili eksternih komandi.

14. Optimizovati hardver za maksimane performanse. Sistemska konfiguracija i konfiguracija

mašine direktno utiču na performanse operativnog sistema koji utiče na performanse Nagiosa.

Najviše treba voditi računa o optimizaciji hard diska. Brzina procesora i memorije su faktori

koji utiču na performanse, ali brzina hard diska je najveće “usko grlo”. Ne treba čuvati

plaginove, log informacije i slično na sporim hard diskovima (stari “IDE” hard diskovi).

Veoma važna napomena za “Linux” korisnike je da većina “Linux” instalacija ne izvršava

optimizaciju hard diska.

http://nagios.sourceforge.net/docs/3_0/configmain.html#command_check_interval

http://nagios.sourceforge.net/docs/3_0/configmain.html#external_command_buffer_slots

117

3.4 Zaklјučak

Nagios je alat za mrežni monitoring koji mrežnom administrator omogućava da nadzire rad računara,

rutera, svičeva, štampača i servisa. Mnoge organizacije odlučuju se za skupa komercijalna rešenja kao

što je “HP OpenView”. Međutim, Nagios je odlično rešenje za one kompanije koje traže proizvod koji

nije skup (ili je besplatan) i koji je zbog otvorenog izvornog koda permanentno u fazi razvoja.

Osnovna prednost Nagiosa je ista kao i njegov osnovni nedostatak: krajnja fleksibilnost. Ovo je

očigledno odlično rešenje za one administratore koji žele da imaju potpunu kontrolu aplikacije i njenu

fleksibilnost. To takođe podrazumeva višednevna testiranja, puno čitanja i podešavanja. Nagios se

definitivno ne može instalirati po principu “clik-and-go”. Postoje brojni paketi koji su potrebni da bi

Nagios radio ispravno.

Postoje debate na internet forumima u kojima se vodi diskusija o prednostima i manama Nagiosa kao i

konkurentnih rešenja za monitoring kao što su “zabbix” i “cacti”. Iskustva početnika sugerišu da su

glavni nedostaci Nagiosa teška konfiguracija, ne toliko jednostavno održavanje, kao i dodaci kao što

mape, integrisani grafikoni. Dodavanje novih hostova se ne može realizovati brzo, i zahteva upotrebu

stranog alata koji će olakšati konfigurisanje fajlova dok recimo kod “zabbix-a” ovaj proces se obavlјa

koristeći veb interfejs. Tu je i pitanje mrežnih segmenta, Nagios generiše jednu veliku mapu, dok

“zabbix” omogućava definisanje proizvolјnih mapa različitih mrežnih segmenata. Takođe, većina

korisnika nisu iskusni “C/C++” programeri što im otežava pisanje skripti.

Plaginovi Nagiosa opisuju stanje nadgledanog servisa sa tri parametra: status , “summary” podacima i

“dugim” podacima dok “item” u “zabbix-u” opisuje samo jedan parametar. “Zabbix” je napravlјen sa

velikim predpostavkama, jedna od njih je da pokreće provere veoma često. Ali, ipak nije tako u

stvarnom životu, posebno u veb scenariu. Neki klijenti ne žele da njihove veb sajtove konstantno

opterećuje monitoring softver.

Nagios nije namenjen početnicima, pomoću njega se dobija skelet koji treba da nadograditi prema

invidualnim potrebama. Uprkos njegovim nedostacima u odnosu na konkurenciju ali i velikim

prednostima koje nudi u odnosu nad konkurencijom, Nagios je odličan “open soruce” alat za

monitoring infrastrukture. U bližoj budućnosti, da bi ostao konkurentan sa ostalim igračima u ovoj

oblasti, njegovi tvorci će morati da posvete više pažnje početnim korisnicima i ugledaju se na

konkurenciju tj. “dopune” Nagios opcijama koje mu nedostaju.

Introdution to ITIL - IT Service Management - Uvod u upravljanje IT Servisima, skripta- srpski

Documents

Transcript of Introdution to ITIL - IT Service Management - Uvod u upravljanje IT Servisima, skripta- srpski