avslutning.tex

\chapter{Avslutning}
\section{Evaluering}
\subsection{Gjennomføring av prosjektet}
Da prosjektarbeidet ble satt i gang ble det tidlig registrert at oppgavebeskrivelsen var noe løs. Det var derfor usikkerhet rundt hvor omfattende overvåkningsløsning oppdragsgiver ønsket seg. Dersom kommunikasjonen mellom gruppen og oppdragsgiver hadde vært grundigere fra starten av, og kravspesifikasjonen hadde vært mer konkret, ville dette ført til mindre tid på oppklaring ved senere tidspunkt. Det ville også gitt et større overblikk over hva som skulle gjøres. På grunn av dette ble overvåkningsløsningen mer omfattende og tidkrevende enn først forutsett av gruppens medlemmer.

Fordi vi ønsket å dekke flest mulig av kategoriene ulikt utstyr og tjenester IKT-avdelingen drifter i produksjon, valgte vi å sitte på fylkeshuset to dager i uken. Det ble derfor brukt mye tid på reising til og fra fylkeshuset.

I forhold til det Gantt skjemaet som ble satt opp i forprosjeketet har vi fulgt de iterasjonene som ble satt opp, med noen unntak. Servermiljø ble flyttet til etter varsling, da enheten for å overvåke servermiljøet kom senere enn forventet. Iterasjonene Servermiljø og Statusvindu ble utført parallelt, grunnet mindre arbeidsmengde enn forventet i Servermiljø. Det ble også satt opp sjekker for UPS-er i infrastrukturiterasjonen, som i utgangspunktet var planlagt for Servermiljø. Noen tjenester har tatt lenger tid å implementere enn planlagt og disse har blitt jobbet med samtidig som andre iterasjoner har pågått.

Innenfor hver iterasjon var det satt opp faser med planlegging, implementering og en fase med testing og evaluering. Utover i prosjeket ble ikke dette fulgt. Planlegging og evaluering har skjedd mer individuelt for hver enhet og tjeneste som har blitt lagt til i overvåkningen. For alle iterasjonene har det vært møter med statusoppdatering, som planlagt. 

Det ble også mye nødvendig dobbeltarbeid med å implementere sjekker i labmiljøet først og så i produksjon. For noen tjenester var det ikke mulig å teste i labmiljøet først.

Valget av Icinga har ikke hindret oss i å få til det som var ønsket. Arkitekturen Icinga baserer seg på er en enkel kjerne hvor tilleggsfunkjsonlitet må legges til. Dette gir stor frihet, og fleksibiltet fordi en kan utnytte et stort antall tredjeparts plugin-er som eksisterer, eller utvikle plugin-er etter behov. 

En overvåkningsløsning basert fri programvare kan ha visse ulemper. Ofte kommer slike løsninger uten support-avtaler, noe en som oftest finner i en proprietær løsning. Properitære løsninger markedsføres, og selges, ofte som en komplett pakke der en får produktet sammen med support-avtaler. 

Tredjeparts kode kan variere i standard og kvalitet. Ofte har dokumentasjonen vært mangelfull eller ikke eksisterende. Det har ikke alltid vært mulig å finne en plugin som fyller alle behov og da har modifisering av eksisterende løsninger vært nødvendig. Dette krever både tid og noe programmeringskunnskaper.

\subsection{Organisering av arbeid}
Innad i gruppen har det blitt avholdt daglige møter for å oppdatere resten av gruppen om utført arbeid, og om eventuelle utfordringer som har oppstått. 

Rollen som gruppeleder har i liten gra vært benyttet. Ved uenigheter og avgjørelser har gruppen alltid kommen til enighet i felleskap. At det ble satt en egen kommunikasjonsansvarlig har etter gruppens mening vært positivt. Det har fungert bra å ha et kontaktpunkt for kommunikasjon utad.

Kontakten med veileder har fungert godt med ukentlige møter og hjelpsomme forslag relatert til arbeidet.

Avtalte møter med oppdragsgiver ble til tider ikke avholdt, grunnet at oppdragsgiver ikke alltid var til stede da gruppen var på Fylkeshuset. Fordi oppsatte møtetidspunkter ikke alltid passet, ble gruppen og oppdragsgiver/teknisk kontakt enig om muntlige oppdateringer utenom møtene. Det var dessuten noe vanskelig å få avtalt overføring av funksjoner fra lab til produksjon med de som hadde ansvar for systemet, da disse ikke alltid var tilstede da gruppen var på fylkeshuset. 

Utgangspunktet for utførelsen av prosjektet var at det meste av vårt arbeid skulle skje i et labmiljø. Vi skulle deretter legge fram et forslag til et overvåkningssystem for implementering ved IKT-avdelingen.

Det positive med å ta en større del av implementeringen av overvåkningssystemet er at det er givende å levere en større løsning til oppdragsgiver, og at systemet som er konstruert kan iverksettes slik det nå fremligger.

Ved utvikling av statusvindu endte vi opp med å skrive om nesten all koden i Nagdash. Her gikk det med mye tid, og strukturen på koden ble heller ikke slik gruppen hadde gjort det om det ble skrevet fra bunnen. 

Gjennomgang av ulike plugin-er viste seg å ta mer tid enn forventet. Årsaken var for det meste dårlig dokumentasjon og varierende kodekvalitet. Et tilfelle var check\_xenapi.pl som ble gjennomgått for å sjekke om det var noe gjennomsnittskalkulering på returnert resultat, og om det var mulig å legge dette til. Plugin-en bruker 12 ekstra Perl-filer for å sette opp kall til RRD-databasen, og gjennomgang av disse tok for mye av tiden i forhold til gevinsten med å få den implementert. Det var den eneste plugin-en som hadde mer funksjonalitet enn å sjekke statusen for en Xen-host, så det ble priortert å gå gjennom koden for denne. 
Det har i ettertid lært oss at det ikke alltid vil være besparende å gjenbruke kode. Noen ganger kan det faktisk lønne seg å finne opp hjulet på nytt.

\subsubsection{Arbeidsfordeling}
Arbeidet har blitt fordelt slik at den av gruppens medlemmer med størst interesse og/eller kunnskap om et tema har satt seg godt inn i dette. Dette har ført til besparing av tid, da det for det meste har blitt utført tre oppgaver parallelt. Dette var nødvendig for å få tid til å gjennomføre målsetningen som ble satt. Utfordringen med denne fordelingen har vært å oppnå god oversikt over det totale arbeidet for hver av oss. Det tok tid å sette seg inn i problemstillinger når andre medlemmer støtte på vanskelige valg eller problemer, og det var behov for å ta felles avgjørelse.

Jevnlig og god kommunikasjon innad i gruppen har resultert i et godt samarbeid med få problemer. 

\subsubsection{Prosjekt som arbeidsform}
Å utføre et prosjekt for en ekstern organisasjon har vært givende og lærerikt. Det å levere et etterspurt produkt til arbeidsgiver gir et godt innblikk i hvordan arbeidslivet fungerer.

Mer tid og ressurser ble brukt på utføringen av bacheloroppgaven enn det som ville blitt med gjenomsnittlige emner med tilsvarende studiepoeng. Dette gjorde at det var utfordrene å følge opp andre fag i tillegg til bacheloroppgaven.

\subsubsection{Subjektiv oppfatning av bacheloroppaven}
Utføringen av bachelorprosjektet har gitt oss mye lærdom om omfattende prosjekter. Dette er relevant når vi nå skal ut i arbeidslivet. Den type erfaring hadde vi ikke tilegnet oss dersom tiden ble brukt i en forelesningsal, og dermed var dette bachelorprosjektet en godt egnet avslutning på utdanningen. 

\section{Videre arbeid}
I denne prosjektoppgaven har hovedfokus vært å bygge opp en overvåkningsløsning som tilfredsstiller kravene i oppgavebeskrivelsen. Det er tatt høyde for tilleggsfunksjonaliteten fra oppgavebeskrivelsen. Hovedsaklig går dette på historisk overvåkning. Det er satt opp grafing av ytelsesdata fra Icinga, men her er det mange muligheter for forbedring og videre arbeid. Dataene kan for eksempel analyseres for å sende varsler til Icinga om trender som indikerer problemer i nær fremtid, for eksempel om bruk av lagringsplass på en filserver.

Parallelt med prosjektarbeidet har IKT-avdelingen gjennomført et prosjekt der en CMDB har blitt implementert. Integrasjon mot denne med konfigurasjon fra objektene i overvåkningen og etterhvert mulighet for å definere avhengigheter som gjenspeiler seg i overvåkningen, kan være aktuelt.

Icinga 2\cite{icinga2} er under utvikling og er en parallell utviklingsprossess med Icinga 1.x. Planlagt stable release er i slutten av 2013. Icinga 2 er en ny kjerne som skal skrives fra bunnen av og fjerner det som Icinga 1.x har arvet i fra Nagios. Den nye kjernen vil fungere sammen med Icinga 1.x gjennom et kompabilitetslag\cite{wiki:comp} som oversetter kall. Her kan enten migrering til Icinga 2, oppsett av Icinga 2 sammen med eksisterende Icinga 1.x, eller å evaluere Icinga 2 som et nytt verktøy være aktuelt videre arbeid. 

Varsling er implementert slik at statusvisning blir oppdatert og det sendes ut varslingsmeldinger til en eller flere personer over e-post og SMS. Det må altså manuelt opprettes en sak i sakssystemet Fooprints. Her kan det være aktuelt å implementere en automatikk i at ønskede varsler registreres i sakssystemet, med ulike parametre som tjeneste eller host, prioritering, og ansvarlig person.

Asterisk og Trio er to telefonsystemer IKT-avdelingen drifter. Her vil det være relevant å overvåke køer, og annen informasjon. Å integrere dette med Icinga kan være en spennende utfordring å basere en oppgave på.

IKT-avdelingen ved Hedmark fylkeskommune har flere lokale IKT-avdelinger, som i hovedsak løser lokale problemer ved skoler, men som er avhengig av sentrale tjenester som trådløse nettverk og Internett-tilgang. Icinga Web muligheter for tilgangstyring på brukernivå for visning av informasjon. Et mulig prosjekt kan være å gjøre de tilpasningene som må til for å integrere de lokale avdelingene i overvåkningsløsningen. 

\section{Bidrag til fri programvare}
Både scriptet for å sjekke hvor mye minne en MySQL Cluster node har brukt og scriptet for å synknronisere kontakt-objekter fra Active Directory ble lagt ut på Internett under en GPL-lisens. Disse ble publisert på Nagios Exchange\cite{monkeyexchange} og Monitoring Exchange\cite{monkeymonndb,monkeymonadsync}, etter godkjenning fra oppdragsgiver. På begge sidene har vi selv funnet flere av plugin-ene benyttet i prosjektet, og vi håper at andre får nytte av vårt arbeid.

For plugin-en ``xen\_api'' ble det rapportert tilbake til utviklerene at sjekker antagelig ikke blir utført i henhold til beskrivelsen (e-post ligger i \ref{app:xenapi}).

%Da statusvinduet ble implementert fant vi ingen dokumentasjon på hvordan prioritere forskjellige host-objekter eller service-objekter. Da vi fant ut måten dette kan gjøres på ble det laget en artikkel på Icinga sin Wiki.
\clearpage 
\section{Konklusjon}
Det viktigste målet med denne prosjektoppgaven ble oppnådd. En ny overvåkningsløsning ble satt i produksjon med overvåkning av store deler av IKT-avdelingens infrastruktur og servertjenester. Løsningen kjører nå parallelt med den overvåknigsløsningen som fantes fra før, og overvåker mye som den gamle løsningen ikke har mulighet til. Oppdragsgiver planlegger at den eksisterende overvåknigsløsningen skal fases ut over tid, etterhvert som resterende tjenester og enheter integreres i den nye løsningen.

Etter gruppens mening vil oppgaven kunne tjene som eksempel på de aller fleste tjenester og enheter ved utvidelse av løsningen. I forhold til Servers Alive er løsningen presentert i denne rapporten mer oversiktlig og tilrettelagt for utvidelse, noe som antagelig kan føre til mer effektiv drift for IKT-avdelingen.

Gruppen er fornøyd med resultatet som ble overlevert. Læringsutbyttet har vært høyt, og vi mener vi har nådd de målene vi satte ved starten av prosjektet. Ved overlevering var ikke alle IKT-avdelings servere og tjenester under overvåkning, men det er lite som skal til for å legge til nye enheter. Dersom det skal legges til nye sjekker vil det som er satt opp tjene som gode eksempler på hva som er mulig, og hvordan det kan settes opp.