# Dashboard ## Hvad det er Et dashboard er en side med paneler, hvor hvert panel er en forespørgsel gjort til et billede, lagt sådan an, at man kan aflæse tilstanden af noget uden at spørge nogen. Det samme kendes under andre navne: Prometheus' egen dokumentation kalder dem konsoller, og et team siger måske bare "skærmen på væggen". Grafana beskriver sine dashboards som et eller flere paneler ordnet i rækker eller faner, der giver et overblik over sammenhørende information med ét blik, og hvert panel som beholderen for en visualisering bygget på en forespørgsel mod en datakilde. Kilden kan være et tidsserielager, en SQL-database, et API eller en almindelig CSV-fil. Panelerne har en håndfuld former. En linje over tid viser en tendens: brugt hukommelse det seneste døgn, forespørgsler pr. minut den seneste uge. Et enkelt stort tal svarer på "hvor meget lige nu". En måler viser en værdi inden for et kendt interval, som brugt diskplads ud af den samlede. En tabel lister ting, der kræver opmærksomhed, én pr. række. En statuslampe siger oppe eller nede. De fleste gode dashboards bruger to eller tre af formerne, valgt efter spørgsmålet, og meget få paneler af hver. På en webside er panelerne almindelige dele af en brugerflade, og W3C's ARIA Authoring Practices Guide beskriver, hvordan hver af dem skal opføre sig for folk, der bruger tastatur eller skærmlæser. Faner skifter mellem visninger og viser ét panel ad gangen. En tabel er et statisk net af rækker og celler; et grid er den interaktive udgave, som man flytter rundt i med piletasterne. En meter er mønsteret for en værdi inden for et defineret interval, og en alert er en kort, vigtig besked, der fanger opmærksomheden uden at afbryde det, læseren er i gang med. En måler skrevet efter meter-mønsteret bærer sit interval og sin aflæsning som tekst: ```html
``` Et dashboard venter på at blive kigget på, og det adskiller det fra dets naboer. En alarm kommer til et menneske, når noget krydser en grænse. En rapport er et øjebliksbillede, lavet når nogen beder om det og derefter fast. Et dashboard er levende, og det er præcis så meget værd som den opmærksomhed, nogen giver det. ## Hvorfor det betyder noget Et dashboard giver et team én fælles aflæsning af, hvordan det står til. Uden det bliver det samme spørgsmål besvaret af den, der lige har en terminal åben, på hver sin måde, og to personer midt i en hændelse kan bruge minutter på at opdage, at de kiggede på forskellige tal. Med det starter samtalen fra det samme billede, og folk, der aldrig ville skrive en forespørgsel, kan se, hvordan systemet har det. Det forkorter også vejen fra "noget er galt" til "den her del er galt". Prometheus' vejledning om konsoller anbefaler ét dashboard pr. tjeneste, der hver viser latens og fejl for de tjenester, den taler med, så man kan starte i toppen af træet og følge de dårlige tal ned til den tjeneste, der giver dem. Et dashboard, der er lagt an efter systemets opbygning, gør den vej til et par klik. Det har også en pris. Hvert panel kører sin forespørgsel ved hver opdatering, på hver skærm, der har det åbent. Hvert panel er desuden en påstand, som nogen skal holde sand, når tjenesten bag den skifter navn, bliver delt op eller lukket. Et dashboard med fyrre paneler har fyrre af de påstande, og de fleste bliver aldrig læst. ## Sådan ser det ud i praksis Virksomhedens [første observability-dashboard](/da/portfolio/developed-and-launched-the-company-s-first-observability-9/) begyndte med at indsamle CPU, RAM, disk og temperatur fra fjerne Linux-servere via SSH, Docker-containere medregnet. En anden version flyttede til Grafana og Prometheus, og panelerne på den blev valgt sammen med DevOps- og engineering-teamene: CPU-udnyttelse, hukommelsesforbrug, oppetid for tjenester og API-latens. Det kørte på den store TV-skærm på kontoret, hvor alle, der gik forbi, kunne se, hvordan produktionen havde det, og alarmering ved overskridelse af tærskler fulgte med. Teams opdagede og løste incidents 40 % hurtigere. Et senere [monitoreringsdashboard på Grafana og Prometheus](/da/portfolio/mitigated-operational-risks-by-implementing-a-monitoring-dashboard-22/) nævner den del, der betød mest: metrikker, der betød noget, frem for forfængelighedstal, der ser travle ud og fortæller en ingenting. Alarmtærskler blev derefter sat på de metrikker og vist der, hvor teamet ville se dem, mens der stadig var tid til at handle. Teamet gik fra brandslukning til at fange problemer, mens de var små. På en vært med 464 MB hukommelse får den samme slags spørgsmål et andet svar. [Syv skrivebeskyttede roller gengiver den levende vært som Markdown-rapporter](/da/portfolio/built-seven-read-only-host-reporting-roles-120/) på forlangende og dækker adgang, trafik, metrikker, sikkerhed og mere, fordi en metrikstak ikke ville passe og ikke ville være sin pris værd, hvis den gjorde. Deres styrende regel passer lige så godt på ethvert dashboard: udskriv kun tal, kørslen målte, for en rapport, der fylder et hul med et plausibelt tal, er værre end en, der lader det stå åbent. ## Hvor det går galt Et dashboard kan se sundt ud og alligevel vildlede, og de fleste af måderne kommer af det, der blev sat på det. **Hvert eneste tal kommer på skærmen.** Det er fristende at vise alt, hvad et system kan måle. Prometheus' vejledning advarer om, at det giver konsoller så tætte, at selv en ekspert har svært ved at læse dem, og foreslår højst fem grafer på en konsol og højst fem linjer på hver graf. Start fra de sandsynlige fejl, og vis det, der skiller dem ad. **Forfængelighedstal tager pladsen.** Et samlet antal forespørgsler siden lanceringen stiger kun, og et antal registrerede brugere siger lidt om i dag. De ser travle ud og ændrer ingen beslutning. Giv panelet til et tal, der ville få nogen til at handle, hvis det flyttede sig. **Ét dashboard prøver at tjene alle.** Det, en vagthavende ingeniør har brug for om natten, nemlig hvad der er i stykker, er noget andet end det, en udvikler har brug for, mens en funktion bygges, som hvor mange der rammer et bestemt grænsetilfælde. Prometheus' vejledning siger ligeud, at ét sæt konsoller sjældent tjener begge, og at to sæt fungerer bedre. **Farven bærer hele budskabet.** En række røde og grønne prikker siger ingenting til den, der ikke kan skelne rød fra grøn, eller på en sort-hvid skærm. WCAG 2.2 succeskriterium 1.4.1 på niveau A siger, at farve ikke må være den eneste visuelle måde at formidle information på; tilføj et ord, en form eller en placering. Efter 1.4.11 på niveau AA skal de dele af en graf, der er nødvendige for at forstå den, have et kontrastforhold på mindst 3:1 mod farverne ved siden af, og det rammer tynde pastelfarvede linjer på hvid bund ofte ved siden af. **En måler antyder et loft, der ikke findes.** APG's meter-mønster er til en værdi inden for et defineret interval, og mønstrets egen note fraråder at bruge det til en værdi uden et meningsfuldt maksimum eller til fremdrift. Forespørgsler pr. sekund har intet naturligt loft, så en måler til dem opfinder et og får en almindelig travl time til at ligne en nødsituation. Brug en linje over tid i stedet. **Skærmen venter på en seer, der er gået hjem.** Et dashboard på en kontor-TV-skærm klokken tre om natten er der ingen, der kigger på. Problemer, der kræver et menneske, hører hjemme i alarmer, og Prometheus' vejledning om alarmering anbefaler at alarmere på de symptomer, brugerne mærker, og at linke hver alarm til den konsol, der hjælper med at finde den del, der fejler. Alarmen tilkalder nogen, og dashboardet er der, de lander. ## Læs mere - [Grafana: Dashboards](https://grafana.com/docs/grafana/latest/visualizations/dashboards/) — paneler, rækker, datakilder, forespørgsler og transformationer, som et udbredt værktøj definerer dem. - [WAI-ARIA Authoring Practices Guide: Patterns](https://www.w3.org/WAI/ARIA/apg/patterns/) — hvordan faner, tabeller, grids, meters og alerts skal opføre sig for brugere af tastatur og skærmlæser. - [Prometheus: Consoles and dashboards](https://prometheus.io/docs/practices/consoles/) — retningslinjen om fem grafer og fem linjer og argumentet for ét publikum pr. sæt. - [Prometheus: Alerting](https://prometheus.io/docs/practices/alerting/) — alarmering på symptomer og et link fra hver alarm til den konsol, der forklarer den. - [Understanding WCAG 2.2: Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html) — hvorfor farve alene ikke kan bære en status, med eksempler. - [Understanding WCAG 2.2: Non-text Contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) — den kontrast på 3:1, som linjer i grafer og dele af en brugerflade skal have.