Oprettelse af Grafana-dashboards til hostinginfrastrukturer

Fra en samling af målinger til et klart målbillede på dashboardet

Et dashboard starter ikke med at vælge farverige paneler, men med et driftsspørgsmål: Skal et team nu reagere på en fejl i dataindsamlingen, begrænset lagerplads eller vedvarende belastning? Grafana viser forespørgsler til datakilder i paneler og kan visualisere dem afhængigt af problemstillingen. Brugergrænsefladen er dermed et beslutningsværktøj og ikke automatisk et bevis på en tjenestes tilstand.

Det øverste niveau, f.eks. „Hosting-status“, bør kun samle få signaler: Tilgængelighed set fra Prometheus, CPU-belastning, ledig hukommelse og netværkstrafik. Formålet er at fastlægge prioriteter: Hvilket område fortjener en undersøgelse? Det forklarer endnu ikke, hvorfor en webserver er langsom, eller hvilken datamængde der udløser en kapacitetsadvarsel.

Blandt andet hjælper Rullevisninger til web-, database-, cache-, e-mail- eller virtualiseringssystemer. Der kan man sammenligne lignende instanser ved hjælp af nøgletal, der er relevante for deres opgave. En databaserolle har for eksempel brug for andre detaljerede værdier end en reverse proxy; en fælles oversigtsside behøver ikke at skjule disse forskelle i et enkelt nøgletal.

Diagnosevisningen giver til sidst adgang til tidsserier pr. instans, oversigter over mountpunkter eller enheder samt driftshændelser. Et stort dashboard med alle værter og tjenester gør det vanskeligt at overskue sammenhængene. Grafana-dashboards kan kombinere forskellige visualiseringer og datakilder; alligevel bør ikke alle detaljerede spørgsmål besvares på samme side.

Kontroller Prometheus-databasen og etiketterne grundigt

Inden man går i gang med at oprette et dashboard, skal Prometheus og de påtænkte eksportmål være tilgængelige, og Grafana skal have en konfigureret Prometheus-datakilde. Prometheus definerer scrape-jobs, målinstanser og regelfiler, der skal indlæses, i sin konfiguration. Konfigurationsændringer kan ganske vist genindlæses, men en fejlbehæftet konfiguration bliver ikke overtaget.

Det afgørende er en konsekvent Etiketstruktur. Mærkerne job og instance identificere kilde og mål; supplerende mærker som f.eks. environment eller role muliggør en overskuelig adskillelse af produktion, testmiljø og serverfunktion. Uden sådanne regler kan den samme variabel blande værter, der ganske vist har lignende navne, men som har forskellige vedligeholdelsesvinduer, ansvarsområder eller kapacitetsgrænser.

Exporter-endepunkter bør ikke være offentligt tilgængelige uden kontrol. Metrikker kan afsløre værtsnavne, mountpoints, netværksgrænseflader eller andre infrastrukturdetaljer. Kontroller desuden, om Grafana har tilladelse til at hente data fra Prometheus, og om de eksisterende tidsserier rent faktisk leverer data i den forventede periode; et tomt panel kan ikke rettes op ved hjælp af en mere attraktiv visualisering.

• Kontroller de faktisk eksisterende metriknavne, labels og labelværdier i Prometheus eller i Explore-området.
• For hvert mål skal det kontrolleres, om scrapes i øjeblikket gennemføres med succes, og om den forventede instans er entydigt identificeret.
• Begræns mountpunkter og grænseflader for filsystem- og netværksmetrikker i henhold til dit eget miljø.
• Eksempler på dashboards overføres først til den lokale metrik- og label-struktur efter denne kontrol.

Node Exporter dokumenterer Collectors for blandt andet filsystem-, netværks- og diskoplysninger. Hvilke rækker der vises under drift, afhænger dog af operativsystemet, kernen, containere, mounts og aktiverede Collectors. README-filen for udviklingsgrenen beskriver desuden ikke automatisk funktionerne i en allerede installeret stabil version.

Kontroller derfor den installerede version af Exporter og dens synlige målinger uafhængigt af udviklingsdokumentationen. På tidspunktet for undersøgelsen blev Node Exporter 1.12.1 udgivet den 14. juli 2026; denne oplysning om udgivelsen erstatter ikke en kontrol af, hvilken build der kører på en bestemt vært. Eksterne dashboard-skabeloner er kun vejledende og udgør ikke en pålidelig oversigt over din egen infrastruktur.

Vælg paneltyper ud fra deres beskrivelse

Paneltypen afhænger af spørgsmålet. Et Stat-panel er velegnet til en aktuel, klart defineret nøgleværdi. Det kan vise en enkelt beregnet værdi og eventuelt en lille tendenslinje. Teksten skal præcist angive, hvilken måling og hvilket teknisk kontrolpunkt der vises; man må ikke ud fra en enkelt måleværdi drage generelle konklusioner om tilstanden af et websted eller en applikation.

Når det gælder belastning, vækst og sammenhænge, er tidsrækker mere passende. De viser for eksempel, om CPU-udnyttelsen kun stiger kortvarigt under en implementering, eller om den forbliver høj i timevis. Først tidsrammen, en korrekt enhed og sammenligningen med andre signaler gør en enkelt værdi til en pålidelig observation. Grafana understøtter her til formålet forskellige visualiseringer, hvis betydning afhænger af forespørgsel og fremstilling.

Tabeller egner sig til mange ensartede enheder. Værter, monteringspunkter eller enheder kan sammenlignes linje for linje med måleværdier og driftsmæssig kontekst, uden at alle rækker skal placeres i et fælles tidsdiagram. Til tidsmæssige sammenhænge er en tidsserie derimod som regel mere velegnet. Vælg derfor visningen ud fra, om du ønsker at sammenligne enheder eller undersøge en udvikling.

Hvert panel skal have en præcis mærkning, der angiver enheden, filteromfanget og fortolkningsgrænsen. „Tilgængelig lagerplads ifølge filsystemet pr. mountpoint“ er mere sigende end „disk“, fordi kvoter, reserverede blokke eller manglende inoder alligevel kan forårsage skriveproblemer. Ligeledes angiver en rød procentværdi hverken tilgængelighed eller en årsag; farver fanger opmærksomheden, men erstatter ikke en diagnose.

Indstil ikke driftsmæssige tærskelværdier blot som pynt. En advarselsfarve kan være nyttig, hvis funktion, vækst, redundans og mulig reaktionstid er kendt. Mangler denne kontekst, bør panelet vise værdien som neutral og føre til den relevante detaljevisning. På den måde forbliver Udtalelse fra panelet og den tekniske grænse skal være forståelig for alle involverede.

Sådan opbygger du en oversigt over hosting-tjenester trin for trin

En oversigtsside starter ikke med alle tilgængelige målinger, men med nogle få spørgsmål, som skal kunne besvares med det samme i driften: Opfyldes de fastsatte mål, stiger hostbelastningen, er der mangel på en relevant volumen, eller ændrer datatrafikken sig markant? Opret derfor i første omgang kun fire panelgrupper. Grafana samler forespørgsler og visninger i paneler; forskellige visualiseringer bør derfor hver især besvare et konkret driftsspørgsmål.

Til at begynde med er det tilstrækkeligt med en tydeligt mærket oversigt over registreringsstatus, en tidsserie for CPU-belastning, en tabel eller tidsserie for ledig hukommelse pr. mountpoint samt en tidsserie for netværksgennemstrømning. Stat-paneler er velegnede til en enkelt aktuel værdi og kan vise en kort tidsserie. De erstatter dog ikke tidsserien, når varighed, hyppighed og tidspunkt for en afvigelse er relevante.

Tabellen er et planlægningsgrundlag, ikke en fast skabelon: Node Exporter dokumenterer Collector-områder for filsystemer, netværk og andre værtsdata, men de synlige målinger og etiketter afhænger af systemet, mount-punkter, containere og aktiverede Collectors. Først derefter skal du tilføje applikationsspecifikke paneler, f.eks. til HTTP-fejl, databaseforbindelser eller køer. En mere uddybende oversigt over Overvågningsstack til hosting kan derigennem uddybe sin forståelse af klassificeringen af infrastruktur- og servicemetrikker.

PromQL-udtryk i denne artikel er udtrykkeligt Eksempler, der skal tilpasses. Kontroller metriknavne, labelværdier og antallet af de resulterende rækker i Explore-området, inden du overfører dem. Giv hvert panel en betegnelse, der er så præcis som den information, det kan formidle. Enheden, det valgte filteromfang og de udelukkede grænseflader eller pseudofilsystemer skal også fremgå tydeligt af panelkonfigurationen eller -beskrivelsen.

Et overskueligt overblik holdes bevidst enkelt. Hvis alle værter, enheder, mountpoints og containerlabels vises på én gang, går prioriteringen tabt. Dette opgives til detaljesiderne: Her kan enkelte instanser, volumener eller tjenester betragtes hver for sig. På den måde forbliver startsiden et orienteringsværktøj i stedet for en visuelt overfyldt samling af usammenhængende nøgletal.

Korrekt kombination af PromQL og variabler

En forespørgsel skal angive både metrikken og dens grænse. Kontroller først i Prometheus eller Grafana Explore, hvilke serier og labels der rent faktisk findes i dit eget miljø. Grafana-variabler kan derefter erstatte faste labelværdier. Hvis der er aktiveret et flervalg, anvendes indholdet heraf som et regulært udtryk; label-matcheren skal derfor =~ i stedet for = brug.

En kumulativ tæller giver ikke umiddelbart et meningsfuldt billede af CPU-udnyttelsen. I det følgende eksempel beregnes en procentdel pr. instans ud fra den CPU-tid, der ikke er brugt i inaktivtilstand. Det forudsætter, at node_cpu_seconds_total samt at de anvendte labels er til stede, og at Grafana-variablerne $job og $instance er blevet defineret korrekt.

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle", job=~"$job", instance=~"$instance"}[$__rate_interval])
  ) * 100
)

Kontroller den resulterende tidsserie over flere tidsintervaller, og sammenlign den med de faktisk registrerede prøver. Et uegnet intervalvindue kan føre til manglende eller mindre meningsfulde resultater. For PromQL-analysen er det desuden vigtigt, at, rate() skal anvendes før aggregeringen, så nulstillinger af tællere kan tages i betragtning ved beregningen.

I oversigten over lagerplads beregner det næste eksempel den tilgængelige andel for hver valgt Monteringspunkt. Kontroller begge målinger og deres mængder af etiketter på forhånd. Hvis tæller og nævner begrænses til forskellige rækker ved hjælp af forskellige filtre, kan divisionen give tomme eller uventede resultater.

100 * node_filesystem_avail_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}
/ node_filesystem_size_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}

Filtrer pseudofilsystemer efter installation i stedet for blot at sammenlægge dem uden videre. Filsystem-Collector leverer filsystemstatistikker, men ikke alle synlige rækker er relevante for beslutningen om kapacitet. Kvoter, reserverede blokke, inoder og skrivrettigheder forbliver separate kontroller. Panelet bør derfor kun angive den tilgængelige andel i henhold til de valgte filsystemmetrikker.

I netværkseksemplet beregnes ændringshastigheden for en byte-tæller, summeres pr. instans og omregnes derefter til bit pr. sekund. Summen giver kun mening, hvis de medregnede grænseflader hører sammen fagligt. Tilføj derfor et forståeligt grænsefladefilter i dit eget miljø i stedet for at lægge alle synlige grænseflader sammen uden at kontrollere dem.

sum by (instance) (
  rate(node_network_receive_bytes_total{job=~"$job", instance=~"$instance"}[$__rate_interval])
) * 8

Multiplikatoren otte omregner den hastighed, der er beregnet ud fra en byte-tæller, til bit pr. sekund. Loopback-, container- og tunnelgrænseflader kan generere et samlet tal, der ikke giver et pålideligt billede af den fysiske forbindelse eller en bestemt tjeneste. Dokumenter derfor i panelet, hvilke grænseflader der medtages eller udelades.

Sørg for, at variablerne er overskuelige og indlejrede: først $environment, så $job og derefter $instance; paneler, der vedrører lagring, kan $mountpoint tilføje. Grafana kan dynamisk generere variabler fra datakilden og gøre dem afhængige af hinanden. Omfattende forespørgsler på labelværdier ved hver indlæsning kan dog gøre initialiseringen af dashboardet langsommere.

Inddele tærskelværdier ud fra driftsmæssig viden

Tærskelværdier bliver pålidelige, når tidsforløbet holdes op mod driftsbegivenhederne. Grafana-annotationer kan markere vedligeholdelse, udgivelser eller infrastrukturændringer i paneler og henvise til dashboard-variabler. På den måde kan man f.eks. kontrollere, om en ændring i belastningen falder sammen med en implementering, i stedet for forhastet at konkludere, at der er tale om en fejl ud fra en kurve.

En kortvarig CPU-spids kan forventes i forbindelse med en sikkerhedskopiering, opvarmning af cachen eller planlagt databehandling. Den bliver først relevant at reagere på, hvis den varer længe, falder sammen med ventetider eller fejl, og der ikke findes en planlagt forklaring for tjenesterollen. CPU-procenten i sig selv er hverken bevis på nedsat tilgængelighed eller årsagen til en langsom applikation.

Et stigende lagerforbrug kræver en anden tilgang. Det afgørende er det pågældende monteringspunkt, dets funktion, vækstraten og det tidspunkt, hvor kapaciteten kan udvides. Et datavolumen med lidt ledig plads kan være mere presserende end et arkivvolumen med en tilsvarende belægning; backup-vinduer, redundans og gendannelsesveje ændrer desuden den driftsmæssige prioritet.

Mærkelig netværkstrafik er heller ikke i sig selv en grund til alarm. En stigning i trafikken kan skyldes en release, en kundehændelse, en replikering eller en virtuelt interface, der er blevet inkluderet fejlagtigt. Sammenlign derfor instans, retning, interfacefilter og den samtidige servicekontekst. Først denne kombination viser, om det giver mening at foretage en nærmere analyse af web-, database- eller netværksmålinger.

For mailservere er host-visningen særdeles sjældent tilstrækkelig som eneste forklaring. CPU, hukommelse og netværk kan afsløre afvigelser, men giver ingen vurdering af hverken afsendelseskvalitet eller leverbarhed. Den Sammenhængen mellem e-mail-hosting og omdømme supplerer hermed de specifikke signaler og afhængigheder.

I stedet for generelle grænseværdier dokumenterer du for hver rolle, hvilken reaktion en tilstand skal udløse: overvågning, kapacitetsplanlægning, underretning af beredskabet eller øjeblikkelig kontrol. Disse Driftskontekst-Reglen forhindrer, at procentværdier, der ser ens ud, behandles på samme måde. Den gør det muligt at justere grænseværdierne på en gennemsigtig måde, når væksten, vedligeholdelsesvinduerne eller redundansen i miljøet ændrer sig.

Sørg for, at forespørgsler og dashboards forbliver skalerbare

Et dashboard bliver svært at læse og kan blive langsomt, hvis hvert panel henter et meget stort antal rækker over lange perioder og udfører de samme ressourcekrævende beregninger flere gange. Begræns derfor udvælgelsen og visningen til de enheder, der er relevante for det pågældende driftsspørgsmål. Hvilke forespørgsler der rent faktisk belaster systemet, bør vurderes ud fra deres køretid og mængden af resultater, ikke alene ud fra deres visuelle kompleksitet.

Også variabler bør underkastes en belastningstest. En værdiliste, der udfører omfattende label-forespørgsler, når dashboardet åbnes, kan forsinke initialiseringen. Det er fornuftigt at anvende en kaskade: først miljø eller rolle, derefter job og først derefter instans eller mountpoint. På den måde bliver udvælgelsessættene mindre, og et oversigtsdashboard forsøger ikke at levere alle historiske og midlertidige labelværdier på én gang.

For ofte anvendte, beregningskrævende PromQL-udtryk er Regler for optagelse en målrettet mulighed. Prometheus udvurderer en regel og gemmer resultatet som en ny tidsserie. Paneler henter derefter denne forudberegnede serie i stedet for det fulde udgangsudtryk. Dette kan fremskynde tilbagevendende dashboard-forespørgsler, men erstatter ikke kontrollen af, om valg, aggregering og opbevaringstid er fagligt passende.

Regler kører i grupper med faste evalueringsintervaller. Hvis evalueringen af en gruppe tager længere tid end dens interval, kan enkelte iterationer springes over. Derfor bør en forudberegning ikke betragtes som en universalløsning for alle forespørgsler: Kontroller først, hvilke paneler der rent faktisk bruges ofte, hvor mange rækker et udtryk behandler, og om en rollebaseret visning allerede indsnævrer forespørgslen tilstrækkeligt.

Inden en regel-fil implementeres, kan dens syntaks kontrolleres lokalt. Følgende terminalkommando kontrollerer den angivne fil, men ændrer hverken en igangværende Prometheus-konfiguration eller aktiverer en regel.

promtool check rules /path/to/example.rules.yml

Hold desuden øje med udførelsestiden og nytten af hver regel. En ny tidsserie skal gemmes og hentes separat. Til et lille dashboard med få værter kan en klart filtreret udskrift være enklere og lettere at vedligeholde; forudberegning er især en god idé, hvis den samme ressourcekrævende beregning skal udføres flere gange pålideligt.

Skalerbarhed opnås altså ikke alene gennem teknisk optimering. Et reduceret antal informative paneler, et begrænset udvalg af etiketter og separate detaljevisninger bidrager også til at forhindre, at et dashboard bliver ulæseligt i tilfælde af en fejl. Hastighed og faglig relevans skal vurderes i sammenhæng.

Planlæg ændringer af forespørgsler som en driftsændring: Kontroller udskriften i en kopi af dashboardet, sammenlign resultatet med kendte tidsperioder, og overfør det først derefter til oversigten. På den måde forbliver påfaldende indlæsningstider, manglende serier eller utilsigtede summer sporbare, i stedet for først at blive synlige i en hændelse.

En kortfattet forespørgsel er dog ikke et bevis på, at den besvarer det rigtige spørgsmål. Reduktionen af rækker må ikke føre til, at afgørende roller, mountpoints eller grænseflader forbliver skjulte. Dokumenter derfor bevidst, hvilke enheder et panel omfatter, og hvilke det udelader for at give et detaljeret overblik.

Tomme paneler og falske signaler tyder på

Et tomt panel er i første omgang en diagnostisk indikation, ikke en angivelse af, om en tjeneste fungerer eller er nede. Kontroller følgende i denne rækkefølge: Findes metrikken i Prometheus, passer de anvendte labels og filtre, indeholder det valgte tidsinterval data, og leverer den installerede eksportørvariant overhovedet denne række? Prometheus overtager ikke fejlbehæftede konfigurationer ved genindlæsning; derfor kan også en uventet mål- eller konfigurationstilstand være relevant.

Hvis et panel viser en uventet indsamlingstilstand, skal du først undersøge det konfigurerede scrape-mål og den faktiske datamængde i Prometheus. Kontroller kun eksportører, netværkssti, certifikater eller adgangsoplysninger som mulige fejlkilder, ikke som en allerede fastslået årsag. For at vurdere tilgængeligheden af et websted eller en applikation kræves der egne, fagligt relevante indikatorer; et indsamlingspanel alene er ikke tilstrækkeligt til at drage denne konklusion.

Uventet mange tidsserier opstår ofte på grund af en for bred matcher eller ekstra labels, der er overtaget fra en skabelon. Kontroller først råforespørgslen uden aggregering og uden Grafana-variabel. Derefter kan man se, om f.eks. instans, enhed eller mountpoint bevidst skal vises separat. En aggregering bør først foretages, når det står klart, hvilke enheder der er fagligt sammenlignelige.

Når det gælder filsystemværdier, kan pseudofilsystemer, container-mounts eller midlertidige stier forvride tabellen og en samlet værdi. Node Exporter dokumenterer en collector til filsystemstatistikker, men de faktisk synlige rækker afhænger af systemet og collector-konfigurationen. Filtrer derfor kun efter en gennemsigtigt dokumenteret regel, og kontroller de inkluderede mountpunkter i det konkrete miljø.

Det samme gælder for netværksgennemstrømning. En sum over alle grænseflader kan omfatte loopback-, tunnel-, virtuelle eller container-grænseflader og dermed give et tal, der ikke har nogen praktisk betydning. Fastlæg, hvilke grænseflader der hører til den pågældende trafikrute. Hvis denne beslutning varierer alt efter værtsrolle, er en rolevisning som regel mere overskuelig end et globalt filter.

Stadigt stigende byte- eller CPU-værdier er ofte ikke en belastningsspids, men Tæller. Sådanne målinger angiver en kumuleret værdi. For gennemstrømning eller CPU-udnyttelse kræves der en hastighed over et passende tidsvindue; Prometheus anbefaler, at man i forbindelse med aggregeringer rate() skal anvendes før aggregeringen. Et for kort vindue fremhæver udsving, mens et for langt vindue muligvis skjuler dem.

Hvis et resultat fortsat virker usandsynligt, skal du sammenligne det med en enkelt forekomst, et enkelt monteringspunkt eller en enkelt grænseflade og et kortere tidsrum. Først derefter bør en formel ændres. Denne trinvise indsnævring forhindrer, at et visningsproblem skjules af stadig mere komplekse filtre.

Importerede dashboard-skabeloner er blot udgangspunkter. Metriknavne og etiketter kan variere afhængigt af operativsystem, eksportørversion, containerisering og aktiverede collectorer. Kontroller derfor altid de eksisterende rækker og ikke blot syntaksen i en importeret forespørgsel.

Fra overblik til velunderbygget driftsbeslutning

Et overskueligt infrastruktur-dashboard er tilstrækkeligt, hvis teamet først og fremmest skal kunne se, hvilken host eller hvilken rolle der kræver opmærksomhed. Scrape-tilgængelighed, belastning, ledig lagerplads og netværkstrafik giver de første indikationer herpå. De giver dog ikke et pålideligt svar på, hvorfor en applikation reagerer langsomt, eller om en specifik tjeneste er tilgængelig for brugerne. Grafana kan visualisere forskellige datakilder, men en fælles brugerflade kan ikke erstatte en årsagsanalyse.

Så snart en afvigelse optræder gentagne gange eller berører flere systemroller, skal oversigten indeholde en Drill-down . Sammenkædede eller adskilte rolevisninger kan f.eks. fokusere på de relevante nøgletal for webservere, databaser, cache- eller mailservere. En diagnosevisning supplerer tidsserier pr. instans, enheds- eller mountpoint-tabeller samt den tidsmæssige sammenhæng med ændringer. På den måde forbliver startsiden handlingsorienteret uden at miste relevante tekniske detaljer.

Udvid databasen trin for trin. Efter stabile hostmetrikker kan der følge applikationsspecifikke værdier såsom fejlrater, svartider, køer eller databasestatus. Logs og traces er især nyttige, når en metrikudvikling indsnævrer en årsag, men ikke forklarer den. Ikke alle visninger behøver at indeholde alle datatyper: Hver ekstra række kræver et konkret spørgsmål og en ansvarlig beslutning om vedligeholdelse.

Fastlæg ansvarsfordelingen for dashboards: Hvem vedligeholder etiketter og variabler, hvem kontrollerer filtre efter ændringer i infrastrukturen, hvem fastsætter grænseværdier, og hvem vurderer ubrugte paneler? Optagelsesregler hører også med i denne vedligeholdelse, da de supplerer regelarkiver og gemte tidsserier. Dine faste gruppeintervaller er en del af datavejen og bør tages i betragtning, når der forventes aktualisering.

Overvågning adskiller i denne sammenhæng observation fra tilsagn. Et grønt panel garanterer hverken sikkerhed, patchstatus, dataintegritet eller generel tilgængelighed. Patch- og sikkerhedsprocesser, sikkerhedskopier, adgangsrettigheder og procedurer ved hændelser kræver egne kontroller. Dashboardet kan give indikationer og understøtte beslutninger, men må ikke erstatte disse driftsopgaver med afledte procenttal.

I små miljøer er et overskueligt sæt infrastrukturpaneler med ensartet mærkning ofte det rigtige udgangspunkt. Når antallet af værter, roller eller klienter vokser, er klare mærkninger, rolleoversigter og forudberegnede forespørgsler vigtigere end en stadig større startside. Det afgørende er, at hver visning muliggør en yderligere gennemgang og synliggør sine fortolkningsgrænser.

Kontroller driftsmodellen regelmæssigt for at se, om der er foretaget nye implementeringer, tilføjet nye eksportører eller ændret serverroller. At fjerne unødvendige paneler og variabler forbedrer overskueligheden, ligesom det gør at tilføje nye målinger. Et dashboard forbliver robust, når dets fremstilling udvikler sig i takt med den faktiske arkitektur og ansvarsfordelingen.