Sådan fungerer PingPuffins overvågningssystem

Version: 1.0
Sidst opdateret: 21. november 2024

Indholdsfortegnelse

Oversigt
Tjek-intervaller og hyppighed
Fejldetektion
Genoprettelse og statusændringer
Manuel opdatering
Beskyttelse mod monitor-fejl
Notifikationssystem
Automatiske dashboard-opdateringer
Dataindsamling og lagring
Tekniske specifikationer
Privatliv og sikkerhed
Systempålidelighed
Almindelige scenarier og eksempler

Oversigt

PingPuffin overvåger HTTP- og HTTPS-endpoints 24/7 for at sikre, at dine websites er tilgængelige. Vores system er bygget med fokus på pålidelighed, præcision og gennemsigtighed.

Nøglefunktioner

✅ Automatiske tjek hvert 5. minut via cron job
✅ 2-tjek verifikation for at undgå falske alarmer
✅ 24/7/365 overvågning uden pauser
✅ Øjeblikkelig genoprettelse når dit site er tilbage
✅ Manuel opdatering for hurtig verifikation
✅ Beskyttelse mod interne fejl i monitor-systemet

Hvorfor gennemsigtighed er vigtigt

Vi tror på åbenhed omkring, hvordan vores overvågning fungerer. Dette dokument forklarer præcis, hvordan vi detekterer nedetid, hvordan vi undgår falske alarmer, og hvordan vi sikrer, at du får besked hurtigst muligt, når der er et reelt problem.

Tjek-intervaller og hyppighed

Automatiske tjek

Alle aktive monitors tjekkes automatisk hvert 5. minut.

Cron-plan:

*/5 * * * *

Dette betyder:

Første tjek: 00:00, 00:05, 00:10, 00:15, ...
Ingen pauser, ingen weekends, ingen helligdage
Alle monitors tjekkes parallelt for effektivitet

Manuel opdatering

Du kan altid udløse et øjeblikkeligt tjek via "Opdater nu"-knappen i dit dashboard:

Resultat vises med det samme
Bypass af 2-tjek-tærskel for hurtig feedback
Nyttigt efter deployments eller konfigurationsændringer

Dækning

Tilgængelighed: 24/7/365
Parallelle tjek: Alle monitors tjekkes samtidigt
Timeout: Standard 30 sekunder (kan konfigureres)
Maksimale redirects: Op til 5 følgeforspørgsler

Fejldetektion

2-tjek verifikationssystem

For at undgå falske alarmer kræver vi 2 på hinanden følgende fejl, før vi markerer et site som nede.

Hvordan det fungerer

Første Fejl (00:00):

Fejltæller sættes til 1
Status forbliver uændret (f.eks. UP)
Ingen notifikation sendes
System logger fejlen til intern overvågning

Anden Fejl (00:05):

Fejltæller opdateres til 2
Status ændres til DOWN
Incident oprettes automatisk
Notifikation sendes til alle konfigurerede kanaler

Total tid: ~5-10 minutter fra første fejl til DOWN-status.

Hvorfor 2-tjek?

Transiente netværksproblemer (DNS blips, kortvarige timeouts, midlertidige serverfejl) forekommer selv på stabile sites. Ved at kræve 2 fejl:

✅ Eliminerer vi falske alarmer fra kortvarige problemer
✅ Bekræfter vi, at der er et reelt problem
✅ Forbedrer vi brugertilliden til notifikationer

Hvad tæller som en fejl?

Følgende situationer markeres som fejl:

HTTP-fejlkoder

4xx Client Errors: 400, 403, 404, 405, osv. (medmindre eksplicit tilladt)
5xx Server Errors: 500, 502, 503, 504, osv.

Netværksfejl

Timeout: Ingen respons inden for timeout-perioden (standard: 30 sekunder)
Connection Refused: Serveren afviser aktivt forbindelser
DNS Failure: Kan ikke løse domænenavnet
Network Unreachable: Host er ikke tilgængelig på netværket

SSL/TLS-fejl

Invalid Certificate: Certifikatet er ugyldigt
Expired Certificate: Certifikatet er udløbet
Untrusted Certificate: Certifikatet er ikke fra en betroet CA
Hostname Mismatch: Certifikatets hostname matcher ikke URL'en

Håndtering af forskellige fejltyper

Vigtigt: ALLE fejltyper tæller med i fejltælleren.

Eksempel:

Tjek 1: HTTP 500 → Fejltæller: 1, Status: UP (venter på bekræftelse)
Tjek 2: Timeout  → Fejltæller: 2, Status: DOWN (bekræftet fejl)

Rationale:

Hvis en server skifter mellem forskellige fejltyper, indikerer det ustabilitet
Det er ikke mindre alvorligt, hvis fejltypen ændrer sig
Enhver fejl betyder, at sitet ikke fungerer korrekt

Genoprettelse og statusændringer

Øjeblikkelig genoprettelse

Når dit site kommer tilbage, reagerer vi straks – ingen 2-tjek-tærskel for genoprettelse.

Genoprettelsesflow:

Status: DOWN
Tjek 1: Site svarer med HTTP 200 → Fejltæller nulstilles, Status: UP
Resultat: Øjeblikkelig genoprettelse, notifikation sendt

Hvorfor øjeblikkelig genoprettelse?

✅ Brugere ønsker hurtig feedback, når deres site er tilbage
✅ Ingen grund til at vente på bekræftelse af, at noget virker
✅ Bedste praksis inden for overvågning
✅ Reducerer bekymring og ventetid

Status-tilstande

🟢 UP (Oppe)

Betydning:

Site svarer med forventet statuskode (typisk 200-399)
Svartid er inden for acceptabelt område
Ingen fejl detekteret

Notifikationer:

Sendes ved genoprettelse fra DOWN-status

🔴 DOWN (Nede)

Betydning:

Site fejlede 2+ på hinanden følgende tjek
Incident oprettet og spores
Alle konfigurerede notifikationskanaler alarmeret

Varighed:

Registreres fra første DOWN-tjek til genoprettelse
Vises i incident-log med præcis varighed

🟡 WARNING (Advarsel)

Betydning:

Site svarer, men med advarsler
Eksempler: Langsom svartid, Cloudflare-udfordring detekteret
Overvågning fortsætter normalt

Notifikationer:

Kan konfigureres per bruger

🔵 REDIRECT (Omdirigering)

Betydning:

Permanent redirect (301) detekteret til anden URL
Site er funktionelt, men URL har ændret sig
Du kan vælge at opdatere URL eller fortsætte med at overvåge oprindelig

Notifikationer:

Kan konfigureres per bruger

Manuel opdatering

Bruger-initierede tjek

Du kan altid udløse et øjeblikkeligt tjek via "Opdater nu"-knappen i dashboardet.

Adfærd:

Bypass af 2-tjek-tærskel: Resultat vises og anvendes med det samme
Øjeblikkelig statusopdatering: Hvis status ændrer sig, opdateres den straks
Notifikation: Sendes hvis status ændrer sig
Fejltæller opdateres: Tælleren opdateres baseret på resultat

Anvendelsestilfælde

✅ Hurtig verifikation efter deployment af rettelser
✅ Test af ny monitor-konfiguration
✅ Øjeblikkelig statustjek uden at vente på cron
✅ Debugging af forbindelsesproblemer

Eksempel:

00:00 - Automatisk tjek fejler → Fejltæller: 1, Status: UP
00:02 - Du klikker "Opdater nu" → Tjek fejler → Status: DOWN øjeblikkeligt
Resultat: Manuel tjek springer 2-tjek-tærskel over for hurtig feedback

Beskyttelse mod monitor-fejl

Intern vs. ekstern fejl

Det er kritisk at skelne mellem fejl i dit site og fejl i vores monitor-system.

Site-fejl (overvåges)

Disse fejl fra dit site tæller som fejl:

✅ HTTP 500 fra target-sitet → Tæller som fejl
✅ Timeout ved forbindelse til target-site → Tæller som fejl
✅ DNS-fejl for target-domæne → Tæller som fejl

Monitor-system-fejl (beskyttet)

Disse fejl i PingPuffin's kode markerer IKKE dit site som nede:

❌ PHP-exception i PingPuffin-kode → Markerer IKKE site som nede
❌ Database-forbindelsesfejl → Markerer IKKE site som nede
❌ Intern logik-fejl → Markerer IKKE site som nede

Administrator-alarmering

Når monitor-systemet fejler:

Logning:

Kritisk fejl logges med fuld stack trace
Timestamp og monitor-ID registreres
Alle detaljer gemt til debugging

Email-alarm:

Email sendes til systemadministrator
Indeholder fejlbesked, stack trace, og kontekst
Rate-limiteret: Maksimum 1 email per time per unik fejl
Forhindrer email-oversvømmelse under systemproblemer

Database:

Status forbliver uændret (ingen falske downs)
Ingen incident oprettes
Brugere påvirkes ikke

Eksempel:

Monitor checker kører
→ Intern fejl detekteres i monitor-system
→ Fejl logges med fuld kontekst
→ Email sendes til systemadministrator
→ Database opdateres IKKE
→ Din site status forbliver uændret

Notifikationssystem

Hvornår notifikationer sendes

Automatiske tjek

Status DOWN: Efter 2 på hinanden følgende fejl bekræftet (~5-10 min)
Status UP: Øjeblikkeligt når site kommer tilbage fra DOWN
Andre ændringer: Konfigurerbart per bruger (redirect, warning, osv.)

Manuelle tjek

Øjeblikkelig notifikation: Hvis status ændrer sig ved manuel opdatering
Ingen forsinkelse: Bypass af 2-tjek-tærskel

Notifikationskanaler

Email

Direkte email-notifikationer
Indeholder: Site-navn, status, fejlbesked, tidspunkt
Indeholder link til dashboard for flere detaljer

Slack

Besked til konfigureret kanal eller DM
Formateret med farver baseret på status (rød=DOWN, grøn=UP)
Inkluderer direkte link til monitor

Webhook

POST-request til brugerdefineret endpoint
JSON-payload med alle detaljer
Statuskode, svartid, fejlbesked inkluderet
Nyttigt til integration med andre systemer

Notifikation snoozing

Du kan midlertidigt slå notifikationer fra (snooze) i 24 timer:

Under Snooze:

✅ Overvågning fortsætter normalt
✅ Status opdateres i dashboardet
❌ Ingen notifikationer sendes til nogen kanal
⏰ Automatisk un-snooze efter 24 timer

Anvendelsestilfælde:

Planlagt vedligeholdelse
Kendt problem under udrulning
Midlertidig nedlukning

Automatiske dashboard-opdateringer

Auto-refresh mekanisme

Dit dashboard opdateres automatisk hver 30. sekund uden at genindlæse siden.

Teknisk:

Dashboard opdateres automatisk hver 30. sekund
Henter seneste data fra databasen via sikre API-kald
Udløser IKKE nye tjek (read-only)
Letvægtskald for hurtig opdatering

Hvad opdateres?

Dashboard viser altid de seneste data fra sidste cron-tjek:

🎨 Status-indikator: Farvet badge (grøn/rød/gul/blå)
⏰ Sidst tjekket: Præcist tidspunkt for sidste tjek
⚡ Svartid: Response time i millisekunder
🔢 Fejltæller: Antal på hinanden følgende fejl
📊 Incident-info: Aktive incidents og varighed

Vigtigt: Auto-refresh respekterer automatisk 2-tjek-logikken, fordi den kun viser data fra cron-tjek, ikke nye tjek.

Dataindsamling og lagring

Tjek-poster

Hver eneste tjek gemmes i databasen med følgende information:

Unikt ID for tjek
Reference til monitor
Tidsstempel (når tjek blev udført)
HTTP-statuskode eller fejltype
Svartid i millisekunder
Succes/fejl status
Fejlbesked (hvis relevant)
Redirect information (hvis relevant)
SSL-fejl detaljer (hvis relevant)

Anvendelse:

Uptime-procentberegninger
Historiske grafer og rapporter
Fejlanalyse og debugging
Performance-tracking over tid

Incident tracking

Når status ændrer sig til DOWN, oprettes en incident med følgende data:

Unikt ID for incident
Reference til monitor
Start tidspunkt
Slut tidspunkt (når løst)
Total varighed

Funktioner:

Automatisk oprettelse ved DOWN-status
Kontinuerlig varighed-beregning
Automatisk løsning ved genoprettelse
Komplet historik vedligeholdes
Eksporterbar til CSV

Aktivitetslog

Alle væsentlige hændelser logges:

✅ Status-ændringer (UP → DOWN, DOWN → UP, osv.)
✅ Manuelle tjek udført af brugere
✅ Konfigurations-ændringer
✅ URL-opdateringer
✅ Metadata-opdateringer

Funktionalitet:

Eksporterbar til CSV-format
Søgbar og filtrerbar
Viser detaljer for hver hændelse
Tidsstempler på alle entries

Tekniske specifikationer

HTTP request-parametre

Når PingPuffin tjekker dit site, sendes følgende request:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: */*
Connection: close
[Optional: Authorization header for Basic Auth]

Note: Vi bruger en standard Chrome user agent for at undgå at blive blokeret af sites, der filtrerer custom user agents.

Konfiguration:

Timeout: Kan konfigureres per monitor (standard: 30 sekunder)
Follow Redirects: Ja, op til 5 redirects maksimalt
SSL Verification: Aktiveret (validerer certifikater)
Connection Reuse: Deaktiveret (frisk forbindelse ved hvert tjek)

Standard forventede statuskoder

Monitors forventer som standard disse koder (kan tilpasses):

2xx Success:

200 OK
201 Created
204 No Content

3xx Redirects:

301 Moved Permanently
302 Found
307 Temporary Redirect
308 Permanent Redirect

Brugerdefineret:

Du kan konfigurere hvilke statuskoder der er acceptable for din specifikke monitor
Eksempel: Accepter 401 for password-beskyttede sider

Svartidsmåling

Hvad måles:

DNS lookup-tid
Forbindelsestid (TCP handshake)
SSL handshake-tid (hvis HTTPS)
Time to first byte (TTFB)

Hvad måles IKKE:

Body download-tid (vi læser kun headers)
JavaScript-eksekveringstid
Asset-indlæsningstid

Lagring:

Målt i millisekunder
Gemt ved hvert tjek
Bruges til performance-tracking
Vises i dashboardet

Avancerede overvågningsindstillinger

For avancerede brugere tilbyder vi:

HTTP-metode

GET: Standard metode
POST: For endpoints der kræver POST

Request body

Send JSON eller form data med POST-requests
Nyttigt til API-endpoints der kræver specifikke data

Basic authentication

Username og password for beskyttede endpoints
Passwords krypteres med AES-256-CBC
Aldrig gemt i klartekst

Future features

Custom headers
Request params
Advanced authentication (OAuth, Bearer tokens)

Privatliv og sikkerhed

Datakryptering

Følsomme credentials:

Alle passwords (Basic Auth) krypteres ved lagring
Algoritme: AES-256-CBC (industry standard)
Nøgle: Gemt sikkert i environment variables
IV: Unik initialization vector per kryptering
Decryption sker kun i hukommelsen under tjek
Aldrig eksponeret i logs eller API responses

Dataadgang

Adgangskontrol:

Tjek-resultater kun synlige for monitor-ejeren
Ingen data deles med tredjeparter
Aktivitetslog kun eksporterbar af ejeren
Sikre API-endpoints med authentication

Database-sikkerhed:

Prepared statements (forhindrer SQL injection)
Session-baseret authentication
CSRF-beskyttelse på alle formularer

HTTPS enforcement

SSL/TLS:

Alle monitor-tjek understøtter HTTPS
SSL-certifikat-validering aktiveret
Advarer ved certifikatproblemer
Detekterer udløbne certifikater

Dashboard:

Altid tilgået via HTTPS
Secure cookies (HttpOnly, Secure flags)
HSTS headers anbefalet

Systempålidelighed

Monitor system sundhed

Vores monitor-system overvåger sig selv:

Fejldetektion:

Automatisk opdagelse af interne fejl
Fuld logging af alle exceptions
Stack traces til debugging

Administrator-alarmer:

Kritiske fejl emailes til systemadministrator
Rate-limiteret for at undgå spam
Detaljer inkluderet for hurtig løsning

Automatisk Recovery:

Cron fortsætter ved fejl i enkelte monitors
Ingen cascade-fejl på tværs af monitors
Database-transaktioner sikrer data-integritet

Uptime-mål

Vi sigter efter følgende pålidelighed:

Monitor-system uptime:

Mål: 99.9% (mindre end 9 timer nedetid per år)
Overvåget: Via cron-log og system-metrics

Tjek-eksekveringsrate:

Mål: 99.5% succesrate for tjek-eksekvering
Overvåget: Fejlrate i logs

Cron-pålidelighed:

Overvåget: Hver cron-kørsel logges
Alerting: Ved manglende eksekvering

Almindelige scenarier og eksempler

Scenarie 1: Transient netværk blip

Situation: Kortvarigt netværksproblem, site er faktisk oppe.

00:00 - Tjek fejler (timeout) → Fejltæller: 1, Status: UP
00:05 - Tjek succeeds → Fejltæller: 0, Status: UP

Resultat:
✅ Ingen notifikation sendt
✅ Ingen status-ændring
✅ Ingen falsk alarm

Hvorfor det virker: 2-tjek-tærskel fanger kortvarige problemer.

Scenarie 2: Reel nedetid

Situation: Serveren er virkelig nede (f.eks. hosting-problem).

00:00 - Tjek fejler (HTTP 500) → Fejltæller: 1, Status: UP
      → System logger første fejl til intern overvågning

00:05 - Tjek fejler (timeout) → Fejltæller: 2, Status: DOWN
      → Incident oprettet automatisk
      → Notifikation sendt via email/Slack/webhook

00:10 - Tjek fejler (timeout) → Fejltæller: 3, Status: DOWN
      → Incident-varighed opdateres løbende

Resultat:
✅ DOWN-status bekræftet ved 00:05
✅ Notifikation sendt ~5 minutter efter første fejl
✅ Forskellige fejltyper (500 + timeout) tæller begge

Hvorfor det virker: To på hinanden følgende fejl bekræfter reelt problem.

Scenarie 3: Hurtig genoprettelse

Situation: Site nede, kommer hurtigt tilbage.

00:00 - Status er DOWN (fra tidligere fejl)
00:05 - Tjek succeeds (HTTP 200) → Fejltæller: 0, Status: UP
      → Incident markeres som løst automatisk
      → Recovery-notifikation sendt

Resultat:
✅ Øjeblikkelig genoprettelse ved første succesfulde tjek
✅ Incident-varighed beregnet (00:00 til 00:05 = 5 min)
✅ Du informeres hurtigt om recovery

Hvorfor det virker: Ingen 2-tjek-tærskel for genoprettelse.

Scenarie 4: Manuel refresh under første fejl

Situation: Automatisk tjek fejlede én gang, bruger vil verificere.

00:00 - Automatisk tjek fejler → Fejltæller: 1, Status: UP
      → Status forbliver UP (venter på bekræftelse)

00:02 - Du klikker "Opdater nu" → Tjek fejler → Status: DOWN omgående
      → Manuel tjek bypass 2-tjek-tærskel for hurtig feedback
      → Notifikation sendt

Resultat:
✅ Manuel tjek giver øjeblikkelig feedback
✅ Status opdateres uden at vente på næste automatiske tjek
✅ Nyttigt til debugging og verifikation

Hvorfor det virker: Manuelle tjek er designet til øjeblikkelig feedback.

Scenarie 5: Monitor-system fejl

Situation: Intern fejl i PingPuffin's egen kode.

00:00 - Monitor-system kører automatisk tjek
      → Intern fejl detekteres
      → Fejl fanges automatisk

      Logging:
      → Fejl logges med fuld kontekst til intern overvågning
      → Fuld teknisk information gemt til debugging

      Administrator-alarm:
      → Email sendt til systemadministrator (max 1 per time)
      → Indeholder fejl-detaljer og kontekst

      Database:
      → Ingen opdatering af din site status
      → Din site status forbliver uændret
      → Fejltæller påvirkes ikke

Resultat:
✅ Monitor-fejl påvirker IKKE din site-status
✅ Administrator alerteret for at kunne fikse problemet
✅ Ingen falsk DOWN-status

Hvorfor det virker: Skelnen mellem monitor-fejl og site-fejl.

Scenarie 6: Forskellige fejltyper på hinanden følgende

Situation: Server ustabil, forskellige fejl hver gang.

00:00 - Tjek fejler (HTTP 500) → Fejltæller: 1, Status: UP
00:05 - Tjek fejler (Connection timeout) → Fejltæller: 2, Status: DOWN
00:10 - Tjek fejler (HTTP 503) → Fejltæller: 3, Status: DOWN

Resultat:
✅ Forskellige fejltyper tæller ALLE med
✅ Status DOWN efter 2 fejl (uanset type)
✅ Indikerer ustabil server (måske værre end én konsistent fejl)

Hvorfor det virker: Enhver fejl betyder site ikke fungerer korrekt.

Ofte Stillede Spørgsmål

Hvor hurtigt får jeg besked om nedetid?

Automatisk tjek: ~5-10 minutter efter første fejl (kræver 2 fejl).
Manuel tjek: Øjeblikkeligt hvis du opdaterer manuelt.

Kan jeg få falske alarmer?

Meget sjældent. 2-tjek-systemet eliminerer langt de fleste kortvarige problemer. Hvis du får en alarm, er der næsten altid et reelt problem.

Hvad hvis min server er midlertidigt langsom?

Hvis svartiden overstiger timeout (standard 30 sek), tæller det som fejl. Du kan øge timeout-værdien for dit monitor.

Hvordan håndteres planlagt vedligeholdelse?

Brug "Snooze"-funktionen til at slå notifikationer fra i 24 timer. Overvågning fortsætter, men du får ingen alarmer.

Kan jeg se historik for alle tjek?

Ja, aktivitetsloggen viser alle tjek og status-ændringer. Du kan også eksportere til CSV.

Hvad sker der hvis PingPuffin selv går ned?

Vores monitors kører på pålidelig infrastruktur. Ved kritiske systemfejl alerteres administrator, men dit site markeres IKKE som nede.

Kontakt & Support

Har du spørgsmål til, hvordan overvågningen fungerer?

📧 Email: support@pingpuffin.com
🐛 Bug reports: Via email
📚 Dokumentation: Se dokumentationssektionen for mere information

Changelog

v1.0 (21. november 2024)

Første version af dokumentation
2-tjek verifikationssystem implementeret
Monitor-fejl beskyttelse tilføjet
Rate-limiterede administrator-alarmer

Dette dokument opdateres løbende. Tjek "Sidst opdateret" øverst for at se, om der er nye versioner.