Dashboard

en skärmbild byggd för att besvara en återkommande fråga

Vad det är

En dashboard är en sida med paneler, där varje panel är en databasfråga som har gjorts om till en bild, upplagd så att vem som helst kan läsa av läget utan att fråga någon. Samma sak går under andra namn: dokumentationen för Prometheus kallar dem konsoler, och i ett team heter den kanske bara ”tavlan” eller ”skärmen på väggen”. Grafana beskriver sina dashboards som en eller flera paneler ordnade i rader eller flikar som ger en överblick över information som hör ihop, och varje panel som behållaren för en visualisering byggd på en databasfråga mot en datakälla. Källan kan vara en tidsseriedatabas, en SQL-databas, ett API eller en vanlig CSV-fil.

Panelerna finns i en handfull former. En linje över tid visar en trend: använt minne det senaste dygnet, anrop per minut den senaste veckan. Ett enda stort tal svarar på ”hur mycket just nu”. En mätare visar ett värde inom ett känt intervall, t.ex. använt diskutrymme av det som finns. En tabell listar det som behöver uppmärksamhet, en sak per rad. En statuslampa säger uppe eller nere. De flesta bra dashboards använder två eller tre av formerna, valda efter frågan de ska besvara, och mycket få paneler av varje.

På en webbsida är panelerna vanliga delar av ett gränssnitt, och ARIA Authoring Practices Guide från W3C beskriver hur var och en ska bete sig för den som använder tangentbord eller skärmläsare. Flikar växlar mellan vyer och visar en panel i taget. En tabell är ett statiskt rutnät av rader och celler; ett grid är den interaktiva varianten, som du flyttar dig i med piltangenterna. Mönstret meter gäller ett värde inom ett definierat intervall, och mönstret alert gäller ett kort, viktigt meddelande som fångar uppmärksamheten utan att avbryta det läsaren håller på med. En mätare som följer meter-mönstret bär sitt intervall och sin avläsning som text:

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

En dashboard väntar på att någon ska titta, och det skiljer den från grannarna. Ett larm kommer till en människa när något passerar en gräns. En rapport är en ögonblicksbild, tagen när någon ber om den och sedan fast. En dashboard är levande, och den är precis så mycket värd som den uppmärksamhet någon ger den.

Varför det spelar roll

En dashboard ger ett team en gemensam avläsning av läget. Samma fråga besvaras annars av den som råkar ha en terminal öppen, på sitt eget sätt, och två personer mitt i en incident kan lägga flera minuter på att upptäcka att de tittade på olika siffror. Med en dashboard börjar samtalet från samma bild, och även den som aldrig skulle skriva en SQL-fråga kan se hur systemet mår.

Den kortar också vägen från ”något är fel” till ”den här delen är fel”. Dokumentationen för Prometheus rekommenderar en dashboard per tjänst, där var och en visar latens och fel för de tjänster den pratar med. Då kan du börja i toppen av trädet och följa de dåliga siffrorna nedåt till den tjänst som orsakar dem. En dashboard som är upplagd efter systemets struktur gör den vägen till några klick.

Den har också ett pris. Varje panel kör sin databasfråga vid varje uppdatering, på varje skärm som har den öppen. Varje panel är dessutom ett påstående som någon måste hålla sant när tjänsten bakom den byter namn, delas upp eller läggs ned. En dashboard med fyrtio paneler bär fyrtio sådana påståenden, och de flesta av dem läses aldrig.

Så ser det ut i praktiken

Företagets första dashboard för observerbarhet började med att samla in systemmätvärden som CPU, RAM, disk och temperatur från Linux-servrar på distans via SSH, Docker-containrar inräknade. En andra version flyttade till Grafana och Prometheus, och panelerna på den valdes tillsammans med DevOps- och utvecklingsteamen: CPU-användning, minnesanvändning, tjänsternas upptid och API-latens. Den visades på den stora tv:n på kontoret, där alla som gick förbi kunde se hur produktionen mådde, och larm vid överskridna tröskelvärden kom med på köpet. Teamen upptäckte och löste incidenter 40 % snabbare.

En senare dashboard för övervakning med Grafana och Prometheus pekar ut det som vägde tyngst: mätvärden som sa något, i stället för siffror för syns skull som ser livliga ut och inte säger någonting. Larmtrösklar sattes sedan för just de mätvärdena och visades där teamet faktiskt skulle se dem, medan det fortfarande fanns tid att agera. Teamet gick från brandsläckning till att fånga problemen medan de ännu var små.

På en värddator med 464 MB minne får samma slags fråga ett annat svar. Sju skrivskyddade roller återger den levande värden som Markdown-rapporter på begäran och täcker åtkomst, trafik, mätvärden, säkerhet med mera, eftersom en stack för mätvärden varken skulle rymmas eller vara värd sin kostnad om den gjorde det. Deras styrande regel passar lika bra för vilken dashboard som helst: skriv bara ut tal som körningen har mätt, eftersom en rapport som fyller en lucka med en rimlig siffra är sämre än en som lämnar luckan tom.

Var det går fel

En dashboard kan se frisk ut och ändå vilseleda, och oftast beror det på vad som lades på den.

Varje siffra som går att få fram hamnar på skärmen. Det är frestande att visa allt ett system kan mäta. Dokumentationen för Prometheus varnar för att det ger konsoler så täta att även en expert har svårt att läsa dem, och föreslår högst fem grafer per konsol och högst fem linjer per graf. Utgå från de troliga felen och visa det som skiljer dem åt.

Siffror för syns skull tar platsen. Det totala antalet besvarade anrop sedan lanseringen kan bara stiga, och antalet registrerade användare säger lite om hur det går i dag. Siffrorna ser livliga ut och ändrar inget beslut. Ge panelen åt ett tal som skulle få någon att agera om det rörde sig.

En enda dashboard ska räcka åt alla. Det den jourhavande behöver mitt i natten, alltså vad som är trasigt, skiljer sig från det en utvecklare behöver medan en funktion byggs, t.ex. hur många som träffar ett visst gränsfall. Dokumentationen för Prometheus säger rakt ut att en uppsättning konsoler sällan tjänar båda, och att två uppsättningar fungerar bättre.

Färgen bär hela budskapet. En rad röda och gröna prickar säger ingenting till den som har svårt att skilja rött från grönt, och lika lite på en svartvit skärm. Framgångskriterium 1.4.1 i WCAG 2.2, på nivå A, säger att färg inte får vara det enda visuella sättet att förmedla information; lägg till ett ord, en form eller en placering. Enligt 1.4.11, på nivå AA, behöver de delar av ett diagram som krävs för att förstå det ett kontrastförhållande på minst 3:1 mot färgerna bredvid, och tunna pastellfärgade linjer på vit bakgrund hamnar ofta under den gränsen.

En mätare antyder ett tak som saknas. Meter-mönstret i APG är till för ett värde inom ett definierat intervall, och mönstrets egen anmärkning avråder från att använda det för ett värde utan meningsfullt maxvärde, eller för att visa hur långt något har kommit. Anrop per sekund har inget naturligt tak, så en mätare för dem hittar på ett och får en vanlig hektisk timme att se ut som ett nödläge. Använd en linje över tid i stället.

Skärmen väntar på en tittare som har gått hem. En dashboard på kontorets tv klockan tre på natten har ingen publik. Problem som kräver en människa hör hemma i larm, och råden om larm i dokumentationen för Prometheus rekommenderar att larma på de symtom som användarna märker och att länka varje larm till den konsol som hjälper till att hitta komponenten som felar. Larmet kallar in någon, och dashboarden är det första den personen ser.

Läs mer

Ordlista