Europæisk cloud

Overvågning og logs: værktøjerne, der også skal med

Overvågning og logs: værktøjerne, der også skal med

Overvågning og logning er de tjenester, der oftest bliver glemt, når servere flyttes til europæisk infrastruktur. Agenterne på serverne sender målinger, logs og fejlrapporter til en tjeneste, der kan ligge hos en helt anden udbyder, og de gør det videre, efter at serverne er flyttet. Værktøjerne skal derfor kortlægges og vælges som en del af skiftet.

Nedenfor følger driftens side: hvor data fra overvågning og logning havner, og hvad det kræver at flytte det.

Hvad der sendes ud

Et typisk miljø har flere strømme, der forlader huset:

Målinger. Belastning, hukommelse, svartider og fejlrater fra servere og programmer.

Logs. Systemlogs, programlogs, adgangslogs og sikkerhedshændelser. De kan indeholde brugernavne, IP-adresser og andre persondata.

Spor. Forløbet af en enkelt forespørgsel gennem flere tjenester, brugt til fejlsøgning.

Fejlrapporter og nedbrudsdata. Sendt automatisk af programmer, ofte med uddrag af hukommelsen.

Udbyderens egne logs. Logs fra cloudplatformen selv, fx over hvem der har logget ind i administrationen. De ligger hos udbyderen og skal eksporteres, hvis de skal gemmes andetsteds.

Hver strøm har en modtager. Det kan være et værktøj, I driver selv, en tjeneste fra en tredjepart eller udbyderens indbyggede overvågning. Kortlægningen begynder med at finde agenterne på serverne og læse, hvor de sender hen.

Åbne byggesten pr. november 2026

Flere af de mest brugte værktøjer er åben kode, som kan drives i eget miljø eller hos en europæisk udbyder. Felterne er de samme for alle: hvad det gør, licens og hvem der står bag. Rækkefølgen er ikke en rangering.

OpenTelemetry. Et open source-projekt med leverandørneutrale værktøjer til at indsamle målinger, logs og spor, som kan sendes til mange forskellige modtagere. Projektet skriver selv, at det er jer, der ejer de data, I genererer. Indsamleren er under Apache 2.0. Det er især nyttigt ved et skifte, fordi agenterne kan pege på en ny modtager uden at blive udskiftet.

Prometheus. Værktøj til målinger og alarmer, startet hos SoundCloud i 2012 og optaget i Cloud Native Computing Foundation i 2016. Licens Apache 2.0.

Grafana. Værktøj til at vise målinger og logs, under AGPLv3. Grafana Labs vedligeholder også Loki til logs, Mimir til målinger og Tempo til spor. Forbehold: Grafana Labs’ hjemland er ikke læst.

Zabbix. Overvågningsværktøj, som fra version 7.0 udgives under AGPLv3 og til og med 6.4 under GPLv2. Forbehold: selskab og land er ikke læst.

Checkmk. Overvågningsværktøj fra Checkmk GmbH i München. Kodelagerets licensfil er GPLv2. Forbehold: de kommercielle udgaver kan have en anden licens.

Åben kode betyder ikke, at værktøjet drives af sig selv. Den, der vælger at drive dem selv, overtager opdatering, lager til logs og målinger, adgangsstyring og høj tilgængelighed. Mange af værktøjerne findes også som tjeneste fra producenten eller fra en udbyder. Så gælder de samme spørgsmål om placering og kontraktpart som for alle andre tjenester.

Spørgsmålene til hvert værktøj

Hvor lagres data? Land og udbyder, også for sikkerhedskopier af værktøjets egne data.

Hvem kan læse dem? Leverandørens supportpersonale, og fra hvilke lande.

Hvad indeholder de? Persondata i logs gør placeringen til et spørgsmål om databeskyttelse ud over drift.

Hvor længe gemmes de? Og kan I selv bestemme det?

Kan de eksporteres? I et åbent format, så historikken ikke går tabt ved et skifte.

Rækkefølgen i et skifte

Overvågningen skal virke på det nye sted, før de første systemer flyttes, ellers flyver I blinde i den periode, hvor risikoen er størst. En brugbar fremgangsmåde er at sætte det nye overvågningsværktøj op først, lade agenterne sende til både gammel og ny modtager i overgangen og slukke den gamle, når historikken er eksporteret eller ikke længere skal bruges.

Logs, der skal gemmes af hensyn til sikkerhed eller regler, skal kunne findes efter skiftet. Planen skal sige, hvor de gamle logs gemmes, og hvor længe.

Hvad det kræver, og hvad det koster at lade være

Kortlægningen kræver, at agenter og modtagere findes på alle servere, typisk et par dage i et mellemstort miljø. Et nyt værktøj kræver opsætning, lager, alarmer og dashboards bygget op igen og en overgang med to modtagere. Posterne er værktøjet efter forbrug eller licens, lager til logs og målinger, eventuel drift af egne servere og egne timer. Tallene er jeres egne.

At lade være betyder, at data om jeres systemer fortsat forlader det miljø, I har valgt. Det kan undergrave grunden til skiftet, og spørgsmålet om, hvor logs opbevares, kan komme fra en kunde, før I selv har stillet det.

Det skal I lade være med

  • At flytte serverne og lade agenterne pege samme sted hen · data om systemerne går så stadig til den gamle modtager.
  • At slukke den gamle overvågning, før den nye er testet · overgangen er perioden med størst risiko.
  • At glemme udbyderens egne logs · de skal eksporteres, hvis de skal gemmes.

Det skal valget kunne vise

  • ☐ Alle strømme af målinger, logs, spor og fejlrapporter, med modtager og land.
  • ☐ Om logs indeholder persondata, og hvor længe de gemmes.
  • ☐ Hvilket værktøj der overtager, med licens og hvem der står bag.
  • ☐ Hvor gamle logs opbevares efter skiftet.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find agenterne på jeres vigtigste servere, og skriv op, hvor hver af dem sender data hen.

Læs også: Forbindelsen mellem miljøer · Efter flytningen

→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Overvejer I at flytte infrastruktur til Europa?

Skriv kort, hvilke systemer eller hvilken platform det drejer sig om, og hvad der sætter spørgsmålet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.