Denne artikkelen er skrevet av de flinke studentene vi har hatt hos oss våren 2020.

I dette prosjektet har vi laget et KPI-dashboard for Aplia. KPI står for "Key Performance Indicator" og blir i denne sammenheng brukt som et verktøy for å kunne måle verdier som dagens antall supportsaker, oversikt over månedens utnyttelsesgrad, og live statusoppdatering for bedriftens servere. 

For dashboardet brukes Python-rammeverket Django, og til frontend brukes Vue.js.

I denne artikkelen ønsker vi å prate om de forskjellige tjenestene vi har ordnet integrasjoner opp mot, i tillegg til utfordringer vi har møtt på veien og eventuelle løsninger vi har kommet med.

Sektordiagram med visning av antall supportsaker

 

Takket være et godt API (Application Programming Interface), med god dokumentasjon så har det ikke vært store utfordringer annet enn det vi har klart å skape selv.

Til å starte med så gjorde vi alle kallene synkront, men etter at kallene mot API'et vokste, så økte forespørseltiden i tillegg. Vi ble anbefalt å bruke en av to ting, det var enten "Webhooks" eller å gjøre kallene asynkrone. Vi endte opp med det sistnevnte. For dette tok vi bruk to biblioteker, som er "Aiohttp" og "Asyncio". Denne artikkelen ble også brukt som referanse, som da ledet oss til de to tidligere nevnte bibliotekene som er godt dokumentert og det var mange eksempler å sette tenna i for inspirasjon.

For Zendesk som håndterer alt som har med support og gjøre, er det behov for og kunne hente ut forskjellige statuser av "tickets". Dette er et eksempel på hvordan man kan lett foreta flere spørringer uten å øke all verdens på responstiden. Det som skjer er at alle forespørslene blir fyrt av samtidig og ettersom de blir ferdig med innhenting av det man er ute etter, blir lagt til i en liste som blir levert som et resultat til videre bruk.

Kode

 

Når det kommer til bruk av enten forespørsler mot et API eller Webhooks, så er det ikke et godt svar for enten eller, siden begge løsninger kommer med sine fordeler og ulemper.

Ulemper ved bruk av Webhooks kan være:

  • Nedetid for tjenesten Dette kan være et problem siden man ikke får noen resultater tilbake, men kan unngås ved sjekk av resultat eller annen løsning som sjekker om det er en tilkobling eller ikke.
  • Ventetid Ved mange Webhook-forespørsler så kan dette settes i kø sammen med brukerforespørsler, som kan resultere i redusert brukeropplevelse, og i verste fall timeouts.
  • Ressursforbruk Dette vil komme an på mengden av Webhook-forespørsler man har som kommer inn, men dette kan medføre i uønsket ressurstopping grunnet mye å prosessere.

Fordeler med Webhooks:

  • Du blir gitt resultat tilbake når endringer skjer Om endring skjer, vil det i løpet av ca. 30 sekunder registreres og resultatet vil da bli gitt til deg.
  • Trenger ikke å utføre periodiske kall Ved bruk av Webhooks trenger man ikke å tenke på å utføre kall i det hele tatt. En annen positiv ting er det og komme seg unna en eventuell rate limit.

Ulemper for asynkrone kall kan være:

  • Tomt resultat tilbake Ganske selvforklarende, men det er fortsatt en mulighet når det blir sendt en forespørsel mot et API hvor resultatet tilbake er tomt. Dette kan lett unngås ved og hente siste registrerte resultater selv om dette ikke skulle stemme overens med tiden man mener et resultat skal eksistere.
  • Må utføre periodiske kall For å kunne hente resultater må man kontinuerlig spørre. Dette kan åpne en mulighet for og overskride API'et sin rate limit.

Fordeler med asynkrone kall:

  • Du kan kjøre flere forespørsler samtidig og få en mengde resultater Muligheten for å kunne kjøre X antall forespørsler og sette sammen et godt utdypende resultat.
  • Bruker trenger ikke å vente for at UI skal lastes Ved bruk av asynkrone kall så vil brukergrensesnittet kunne lastes og bli klart mens kallene blir utført på siden, og vil da kunne bli fylt på i etterkant i deres respektive komponenter når arbeidet er ferdig.

Timeføring og visuell presentasjon

Tripletex er et skybasert økonomisystem bygget opp av ulike moduler som kan settes sammen etter behov. Noen av modulene er timeføring, regnskap, ansattoversikt og mye mer. For dashboardet var det et ønske fra de ansatte i Aplia om å vise utnyttelsesgraden til utviklerne. Det er også blitt hentet ut fødselsdager, slik at det popper opp en hyggelig melding når noen har bursdag.

Det ble brukt en del tid på å forstå seg på selve API'et deres som er meget godt dokumentert, men massivt for å si det direkte. Noe som er svært forståelig med tanke på hvor mye funksjonalitet de har. Men det er helt på starten av dokumentasjonen deres at all forvirring kan dukke opp. Men så fort man får oversikt og kontroll på nøkkelen en admin generer til deg, nøkkelen man får av support, og får brukt de to kombinert til å opprette en "session token", først da kan man virkelig komme i gang!

For å kunne hente riktig timer fra Tripletex så er første trinn å kunne få tak i timene for korrekt dato. Dette blir utført ved å gjennomføre tre sjekker, nytt år, ny måned og inneværende måned. Med de tre følgende sjekkene får man tak i et endepunkt som brukes for å gi korrekt antall timer for situasjonen man befinner seg i.

Kode

 

Etter å ha hentet timene for nåværende dato er det på tide å sortere timene for ansatte som jobber administrativt, og utviklere som har fakturerbare timer. Siden Tripletex sitt API tilsynelatende ikke har et endepunkt for og enkelt kunne hente ut kun utviklere og kun administrativt personell, ender det opp med å gjøre litt luking selv. Denne løsningen har en liste med ID'er over administrativt personell som blir brukt for å kunne skille mellom hvilken timer som skal hvor. Dette er en måte å gjøre det på, men som krever vedlikehold om det skulle komme en ny ansatt på administrativt. Enkelt å fikse, men unødvendig.

Kode

 

Med timene i orden, så er det på tide for en visuell presentasjon av utnyttelsesgrad for utviklerne:

 

Diagrammer kan veldig lett fikse en visuell presentasjon, men det å lage en fra bunn av kan fort bli en oppgave som sluker en del timer. For å unngå dette ble et Javascript-bibliotek tatt i bruk. Dette biblioteket har en god variasjon av diagrammer, og det kommer med mulighet for skreddersøm. Biblioteket kan du finne på Apexcharts og er veldig enkelt å sette opp.

Datadog - Serverstatus og overvåkning

Datadog er en overvåkningstjeneste som kjøres på en server og leverer tilbake data via en Cloud-tjeneste. Dette kan være logger, sporinger eller metriske data som load, iowait, cpu, minne og diskplass. Datadog har over 60 unike systemsjekker, hvor disse også kan ha forskjellige type aggregering som min, max, average og sum. Tjenesten kan derfor settes opp ganske egendefinert for å dekke visse behov. Dokumentasjonen er innholdsrik og tilbyr det meste man er ute etter. De har også et API som brukes til å hente ut dataene som er rapportert tilbake til Cloud.

Data hentes ut ved at Vue-appen sender asynkrone kall mot Datadog sitt API på en intervall på ett minutt gjøres dette via Python-biblioteket asyncio. Vi får tilbake KPI'er som CPU, diskplass, load, iowait og minnebruk for hver host vi har registrert. Hver punkt går igjen en algoritme som forteller om verdier går over aksepterte terskler. Disse blir satt på en liste i dashboardet og support blir varslet, slik at de kan finne ut hva som er galt og fikse problemet så fort som mulig.

Oversikt over serverstatus

 

Pingdom, den enkleste helsesjekken

Pingdom er en tjeneste som sender ping til websider/servere for å sjekke om disse er oppe, satt på pause eller er nede. Det inneholder også et varslingssystem som sender ut varsel via SMS, e-post og push-notifikasjoner hvis noe ikke responderer.

Uthenting av data

Her gjøres en synkron spørring mot pingdom API'et for å hente ut alle statusene til hostene en forholdsvis enkel spørring. Data loopes imellom og legges i en dictionary med servernavn og status, og returneres til front-end. Hvis noen av serverne er nede, blir denne listen slått sammen med listen fra Datadog, slik at disse vises i listen over servere med feilmelding.

Vuex

Vuez er et state management-bibliotek for Vue.js som alle components og child components enkelt kan hente og sette variabler i. Dette er tatt i bruk fordi det er oversiktlig, enkelt å bruke, og man slipper å passere data mellom flere komponenter fr det kommer på rett sted. 

Dataene som kommer tilbake fra pingdom blir deretter sendt til Vuex hvor det settes som state variabler, så kan server status component enkelt hente ut disse.

Værstasjon og hvorfor bruke det?

Netatmo er en leverandør av flere ulike produkter til hjemmet, som for eksempel overvåkningskamera, værstasjon eller smart brannvarsler. Det som var nødvendig for kontoret til Aplia var en egen "Weatherstation". Denne fiffige saken er en "base" hvor det da kan kobles flere moduler opp imot for kunne lese informasjon som for eksempel CO2, temperaturer og luftfuktighet. En kjekk ting å vite er at "basen" har funksjonalitet på lik linje som en modul, slik at man kan få informasjon fra den i tillegg. Til vårt bruk var det nødvendig med en modul for kontorlandskapet, møterommet og det mindre kontoret i 5. etasje. Det endte opp med å få inn data for en dag eller to, også ble det hjemmekontortilstander. Nå kan man i hvert fall med sikkerhet si at luften på kontoret per dags dato er ganske solid.

En grunn til å bruke et produkt som det Netatmo leverer er for å få oversikt over luftkvalitet. Temperatur og luftfuktighet er også gode ting å vite, men når man sitter på kontoret en hel arbeidsdag, kan luften bli dårlig, noe som kan resultere i redusert effektivitet blant de ansatte. Noe som er viktig å vite er hvordan luftkvaliteten blir mål og om verdien er god, OK eller dårlig. Kort og konsist er verdiene og legge merke til alt under 1000 PPM (parts per million), mellom 1000-2000, og alt over 2000 PPM. Du kan lese mer utdypende informasjon om dette i denne artikkelen, men det man kan ta med herfra er at over 1000 PPM vil man begynne å merke redusert effektivitet pga. døsighet eller hodepine.

Når værstasjonen og modulene skulle settes opp på kontoret var det noen problemer som oppstod, mer spesifikt, å synkronisere modulene opp i mot basen. Etter litt om og men ble de til slutt synkronisert. Annet enn det så er det veldig ut av eksen å begynne å bruke de.

På den litt mer tekniske siden er API dokumentasjon veldig kort og direkte, noe vi personlig liker veldig godt, men det å navigere seg til den spesifikke dokumentasjonen var en smule vrient. Her var det også en del frem og tilbake før vi endelig fant veien, men dette kan også ha vært en brukerfeil fra vår side.

Værdata i XML-format

Yr.no tilbyr en veldig solid løsning for å kunne hente værdata og ta i bruk dette slik man selv ønsker. Yr.no tilbyr forskjellige løsninger som "Time for time", eller "Varsel for 6 timers perioder". Vedlig genial, gratis tjeneste for de som ønsker å sin egen løsning på værmeldingen. De tilbyr også egne løsninger som er veldig ut av eksen og klar-til-bruk-løsning, men som tilbyr lite mulighet for skreddersøm.

For dashboardet ble det valgt å ta i bruk "Time for time" hvor vi får værdata fra Yr.no i XML-format og som vi igjen kan leke med slik vi ønsker.

Yr.no har egentlig vært veldig enkelt å arbeide med. I starten var målet å hente informasjon som kunne brukes opp mot API'et til Meterologisk Institutt (MET). Første problemet var Yr.no som har gitt symbolene sine egne navn, som var veldig enkelt og greit å ta i bruk og forstå, mens MET har sin egen navngivning. Heldigvis så har Yr inkludert disse navnene i API'et, men det nye problemet som da dukket opp er at "tags" og data i Yr sitt XML-dokument er på norsk, og det MET tilbyr er på engelsk. Løsningen på dette problemet ble å droppe Yr sine bilder, med deres navngivning, og legge det til som ressurser i prosjektet.

Dark-mode

Applikasjonen har også en dark-mode. Yr-komponenten henter ut soloppgang og solnedgang hvor disse blir satt i Vuex og applikasjonen bruker disse verdiene til å finne ut hvilken modus som skal aktiveres.

Dashboardet fremvist i egen dark-mode

 

Vi har da kommet oss igjennom alt vi ønsket å dele. Noen ting som kan være kjekt å vite fast i her er:

  • Utnytt samarbeidet man har med makkeren sin.
  • Gode medarbeidere er prima.
  • Les dokumentasjon nøye, det vil gjøre livet ditt enklere.
  • Ikke finn opp hjulet på nytt, det finnes mange "open source"-bibliotek å utnytte på nett.

Vi er fortsatt litt grønne når det gjelder prosjekter som dette, så om det er noe dere lesere er enige eller uenige i så fyr løs og gi oss gjerne et annet perspektiv på det. Det kan bli lærerikt.