Dashbord

én skjerm bygd for å besvare et spørsmål som går igjen

Hva det er

Et dashbord er en side med paneler, der hvert panel er en spørring gjort om til et bilde, og der helheten er lagt opp slik at du kan lese av tilstanden til noe uten å spørre noen. Mange norske team sier bare dashboard, og ordet brukes om hverandre med dashbord. Prometheus kaller det samme for konsoller i sin egen dokumentasjon, og på kontoret heter det gjerne «skjermen på veggen». Grafana beskriver dashbordene sine som ett eller flere paneler ordnet i rader eller faner, som gir et raskt overblikk over informasjon som hører sammen. Hvert panel er i Grafanas ordbruk beholderen for en visualisering bygd på en spørring mot en datakilde. Kilden kan være en tidsseriedatabase, en SQL-database, et API eller en helt vanlig CSV-fil.

Panelene finnes i en håndfull former, og hver form svarer på sitt spørsmål:

  • En linje over tid viser en utvikling: minnebruk det siste døgnet, forespørsler per minutt den siste uka.
  • Ett stort tall svarer på «hvor mye akkurat nå».
  • En måler viser en verdi innenfor et kjent område, f.eks. brukt diskplass av den totale.
  • En tabell lister det som trenger oppmerksomhet, én ting per rad.
  • En statuslampe sier oppe eller nede.

De fleste gode dashbord nøyer seg med to eller tre av disse formene, valgt ut fra spørsmålet, og svært få paneler av hver.

På en nettside er panelene vanlige deler av et brukergrensesnitt, og W3Cs ARIA Authoring Practices Guide beskriver hvordan hver del skal oppføre seg for den som bruker tastatur eller skjermleser. Faner bytter mellom visninger og viser ett panel om gangen. En tabell er et statisk rutenett av rader og celler, mens et grid er den interaktive varianten du flytter deg rundt i med piltastene. Meter er mønsteret for en verdi innenfor et definert område, og alert er en kort, viktig melding som fanger oppmerksomheten uten å avbryte det leseren holder på med. En måler skrevet etter meter-mønsteret oppgir både området og avlesningen som tekst:

<div
    role="meter"
    aria-label="Disk used"
    aria-valuemin="0"
    aria-valuemax="100"
    aria-valuenow="72"
    aria-valuetext="72% (31 GB free)"
></div>

Det som skiller et dashbord fra naboene, er at det venter på å bli sett. Et varsel oppsøker et menneske når noe krysser en grense. En rapport er et øyeblikksbilde som lages når noen ber om det, og som deretter står fast. Et dashbord er levende, og det er verdt nøyaktig like mye som oppmerksomheten noen gir det.

Hvorfor det er viktig

Et dashbord gir teamet én felles avlesning av hvordan ting står til. Uten det blir det samme spørsmålet besvart av den som tilfeldigvis har en terminal åpen, på sin egen måte, og to personer midt i en hendelse kan bruke minutter på å oppdage at de så på forskjellige tall. Med det starter samtalen fra det samme bildet, og folk som aldri ville skrevet en spørring selv, kan se hvordan systemet har det.

Det korter også ned veien fra «noe er galt» til «akkurat denne delen er gal». Prometheus anbefaler i veiledningen om konsoller ett dashbord per tjeneste, der hvert viser latens og feil for tjenestene den snakker med. Da kan du starte øverst i treet og følge de dårlige tallene nedover til tjenesten som lager dem. Et dashbord som er lagt opp etter systemets egen struktur, gjør den veien til et par klikk.

Prisen er reell. Hvert panel kjører spørringen sin ved hver oppdatering, på hver skjerm som har det åpent. Hvert panel er dessuten en påstand som noen må holde sann når tjenesten bak det får nytt navn, deles opp eller legges ned. Et dashbord med førti paneler bærer førti slike påstander, og de fleste av dem blir aldri lest. Før dere legger til et panel, er det derfor verdt å spørre hvem som skal se på det, og hva vedkommende skal gjøre annerledes når tallet endrer seg.

Slik ser det ut i praksis

Selskapets første dashbord for observerbarhet begynte med å samle inn CPU, RAM, disk og temperatur fra eksterne Linux-servere over SSH, Docker-containere medregnet. En andre versjon flyttet over til Grafana og Prometheus, og panelene ble valgt sammen med DevOps- og utviklingsteamene: CPU-utnyttelse, minnebruk, oppetid for tjenester og API-latens. Dashbordet gikk på den store TV-skjermen på kontoret, der alle som gikk forbi kunne se hvordan produksjonen hadde det, og varsling ved terskelbrudd gikk side om side med det. Teamene oppdaget og løste hendelser 40 % raskere.

Et senere overvåkingsdashbord på Grafana og Prometheus peker ut det som betydde mest: metrikker som sa noe, i stedet for pyntetall som ser travle ut og forteller ingenting. Varslingsterskler ble deretter satt på nettopp de metrikkene og vist der teamet ville se dem mens det fortsatt var tid til å handle. Teamet gikk fra brannslukking til å fange opp problemene mens de ennå var små.

På en vert med 464 MB minne får det samme spørsmålet et annet svar. Sju skrivebeskyttede roller gjengir den levende verten som Markdown-rapporter ved behov, med tilgang, trafikk, metrikker, sikkerhet og mer, fordi en metrikkstack ikke ville fått plass og heller ikke ville betalt for seg om den fikk det. Regelen de styres etter, passer like godt for ethvert dashbord: skriv bare ut tall som kjøringen har målt. En rapport som fyller et hull med et sannsynlig tall, er verre enn en som lar hullet stå tomt.

Hvor det går galt

Et dashbord kan se friskt ut og likevel villede, og som regel kommer det av hva som ble satt på det.

Hvert tilgjengelige tall havner på skjermen. Det er fristende å vise alt et system kan måle. Prometheus advarer om at det gir konsoller så tette at selv en ekspert sliter med å lese dem, og foreslår høyst fem grafer per konsoll og høyst fem linjer per graf. Begynn med de feilene som er sannsynlige, og vis det som skiller dem fra hverandre.

Pyntetall tar plassen. Totalt antall forespørsler siden lansering går bare oppover, og antall registrerte brukere sier lite om i dag. Slike tall ser travle ut og endrer ingen beslutning. Gi panelet heller til et tall som ville fått noen til å handle hvis det flyttet seg.

Ett dashbord skal tjene alle. Det en vakthavende ingeniør trenger om natten, nemlig hva som er ødelagt, er noe annet enn det en utvikler trenger mens en funksjon bygges, f.eks. hvor mange som treffer et bestemt grensetilfelle. Prometheus sier rett ut at ett sett konsoller sjelden dekker begge behovene, og at to sett fungerer bedre.

Fargen bærer hele budskapet. En rad med røde og grønne prikker sier ingenting til den som ikke skiller rødt fra grønt, og heller ingenting på en svart-hvitt-skjerm. Suksesskriterium 1.4.1 i WCAG 2.2, på nivå A, sier at farge ikke skal være det eneste visuelle middelet for å formidle informasjon; legg til et ord, en form eller en plassering. Etter 1.4.11, på nivå AA, trenger de delene av en graf som er nødvendige for å forstå den, et kontrastforhold på minst 3:1 mot fargene ved siden av. Tynne pastellfargede linjer på hvit bakgrunn bommer ofte på det kravet.

En måler antyder et tak som ikke finnes. Meter-mønsteret i APG er laget for en verdi innenfor et definert område, og mønsterets egen merknad fraråder å bruke det for en verdi uten noe meningsfullt maksimum, eller for fremdrift. Forespørsler per sekund har ikke noe naturlig tak, så en måler for dem finner opp et og får en helt vanlig travel time til å se ut som en krise. Bruk en linje over tid i stedet.

Skjermen venter på en seer som har gått hjem. Et dashbord på en TV på kontoret klokka tre om natten er det ingen som ser på. Problemer som krever et menneske, hører hjemme i varsler, og Prometheus anbefaler i veiledningen om varsling å varsle på symptomene brukerne merker, og å lenke hvert varsel til konsollen som hjelper deg å finne komponenten som svikter. Varselet tilkaller noen, og dashbordet er der de lander.

Les mer

Ordliste