Jeg ville vide, når mine sites går ned, før nogen fortæller mig det – og jeg ville vide det på en måde, jeg selv kunne stå inde for. Så jeg byggede Monitor: en overvågning, der holder øje med websites, API'er, certifikater, domæner og maskiner, registrerer hvad der skete, og viser det på et dashboard, der opdaterer sig selv, mens man kigger på det. Skærmbillederne her er fra demokontoen for det opdigtede firma Fjordmark – intet af det er rigtigt, men alt er, som det ser ud i drift.
Dashboardet: ét blik på det hele
Øverst løber et live-signal – hvert eneste tjek på tværs af alle monitorer, ældst til venstre, opdateret hvert femte sekund. Under det fire tal, man faktisk vil kende: oppetid de seneste 24 timer, gennemsnitlig svartid, åbne hændelser og hvor meget der overvåges. Et verdenskort viser monitorerne på de lokationer, de står i – en nål får farven fra det værste, der sker der – og nederst ligger svartidsgrafen og de seneste hændelser med årsagen skrevet i klart sprog.
Monitors: ni typer tjek
Listen viser alle monitorer med status, de seneste tjek som små bjælker, svartid og oppetid, og kan filtreres på status, gruppe og lokation. Der er ni typer: almindelige website-tjek, nøgleord på siden ("Add to basket" skal være der), JSON-API'er med betingelser ("queue.depth skal være under 100"), flertrins-API-sekvenser som et helt checkout-flow, ping, åbne porte som SMTP, udløb af TLS-certifikater, domæneregistrering og DNS-poster.
Åbner man en monitor, får man hele billedet: svartid nu, gennemsnit og p95, oppetid for 24 timer, 7 og 30 dage, certifikatets restlevetid og en tilgængelighedsring. Grafen kan vises fra 1 time til 90 dage – den fuldt optrukne linje er gennemsnittet, den stiplede p95, og røde bånd er registrerede nedbrud. Nedenunder står konfigurationen (interval, timeout, antal forsøg før "nede", forventet statuskode, nøgleord, grænse for "langsom"), hvilke grupper monitoren er delt med, og "hvem får besked": pr. kanal vælger man, om den skal høre om nede, oprettet igen, langsomme svar eller udløbende certifikat – efter hvor mange fejl, hvor ofte det gentages, og hvilke timer der er stille.
Når noget er nede, står årsagen med det samme: "The name staging.fjordmark.example did not resolve." – ikke en fejlkode, men det, der faktisk skete.
Hændelser: hvad gik galt, hvor længe – og hvem kvitterede
Hver afbrydelse bliver en hændelse: hvornår den startede, hvor længe den varede, årsagen i klart sprog, hvor mange tjek der fejlede, og hvem der har kvitteret for den. Listen kan vises som alle, åbne eller løste, og en hændelse kan kvitteres enkeltvis eller alle på én gang.
Servere og klienter: maskinerne, ikke kun URL'erne
Oppetidstjek fortæller kun, at noget svarer. For de maskiner, man selv ejer, rapporterer en lille agent resten. Serversiden starter med fire tal – hvor mange har meldt ind til tiden, hvor mange er gået stille, hvor mange har sikkerhedsopdateringer ventende, og hvor mange venter på en genstart – og viser så hver maskine som et kort med processor, hukommelse, lager, styresystem, ventende opdateringer og lokation. Klientsiden gør det samme for laptops og desktops: Windows 11, Ubuntu og macOS side om side.
db-01: én maskine, helt tæt på
Maskinesiden er der, hvor agenten viser sit værd. Fem knapper øverst – rapportér nu, tjek for opdateringer, opdatér agenten, installér opdateringer og genstart – og en vigtig sætning ved siden af: ordren sættes i kø og hentes inden for et minut, og maskinen afviser alt, den ikke er installeret til at tillade. Under tallene for processor, hukommelse, lager og oppetid ligger "What it is doing": det, agenten selv siger, linje for linje, mens en kommando kører.
Jeg trykkede "Check for updates" på db-01. Inden for ti sekunder begyndte agentens apt-output at rulle ind i loggen, og kort efter stod resultatet øverst på siden: tre opdateringer venter, to af dem sikkerhed – og en bemærkning om, at en tidligere opdatering er færdig, men maskinen ikke er genstartet. Til højre står maskinen selv: Debian 13, kernel, CPU, virtualiseringsplatform, agentens version og hvilken opdateringspolitik den følger.
Windows-maskiner får samme behandling. På filserveren FS-01 (Windows Server 2022) ser man lageret pr. drev, ventende Windows-opdateringer med KB-numre og kategori, og de kørende tjenester med tilstand og opstartstype.
Tilmelding: én kommando pr. maskine
At tilføje en maskine er én kommando på Linux, macOS eller Windows, med installationsscriptets SHA-256 vist ved siden af, så man kan tjekke det. Agenten rapporterer over HTTPS og lytter aldrig på noget – der skal ikke åbnes en port. Som standard kan intet på maskinen ændres herfra; vil man tillade opdateringer eller genstart, giver man --allow-updates eller --allow-reboot ved installationen, og maskinen beholder retten til at sige nej. En tilmeldingsnøgle er en kupon, ikke en identitet: maskinen bruger den én gang og får sit eget token, så en tilbagekaldt nøgle stopper nye maskiner uden at røre de eksisterende.
Automatiske opdateringer: patch-nat uden at sidde oppe
En opdateringspolitik tjekker for opdateringer og installerer dem efter en plan på de maskiner, der følger den. Demoen har to: "Clients — Wednesday evening" tjekker på hverdage kl. 12 og installerer onsdag kl. 18 på kontorets fire maskiner, og "Weekly patching — production" tjekker hver nat kl. 02, installerer lørdag kl. 03 og genstarter bagefter, hvor det er nødvendigt. Listen viser, hvad der skete sidst: sat i kø på 3 af 3, én havde intet ventende, én vil ikke installere, fordi den ikke er installeret med --allow-updates.
Selve politikken er tre trin med hver sin plan: tjek (installerer intet og kræver intet samtykke på maskinen), installér (kun på maskiner med --allow-updates; en maskine uden noget ventende lades i fred), og genstart bagefter (kun hvis maskinen har brug for det og er installeret med --allow-reboot – den, der sidder ved den, får et minuts varsel). Til sidst én e-mail for hele politikken, når alle maskiner er færdige og meldt tilbage.
Personer, grupper og lokationer
Under Administration ligger de ting, der ellers ender i et regneark. *People* viser hver person med rolle (Viewer, Editor eller Administrator), grupper, seneste login, og om kontoen kommer fra Entra ID eller er deaktiveret; en person redigeres med navn, e-mail, ny adgangskode og tidszone.
*Groups* afgør, hvem der ser hvilke monitorer. En gruppe har medlemmer og en liste over delte monitorer med adgangsniveau, og den kan tildele en rolle til alle sine medlemmer – så "hvem er administrator" bor i Entra ID i stedet for to steder. Den mest tilladende gruppe vinder.
*Locations* er de steder, monitorerne står – navn, adresse og koordinater – og det er dem, der bliver til nåle på dashboardets kort.
Indstillinger: fire faner og en liste over kanaler
*Generelt* viser først, om planlæggeren kører – "Cron is doing its job", seneste tjek for 6 sekunder siden, og præcis den cron-linje, der skal stå på serveren – og derefter hvor meget der er gemt: 232.000 tjek, 325.000 minut-intervaller og 19.000 time-intervaller. Resten er sitets navn, URL, tidszone, standardværdier for tjek og hvor længe data gemmes.
*Agent* er flådestyringen: hvilken agentversion serveren tilbyder, hvor mange maskiner der er tilmeldt og hvor mange der kører en ældre version, og hvad en ny maskine starter med – rapportinterval, logniveau, om den er på den "levende kanal", hvor den banker på hvert par sekunder, og om den må modtage kommandoer.
*Notifikationer* sender e-mail via SMTP eller lokal sendmail, med adgangskoden krypteret før den gemmes. En testmail svarer med den grund, mailserveren faktisk gav – ikke bare "kunne ikke sende".
*Entra ID* slår "Log ind med Microsoft" til: redirect-URI'en og de to Graph-tilladelser står klar til at kopiere, nye konti får en standardrolle, adgangskode-login kan beholdes, indtil Microsoft-login har virket mindst én gang, og udvalgte grupper spejles hver time – skrivebeskyttet, med profilbilleder.
*Kanaler* er navngivne modtagerlister – "Operations on-call", "Web team", en enkelt person – som hver monitor vælger imellem. Under listen står "hvad blev sendt": hver notifikation med resultat og detalje, så man kan se, at demoens eksempeldomæner naturligvis ikke kan modtage mail.
*Aktivitetsloggen* svarer på "hvem ændrede hvad": tidspunkt, person, handling, detalje og IP-adresse – fra "Updated monitor Web shop" til "Queued Install updates on FS-01". Også demo-login via nøgle logges.
Kedeligt med vilje
Stakken er ren PHP 8 og MySQL: ingen Node, intet build-step, ingen containere. Det er ikke nostalgi, det er et tilgængelighedsargument – et overvågningsværktøj er det ene, der skal blive ved med at køre, når alt andet brænder, så det skal have så få bevægelige dele som muligt. Målingerne samles i intervaller pr. minut, pr. time og pr. dag, i takt med at de kommer ind, så 90-dages-graferne tegnes lige så hurtigt efter et år som efter en dag.
Kedeligt betyder ikke sjusket: adgangskoder hashes med Argon2id, hemmeligheder krypteres før de gemmes, alle forespørgsler er parametriserede, formularer bærer CSRF-tokens, private og loopback-adresser afvises som standard, og databasens adgangskode ligger i en .env-fil ét niveau over web-roden – samme trick, som dette site bruger.
Derfor er det et betalt produkt
Et overvågningsværktøj er kun noget værd, hvis det selv er oppe, og hvis nogen holder det ved lige: nye typer tjek, agenter til næste Windows- og Debian-version, og en person, der kender koden, når noget ser mærkeligt ud klokken tre om natten. Det er den aftale, Monitor sælges på – hostet og supporteret af mig, som et abonnement pr. organisation, uden binding.
Prøv den
Vil I se Monitor køre med Fjordmarks data – eller tale om, hvordan jeres egne systemer og maskiner ville se ud i den – så skriv til mig, så aftaler vi en demo.