PERSPECT.IO. - Et fleksibelt og kraftig verktøy for visualisering av måledata. Gruppe 24

Transkript

1 PERSPECT.IO - Et fleksibelt og kraftig verktøy for visualisering av måledata Gruppe 24 Jonas Hasle s Jan Thomas Hanto - s Svein G. Fagerheim - s Nicholas Morsman - s181123

2 Studieprogram: Bachelorstudium i ingeniørfag - Data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: PROSJEKT NR. 24 TILGJENGELIGHET Åpent HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Perspect.to Et fleksibelt og kraftig verktøy for visualisering av måledata. DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Jonas Hasle s Jan Thomas Hanto s Svein Gunnar Fagerheim s Nicholas Morsman s INTERN VEILEDER Alfred Bratterud OPPDRAGSGIVER Kyrre Begnum KONTAKTPERSON Kyrre Begnum SAMMENDRAG Perspect.io er ett visualiseringslag, ment til å forenkle overvåkning av big data. Produktet er utformet for web med JavaScript/jQuery, og Node.js i backend. Dette systemet er koblet opp mot en Time Series Database (OpenTSDB), og viser elegant informasjon i et dashbord i form av widgets. 3 STIKKORD Big data Utforskende dataanalyse Monitorering

3 Forord Denne rapporten er skrevet som en avslutning på vår bachelorgrad i ingeniørfag data ved Høgskolen i Oslo og Akershus, og den vil ta for seg hvordan vi har jobbet i vårt prosjekt. Her vil vi ha en gjennomgang av prosessen underveis hva vi har gjort og hvilke valg vi har tatt. Vi vil gå grundig gjennom teknikker og metoder brukt for å komme frem til løsningene. Rapporten er skrevet for sensor, veileder, oppdragsgiver og ikke minst alle andre som enten vil bruke den som et fundament for videre forskning og utvikling, eller rett og slett kun vil pirre egen nysgjerrighet. Rapporten inneholder også en del faglige uttrykk, forsøkt forklart underveis i prosessen, så det er en klar fordel med grunnleggende kunnskaper innen IT. Arbeidet med oppgaven har vært utfordrende, omfattende og veldig lærerikt. Etter hvert som vi har opparbeidet oss mer kunnskap innen emnet, har også interessen blitt større. Dette gjelder også innen utforming av forskningsrapport, som var helt nytt for samtlige gruppemedlemmer. Vi ønsker å takke vår veileder Alfred Bratterud for gode diskusjoner og innspill underveis. Vi vil også takke oppdragsgiver Kyrre Begnum for masse informasjon og hjelp underveis vedrørende skriving av forskningsrapport. I tillegg vil vi gjerne takke venner og familie som har vært behjelpelige med tilbakemeldinger, tips og støtte knyttet til oppgaven, både faglig og på andre områder. Til slutt vil vi rette en stor takk til Marte G. Skåtterød for hennes hjelp og innspill i arbeidet med oppgaven. i

4 ii

5 Innholdsfortegnelse FORORD... I INNHOLDSFORTEGNELSE... III KAPITTEL 1: INTRODUKSJON PROBLEMOMRÅDE PROBLEMSTILLING... 3 KAPITTEL 2: BAKGRUNN BEHOVET OVERVÅKNINGSLØSNINGER EKSISTERENDE INFRASTRUKTUR... 9 KAPITTEL 3: TILNÆRMING EGENSKAPER EGENSKAPSANALYSE UTVIKLINGSMETODE OPPDRAGSGIVER KAPITTEL 4: RESULTAT KRAVSPESIFIKASJON Innledning Overordnet systembeskrivelse Rammekrav Systemets funksjonelle egenskaper Logisk datamodell Krav til systemkonstruksjonen Krav til dokumentasjon Krav til manuelle funksjoner SYSTEMDESIGN Utviklingsmiljø Detaljert systembeskrivelse Brukergrensesnitt IMPLEMENTASJONEN iii

6 Domenenavn og lokasjon Programvare Systemfiler Tilkoblinger Databaser Autentisering Dashbord KAPITTEL 5: ANALYSE KAPITTEL 6: DISKUSJON PRODUKSJON HVORDAN HAR DET GÅTT? SAMFUNNSNYTTEN PROBLEMOMRÅDET KAPITTEL 7: KONKLUSJON VEDLEGG A: PROSESSDOKUMENTASJON VEDLEGG B: PRODUKTDOKUMENTASJON VEDLEGG C: ATTEST FRA OPPDRAGSGIVER iv

7 Kapittel 1: Introduksjon 1.1. Problemområde En definisjon av informasjon er at det består av data som gir mening. Hva som er meningsgivende data varierer fra bruker til bruker, og datamengdene vi har i dag er gigantisk. I mange tilfeller er datamengden så stor at informasjonsvisningen kan se ut som oppstykkede data, som vil gi liten beslutningskraft for en eventuell sluttbruker. Man kan argumentere for at relevant og nøyaktig informasjon er nødvendig for å kunne trekke riktige beslutninger og iverksette tiltak/handlinger. Et systems effektivitet øker desto mer informasjon man klarer å hente ut og tolke av datamengden man har. Valgene som tas vedrørende systemet kan da tas hurtigere, og vil være basert på et mer informativt grunnlag. Ved enorme datamengder, også kjent som «big data», blir det å systematisere fremvisningen av dataene både mer komplisert og kritisk. Det er her behovet ligger: Å gjøre dette lettere. Figur 1: Big data Hvis vi for eksempel ser for oss en person, Kjell, direktør i Google Norge. Han ønsker å vite hvordan Google sin aksjepris står i sammenheng med dollar-kursen. Kjell har 1

8 muligheten til å bruke en applikasjon for å se Google sine aksjepriser, og en applikasjon for å se dollarkursen. Informasjonen kommer da fra to fundamentalt forskjellige datakilder - en ekstern og en intern. Disse kan Kjell kjøre side om side, men konfigurasjonen av disse applikasjonene er veldig forskjellige. Kjell har derfor ikke muligheten til å kunne kombinere informasjonen i de to ulike applikasjonene, annet enn ved å fysisk se den ved siden av hverandre. Han har heller ingen mulighet for varslinger dersom det skulle være en felles endring på disse. OpenTSDB [1] er et skalerbart system laget nettopp for å løse behovet ved å lagre og indeksere data, på en stor skala, fra flere kilder. Her kan man da lagre data fra forskjellige applikasjoner og ved forskjellige intervaller - dataene havner da i en felles kilde, uavhengig av opphav, art, formatering og eierskap. OpenTSDB har også mulighet til å visualisere med enkeltvisning av dataene. Det brukes altså i stor grad flere instanser av en applikasjon, eller flere applikasjoner samtidig, for å gi et komplett bilde over informasjonen ett eller flere systemer gir. Det er mulig å få tak i alle ønskelige data, men da må man belage seg på å sette seg inn i flere løsninger. Ved enkelte tilfeller kan dette fungere godt nok, spesielt om man kun er interessert i informasjon innenfor kun ett felt. Problemene er å se dataene i sammenheng, og å kunne tilpasse informasjonen som er relevant for den enkelte bruker. Man er avhengig av at utvikleren har tilrettelagt for nøyaktig den informasjonen man ønsker å se. En mengde data kan ha forskjellige betydninger basert på perspektivet man har. Siden hver applikasjon har ulike spesialfelt, er det vanskelig at alle brukerne finner den konkrete informasjonen de er ute etter. Perspect.io vil være et visualiseringslag, på toppen av en Time Series Database - som OpenTSDB, dette vil gjøre det mulig å forholde seg til ett system for visualisering av enorme datamengder. Visningen av informasjonen vil være skreddersydd, slik at det passer for hver enkelt bruker, uavhengig av perspektivet deres. Ved en løsning hvor man enkelt kan vise kun dataene man er interessert i inn i ett enkelt system, vil man bruke mindre ressurser på å ta systematisk gode beslutninger. 2

9 1.2. Problemstilling Hvordan fasilitere en enkel og utforskende overvåkningsprosess, der man på forhånd ikke må avgrense perspektivet man trenger på dataene? Å fasilitere vil si å lette eller legge til rette for noe. Vi ønsker et produkt som forenkler overvåkningsprosessen på brukernivå. Med enkel og utforskende mener vi her at det man ønsker å se ikke skal være forhåndsdefinert, men at det skal være redigerbart for enkeltbrukeren på en intuitiv og oversiktlig måte. Det man ønsker å se i dag er heller ikke nødvendigvis det man ønsker å se i morgen, og er det som menes med at man på forhånd ikke må avgrense perspektivet. En overvåkningsprosess er tall som endrer seg over tid, ikke en tilstand, med en naturlig utvikling gjennom flere stadier. 3

10 4

11 Kapittel 2: Bakgrunn Dette kapittelet vil sette fokus på hvordan, og hvorfor behovet for effektivisering av monitorering har vokst frem i dagens samfunn. Samtidig vil det også gi bakgrunnsinformasjon om relevante overvåkningsteknologier, slik at enhver leser, selv uten å inneha avansert fagkunnskap innenfor teknologiene, forstår hva rapporten omhandler. Leseren vil i dette kapittelet få et grundig overblikk over: Behovet for overvåkningsprosesser og effektiviseringen av disse. Dagens eksisterende overvåkningsløsninger og hvorfor disse ikke oppfyller vår problemstilling. Eksisterende infrastruktur i caset vi har fått presentert Behovet De siste 30 årene har teknologien for datamaskiner, nettverk og internett vokst i et ekstremt tempo. I takt med dette har også datamengdene vokst seg opp til gigantiske nivåer. Verdens teknologiske kapasitet til å lagre informasjon har omtrent doblet seg hver 40. måned siden 1980-tallet [2], og fra og med 2012 har det daglig blitt opprettet 2,5 exabyte 1 med data. Figur 2: Utvikling Datalagringsteknologi. Fra 26 bytes Hullkort til Fremtiden 1 En informasjonsstørrelse ca. lik en trillion bytes (10 18 eller 2 60 ) 5

12 Big data blir generert av mye rundt oss til enhver tid. Hver digitale prosess og hver utveksling på sosiale medier produserer det. Systemer, sensorer og mobile enheter overfører det. Big data kommer fra flere kilder med en alarmerende hastighet, volum og variasjon. For å trekke ut meningsfylt verdi og informasjon fra store mengder data, kommer man godt på vei med gode analyseringsevner og -ferdigheter. Vi antar at dagens organisasjoner i stor grad består av interne infrastrukturer som produserer enorme mengder data. Eksempelvis nettverksdiagnostikk, nettstedshistorikk og økonomiske data. Kun ved disse 3 eksemplene har bedriftene minst 3 forskjellige løsninger som både samler og viser informasjon. I tillegg antar vi at en flere av menneskene koblet til hver løsning ikke nødvendigvis er direkte avhengig av hele informasjonsvisningen de har tilgang til. Dette kan virke mot sin hensikt, og blir fort forvirrende Overvåkningsløsninger Det finnes mange eksisterende overvåkningsløsninger, hver med forskjellig bruksområde. Dette resulterer i at man må ha flere verktøy for å få et komplett bilde av systemet sitt. Et verktøy for applikasjonsovervåking, et annet verktøy for overvåkning av serverhelse og et tredje verktøy for tjeneste-overvåkning 2 er ikke et usannsynlig scenario. Få, eller ingen overvåkningsløsninger har mulighet til å presentere et utsnitt av data for en gitt tidsperiode, samt gi metadata 3 for både server, tjeneste og applikasjon samlet i en felles løsning. Et annet gjengående problem er at mange av de eksisterende løsningene enten har historikk på kun 24 timer eller at de kombinerer data for større tids-spenn, og derfor mister potensielt verdifull informasjon. Vi vil gi et overblikk på noen av dagens ledende overvåknings- og styringsverktøy, med spesiell oppmerksomhet på de som innehar elementer vi ønsker å ta lærdom av. 2 Også kalt daemon-overvåkning. 3 Data som definerer eller beskriver andre data 6

13 Ganglia Ganglia [3] har åpen kildekode og er et skalerbart overvåkningsverktøy for monitorering av systemytelse. Ganglia tillater systemadministratorer å definere, overvåke og endre servergrupper, uten behov for rekonfigurering av servere. Administratorene kan derfor lett monitorere både individuelle og kollektive serverberegninger på dynamiske cloud-infrastrukturer 4 ved stor skala - hvor rollen til serverne, potensielt ofte er i endring. Figur 3: Dashbordet til Ganglia C2MS C2MS [4] er et system bygget som en utvidelse til Ganglia. C2MS fungerer som et visualiseringslag på toppen av Ganglia. Det er designet for å overvåke og kontrollere dynamiske grupper av fysiske, eller virtuelle servere i en cloud-infrastruktur. Systemet komplementerer Ganglia ved å legge til et ekstra kontrollelement ved gruppemonitorering. Dette åpner for at administratorspesifiserte handlinger kan bli utført over servere innenfor samme tjenestegruppe. Samtidig introduserer de ytterligere overvåkningsberegninger som kan tilpasses. Ulempen med C2MS er at løsningen både er tett integrert med, samt begrenset av systemet under. 4 Nettsky, internettbasert databehandling der grupper av eksterne servere er i nettverk. 7

14 RRDtool RRDtool [5] er en forkortelse for Round Robin Database tool. Programmet logger all systeminformasjon, setter et tidsstempel på dataene og kan fremstille denne dataen grafisk. RRDtool overvåker kun serveren den er installert på, så hvis man ønsker å monitorere en sky må man installere programmet på hver eneste maskin i skyen. Når man konfigurerer RRDtool definerer man hvor stor lagringsplass databasen skal ha. Hvis RRDtool bruker opp den tildelte plassen, vil den eldste dataen bli skrevet over. Dette gjør at man har en begrenset mengde med historikk, og konsekvensen av dette er at man kan risikere å miste verdifull overvåkningsdata. Figur 4: RRDtool graffunksjon Cacti Cacti [6] er et webbasert visualiseringslag på toppen av RRDtool [6]. Det brukes til overvåkning og visuell fremstilling av nettverksdata - data som kan oppdateres på brukerens forhåndsbestemte intervaller i verktøyet. Utviklerne har laget et program med det formål å få et grensesnitt som er mer intuitivt og enklere å bruke enn det som er i RRDtool. Cacti bør settes opp med god kunnskap, da det er veldig vanskelig å rette opp i feil i etterkant av konfigurasjonen. Figur 5: Skjermbilde av Cacti dashbord reenshot.png 8

15 New Relic New Relic [7] er en SaaS (Software as a Service) løsning som overvåker web- og mobilapplikasjoner som kjører i en sky, på en lokal server eller i et hybridmiljø av disse, i sanntid. Programmet kan ha flere datakilder i samme dashbord og vise statistikk, representert med diagrammer. Det må installeres en agent på hver maskin hvor applikasjonen som skal overvåkes befinner seg. Hver agent sender statistikk til New Relic sine servere hvor det lagres. Fra New Relic sitt dashbord får man en samlet oversikt over tilstanden til alle applikasjonene sine. Siden dette er en tjeneste New Relic leverer koster denne løsningen penger hvis man vil ha statistikk utover et 24-timers tidsvindu. Figur 6: Skjermbilde av grensesnittet til New Relic content/uploads/2013/12/screen-shot at png 2.3. Eksisterende infrastruktur Oppdragsgiveren til caset vårt har en eksisterende infrastruktur vi vil jobbe tett opp mot. Alto, skyen til Høgskolen i Oslo og Akershus, består av teknologiene: OpenStack [8], Nova [9], Sensu [10] og OpenTSDB - disse er alle skrevet om, i detalj, i dette delkapittelet. OpenTSDB er den mest relevante teknologien for vår problemstilling som helhet, da dette er en Time Series Database 5 som løser problemet med å ha flere datakilder ved å samle dem inn til en felles datakilde. 5 Tidsstemplet database, en database som lagrer matriser av tall indeksert på tid 9

16 OpenStack OpenStack er skrevet i programmeringsspråket Python, og er et skalerbart virtualiseringsverktøy 6 som blir benyttet på Alto. OpenStack er en robust løsning med en modulær 7 arkitektur, som har komponenter til blant annet beregning, lagring, nettverk og autentisering. Verktøyet har i tillegg et køsystem for oppgaver, som gjør at systemet vil kjøre stabilt. Hvis man for eksempel trenger 5000 nye virtuelle maskiner blir ikke opprettelsen av samtlige begynt på samme tid, men de vil bli lagt i kø og oppgaven vil bli behandlet så snart systemet har ressurser tilgjengelig for gjennomføringen. OpenStack kan kjøre som en software på både Linux og Windows, men kan også kjøres «rett på metallet», slik som det gjøres i Alto. Nova Nova (OpenStack Compute) er programvaren som styrer dataplattformen til en sky, og er utformet for å administrere og automatisere store samlinger av dataressurser. Nova kan jobbe med tilgjengelige virtualiseringsteknologier, blant annet OpenStack. Arkitekturen er designet til å skalere horisontalt på standard maskinvare, uten proprietære maskin- eller programvarekrav. Konsekvensen av dette er at det gir Nova fleksibilitet gjennom muligheten til å integrere med eksisterende systemer og tredjepartsteknologier. Sensu Sensu er monitoreringsløsningen som henter ut data fra de ulike komponentene i skyen. Det er et overvåkningsrammeverk skrevet i programmeringsspråket Ruby, som henter resultater fra såkalte «checks» som kjører på opptil flere systemer. En check er et skript som returnerer en tilstand eller en verdi fra en applikasjon, tjeneste eller et system. Det 6 Etableringen av en virtuell versjon av noe, for eksempel et operativsystem, en server, nettverksressurser, en lagringsenhet, eller rett og slett en harddiskpartisjon. 7 Koden er oppdelt gruppevis, slik at det er enkelt å erstatte eller legge til kode. 10

17 er Sensu Client som har ansvaret for å kjøre checks og sende resultatet inn i en kø. På en av maskinene i skyen kjører Sensu Server. Denne serveren har som oppgave å hente informasjon fra klient-køen og prosessere disse resultatene. Etter prosessering sendes dataene videre, for eksempel i en e-post eller til en database. Sensu sin styrke i forhold til andre overvåkningsrammverk er i hovedsak at det er tatt utgangspunkt for overvåkning av en sky, og at det er modulært. Det er enkelt å skrive plugins 8 til rammeverket siden Sensu støtter plugins skrevet i alle programmeringsspråk. OpenTSDB OpenTSDB står for Open Time Series Database. Dette systemet ble laget fordi det er et behov for å lagre og indeksere måledata fra servere, virtuelle maskiner og operativsystemer på en stor skala. OpenTSDB gjør dataene lett tilgjengelig og kan fremstille de grafisk hvis brukeren ønsker det. Det kreves at man kjører en eller flere Time Series Daemons (TSD) som prosesserer data både ved innsetting og uthenting. Disse kommuniserer med HBase, en distribuert database skrevet i Java, hvor dataene blir lagret. Figur 7: Modell av Infrastrukturen til OpenTSDB Data som lagres i OpenTSDB kan være hva som helst man ønsker å måle over tid og består av et tidsstempel, en måling og enten ingen eller flere tagger 9 som beskriver hva målingen betyr. Det er viktig at OpenTSDB ikke behandler observasjonen på noen måte, den skal kun motta en verdi, sette på et tidsstempel og tagger som beskriver verdien. 8 Plug-in, addon eller Innstikk; en modul som legges inn i et program for tilleggsfunksjonalitet 9 Merkelapp 11

18 OpenTSDB tilbyr et API og et web-grensesnitt for å aksessere data. Brukeren kan bestemme i hvilken form dataene skal returneres fra databasen. Dette kan for eksempel være alle observasjonene som har blitt gjort i et gitt tidsrom, eller et gjennomsnitt av observasjonene i tidsrommet. 12

19 Kapittel 3: Tilnærming Dette kapittelet vil gi et detaljert bilde av hvordan vi skal løse problemstillingen - Hvordan fasilitere en enkel og utforskende overvåkningsprosess, der man på forhånd ikke må avgrense perspektivet man trenger på dataene? Kapittelet vil også belyse hvilke egenskaper prototypen må ha, i form av både funksjonelle og ikke-funksjonelle krav. Samtidig vil vi se på hvordan egenskapene skal kunne bevises slik at man enklere kan definere om forsøket har vært vellykket eller ikke, samt prosessen det vil ta å komme dit. Dataene eksisterer i et system - funksjonaliteten vi mangler er noe som enkelt gir hver unike bruker informasjonen de søker, uten at vi som utviklere trenger å vite hvordan dataene de er interesserte i ser ut. Det mest naturlige vil være å lage en prototype som må kunne endre informasjonen brukeren ønsker å se, endre visningen av dataene, og kunne endre visning av informasjonen i forhold til hva du ønsker ut av systemet. Disse egenskapene kan navngis til - å kunne endre informasjon, endre presentasjon, og endre perspektiv Egenskaper Å endre informasjon innebærer å alltid ha rett datakilde ut i fra dine behov som bruker. Big-data er noe som er tilgjengelig, men det er kun de dataene som til enhver tid er relevante som skal inngå i den individuelle presentasjonen. Ny data som har kommet inn i systemet, som er relevant må også inkluderes. Funksjonaliteten vi da er ute etter for å kunne endre informasjon er å kunne ha: Egendefinerte datakilder Redigeringsmuligheter av egendefinerte datakilder Nyeste datakilde Å endre presentasjon går ut på å forandre utseende på hvordan informasjonen 13

20 presenteres. Det skal være mulig for brukerne å enkelt endre diagramtyper, plassering og størrelse, alt etter behov, ønsker eller kriterier man ønsker å vektlegge. Funksjonaliteten ved å kunne endre presentasjon er da valg og redigeringsmulighet av: Visningsmodell Plassering/lokasjon av hver enkeltvisning i forhold til hverandre. Størrelsen på hver enkeltvisning Å endre perspektiv omhandler brukeropplevelsen av informasjonen som blir vist. To brukere kan ha behov for å se den samme informasjonen, men oppfattelsen av informasjonen kan være forskjellig mellom disse to. Egenskapen systemet vårt må inneha er muligheten til å vise samme informasjon, men på forskjellige måter. Hvis en bruker ønsker å se tre informasjonskilder samtidig, vil kanskje en annen bruker kun se to. Det er også ønskelig at systemet skal gjøre det mulig å bytte perspektiver, sitt eget eller andres, slik at man kan hente frem rett perspektiv til rett tid. Funksjonalitet som gir muligheten til å endre perspektiv er å kunne: Se på andres perspektiver Dele egne perspektiver Lage flere perspektiver for deg selv 3.2. Egenskapsanalyse Vi anser vår problemstilling som løst dersom prototypen vi utvikler innehar de tre definerte egenskapene omtalt i avsnitt 3.1. Hver egenskap vil evalueres hver for seg før vi trekker en felles konklusjon på dette. For å kunne definere prototypen som en suksess, må den inneholde flere av elementene som er definert nedenfor, innenfor hver egenskap. 14

21 En brukertest, gjennomført basert på et representativ utvalg av populasjonen, vil gjøre oss i stand til å evaluere hvorvidt prototypen vil være dekkende for gi svar på problemstillingen. Siden utførelse av bruketester er utenfor vårt fagfelt, vil risikoen for å feilvurdere hva som skal vektlegges og tolkes av resultatet være stor. En brukertest vil således ikke gjennomføres dersom dette kan unngås. Som alternativ handling til en brukertest vil vi ved å observere om gitt funksjonalitet er tilstede, og om disse fungerer tilfredsstillende, kunne evaluere prototypen. Endre informasjon Å kunne endre på informasjon kan evalueres ved om det finnes funksjonalitet for å: Endre dataen i en enkeltvisning Vise hvilke data man kan ha Legge til flere datakilder Representere flere datakilder i samme enkeltvisning Oppdatere datakilden med en hensiktsmessig frekvens Prototypen må bli laget slik at en sluttbruker selv velger hvilke data som skal bli sett. Dette kan vi evaluere ved å se om det er en slik type funksjonalitet i brukergrensesnittet til prototypen. Det bør også være mulig å få frem en oversikt som viser hvilke data som er tilgjengelig til enhver tid. Dette kan evalueres ved eksistensen av en kategorisk informasjonsside over tilgjengelige datakategorier, eller et smart brukergrensesnitt som automatisk kan fortelle deg hva som er tilgjengelig. Prototypen må bli laget slik at det vil være mulig å hente data fra flere systemer, dette for at dataene skal være tilgjengelig uavhengig av hvilket system det befinner seg i. Evalueringen av antall datakilder avhenger av modulariteten til systemet. Hvis antall datastrømmer applikasjonen kan ta imot er tilnærmet ubegrenset, og kun må endres på modulbasis, er systemet modulært nok. Om flere datakilder kan være representert i samme visning kan vi evaluere på to måter: 15

22 Enten ved at man har mulighet til å spesifisere datakildene i et brukergrensesnitt eller hvorvidt det funksjonelt er utført. Hva som er en hensiktsmessig oppdatering av datakilde vil variere fra datakilde til datakilde. Eksempelvis vil en temperatursensor gi signal om endring oftere enn Amerika bytter president. Siden man ikke har mulighet til å hente nyere informasjon enn det som allerede ligger i en database, kan dette evalueres ved funksjonaliteten rundt oppdatering av den nyeste informasjonen i databasen. Endre presentasjon Å kunne endre presentasjon kan evalueres ved om det finnes funksjonalitet for å: Endre utseende på dataene Endre størrelse på en datavisning Endre posisjonen på en datavisning Ha flere datavisninger i samme vindu Endring av utseende kan evalueres ved at man som bruker har mulighet til å endre hvordan dataen visuelt fremvises. Her vil det være naturlig å bruke prinsipper fra statistikken, da statistikk har gode visuelle virkemidler å representere data på. Det vil derfor være sentralt å kunne gi forskjellig fremvisning av samme data, som for eksempel å kunne endre graftype. Størrelse og posisjonering skal gi brukeren en mulighet til å sortere hva som er viktig og hva som er mindre viktig. Dette kan evalueres gjennom brukertesting eller alternativt ved å se om løsningen vår kan gjøre dette funksjonelt. Evalueringen av om man kan ha flere datavisninger i samme vindu kan gjøres ved å teste om man kan sette flere datavisninger ved siden av hverandre. 16

23 Endre perspektiv Å kunne endre perspektiv kan evalueres ved om det finnes funksjonalitet for å: Lage «et bilde» med dataen Vise sine samlinger av data til andre Hente frem gamle perspektiver Med å lage «et bilde» med dataen mener vi her det individuelle inntrykket og den informasjonen en bruker ønsker å ha i ett og samme vindu. Dette kan evalueres ved å se om man kan lage flere vinduer med forskjellige bruksområder. For eksempel ett vindu med varslinger, ett vindu som viser forhold mellom data eller ett vindu med alt samlet, alt ettersom hva brukeren ønsker. Muligheten til å vise og dele sine data med andre kan evalueres ved å se om det er funksjonelt gjennomført. Har man en måte å vise ett vindu til andre uten å måtte gi sine brukerdetaljer eller dele skjerm med noen, er funksjonaliteten tilstede i løsningen. Å evaluere funksjonalitet for å hente frem gamle perspektiver kan gjøres ved at ulike vinduer kan identifisere som nettopp «dette» vinduet. Det må da være mulig for en bruker å ha flere ulike vinduer og med forskjellige datavisninger. Hvert vindu må i tillegg gis en unik «id» for identifisering Utviklingsmetode Når flere utviklere skal arbeide sammen bør man ha en utviklingsmetode og et rammeverk for kildekodekontroll for å ha kontroll på prosessen og arbeidet. Nedenfor går vi innpå hvilken metode vi har valgt å jobbe etter, rammeverket for kildekodekontroll og hvorfor vi har valgt nettopp dette. Kanban Vi trenger en smidig og oversiktlig metode for å holde best mulig kontroll på 17

24 utviklingsprosessen. Kanban er en smidig utviklingsmetode hvor man visualiserer arbeidsoppgavene som lapper på en tavle, med faner som forklarer status på arbeidsoppgaven. Denne metoden gjør det mulig for hver utvikler å selv velge hvilken arbeidsoppgave som de skal arbeide på. Ved å gi den enkelte utvikler denne friheten reduseres arbeidet til lederen av utviklingsgruppen. Stegene vi må igjennom for å komme oss fra design til prototype er gitt av fanene vi setter opp i Kanban. Disse er definert nedenfor. Gjenstår Under denne fanen vil man finne arbeidsoppgaver som ikke er påbegynt eller som skal forbedres. Her kan prosjektdeltakere velge de oppgavene de synes ser mest spennende ut, som gjør arbeidsoppgavene varierte og interessante. Utvikling I utviklingsfanen finner man alle de oppgavene som er påbegynt og som arbeides med akkurat nå. Før man jobber videre med en av oppgavene innunder denne fanen eller lager noe som bygger på dette arbeidet, kan det være lurt å først rådføre seg med de personene som har valgt aktuell oppgave. Testing Arbeidsoppgaver som er påstått ferdig utviklet finner man i fanen for testing. For å kunne konkludere om dette fungerer i henhold til forventningene og utgangspunktet så må arbeidet testes. Fullføring av testingen kan i enkelte tilfeller være avhengig av at også andre oppgaver er tilgjengelig for testing. Implementering Når vi kommer frem til implementeringsfanen betyr det at oppgaven er ferdig utviklet, og kun trenger å bli implementert i hovedløsningen. Dette er det siste steget før vi kan se resultat. Ferdig Arbeidsoppgaven er nå ferdig, men kan alltids bli videreutviklet avhengig av 18

25 testing/implementering av andre arbeidsoppgaver. Når samtlige oppgaver ligger i denne fanen, er prototypen ferdig utviklet. Innenfor metoden er det i tillegg noen definerte «Work In Progress» (WIP) prinsipper som går ut på å fastsette en maksgrense for hvor mange arbeidsoppgaver som kan ligge i hver unike fane til enhver tid. Da kan man også raskt avdekke hvor flaskehalsen ligger i utviklingsprosessen, når man enkelt kan se når en arbeidsoppgave har ligget lenge i én fane. Hjelpeverktøy for å avdekke flaskehalser tidsnok vil være viktigere ved mange utviklere, da det blir vanskeligere å holde totaloversikten, enn ved få utviklere. Vi kommer ikke til å benytte oss av WIP-prinsippene, da det anses som unødvendig når vi kun er 4 utviklere i gruppen. Ved bruk av Kanban vil alle arbeidsoppgavene gli smidig igjennom alle stegene i utviklingsprosessen og man har til enhver tid oversikt over hvilke oppgaver som ligger innunder hvilket steg. Vi vil bruke Kanban utviklingsmetode i vårt arbeid ved bruk av Trello. Trello er en web-applikasjon som enkelt gir muligheten til å bruke utviklingsmetoden Kanban. GIT Git er et gratis og åpent kildekodekontrollsystem (SCM) som gir hver bruker ett kodelager av hele produksjonen, som gjør at man kan utvikle uavhengig av hverandre. Versjonskontrollen som GIT tilbyr gir oss mulighet til å lete oss tilbake til ønsket versjon dersom det skulle skje uønskede endringer. Git har enkle kommandoer for å legge hele eller deler av sitt lokale reservoar av kodelinjer inn i ett hovedreservoar, uten å måtte bruke for mye tid på å se hva andre har gjort i filene. Git er et godt valg dersom man ønsker å utvikle samtidig, det er godt dokumentert, og i tillegg er det mange funksjoner innebygd. Av overnevnte grunner vil vi benytte oss av Git i dette prosjektet. 19

26 3.4. Oppdragsgiver Gjennom hele prosessen er det viktig at vi sikrer en løpende og god dialog med oppdragsgiver. Planen er at vi går i dialog med oppdragsgiver før arbeidet påbegynnes for å få kartlagt og skissert kundens ønsker. Det skal utarbeides en kravspesifikasjon i samarbeid med oppdragsgiver, og vi regner med at denne kommer til å endre seg fortløpende. Vi ønsker å samarbeide tett med oppdragsgiver og presentere grafiske prototyper underveis for å sikre konkrete og gode tilbakemeldinger på arbeidet underveis. Det er naturlig at det vil komme endringer i løpet av prosessen og grunnet vår oppdelte utvikling i Kanban vil det være lett å implementere nye ønsker og endringer underveis i prosjektet. Oppdragsgiver vil jevnlig bli presentert de ulike delene som befinner seg i test- og implementasjonsfasen til enhver tid. Hensikten med dette er for å kunne ta utfordringene og avklaringer underveis og dermed utbedre de fortløpende. Ved leveransedato ser vi for oss at vi leverer en prototype som oppdragsgiver føler kjennskap til, som har den funksjonaliteten og ser ut slik oppdragsgiver ønsker. Videre har oppdragsgiver egne krav og forventninger til produktet. Disse tilleggskravene er at løsningen må ha ytterligere egenskaper som brukervennlig, skalerbar, åpen og fleksibel. Det vil også være naturlig å komme frem til en enighet med oppdragsgiver rundt hvilke teknologier og eksisterende rammeverk vi skal bruke. Dette vil være spesielt aktuelt dersom løsningen skal være åpen kildekode og om koden skal ligge på for eksempel GitHub. Dette vil vi avklare med oppdragsgiver før arbeidet påbegynnes. 20

27 Kapittel 4: Resultat Dette kapittelet er delt opp i to deler, første del omhandler designet, eller «tegnebrettet», for produktet som oppfyller kravene for både oppdragsgiver samt problemstillingen. Herav kravspesifikasjon (4.1) og systemdesign (4.2). Andre del vil gå inn på selve implementasjonen av det endelige produktet, altså hva man klarte i praksis. Herav implementasjon (4.3) Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker Innledning Informasjon om hvordan kravspesifikasjonens oppbygging er organisert: En overordnet systembeskrivelse: Beskriver fordelene ved vårt system. Her vil det være informasjon om systemets egenskaper, produktivitet og operasjoner Rammekrav: Spesifisering av rammene som gjelder for systemet. a. Sikringstiltak ved adgangskontroll. b. Brukervennlighet ved varsling av bruker- og systemfeil, samt funksjonalitet rundt grensesnitt. c. Tilgjengelighet for brukere samt rundt åpenheten av produktet og koden. d. Systemets funksjoner rundt datainnsamling Systemets funksjonelle egenskaper: En detaljert beskrivelse av funksjonene innen hvert delsystem av løsningen. Det vil også være eksempel på inndata i funksjonen Logisk datamodell: En datamodell av hvordan den logiske sammenhengen mellom datasettene er ved hjelp av datastrukturdiagrammer. 21

28 Krav til systemkonstruksjonen: Eventuelt eksisterende maskinutstyr og oppsett som skal benyttes. Spesifikk liste over hvilket databasesystem, operativsystem og lignende vil dekkes her Krav til dokumentasjon: Inneholder kravene til bruker-, administrator- og modularitetsdokumentasjonen som skal utarbeides for systemet Krav til manuelle funksjoner Overordnet systembeskrivelse Det skal være mulig for brukeren å logge seg inn med brukernavn og passord. Ved første innlogging vil brukeren møte et tomt dashbord. Brukeren vil da tilpasse dashbordet sitt med widgets som overvåker hvert sitt område av skyen. Brukeren kan da tilpasse størrelsen og lokasjonen til hver enkelt widget etter egne preferanser, slik at man kan ha store og små widgets side om side. Størrelsen skal kunnes låses slik at man ikke kan endre størrelsen ved et uhell. Alle endringer vil bli lagret slik at brukeren vil få opp det samme dashbordet de hadde da de logget seg ut forrige gang. Brukeren har mulighet til å opprette flere dashbord om det skulle være ønskelig. Administratoren vil ha mulighet til å opprette og slette brukere når det blir nødvendig. Ved å innføre vårt system vil oppdragsgiver, og andre brukere av det, kunne bruke tiden sin mer effektivt ved å monitorere flere egendefinerte datakilder i samme visning. I tabellen under er det laget en punktlig beskrivelse av produktet vi har tenkt å lage for oppdragsgiver. Hovedbeskrivelse 1. Skal være mulig å logge seg inn og ut av sin egen brukerkonto. 2. Bruker skal kunne få tilpasse dashboardene sine. Detaljert beskrivelse 1.1. Innlogging krever en Google konto Det må være mulig å legge til flere autentiseringsløsninger Bruker skal få tildelt et tomt, redigerbart dashbord ved første innlogging. 22

29 2.2. Brukeren skal kunne forandre størrelsen på widgets Brukeren skal kunne forandre rekkefølgen på widgets ved bruk av drag and drop Det skal være mulig å låse en widget på plass Alle endringer skal kunne lagres eller avbrytes Bruker skal kunne lage en eller flere dashbord 3. Det skal være mulig å lage widgets 3.1. Brukeren skal fylle ut en form for å lage en for dashbordet. widget Widgeten skal overvåke en brukerdefinert del av skyen Widgeten skal kunnes fjernes av brukeren Widgeten skal kunnes endres av brukeren. 4. Administratorens muligheter 4.1. Opprette en ny bruker Slette en bruker Tildele brukere administrative rettigheter 5. Brukerpanel 5.1 Bruker skal kunne dele sine dashbord med andre 5.2 Bruker skal kunne benytte seg av andres dashbord, uten å kunne endre på det. 5.3 Bruker skal ha en form for profil. 23

30 Rammekrav Tabellen nedenfor viser kravene for funksjonene systemet skal støtte samt et prioritetsnivå for hver enkelt funksjon. Prioritetsskalaen går fra 1 til 3, hvor 1 er viktigst, og 3 er minst viktig. Krav Prioritet 1. Systemet skal vise en feilmelding dersom systemet eller nettsiden er 1 nede. 2. Systemet skal vise feilmeldinger dersom enkeltmoduler ikke viser riktig 1 data eller bruker har gjort en feil ved opprettelse. 3. Det skal eksistere rutiner for håndtering av uforutsette feil? 1 4. Adgangskontroll til systemet sikres ved brukernavn og passord Planlagte systemoppdateringer skal forhåndsvarsles? 3 6. Systemet gjør en vurdering av data fra overvåkningstjenesten Systemet oppdateres i sanntid med dataen fra overvåkningstjenesten 1 bak. 8. Systemet kjøres i nettleser Brukervennlig utforming av nettstedet med funksjoner Prosjektet skal ha åpen kildekode og ligge ute på GitHub Skal være modulært, i en utvidbar plugin-arkitektur, slik at man enkelt 1 å legge til, endre eller fjerne funksjoner, og widgets, for å kunne visualisere nye deler av datamengden. 12. Stor visning av en enkelt widget skal være mulig Systemet skal være ett flerbrukersystem Systemet skal benytte seg av ett visualiseringsverktøy for 2 datafremvisning. 15. Lagre alle endringer brukeren gjør på dashbordet. 1 24

31 Systemets funksjonelle egenskaper I tabellen nedenfor presenterer en mer detaljert oversikt over hva funksjonene i systemet skal gjøre, samt hvilke data funksjonen eventuelt skal eller kan behandle. Funksjon Beskrivelse Databehandling 1. Innlogging Brukeren må logge inn ved å autentisere seg med Google. Dette gjøres ved at bruker trykker på en knapp som sender brukeren til google. Her må brukeren registrere ny konto dersom man ikke har en eksisterende konto, og logge inn dersom man ikke allerede er logget inn fra før. Deretter må brukeren godkjenne tilgangen til google-kontoen for systemet slik at man er autentisert. Google sender da en token til systemet dersom det er godkjent, og brukeren er identifisert og logget inn. 2. Utlogging Brukerens økt brytes ved at cookies og Google token slettes slik at brukeren logger ut. 3. Brukere kan 3.1. Lage nye dashbord administrere egen Skal være mulig å lage nye og tomme dashbord brukerkonto. og gi dem et navn Få opp en liste over alle dashbord. Skal være mulig å få opp en liste over alle dashbord som finnes Legge bord til favoritter. Skal være mulig å legge et dashbord til en favorittliste. Dette vil gjøre det enklere å finne de dashbordene man bruker ofte Slette dashbord Skal være mulig å slette de dashbordene som man ikke har bruk for lengre. Inn: app-id, secret Ut: bruker-token Inn: bruker-id Inn: tittel Ut: dashbord Ut: liste med dashbord Inn: dashbord-id Inn: dashbord-id 25

32 4. Brukere kan administrere sitt eget dashbord 5. Administratorens muligheter 4.1. Legge til widget. Brukeren skal ha mulighet til å legge til nye widgeter når dem mener dette er nødvendig Endre widget. Bruker skal kunne endre informasjonen i en widget. Da endre visuell representasjon, i form av annen graf, eller datastrømmen Slette widget. Widgeter som brukeren mener ikke har lyst på lenger skal kunnes slettes av brukeren Endre plasseringen til widgeten på dashbordet. Skal være mulig med drag and drop å endre plasseringen til widgetene Låse plasseringen til widgetene Widgetene skal kunnes låses på plass slik at man ikke endrer størrelsen eller plasseringen ved et uhell Registrere nye brukere Registrere nye brukere slik at de kan lage sine egne dashbord Slette brukere Slette brukere som ikke lengere skal ha tilgang til overvåkningsdata til skyen. Kan for eksempel skje når noen slutter Deaktivere brukere Deaktivere brukere som midlertidlig ikke skal ha tilgang til skyen. Kan for eksempel være når en ansatt blir suspendert for noe og man ikke ønsker at den ansatte skal ha tilgang til noe før grunnen til suspensasjonen blir avklart Slette dashbord Ut: widget Inn: endret informasjon Ut: widget Inn: widget-id Inn: serialisert layout Inn: Googleobjekt eller brukernavn+pas sord Inn: bruker-id Inn: bruker-id Inn: dashbord-id 26

33 6. Brukervennlig design. Skal være mulig å slette dashbordene til andre brukere som man ikke har bruk for lengre. 5.5 Liste opp alle brukere Administratoren er nødt til å få opp en liste over alle brukere for å kunne administrere brukerne på en effektiv måte Responsivt Skal være mulig endre størrelsen på nettleser og forvente at dashbordet tilpasser seg den nye størrelsen automatisk. Ut: liste av brukere Logisk datamodell «Dashboard» (web-applikasjonen) Dette er selve fremvisningslaget som visualiserer data hentet fra API et. Figur 8: Modell av produktets infrastruktur API Et RESTful-API som leverer data fra backend-applikasjonen til forskjellige fremvisningslag. Primært vil API et levere data til web-applikasjonen, men vil også kunne brukes til en mobilapplikasjon eller et varslingsystem. Backend-applikasjon Prosesserer data fra alle nodene i infrastrukturen og beregner hva som er ansett som «viktig» for fremvisningslaget. Lagrer dataene i databasen, så de raskt kan hentes ut av API et ved senere tidspunkt. Database/cache 27

34 Lagrer ferdigprosessert data for raskest mulig respons fra API et. Lagrer også brukerinnstillinger fra web-applikasjonen Krav til systemkonstruksjonen En maskin med nettforbindelse som kjører applikasjonen Valgfritt operativsystem, men Linux/Ubuntu Server anbefales Maskinen må være tilgjengelig på internett så brukere kan nå applikasjonen Maskinen må kunne kommunisere med OpenTSDB En datakilde, Open Time Series Database Hvis applikasjonen skal tilby autentisering gjennom Google En offentlig IP eller et offentlig domene for å nå maskinen kreves av Google Nøkkel og passord til Google sitt API 28

35 Krav til dokumentasjon Det er vanlig praksis å dokumentere ett produkt når det er ferdig utviklet, vi ser for oss en enkel brukerveiledning basert på screenshots ( ) som viser hvordan systemet ser ut fra brukersiden. I tillegg vil det være noen funksjoner som er administratorspesifikke som kommer i egen del ( ). Siden vår løsning er modulær vil vi også legge ved noen eksempler på hvordan de mest kritiske modulene kan se ut ( ). Det vil også være kommentarer i kildekoden. Tabellen nedenfor setter kravene vi vil dekke i forhold til dokumentasjon. Punkt Underpunkt 1. Brukerdokumentasjon 1.1 Logger på 1.2 Logger ut 1.3 Legger til dashbord 1.4 Deler dashbord 1.5 Bytte dashbord 1.6 Legger til widgets 1.7 Gir nytt navn til widget 1.8 Flytter widget 1.9 Endrer størrelse på widget 1.10 Fjerner widget 1.11 Endre globale variabler 2. Administrasjonsdokumentasjon 2.1 Endrer registreringspolicy 2.2 Brukerhåndtering 2.3 Endre Autentiseringmåte 2.4 Installasjon 3. Modularitetsdokumentasjon 3.1 Dummymodul for autentisering 3.2 Dummymodul for widgets 3.3 Dummymodul for legge til datamodell. 29

36 Krav til manuelle funksjoner Det finnes noen manuelle funksjoner som kunne vært automatisert. Disse er ikke automatisert da de enten har lite hensikt for systemet, eller det vil kreve tilknytning til ytterligere resursser. De manuelle funksjonene blir nevnt nedenfor. Manuell funksjon Beskrivelse 1. Endre registreringspolicy Hvis man skulle ønske å begrense hvem som skal kunne registrere seg, må administrator selv endre policy. 2. Brukerhåndtering Hvis man skal aktivere eller deaktivere brukere må dette gjøres manuellt Systemdesign Systemet skal gi brukerne full kontroll over informasjonsflyten i et monitoreringssystem. Informasjonen skal representeres etter brukerens egne ønsker og behov, og hvordan andre brukere av systemet har definert dette i egne dashbord. Designet, i de påfølgende delkapitlene, vil illustrere systemets virkemåte og hovedkomponentene som blir tatt i bruk for å gjennomføre dette Utviklingsmiljø Backend Vi ser for oss et system som kommuniserer ved hjelp av JSON (Javascript Object Notation). Dette er naturlig siden vi bruker mye teknologi som allerede benytter seg av JSON eller kjører V8 Javascript motoren. Vi ser for oss følgende backend applikasjonsstack: Node.js MongoDB REST API 30

37 JavaScript, en implementasjon av ECMAScript, er et skriptspråk som hovedsakelig håndterer alle dynamiske hendelser på en nettside, både visuelt og operasjonelt. Sammen med øvrig innhold på nettsiden sendes det kode, som kjøres lokalt i nettleseren, automatisk eller som reaksjon på brukervalg på nettsiden. Vanlige bruksområder er å endre innhold på en nettside samtidig som det kommuniseres mot et API, gjerne som en konsekvens av en form for brukerinteraksjon som klikk, scroll og fokus. Node.js er en programvareplatform med fokus på skalerbare serverside og nettverksbaserte applikasjoner. Den er basert på Google sin V8 Javascript motor, den samme motoren som blant annet kjører i Google Chrome. Dette vil si at Node.js kjører Javascript, bare på serversiden istedenfor i en nettleser. Node.js kjører, som Java, i sitt egne virtuelle miljø, noe som gjør at programvaren fungerer på alle operativsystemer. Siden Node.js-applikasjoner kun kjører i en prosess-tråd er det mindre egnet for veldig CPU-intensive oppgaver, men alle I/O-operasjoner som filbehandling og HTTP-kall kjøres i egne tråder for å ikke blokkere for hovedtråden. Andre server-side språk som kunne blitt brukt for denne applikasjonen, som for eksempel PHP og Python, vil en funksjon først starte når foregående er ferdig med å kjøre. Dette vil si at man kan komme til å vente ved flere samtidige hendelser. På grunn av Node.js sin handlingsbaserte og asynkrone natur er det veldig godt egnet for sanntidsapplikasjoner, noe vi tror vil gi oss en raskere løsning enn de alternative språkene. [11]. MongoDB er en NoSQL database, laget for å takle lagring av big data. Dette vil si at det ikke er de samme begrensningene som i tradisjonelle SQL databaser når det kommer til skalering og behandling av store datamengder. MongoDB skalerer horisontalt, det vil si at man kan lagre databasen over flere maskiner. I MongoDB lagres data i BSON (Binary JSON), noe som gjør at innsetting og uthenting av JSON-objekter kan skje uten noen formatering. Siden vi vet det kommer ustrukturert data, kan vi egentlig utelukke relasjonsdatabasen MySQL, og når det ser ut til at MongoDB også er raskere faller valget vårt her. [12]. 31

38 JSON er en universell datanotasjon for komplekse data. JSON er mindre ressurskrevende enn XML, som har et dårlig forhold mellom egentlig data versus markeringen av denne. Siden vi ikke har behov for å forstå rammene av dataene, stiller JSON sterkt. Et JSON objekt består som regel av en eller flere matriser, men kan også bestå av en liste med par hvor den første i paret er en attributt og den andre er en verdi. REST står for Representational State Transfer og definerer en arkitektonisk 10 stil som blant annet blir brukt på HTTP-protokollen. REST tilbyr oss fire verb for å behandle ressurser: GET - Henting av objekt(er) POST - Opprettelse av et nytt objekt PUT - Endring av eksisterende objekt DELETE - Sletting av objekt API står for Application Programming Interface, og er altså et grensesnitt som brukes for å programmere mot en applikasjon. Et RESTful API er et API som benytter seg av REST sin arkitektoniske stil. Dette fører til at utviklere som tidligere har jobbet med REST instinktivt forstår hvordan de skal programmere mot vårt API siden det følger de samme generelle retningslinjene. Frontend Når vi ønsker å ha et JavaScriptmiljø på backend og vår løsning skal kjøres på web, ser vi det som naturlig å bruke følgende stack på frontend: HTML5 & CSS3 JavaScript, forenklet med jquery-biblioteket Google Charts Bootstrap Andre jquery biblioteker med funksjonalitet vi er ute etter, herav: Gridster Toaster.js 10 Med hensyn til arkitektur 32

39 HTML5 (HyperText Markup Language) er et markeringsspråk benyttet til strukturering, formatering og presentasjon av informasjon for nettsider som kan vises i en nettleser. HTML er en kjerneteknologi på internett, og som et språk har det som mål å ha en syntaks som maskiner skjønner og som mennesker lett kan lese. HTML5 er den nyeste HTML standarden, og er den W3C anbefaler. CSS (Cascading Style Sheets) er et språk som definerer utseendet på HTML- og XMLfiler. Prinsippet er at HTML utelukkende skal beskrive struktur og semantikk, mens stilinformasjon som oppsett, font og farger skal beskrives med CSS. CSS er også en kjerneteknologi på internett, og omtrent alle nettsteder bruker CSS-stilark for å presentere innholdet på nettsidene sine. Siden vi planlegger å bruke JavaScript i backend, finner vi det lite nødvendig å trekke inn ytterligere språk i frontend da forskjellige språk kan snakke godt sammen - vil fortsatt et språk snakke best innad. jquery er et JavaScript-bibliotek utviklet for å forenkle JavaScript-syntaksen, og er laget for å gjøre det lettere å navigere et dokument, velge HTML-elementer, opprette animasjoner, behandle hendelser og utvikle Ajax-applikasjoner. jquery gjør det derfor også enklere, og raskere, for utviklere å lage utvidelser til JavaScript-biblioteket. Google Charts er et API for visualisering av grafer og tabeller. Her har man et stort utvalg av ferdigsydde komponenter som skal være enkelt å ta i bruk, som gir tabelldata ett løft når det kommer til visuell fremstilling. Den største ulempen med Google Charts er at det ikke har åpen kildekode, som fører til at man trenger en aktiv internettforbindelse på klientmaskinen for å koble seg opp mot Google sine servere. Bootstrap, utviklet av Twitter, er en samling av verktøy for å lage websider og webapplikasjoner. Laget for effektivisering av design og visualisering på nett, vil det spare oss for mye arbeid. Valget stod mellom Bootstrap og jqueryui, men siden vi har god kjennskap til Bootstrap fra før vil vi gå for denne løsningen. Bootstrap inneholder HTML og CSS-baserte designmaler for typografi, skjemaer, knapper, navigasjon og andre grensesnittkomponenter, samt valgfrie JavaScript-utvidelser. 33

40 For å gjøre selve dashbordet så enkelt og intuitivt som mulig, vil vi benytte oss av en rutenettløsning med drag and drop funksjonalitet. Vi fant to aktuelle jquery-bibliotek for dette, Gridster og Shapeshift. Når vi sammenligner disse to, ser vi fort at Shapeshift er mer plassbesparende, grunnet en algoritme som regner ut plassering ut fra minst mulig tomrom. Problemet med dette er at en enkel forflytning av en boks kunne potensiellt endre hele layouten på dashbordet til brukeren. Gridster gjør det mulig å bygge intuitive og flyttbare oppsett som man kan endre størrelse på. Det blir laget et rutenett hvor man kan legge til og fjerne elementer dynamisk. Informasjonen om hver enkelt boks kan serialiseres til en string som man kan lagre til fil. Dette gir muligheten for å gjenskape den opprinnelige strukturen på rutenettet. Dette vil vi bruke slik at brukere kan sette opp sine egne presentasjoner, med fokus på plassering, størrelse og visning. Toaster.js er et varslingssystem skrevet som et plugin til jquery. Meldingene er i Bootstrap stil og kan varsle suksesser, advarseler, info og feil. Man kan bestemme hvor på nettsiden meldingene skal dukke opp og hvor lenge de skal vises. Hvis flere advarsler kommer samtidig kan de enten komme etter hverandre eller under hverandre Detaljert systembeskrivelse Tilkoblinger Siden Perspect.io kun blir et visualiseringslag, ønsker vi å ha så få eksterne avhengigheter som mulig. På Alto, skyen på Høgskolen i Oslo og Akershus, kjører en OpenTSDB database som vi skal hente data fra i denne prosjektløsningen. Per dags dato er det ingen måte å hente data ut i JSON-format, så dette må vi lage en løsning på selv. 34

41 Løsningen vi ser for oss vil være å lage en form for datakildemodul, som definerer hvor datastrømmen skal komme fra. Da vil man enkelt kunne sette vårt lag på toppen av hvilket som helst datalager, uten for mye konfigurasjon av systemet. Databaser Vi ønsker en database som i hovedsak skal benyttes til to ting: lagring av brukerdata som profilinfo, widgets og brett, og caching. Brukerdata vil være nøkkel for å kunne dele både brett og widgets. Samtidig vil vi cache data fra datakildene for å legge mindre press på Figur 9: Modell av påtenkt tilkoblingsløsning maskinvaren. Siden OpenTSDB ikke leverer oss ren JSON må vårt API prosessere og sortere mye av dataene vi får levert. Dette krever spesielt mye CPU når det er snakk om store mengder data fra flere samtidige spørringer. Ikke bare vil caching sørge for lavere CPU-forbruk og færre spørringer til OpenTSDB, men det vil også føre til raskere svar tilbake til brukeren. Dette er spesielt viktig hvis flere brukere spør etter samme informasjonen innenfor et gitt tidsrom og API et kan levere cachet data uten å utføre spørringer eller prosessering. Autentisering Autentisering er viktig og må gjøres riktig. Det er teknisk krevende å lage en nesten sikker autentiseringsløsning, uten at det tar for mye tid. Vår plan er å benytte oss av en av de mange store autentiseringstilbyderne. Både Google, Facebook og Twitter, for å nevne noen, tilbyr tredjeparts autentisering gjennom deres OAuth grensesnitt. 35

42 Dashbord Det første man vil gjøre i Perspect.io etter innlogging er opprettelsen av et dashbord. Rutenettet i dashbordet blir bygget opp ved hjelp av Gridster, hvor rutenettet får en serialiseringsfunksjon som vi vil bruke for å lagre innhold, posisjon og størrelse til databasen. Brukeren som opprettet dashbordet er eieren, men kan dele dashbordet med andre brukere kun ved å dele URLen. Andre brukere har lesetilgang til brettet, de kan se på det men ikke gjøre endringer, samtidig som de kan bokmerke brettet for å enkelt finne tilbake til det senere. Innholdet i et dashbord består av flere widgets. Widgets Widgets håndterer visualisering av data i form av grafer. Når brukeren oppretter en widget vil man trykke på ett plusstegn i den ferdiglagde griden. Videre får man opp ett to-delt vindu hvor man skriver inn en tittel og velger datatype som vi har hentet fra datakilden på forhånd. Når du har valgt datatype, vil du få en liste med sjekkbokser på høyre side, hvor du kan huke av hvilke maskiner du vil monitorere. Du vil også få muligheten til å spesifisere utseende til grafen i dette vinduet. Vi ønsker å benytte oss av Google Charts som løsning for visualiseringen av data. Det er allerede mange charts ferdig definert i API et, med flere unike instillinger per chart. Vi kunne dratt fordel av et rent HTML5-basert visualiseringssystem, men de fleste av disse bibliotekene var enten ikke modulære eller effektive nok. Mange av HTML5-bibliotekene vi fant kunne vi holde lokalt. Fordelene med et lokalt visualiserings-bibliotek er at vi slipper å forholde oss til en tredjepart for visualiseringen. 36

43 Brukergrensesnitt Brukergrensesnittet på applikasjonen skal være minimalistisk, oversiktelig og moderne med lyse farger og rette linjer som ikke tar fokuset vekk fra informasjonen i dataene. Selve designet er tenkt representert med CSS3, fordi man da enkelt kan skreddersy designet ved behov. Innholdet i et dashbord skal plasseres i et rutenett med flyttbare bokser man kan justere størrelsen på. Det skal benyttes JavaScript for å skape en dynamisk brukeropplevelse. Menyen skal kun representeres ved en knapp, som når trykket på, utvider innholdet i menyen inn i synsfeltet på dashbordet. Dette gjør at menyen ikke tar unødvendig plass når man ikke har bruk for innholdet i den. Menyen vil inneholde lenker til de samme brukerområdene for alle brukere, blant annet: ny widget, egne dashbord, favoritter, profil og logg ut. Administratorer vil i tillegg ha en lenke administrasjon som peker på siden for administrasjonsinstillinger. Nettsiden med egne dashbord vil inneholde en liste med lenker til alle dashbordene en bruker har. Favoritter inneholder en lenke til alle dashbordene til andre brukere som brukeren har valgt å bokmerke. Profil vil inneholde informasjon om brukeren og administrasjonsinstillinger vil inneholde applikasjonsinnstillinger som kun skal kunne endres av superbrukere. Dette inkluderer valg av autentiseringsmekanisme og hvor åpent systemet skal være: Åpent - alle kan registrere seg og bruke tjenesten Administrert - alle kan registrere seg, men må bli godkjent av en administrator for å kunne bruke tjenesten Lukket - Ingen nye registreringer Ved å trykke på ny widget vil en boks dukke opp i skjermbildet. Denne vil inneholde valg brukeren må ta for å avgjøre hva som skal bli vist og hvordan det skal bli presentert. 37

44 Visualiseringen av data Widgetene i dashbordet kommer til å bestå av flere forskjellige Google Chart diagrammer som vil visualisere utvalget av informasjon brukeren definerer i ny widget dialogen. Valg av diagrammer vi mener vil være naturlige i løsningen er: Speedometer kan vise hvor stor del av en ressurs blir brukt, for eksempel hvor stor prosentandel av CPU som blir brukt. Dette diagrammet kan kun vise informasjon i sanntid og kan dermed ikke vise historisk statistikk. Den er også utstyrt med fargefelt, for å kunne indikere faretegn. Fargefeltene må settes manuellt. Tidslinje diagram kan vise tidslinjen til en eller flere ressurser, for eksempel til visning av hvilke VMer som har levetid når. Linjediagram er diagrammet som er mest allsidig og er en av de få diagramtypene som enkelt kan vise flere datakilder over tid. Dette er samme type grafer som OpenTSDB benytter seg av, og vil også være primære for dette systemet. Søylediagram er diagrammet som kan vise mengdeforhold veldig enkelt. For fremtiden kan man for eksempel velge å se antall VMer for hver tenant. Kakediagram er en annen måte å se mengdeforhold på. Diagrammet er enkelt å forstå, når man lett ser hvem som tar størst del av kaken. Kan for eksempel brukes til å se hvilken CPU som jobber mest. Figur 10: Utvalg av grafer fra Google Charts 38

45 4.3. Implementasjonen Systemet gir brukeren kontroll over sin egen monitorering. Selv om det har blitt en del endringer underveis, har vi satt sammen en solid monitoreringsløsning som gir brukeren mulighet til å se dataene de selv vil se. Man har fått muligheten til å dele brettene med andre, og løsningen skal være enkel å videreutvikle. Videre i delkapitlet vil vi gå detaljert inn på hvordan det ble, og hvor vi har modifisert i henhold til planleggingen Domenenavn og lokasjon Oppdragsgiver har gått til innkjøp av domenet Perspect.io. Dette navnet ble valgt fordi det sier noe om perspektiver som er viktig for vårt produkt. Løsningen er testet på Alto, skyen vi henter data fra på Høgskolen i Oslo og Akerskus, og blir kjørt på en virtuell Ubuntu server. Løsningen ligger klar til bruk, og kan benyttes allerede nå. Kildekoden blir også flyttet over på Github, for videre utvikling Programvare Perspect.io er en Node.js applikasjon, og behøver derfor Node.js og NPM (Node Package Manager) installert på systemet. Node.js kjører, i likhet med Java, applikasjonen i et virtuelt miljø og NPM installerer applikasjons-avhengigheter som ikke allerede finnes på systemet. MongoDB er databasen brukt av Perspect.io og kjøres på samme maskin som Node.js. Siden prosjektet er hostet på Github er det en fordel å ha Git installert. Man kan da klone Perspect.io fra Github til sin lokale maskin eller server og enkelt håndtere versjonering. All programvaren som kreves er gratis og kan kjøre på alle plattformer. Vi valgte å bruke Ubuntu Server som operativsystem for stabiliteten av en Linux server, samtidig som all programvaren finnes i Ubuntu sitt programvarebibliotek. 39

46 Systemfiler Frontend Filnavn Beskrivelse #Linjer /build/ Gruntfile.js package.json /build/src/ api/ app/ util/ widget/ app.js common.js /public/css/ highlight.js.css markdown.css style.css /public/js/ app.js app.min.js /public/lib/ bootstrap/ gridster/ jquery/ toastr/ async.js Grunt konfigurasjon Selve Grunt konfigurasjon Metadata for applikasjonen Javascript som skal behandles av Grunt Kommunikasjon mot API et Applikasjonslogikk Hjelpeklasser Visualisering og logikk for widgets Applikasjons-GUI Generelle funksjoner Stilark for applikasjonen Syntax highlighting i dokumentasjon CSS for API-dokumentasjon CSS for selve applikasjonen JavaScript til applikasjonen All applikasjonslogikk Minified applikasjonslogikk JavaScript bibliotek Bootstrap jquery Gridster - Grid verktøy jquery Core jquery Toastr - Varslingsystem Verktøy for asynkrone JavaScript /public/ index.html HTML til applikasjonen

47 Filene app.js og app.min.js er helt like, men app.min.js er en «minified» versjon. Dette vil si at den er krympet til minst mulig størrelse for å redusere antall bytes besøkende sin nettleser må laste ned. Det er blitt benyttet Grunt for å først slå alle applikasjons- JavaScript i «build»-mappen sammen, som resulterte i app.js. Til slutt er det igjen blitt brukt Grunt for å forminske resultatet, som produserte app.min.js som til slutt inkluderes fra index-filen. Gruntfile.js inneholder logikken som spesifiserer hvordan denne byggeprosessen skal utføres. Figur 11: Flowchart av frontenden Backend Filnavn Beskrivelse #Linjer /api/ docs/ model/ routes/ /core/ router/docstore.js router/index.js router/route.js user.js /node_modules/ API-funksjonalitet API dokumentasjon Mongoose databasemodeller API endepunkter Kjernefunksjonalitet Indeksering av dokumentasjon Factory for API endepunkter API enderpunkts-klasse Logikk for registrering av bruker Node.js moduler

48 async/ bcrypt/ consolidate/ ejs/ express/ highlight-js/ marked/ MD5/ mongoose/ passport/ passport-google-auth/ passport-http/ passport-local/ request/ winston/ /tsdb/ client/cache.js client/parser.js client/query.js route.js /util/ config.js helpers.js http.js logger.js Async Bcrypt-kryptering av passord Express template engine middleware Ejs templating språk Express, web-rammeverket Syntax highlighting Markdown templating språk MD5 for opprettelse av hash Håndterer databasekommunikasjon Autentiserings-middleware Google autentisering HTTP autentisering Lokal autentisering Fleksibel HTTP klient Logging Kommunikasjon mot OpenTSDB Caching av resultater Sortering og indeksering av data Spørringsklasse til OpenTSDB API endepunkt for generell spørring Verktøy Applikasjonskonfigurasjon Hjelpefunksjoner HTTP klient Loggføringsklasse / server.js Prosjektroten Applikasjonen/Bootstrap

49 Figur 12: Flowchart av backend Tilkoblinger For å levere JSON gjennom API et og HTML gjennom frontenden benytter vi oss av Node.js-modulen «Express». Dette er et kjent og mye brukt webapplikasjonsrammeverk for å raskt kunne lage fleksible web-løsninger i Node.js. All kommunikasjon mellom API et og databasen håndteres av modulen «Mongoose», som leverer et grensesnitt til MongoDB. Man oppretter database-modellene i Javascript, 43

50 Mongoose vil tilpasse og oppdatere MongoDB automatisk. Dette gir oss mye «gratis» med tanke på databasevedlikehold, siden Mongoose gjør mye av denne jobben for oss. For at backenden kan hente data fra OpenTSDB brukes modulen «Request». Dette er en enkel, men veldig fleksibel HTTP klient Databaser MongoDB er databasen som lagrer alle dataene til applikasjonen. Den inneholder brukerdata, dashbord og metadata for alle widgets. Samtidig cacher den data vi henter fra OpenTSDB. Siden det er CPU-messig kostbart å utføre et HTTP kall til OpenTSDB, samt analysere dataene og sende de videre til brukeren, vil det være veldig lønnsomt å cache opp ferdig-prosesserte data, spesielt om flere brukere spør etter de samme dataene innenfor et tidsrom. Vi valgte å cache opp data i 60 sekunder før de blir invaliderte, siden det omtrent var tidsintervallet mellom nye data i OpenTSDB Autentisering Node.js-modulen vi bruker for brukerautentisering heter Passport. Dette er en modulær autentiserings «middleware» som veldig enkelt kan kobles på Express, webrammeverket applikasjonen kjøres på. Siden Passport er modulær behøver man kun integrere kjernemodulen «passport» inn i applikasjonen, deretter kan man enkelt legge til og fjerne Passport autentiserings-tilbydere etter behov. Vi valgte å bruke OAuth2 autentisering gjennom Google som standard for applikasjonen. Det positive ved å bruke Google som autentiserings-leverandør er at mange har en Google konto, noe som gjør applikasjonen veldig tilgjengelig. Samtidig legger vi sikkerhetsansvaret over i Google sine hender, vi slipper å bekymre oss over å sikre sensitiv brukerinformasjon. 44

51 Figur 13: Autentisering ved bruk av Passport og Google OAuth Perspect.io har også støtte for vanlig brukernavn og passord autentisering i tilfellene hvor det å bruke en ekstern leverandør er utelukket. Passordene blir saltet og hashet med bcrypt-algoritmen, en treg men sikker krypteringsalgoritme Dashbord Det første en ny bruker blir møtt med ved innlogging er en knapp som oppretter et nytt dashboard. Alt brukeren behøver å fylle ut er et navn slik at vedkommende kan kjenne det igjen senere. Inne i dashbordet kan brukeren legge til nye widgets, og justere plassering og størrelsen på disse. Ved endringer i dashbord-griden lagres layout en serialisert til databasen. En ny widget inneholder ingen data under opprettelse, men ved å trykke på tannhjulet på widgeten kan brukeren bestemme hvilke data som skal hentes og hvordan de skal presenteres. Denne informasjonen lagres ikke på dashbordet, men på selve widgeten. For å bytte tittel på en widget trenger brukeren kun å klikke på tittel-teksten for å redigere den. Et dashbord kan inneholde det vi har kalt «globale variabler». Dette er variabler som gjelder for et enkelt dashbord og alle widgets det inneholder. Ved å benytte seg av globale variabler kan man for eksempel si at alle widgets for et dashbord skal vise statistikk fra maskin X. 45

52 Figur 14: Linjediagram visualisert med Google Charts Hvis man da setter at X er lik maskin01 vil alle widgets vise statistikk for maskin01. Endrer man variabel X til å være maskin02 vil alle widgets nå vise data for maskin02. Dette gjør at en bruker kan bruke samme dashbord til å vise informasjon fra forskjellige kilder uten å endre hver enkelt widget. Globale variabler kan endres «on the fly» ved å overskrive de i URLen, for eksempel perspect.io/#board ?X=maskin08. Dashbord kan deles mellom brukere kun ved å videreformidle URLen, men det er kun eieren som kan gjøre endringer på det. Andre brukere kan bokmerke dashbord de ikke eier, så de enkelt kan finne tilbake til det senere. 46

53 Kapittel 5: Analyse Endre informasjon Finnes det funksjonalitet for å kunne endre dataen i enkeltvisningen? Ja. Man har mulighet til å endre hvilken informasjon man vil se ved å spesifisere rålenken fra OpenTSDB man ønsker å benytte deg av. Finnes det funksjonalitet som viser hvilke data man kan ha? Nei. Det finnes ikke per i dag noen måte til å se alle typer data du kan hente. Det er grunnet implementasjonen av rålenkene fra OpenTSDB. Man kan velge hvilke data man vil se direkte i timeseries databasen. Vi anerkjenner også problematikken rundt å vise samtlige datastrømmer uten å lage et system som ville blitt desto mer rotete, desto mer dataen skalerte. Kan man legge til flere datakilder? Ja. Systemet skal være modulært nok til å kunne hente data fra flere systemer. Hvorvidt det blir aktuelt for en bruker er et annet spørsmål. Slik som det er for Høgskolen i Oslo og Akershus, har man mulighet til å lagre nesten hva som helst i OpenTSDB, så tanken er; finnes det i OpenTSDB, kan det visualiseres i Perspect.io. Kan flere datakilder være representert i samme enkeltvisning? Nei. Vi har ikke mulighet til å presentere data fra flere datakilder i samme enkeltvisning. Dette fordi vi gikk for OpenTSDB-lenker som informasjonsstrøm. Man kan dog bruke timeseries databasen til å samle all informasjon man innehar. Så dette punktet blir eliminert ved at man burde pushe dataene sine inn i en database. Har oppdatering av datakilden en hensiktsmessig frekvens? Ja. Vi cacher dataene vi får fra kilden, og cachingen har fått en levetid på 60 sekunder. På denne måten kan ikke datane som blir sett i produktet være mer enn 60 sekunder gamle. 47

54 Endre presentasjon Finnes det funksjonalitet for å endre utseende av dataene? Ja. Vi har implementert to forskjellige måter å visualisere data på i vårt system, som vi kaller for widgets. Man kan vise råbilder fra OpenTSDB og visualisere data med Google Charts. Finnes det funksjonalitet for å endre størrelse på en datavisning? Ja. Implementasjonen av Gridster gjør at en bruker enkelt kan endre størrelsen på en widget. Finnes det funksjonalitet for å endre posisjonen på en datavisning? Ja. Gridster har også funksjonalitet til å lage også et rutenett med posisjonslagring. Kan man lage en samling av datavisninger? Ja. Gridster har gjort at man enkelt kan vise flere widgets i samme dashbord. Endre perspektiv Kan man lage «et bilde» med dataen? Ja. Man har mulighet til å lage «et bilde» med dataene. Det er egentlig bare kreativitet som vil sette grenser her. Vi har også lagt inn globale variabler. Dette vil si at man kan dynamisk vise sine «bilder» til andre, men med informasjon de vil syntes er interessante. Har man mulighet til å vise sine samlinger av data til andre? Ja. Siden dashbordene i produktene ikke har noen privat aksess, kan man enkelt dele sine samlinger med andre. Dette gjøres enkelt ved å dele en link. Finnes det funksjonalitet for å hente frem gamle perspektiver? Ja. Perspektiver, eller dashbord, vil lagres og knyttes til bruker. Man vil finne alle perspektiver man har laget, som man ikke har valgt å slette, under «my boards» i hovedmenyen. 48

55 Kapittel 6: Diskusjon I analysen beskrives to underpunkter fra planen som ikke er blitt implementert. Bakgrunnen for dette er endring i ønsker fra oppdragsgiver, noe som resulterte i et sterkere visualiseringslag for leveransen enn opprinnelig planlagt. Endringene kan anses å svekke totalen noe, da løsningen kun ble testet mot en datastrøm og ikke mot flere datastrømmer som var opprinnelig plan. Vi kunne nok med fordel hatt en annerledes måte å hente datakilde på, og underveis i utviklingen dukket akkurat dette spørsmålet opp. Strukturerte versus ustrukturerte data vil derfor bli diskutert og utdypet nedenfor, innunder Fleksibilitet Produksjon Visualisering av data Google Charts er vår visualiseringsløsning av data. Ved testingen av teknologien så vi raskt at dette var et online bibliotek. Dette er nok det største problemet med biblioteket, da det i et miljø med strengt lukkede intranett ikke vil kunne brukes. Underveis fant vi også ut at det ikke var noen direkte støtte for JSON, og at Google Charts til tider var kresent på hvordan det ville ha data matet inn. Ved flere anledninger har vi sendt inn rett formatert data og fått formaterings-feilmeldinger tilbake. Samtidig er dette biblioteket til dels dårlig dokumentert, når all informasjon om spesifikke egenskaper og funksjoner ikke befinner seg på samme plass. Vi kunne med fordel byttet ut Google Charts med et annet visualiseringsverktøy. I implementasjonen fant vi to verktøy som så ut til å gjøre jobben godt: FusionCharts [13] og CanvasJS [14]. FusionCharts ser avansert ut, men innehar mange av de grafiske fremstillingene vi var ute etter. Dessverre koster FusionCharts penger, og ble i vårt tilfelle avvist grunnet 49

56 dette, men burde helt klart være et alternativ som burde undersøkes nærmere ved oppdatering og videreutvikling av produktet. CanvasJS er utformet mer modulært enn Google Charts, og vi ville fått kildekoden lokalt. Dette ville løst problemet rundt intranett scenarioet, og hadde fungert som et sikkerhetsnett mot en potensiell avvikling av tjenesten. CanvasJS er lisensiert under Creative Commons Attribution-NonCommercial 3.0 License[15], noe som gjør at dette kunne blitt brukt både for oppdragsgiver samt vår prototype. Vi hadde til funksjonell widget-struktur da vi fant dette biblioteket og valgte derfor å ikke bytte bibliotek så sent i prosessen. Visualiseringsløsningen til Perspect.io er modulær, som vil si at det skal være enkelt å bytte Google Charts med et annet visualiseringsverktøy. Widget Ett av kravene var at det skulle være flere måter å fremstille data på, og i utgangspunktet var planen å legge ved fem widgets: Linjediagram, søylediagram, speedometer, tidslinje og kakediagram. Hovedfokuset ble å få implementert linjediagrammet først, da dette er mest fleksibelt med tanke på presentasjonen av data. Prioritet nummer to ble stolpediagram, da dette har enkelt for å vise forholdet mellom mengder. Det ble kun disse som ble implementert, samt råbilde av grafen produsert av OpenTSDB. Det burde helt klart vært implementert flere av de planlagte widgetene for en mer gjennomført og komplett datavisning. Hovedfokuset var å ferdigstille det viktigste, men hadde vi hatt mer tid ville vi lagt til kakediagram og speedometer. Igjen støtter produktet seg på modulariteten, som gjør det enkelt å legge til ytterligere widgets dersom det er ønskelig. 50

57 Dashbord Opprinnelig var planen å gjøre Gridster responsiv selv, og vi utviklet derfor en prototype for dette. Ved manuell størrelsesendring av nettleser måtte man laste inn siden på nytt for å få størrelsene oppdatert. Underveis i utviklingsprosessen fant vi et rammeverk, kalt gridster-responsive [15] som løste problemet, og vi valgte derfor å gå for dette istedenfor. Ved videre arbeid viste det seg at gridster-responsive hadde mangler i forbindelse med størrelsen på bokser, men dette fant vi ut av alt for sent i utviklingen. Mangelen går ut på at noen bokser kan blir for små ved visning i små vinduer, som for eksempel på mobiltelefoner. En fremtidig løsning på dette vil være at bokser posisjonerer seg under hverandre når skjermen er under en viss størrelse. Dette er definitivt noe vi ville implementert med jquery ved videre arbeid. Perspect.io funger nå fint både på PC og tablet, og det er hovedsakelig de skjermstørrelsene oppdragsgiver vil benytte seg av. Et av kravene til oppdragsgiver var at systemet skulle være brukervennlig. Å måle brukervennlighet burde vært gjort med brukertesting. Vi er likevel klare over noen mangler ved funksjonaliteten i vårt system vedrørende brukervennlighet. Vi skulle hatt hover-tekst 11 på alle knappene våre, som ga en forklaring på hva knappen var til. Samtidig kan det være vanskelig å forstå hvordan redigeringsknappen fungerer, da det er lite forklaring rundt den. Per nå er det bare redigeringsmodus av og på, og ingen muligheter for å avbryte endringer, annet enn ved å laste inn siden på nytt. Dette kunne vært løst ved at en boks sklir ned, da man trykker på redigeringsknappen, med «Lagre» og «Avbryt» knapper. Brukergrensesnittet er minimalistisk slik at datavisningen blir satt i fokus. Det er uinteressant for en sluttbruker å ha mange støyende elementer i perspektivet sitt, og 11 Hover: Musepekeren er over et element og en gitt funksjon kjøres - her ved at et element med tekst dukker opp. 51

58 det løser Perspect.io på en god måte - med små knapper og en meny som sklir inn fra siden. Måten man legger til widgets har endret seg fra designfasen, hvor vi så for oss å ha en grid full av tomme bokser, med mulighet til å legge ting i de. I dagens løsning legger man til widgets dynamisk i rutenettet, for deretter å fylle dem med data fra visualiseringsløsning. Dette vil vi si gir minimalt med støyende ekstra elementer. Backend Perspect.io API et har vært gjennom noen små endringer siden designfasen. Vi forestilte oss opprinnelig at vi skulle velge alle TSDB-parameterne i et grensesnitt og sende denne listen til API et for deretter å opprette en spørring mot OpenTSDB. API et skulle dynamisk lage en OpenTSDB-URL av disse parameterne og deretter utføre spørringen. Etter møte med oppdragsgiver kom vi fram til at det heller skulle være mulig å lime inn en ferdig OpenTSDB-URL som skulle lagres på en widget. Dette istedenfor å sende generelle spørringer til API et for data kunne vi dermed sende en dataforespørsel til en enkelt widget. Siden en widget kjente til sin egne OpenTSDB-URL behøvde ikke API et lenger opprette denne. Denne designendringen førte også til at vi, i applikasjonen, slapp å ta hensyn til alle mulige parametere i OpenTSDB - vi trengte kun å lage et mottak for en URL. Dette forenklet utviklingsprosessen vår og skapte mindre forvirring under opprettelse av widgets. Produktet skulle opprinnelig innehatt ett varslingssystem. I samtale med veileder og kunde ble vi fort enige om at dette var en vanskelig oppgave. Hvordan kan man lage varsling for noe man ikke vet hvordan ser ut? Her er vi inne på fagfeltet om kunstig intelligens, noe prosjektdeltakerne har svært lite kunnskap om. Den absolutt enkleste implementasjonen av et varslingsystem hadde vært en modul til widgets. Denne modulen kunne analysert dataene som ble sendt til widget, og det ville 52

59 vært sluttbrukeren som selv satte opp reglene for hva som skulle skjedd dersom en verdi traff over en gitt terskel. Brukerdefinert varsling bør fremdeles være mulig å implementere uten for mye utviklingsarbeid. Ut ifra et totalbilde hvor vi tok hensyn til alle prioriteringer og tilgjengelig tid, valgte vi i samråd med oppdragsgiver å ikke utvikle et varslingssystem, da det ville innebære utviklingen av en helt ny modul. Autentisering Vi har laget et modulært autentiseringssystem som allerede har støtte for autentisering gjennom Google eller lokalt med brukernavn og passord. Hvis det i fremtiden skulle være ønskelig å legge inn autentisering mot OpenStack Keystone 12, som ville gitt alle brukere i skyen mulighet til å logge seg på Perspect.io, behøver man kun å legge inn Passport sin Keystone-modul. Vi ser på autentisering mot Google som en god og sikker løsning. Siden de er et så stort selskap, med så utrolig mange brukere, er det nesten en selvfølge at de har høy sikkerhet på autentiseringsmekanismene sine. Det at Google har så mange brukere gjør det også sannsynlig at de fleste allerede har en Google konto. Dermed slipper man å fylle ut informasjon for å opprette en egen konto til vår applikasjon. Vår løsninger bygger på noen basisfunksjoner for administrasjonskontroll. Dette inkluderer aktivering og deaktivering av brukere og tildeling av administrative rettigheter. Det er den første brukeren som registrerer seg som får eier-rettigheter til applikasjonen. Disse eier-rettighetene er det ikke mulig å flytte til en annen bruker, og er noe vi helst skulle hatt implementert. En annen administrativ funksjon som mangler er det å kunne slette brukere. Administratorer kan deaktivere brukerkontoer, slik at brukeren ikke kan logge seg inn, men brukerkontoen forblir fortsatt i systemet. 12 Keystone: Autentiseringsløsningen til OpenStack 53

60 Koblingen mot OpenTSDB Vi fant en enkel måte å kjøre brukertesting på, som skal kunne gi oss veldig god innsikt i hvor eventuelle problemer ligger. Dette kalles hallway usability testing[16], hvor man rett og slett går ut på gangen for å få en helt tilfeldig person til å prøve produktet ditt. Ett problem som oppstod, var å finne tilfeldige personer som hadde nok kunnskaper om OpenTSDB, slik at testingen kunne gjennomføres uten at utviklingsgruppen påvirket hvordan testobjektet brukte systemet. Vi kunne dog testet endring av presentasjon og perspektiv, men da vi anså at dataendringen var en såpass stor del av produktet, valgte vi å ikke utføre en brukertest. Vi ser her at vårt sluttprodukt, er knyttet sterkt opp mot OpenTSDB, og det er egentlig å forvente. I denne runden hadde vi ikke tid til å lage et system som passet til absolutt alt, det skal med noen enkle grep være mulig å legge dette laget på toppen av andre Time Series Databaser også. Fleksibilitet Ved begynnelsen av utviklingen av Perspect.io så vi for oss et system som på egenhånd kunne avgjøre hvilke data som var relevante for brukeren. Vi hadde planlagt svært konfigurerbare widgets, med mulighet for å velge mellom alle tilgjengelige datastrømmer og tilgjengelige valg for den strømmen, både visuelle og funksjonelle. Fordi OpenTSDB kun lagrer ustrukturerte tag-baserte dataobjekter viste dette seg å være umulig kun ved bruk av OpenTSDB. Vi kunne for eksempel hente ut hvor høyt prosessforbruk det var på maskin 1, 2 og 3, men vi kunne ikke vite hvilke brukere som ble påvirket av disse verdiene. Planen var opprinnelig å opprette en kobling mellom Perspect.io og OpenStack Nova, for å strukturere OpenTSDB sine ustrukturerte data. Med denne koblingen kunne vi for eksempel, fra OpenTSDB, fastslått at maskin 3 var under høy last. Fra OpenStack Nova kunne vi deretter funnet ut hvilke brukere som var tilknyttet maskin 3 og utført en handling basert på denne informasjonen. Under et møte med oppdragsgiver ble vi enige 54

61 om at dette ville føre til flere avhengigheter enn nødvendig, samtidig som det havnet utenfor kravspesifikasjonen. C2MS, nevnt i bakgrunn, har en lignende strukturert løsning som vi forestilte oss i utgangspunktet, og det ble på Cloudcom fastslått at den ikke skalerer. Både vi og oppdragsgiver ønsket å holde systemet så fleksibelt som mulig, som førte til at det ble naturlig å lage systemet på en fundamentalt annerledes måte. Vi kunne ha valgt å løse det på den opprinnelig planlagte måten, men vekten av argumenter for en bredere løsning, og faktumet at ingen hadde prøvd å gjøre det på samme måte som oss, var tung. Fordelene med å holde seg til datastrukturen til OpenTSDB, en ustrukturert tag-basert datamodell, er at det gjør systemet ekstremt fleksibelt og skalerbart. Ulempene er at applikasjonen ikke kan fastslå betydningen og konsekvensene dataene har for en bruker, brukeren må selv definere hva dataene betyr. Det hadde allikevel vært interessant å se hvordan en fundamentalt annerledes løsning kunne blitt laget. Det ville blitt enklere for en sluttbruker å benytte seg av systemet, men var i denne runden ikke hensiktsmessig i forhold til hvilket bruk oppdragsgiver så for seg Hvordan har det gått? Forberedelser Resultatet oppfyller de fleste kravene, med tanke på hva oppdragsgiver ønsket seg. Vi burde satt av mer tid på å gjøre research på eksisterende løsninger. Hovedproblemet var at vi brukte mye tid på å sette oss inn i hvordan OpenStack fungerte, for å se på hva vi kunne hente ut og visualisere. Vi hadde også liten kunnskap om OpenTSDB. Hadde vi visst og skjønt i begynnelsen hvor stor rolle OpenTSDB ville spile i prosjektet vårt, og at vi i stor grad kun kom til å hente data fra dette systemet, hadde vi brukt mye mer av forberedelsestiden på å se på 55

62 styrker og svakheter ved det. Hadde vi for eksempel vært klar over begrensingen i antall metrics (30) man kan hente fra systemet på en gang, hadde vi lagt ned planene om å hente alle fra OpenTSDB mye raskere enn det vi gjorde. Vi brukte også mye tid på å se spesifikt hva andre løsninger monitorerte og hvordan de visuelt løste det, men dette er også grunnen til at vår løsning er så visuelt sterk i forhold til andre løsninger. Samtidig har vi da fått lite tid til å teste mot andre datakilder, selv om systemet er klart til å brukes sammen med andre datakilder også. Nye teknologier Som nevnt tidligere er det mange teknologier som har hatt kort fartstid, og som er nye for oss. Node.js er en av de, og er en teknologi som er under stadig utvikling. Mange av oss har brukt JavaScript og jquery til overliggende visuelle funksjoner før, men veldig lite logisk programmering. Det har tatt tid å venne seg til måten JavaScript ønsker å lage asynkronisere kall ved å sende med callback-funksjoner 13 til oppgavene man ønsker skal bli gjort. I noen tilfeller under utviklingen har koden blitt dårlig og rotete, med callbacks i callbacks. Vi har dog klart å skrive om koden for å gjøre den mest mulig forståelig i slike tilfeller. Dette er spesielt viktig med tanke på modulariteten vi ønsker å gi. Sent i utviklingsprosessen kom også OpenTSDB 2.0 med støtte for JSON. Dette hadde vi ikke tid til å se på da vi allerede var godt i gang med backenden. Dette vil også igjen, grunnet modulariteten i Perspect.io, være enkelt å integrere. Samtidig har vi metoder for å ta hånd om JSON som kan bli brukt til andre, fremtidige, deler av systemet. 13 Callback: En funksjon a du sender som parameter til en funksjon b, som blir kjørt når funksjon b er ferdig. 56

63 Utviklingsmetode Vi valgte å benytte oss av Kanban for å kunne utvikle smidig. Det viste seg likevel at det å utvikle synkront skulle bli utfordrende. Da vi i tillegg jobbet med teknologier som er nye for mange av oss, var det problematisk å se for seg nøyaktig hvordan alt skulle bli til slutt. Dette har ført til at mye kode har blitt skrevet om igjen flere ganger. Det klareste problemet oppstod da widgets skulle utvikles, og vi var usikre på formateringen på dataen vi vi ville få ut av backend-api et. Her skulle det vise seg å bli mange revideringer. Kanban er et solid system for smidige utviklingsprosesser. Vi burde vært mye mer detaljert i oppgavene som ble lagt på vårt arbeidsoppgavebrett, vi ser i ettertid at oppgavene var for generelle. Hadde vi hatt mer spesifikke oppgaver, ville vi sett fremgangen mye bedre samtidig som at vi lettere kunne holdt oss oppdaterte på hvordan de andre lå i utviklingen av sine respektive områder. Vi er fornøyde med at vi hadde Kanban som en slags ryggrad for prosjektutviklingen. Da programmeringsnivået på prosjektdeltakerne også er varierende ble det vanskelig å fastsette reelle tidsrammer. Sosialt medium På et tidspunkt ble det sagt at «vi lager facebook for statistikere», og det kan være sant når vi ser på all funksjonaliteten vi tidlig ønsket å ha med. Vi så for oss et rangeringssystem basert på «likes», deling via personlige meldinger, eller ved profilbesøk. Meldingssystemet kunne vært veldig givende for en uerfaren sluttbruker for å diskutere og få hjelp med de forskjellige løsningene. Dette er noe vi ville prøvd å implementere ved senere arbeid, hvor man selv kunne velge hva som skulle vært offentlig og hva som skulle vært privat. Det ble ikke utviklet i denne runden siden det ikke er kritisk for systemet. Egendefinerte fargetemaer er en funksjon som hadde vært bra å ha i produktet, med tanke på at vi ikke har tatt høyde for personer som er svaksynte eller har andre 57

64 funksjonshemninger. Menyen kan potensielt være vanskelig for svaksynte å se, men utformingen, og farger utenom dette bør fungere selv for de med svakere syn. Fargetemaer ville også tilført en enda større følelse av egendefinert konfigurasjon. Her kunne man for eksempel valgt farger på dashbordbasis, og enkelt kunne vite hvilket perspektiv du så ved hjelp av fargekoding. Men dette er så langt ned på listen over ting som er viktige å ha med, at det ble utelatt Samfunnsnytten Problemet rundt visualisering av store mengder data er problematisk å begripe ved noe annet enn en prototype. Et alternativ kunne vært å studere en eksisterende løsning for å dokumentere eventuelle svakheter ved denne. Informasjonen dette dog ville gitt er at det er et verktøy som gir deg liten, eller stor, nok frihet i visualiseringen av data. En arbeidsmetodikk vi burde benyttet oss mer av er brukerundersøkelser, for å fastsette om dette egentlig er et viktig felt. Byggesteinene i produktet vårt er jo nettopp denne påstanden: At dette er et viktig. Men da vi allerede hadde fastsatt at vi skulle levere et produkt til en oppdragsgiver uansett, var det uansett naturlig å fokusere på oppdragsgivers ønsker. Hvilke konsekvenser ville en endring i problemstillingen utgjort? Om vi ikke hadde hatt den opprinnelige problemstillingen vår, men trukket inn OpenTSDB i problemstillingen, ville vi endt opp med ett helt annet produkt, og en helt annen vinkling på systemet. Med problemstillinger som Hvordan visualisere overvåkningsprosessen til OpenTSDB, ville produktet vårt kun blitt knyttet til OpenTSDB brukere. Målet var å utvikle et visuelt lag på toppen av alle steder hvor det er lagret big data. Dette for å kunne hjelpe alle som sliter med visualiseringen av disse dataene gjennom for spesifiserte systemer, eller for mange applikasjoner å forholde seg til. 58

65 Perspect.io vil ikke tvinge brukere til å bytte ut din eksiterende infrastruktur, den vil kun gi deg muligheten til å visualisere på toppen av dataene de allerede har Problemområdet Vi ville gi verden ett nytt verktøy å jobbe med, for å enklere kunne analysere sine data. Man skulle kunne endre utvalget av informasjonen man ønsket å se, man skulle kunne endre hvordan den ble fremstilt, og man skulle kunne endre perspektivet man kunne se dataen i. Ut fra problemområdet vi så, vil hver enkelt bruker nå ha mulighet til å se sammenhengen av dataene, på en måte som passer dem. Vi har laget et visualiseringslag som på en enkel måte settes på toppen av alle dataene man skulle ha. En av de få tingene vi ikke har løst, er å dekke alle mulige utfall av teknologi som benyttes for datasamling i dag. Lisensieringen på produktet gir mulighet for at flere uavhengige kilder kan bygge videre på verktøy. Vi har utviklet systemet på en nokså universell plattform. Prototypen er allerede klar for bruk med OpenTSDB, og man kan skrive egne moduler som passer hvert enkelt system. Problemområdet er definitivt aktuelt da Google nettopp har kjøpt StackDriver [17]. Perspect.io tilbyr muligheten til å bruke mindre ressurser på å ta systematisk gode beslutninger. Figur 15: Endelig løsning 59

66 60

67 Kapittel 7: Konklusjon På tross av problemer vedrørende datavisualisering, og store endringer i løsningsoppbygging, har vi kommet frem med et produkt. Noen mangler finnes, med varslingssystem og meldingssystemer, men allikevel er det produsert et robust produkt, med nye teknologier som også kommer til å utvikles videre. Node.js kommer stadig med nye oppdateringer, og JavaScript er stort. Disse teknologiene kommer antageligvis til å leve lenge, og dette bidrar til en lys fremtid for Perspect.io. Systemet er modulært, og skal være enkelt for andre å sette seg inn i. Man skal med enkelhet kunne lage nye moduler, for å gjøre ønskede endringer eller rett og slett legge til ny funksjonalitet. Ved å gjøre prosjektet tilgjengelig på github kan hvem som helst som skulle være interesserte ha mulighet til å forbedre systemet, samtidig som vi i utviklingsgruppen kan fortsette å bygge på det. Perspect.io fungerer nå som et visualiseringslag på toppen av en Time Series Database, og brukeren har fått full kontroll over hvordan visualiseringen skal være. Oppdragsgiver har gitt signal om at det er ønskelig å ta produktet i bruk, både for forskningen på Alto, skyen på Høgskolen i Oslo og Akershus og for kommende elever der. Spørsmålet som blir stilt i slutten av et hvert utviklingsprosjekt er: har vi reddet verden? Det har vi helt klart ikke, men vi har tilført noen egenskaper for å enklere kunne se morgendagens informasjon - uten å trenge å vite noe om den i dag. 61

68 62

69 Kilder & Litteraturliste [1] OpenTSDB, nettsted [Online]. Tilgjengelig fra: [2] Martin Hilbert et. al. (2011, Apr). The World s Technological Capacity to Store, Communicate, and Compute Information, Science [Online]. 332, (6025), Hentet fra: [3] Ganglia, nettsted [Online]. Tilgjengelig fra: [4] Gary A. McGilvary et. al. (2013, Des). C2MS: Dynamic Monitoring and Management of Cloud Infrastructures, Cloud Computing Technology and Science(CloudCom), 2013 IEEE 5th International Conference on [Online]. 1, (1), Hentet fra: [5] RRDtool, nettsted [Online]. Tilgjengelig fra: [6] Cacti, nettsted [Online]. Tilgjengelig fra: [7] New Relic, nettsted [Online]. Tilgjengelig fra: [8] OpenStack, nettsted [Online]. Tilgjengelig fra: [9] Nova, nettsted [Online]. Tilgjengelig fra: [10] Sensu, nettsted [Online]. Tilgjengelig fra: [11] node-js-vs-apache-php-benchmark code.google.com. [Online] Tilgjengelig fra: [Besøkt: Feb. 21, 2014] [12] MySql vs MongoDB performance benchmark moredevs.ro.[online] Tilgjengelig fra: [Online] [Besøkt: Feb. 21, 2014] [13] FusionCharts, nettsted [Online] Tilgjengelig fra: [14] Canvas.js, nettsted [Online] Tilgjengelig fra: [15] Creative Commons Creative Commons Attribution-NonCommercial 3.0 License 63

70 creativecomons.org. [Online] Tilgjengelig fra: [16] gridster-responsive github.com. [Online] Tilgjengelig fra: [17] Joel on Software [Online] Tilgjengelig fra: [18] StackDriver, nettsted [Online] Tilgjengelig fra 64

71 Vedlegg A: Prosessdokumentasjon A.1. Redegjørelse Temabakgrunn Alto, skyen på Høgskolen i Oslo og Akershus, er bygget av forskningsgruppen der på huset. Hovedpersonen bak skyen er Kyrre Begnum, førsteamanuensis, og er også vår oppdragsgiver. Det hele startet med at oppdragsgiver hadde ett problem. Han hadde en sky, men visste ikke om den fungerte. Tanken var at dette kunne være et passende bachelorprosjekt, for noen skyinteresserte studenter, og det var her vi kom inn. Vi ble presentert skyen av veilederen vår Alfred Bratterud, høgskolelektor, sammen med OpenStack og OpenTSDB, og detaljer rundt dette. Det ble tidlig fastslått at vi skulle lage en overvåkningsløsning for skyen, og at det var en del mangler i eksisterende løsninger. Det viktigste for oppdragsgiveren virket å være å kunne se så mye data på en gang som overhodet mulig. Og få satt dataene i sammenheng, altså se flere datakilder på samme tid, i samme vindu. Slik begynte prosjektet vi nå refererer til som Perspect.io. Problemstilling Vi skulle merke at å skrive en problemstilling til dette prosjektet skulle bli vanskelig fort. Etter en del forslag hvor skyen var nøkkel i problemet, kom vi frem til at vi kunne lage en mer generell løsning, som ikke bare kunne overvåke sky. Siden systemet skulle vise seg å visualisere data fra en database som er indeksert på tid, og det var eneste begrensing, kunne man fremstille mye mer enn kun skyhelse. Problemet var ikke lengere hvordan overvåke en sky brukervennlig og effektivt, men mer i banene av hvordan man kan overvåke data som vi ikke vet hvordan ser ut og som endrer seg hele tiden. Istedenfor å overvåke sky, ble det helt generelt overvåking av big data. 65

72 Omfangsbegrensning Målet vårt for denne oppgaven var å lage overvåkningsløsningen for skyen. Vi hadde mange ideer. Og vi sammenlignet de påtenkte widgetene, som delbart materiale. Vi så for oss en side med widgets, hvor man kunne se hvem som hadde laget den, hva den monitorerte, og hvor mange «likes» den hadde fått. Vi ville lage ett form for sosialt medium, for skyovervåkning. Meldingssystem kom fort på banen, at hadde vært interessant å ha, for å snakke om widgets, og for enkel deling av dem. Etterhvert tenkte vi at det samme måtte være mulig å gjøre med påtenkte brett, men først av alt måtte vi ha data å vise frem i widgeter på brett. Så det var naturlig å begynne her. I samtale med veileder og oppdragsgiver ble vi også enige om at dette blir «nice-tohave-features». Fordi vi har hatt disse tankene, skal det ikke være vanskelig å implementere dette, men når alt kom til alt, ble det ikke tid til å lage dataovervåkningsens facebook. Prosesshistorie Gruppen hadde sitt første møte med oppdragsgiveren og veileder den På dette møtet presenterte oppdragsgiver hva han ønsket at gruppen skulle lage. Oppdragsgiver skulle ha rollen som project owner, mens veilederen skulle være rådgivere angående teknologier som skulle brukes, og en sterk fagperson. Vi gikk så igjennom hvilken type teknologi som kunne være aktuell å bruke. Det ble også fastsatt at vi ønsket å gjøre et forsøk på forskningsrapport når både oppdragsgiver og veileder hadde god kontroll på hvordan dette var utformet. Vi så på det som en mulighet til å forberede oss til masteroppgaven om to år, de av oss som skulle det. 66

73 Vi brukte deretter tiden over jul på å se på teknologi som kunne være relevant og få enda bedre oversikt over OpenStack, og tenke på hvordan en sluttløsning kunne bli. Det første møtet vi hadde på nyåret gikk vi igjennom hva oppdragsgiver ønsket seg av produktet og hvordan vi man skal skrive en introduksjon i en masteroppgave. Vi begynte snarlig å produsere det første kapitlet. I det andre møtet i januar så fikk vi en grundigere gjennomgang av hvordan Alto, skyen på Høgskolen i Oslo og Akershus, er bygd opp og hvordan opentsdb fungerte. Det var viktig at vi fikk vite hvordan alt fungerte for å lage APIet. Etter møtet så ble arbeidoppgave ble fordelt i oppgavene backend, design og widgets. Backenden består av å lage et API som kommuniserer med OpenTSDB og sender ferdig prosessert til frontend. Designet går ut på å lage rammen som siden skal kjøres i, samt implementere nødvendige biblioteker for å tilrettelegge for ryddige visning av flere ting. Vi ønsket også å gjøre designet responsivt. Vi så for oss noen små applikasjoner som kjørte i noen bokser som skulle visualisere data, vi valgte å kalle de for widgets. Vi leste oss opp på mer teknologi, og fant ut etter testing hvilke teknologier vi ønsket å benytte oss av. Videre begynte vi å skrive neste kapittel i rapporten, på tross av manglende tilbakemelding på første kapittel. Det var i midten av mars vi var i samtale med oppdragsgiver om tilgang til noen flere ressurser i skyen for å kunne visualisere data fra virituelle maskiner. Her ble det store diskusjoner rundt ustrukturerte og strukturerte data. Vi hadde tatt utgangspunkt tidlig i at det ville bli en form for trestruktur. Når endringen kom så betydde dette store omveltninger i programmet. 67

74 Vi begynte omstruktureringen av hele produktet vårt med en gang, men det var en mye tyngre prosesse enn hva vi trodde, og vi var offisiellt bak skjema. Vi måtte få gjort ferdig produktet fortest mulig. I mai så begynte det å haste å få ferdig rapporten, siden koden hadde blitt såpass avansert og resultater lot vente på seg, begynte store deler av gruppen å fokusere på rapportferdigstiling når vi innså at dette begynte å bli minst like kritisk som produktet. Beslutningsprosess Måten vi har håndert problemer og valg underveis er ved den godt anerkjente demokratiske avstemningen. Siden vi gruppemedlemmenes antall var partall, hadde vi en valgt gruppeleder som i de tilfeller det skulle være nødvendig hadde dobbelt stemme. Dette var noe vi i liten grad brukte når gruppen stort sett var enige om hvordan ting måtte gjøres når alle hadde fått vist frem sitt syn på saken. Vi som gruppe var interessert i å høre på de som hadde erfaring med like situasjoner, eller teknologier fra før og deres stemme ble derfor vektet tyngre de stedene det var naturlig. Utgått arbeid Hele vårt system har blitt gjort om for å passe tidsstemplet data. Den alpha versjonen vi hadde klart i mars, er det mindre deler av som er representert i det endelige produktet. Vi hadde fler widgets, vi hadde ett annerledes backend api, og vi hadde enda ikke sett nødvendigheten til et frontend-api. Disse delene har blitt omarbeidet, eller kastet når de ikke har vært aktuelle for produktet lengere. Bidragsytere Kyrre Begnum underviser på masternivå på Høgskolen, og har stilt alle sine oppgaveskrivings seminarer tilgjengelige på nett. Dette har gitt oss muligheten til å se 68

75 gode eksempler på hvordan en forskningsrapport skal bygges opp, og vi har brukt mye tid i disse videoene. Det viktigste er at vi har kunnet brukt tid på dette når det har passet for oss i en hektisk hverdag. Samtidig har vår veileder Alfred Bratterud veiledet på en annerledes måte enn hva vi forventet på forhånd. Han har stilt en mengde kritiske spørsmål og har hjulpet oss til å forme produktet, slik vi ønsker, og som fremdeles er teknisk godt. Kombinasjonen av disse fagsterke menneskene, og den hjelpen vi har fått fra dem, har hjulpet oss igjennom en fremmed verden av forskning, skytjenester og abstrakte modeller. Utarbeiding av artikkelen De første utkastene til de første kapitlene ble skrevet i sammarbeid, med nokså lik arbeidsmengde. Men det blir ofte slik at når man utvikler ett produkt, og ønsker seg gull, vil alltid de som er sterkest i faget jobbe med å perfeksjonere det fysiske systemet. Dette førte til at noen av deltakerene har bidratt til de produktkritiske delene av rapporten, mens resten har formet artiklen og styrt prosjektet i den retningen det måtte for å komme i mål. Det er gruppen som har formet artiklen som i har kontroll-lest, og vært fagpersoner i de redaksjonelle banene. Vi valgte å bruke Google Drive til utvikling av rapporten, når dette onlinesystemet innehar mange av de egenskapene vi kjenner fra GIT. Vi får muligheten til å samtidig kunne redigere samme dokument i sanntid, og kan fortløpende legge kommentarer knyttet til spesifikkedeler av teksten. 69

76 A.2. Milepælsplan Figur 16: Aktivitestplan - forberedelse Figur 17: Aktivitestplan - implementering 70

77 Alle våre grener har samme milepæler og er delt opp etter rekkefølge: 1. Informasjon tilegnet 2. Protoyp produsert 3. Implementert med de andre grenene 4. Ferdigstilt produkt 71

78 A.3. Prosjekstyringsapplikasjoner Netbeans Et gratis utviklingsmiljø (IDE) for programvareutviklere som gjør det mulig å utvikle integrerte applikasjoner for Java, PHP, C++, HTML5 og andre platformer. Dette verktøyet er nyttig til utvikling av produkter fordi det har høy funksjonalitet uansett hvilke språk man utvikler i, og spesielt om man har flere språk å forholde seg til er dette et stort pluss. Google Drive En gratis og nettbasert programvarepakke med ulike programmer tilpasset kontorbruk som f.eks. Microsoft Office. Flere brukere kan opprette, dele og redigere dokumenter samtidig i sanntid. Samtidig er det lett å lagre dokumenter både på og fra egne PC er i flere forskjellige filformater. yed Et kraftig cross-platform diagramprogram som er raskt, effektivt og kan kjøres på blant annet Windows, Linux og Mac OS. Programmet kan tegne mange forskjellige type diagrammer. Trello En gratis webapplikasjon for projektstyringsformen kanban. Prosjektene er representert med dashbord som inneholder kort med oppgavelister. Disse oppgavelistene blir da flyttet mellom kortene, oftest da mellom opprettede «To Do», «Doing» og «Done». Vagrant Vagrant er en gratis applikasjon som veldig enkelt setter opp lokale utviklingsmiljøer. Ved å fortelle Vagrant hvilken «oppskrift» den skal følge, setter den opp en virtuell maskin og installerer ønsket operativsystem og programvare. Vagrant gjør det også smertefritt å reinstallere utviklingsmiljøet hvis man har eksperimentert og vil begynne fra scratch. 72

79 Vedlegg B: Produktdokumentasjon B.1. Brukerdokumentasjon 1.1 Logge inn Det første som møter brukeren når brukeren kommer til siden for første gang er en innloggingsmeny slik som den nedenfor. Her vil brukeren bli bedt om å logge inn med en Google konto. Hvis brukeren ikke har dette så må dette opprettes hos Google, ved å tryke på «Opprett konto». 73

80 1.2 Logge ut Trykk først på dette ikonet er oppe i venstre hjørnet. En ny meny vil da bli synlig på venstre side av skjermen, helt nederst på denne menyen vil det være et valg som heter «Log out». Når brukeren trykker på denne knappen så vil brukeren bli logget ut. 1.3 Legger til første dashbord Først så åpner man menyen som man har gjort tidligere og deretter velger man alternativet som heter «New board» helt øverst i menyen. 74

81 Her trenger man bare å skrive inn navnet man ønsker det nye dashbordet skal ha også trykke på ikonet «Create board» nederst i høyre hjørnet av bildet. Når dette er gjort så får man det bildet man ser under som er et tomt dashbord. 1.4 Legge til widget Nå når man har laget et nytt dashbord så kan man legge til widgeter på dette dashbordet. Dette gjøres ved først å på ikonet som har en pluss i seg, vist nedenfor. 75

82 Når man har trykket på denne så vil det bli laget en tom widget som legger seg på dashbordet til brukeren. Denne widgeten er brukeren selv nødt til å fylle med innhold. Figueren under er av en tom widget. 1.5 Gir nytt navn til widget For å gi nytt navn på widgeten man har laget så er det bare å trykke på teksten hvor det står «Click to edit title». Nå er det bare å viske ut den eksisterende teksten og skrive inn navnen på widgeten. 1.6 Legge til innhold i widgeten. Først må man slå på muligheten til å endre innholdet i den tomme widgeten. Dette gjøres ved å trykke på dette ikonet. 76

83 Fargen på ikonet vil gå fra blått til gult og det er da mulig å endre innholdet. Det er nå tre nye ikoner oppe til høyre på widgeten. For å endre på inngoldet så må man trykke på den midterste ikonet som har et tannhjul i seg. Når man trykker på dette ikonet får man opp en ny meny slik som den vist på figuren under. Her velger man hvilken widget type man ønsker også limer man inn en opentsdb url og trykker på «Save widget». 1.7 Flytter widget Trykker på «Grid editing» ikonet og deretter holder musepekeren over widgeten og hvis musepekeren ser slik ut. Så er det bare å trykke og holde inn venste museknapp også trekke widgeten dit brukeren ønsker å ha den. Når brukeren er ferdig med å plassere widgetene så må brukeren huske å skru av «Grid editing» ved å trykke på ikonet slik at posisjonene blir lagret. 1.8 Endrer størrelse på widget 77

84 Må bare trykke på «Grid editing» ikonet også plassere musepekeren nede i høyre hjørne av widgeten slik at musepekeren endrer seg til musepekeren på figuren under. Nå er det bare å holde inn venstre museknapp og dra musepekeren i en retning for å gjøre størrelsen større eller mindre. Når man er ferdig så er det bare å trykke på «Grid editing» ikonet igjen. 1.9 Fjerner widget Når man skal slette en widget så må man trykke på «Grid editing» ikonet igjen og deretter trykke på «Delete widget» ikonet oppe i høyre hjørnet på widgeten, figuren under viser hvordan ikonet ser ut. Når ikonet er trykket på så vil widgeten bli slettet og man er bare nødt til å trykke på «Grid editing» for å lagre endringene Deler dashbord Hvis man er på dashbordet man ønsker å dele med andre så kan man gjøre dette ved å dele linken med andre Bytte dashbord Når man skal bytte dashbord så åpner man menyen til venstre og trykker på «My boars» alternativet. Da vil man få opp alle dashbordene man har laget og det er bare å trykke på det dashbordet man ønsker å bruke. Nedenfor ser man hvordan listen med dashbord ser ut. 78

85 1.13 Endre globale variabler Globale variabler går ut på at man kan endre den samme variabelen i alle widgetene ved å skrive navnet på variabelen og hva den skal endres til. For å få tilgang til globale variabler så trykker man på ikonet som heter «Global variables». Man vil da få opp en meny som er over alle widget slik som den vist under. Her setter man inn navnet på variabelen i venstre og hva variabelen skal være til høyre. Når man har gjort det så er det bare å trykke enter så har man lagt inn variabelen. 79

86 B.2. Administrasjonsdokumentasjon 2.1 Endre registreringspolicy Man åpner menyen til venstre og velger alternativet som heter «Administration». Da får man opp en meny som den vist nedenfor. For å endre registreringspolicy så er det bare å velge en radioknapp inder «Registration» til venstre i bildet. «Closed» betyr at ingen nye brukere kan registrere seg. «Open» betyr at alle kan registrere seg og begynne å bruke dashbordet med en gang. «Managed» betyr at man kan registrere seg, men man kan ikke gjøre noe før administratoren har aktivert den nye brukeren. 2.2 Brukerhåndtering Man går på administrasjons siden og trykker på fanen som heter «Users». Da får man opp en liste lik den som er vist nedenfor. Her kan man aktivere og deaktivere brukere ved å trykke på knappen lengst til høyre på bildet. Man kan også gi og ta ifra andre brukere admin rettigheter ved å trykke på knappen som er til venstre for activate/disable knappen. 80

87 2.3 Endre Autentiseringmåte Man kan velge om man skal bruke google sitt autentisiering verkøy for brukerne eller en HTTP løsning. Dette gjøres på samme sted hvor man endrer registreringpolicy. 81