Slik drifter du Fathom Lite selv i 2026: sporingsskript, SQLite og personvern

Det finnes to versjoner av «å kjøre Fathom Lite»: enten finnes det en container, eller så fullfører tjenesten den faktiske oppgaven sin. Det er bare den siste som betyr noe. Her er beviset å legge til et nettsted, laste inn sporingsskriptet på en testsiden, generere besøk og bekrefte at kontrollpanelet registrerer dem uten cookies.

Fathom Lite er laget for dette: cookie-fri, selvhostet analyse av sidevisninger. Distribusjonen må bevare komponentene som gir denne funksjonaliteten; en port, et volume og et sertifikat er forutsetninger, ikke selve resultatet.

Legitimasjon, roller og eksponerte flater

For Fathom Lite er den verdifulle flaten ikke nødvendigvis landingssiden. Den vanligste feilen er å gjenbruke en eksempelhemmelighet eller eksponere admin-påloggingen uten TLS. Motvirk dette bevisst: Beskytt analysepåloggingen, hold applikasjonshemmeligheten stabil og publiser bare skriptet fra den forventede HTTPS-verten.

Behandle FATHOM_SECRET i tråd med rollen den har i Fathom Lite: hold sensitive verdier utenfor Git, dokumenter konsekvensene av rotasjon og bruk aldri et offentlig eksempel i produksjon. Bruk en containerbruker uten privilegier når imaget støtter det, og mount ingen uvedkommende legitimasjoner. Bruk begrensninger på rate eller størrelse ved ingress der upålitelige forespørsler kan forbruke kapasitet til skriving av sidevisninger, databaseindekser, retention og nettverksbanen fra besøkendes nettlesere.

Skill Fathom Lite fra avhengighetene

Den minste forsvarlige topologien for Fathom Lite består av én privat listener på 8080, en ingress-rute og en dokumentert state-grense. Nettverkskontrakten for Fathom Lite er SQLite eller en støttet ekstern database, samt korrekt plassering av skriptet på klientsiden. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Fathom Lite en avgrenset service-legitimasjon.

Valider topologien ved å be en ren klient om å legge til et nettsted, laste inn sporingsskriptet på en testside, generere besøk og bekrefte at kontrollpanelet registrerer dem uten cookies. Følg med på skrivehastigheten for sidevisninger, databaseindekser, retention og nettverksbanen fra besøkendes nettlesere mens den kjører. Resultatet forteller deg om den neste forbedringen hører hjemme i minne, lagring, nettverk eller en separat worker, i stedet for å oppmuntre til vilkårlig dimensjonering av containere.

Et Docker-grunnoppsett for Fathom Lite

En minimal kommando er nyttig når den synliggjør hva plattformen senere skal administrere.

docker run -d \
  --name fathom-lite \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v fathom-lite-data:/app \
  -e FATHOM_SECRET=replace-with-a-long-random-value \
  -e FATHOM_SERVER_ADDR=:8080 \
  -e FATHOM_DATABASE_DRIVER=sqlite3 \
  -e FATHOM_DATABASE_NAME=/app/fathom.db \
  usefathom/fathom:latest

Her forblir port 8080 privat på verten, og alle nødvendige stier er eksplisitte. Legg til de gjennomgåtte tilkoblingsinnstillingene for SQLite eller en støttet ekstern database, samt korrekt plassering av skriptet på klientsiden; bruk private navn for private tjenester. Bekreft oppstart med både logger og det applikasjonsspesifikke beviset: legg til et nettsted, last inn sporingsskriptet på en testside, generer besøk og bekreft at kontrollpanelet registrerer dem uten cookies. Når dette er bekreftet, låser du image-versjonen slik at en vanlig utskifting ikke endrer funksjonaliteten i det stille.

Bevis at Fathom Lite-distribusjonen fungerer fra ende til ende

Opprett en liten, midlertidig Fathom Lite-fixture og behold den for hver release. Fixturen bør utøve den faktiske arbeidsflyten: legg til et nettsted, last inn sporingsskriptet på en testside, generer besøk og bekreft at kontrollpanelet registrerer dem uten cookies. Registrer image-digest, ekstern hostname, adressen til avhengigheten og forventet resultat, slik at en senere operatør kan gjenta testen uten å tolke denne veiledningen.

Kjør fixturen tre ganger. Først bruker du den nye distribusjonen. Deretter erstatter du containeren uten å endre persistent state. Til slutt gjenoppretter du sikkerhetskopien i et tomt miljø. Den tredje kjøringen består bare når nettsteder, brukere og historiske sidevisninger kommer tilbake, og et nytt testbesøk vises etter gjenopprettingen. Registrer under hver kjøring latenstid og ressursbruk for skrivehastigheten for sidevisninger, databaseindekser, retention og nettverksbanen fra besøkendes nettlesere. Dette blir grunnlaget for varsler, i stedet for en vilkårlig CPU-prosent.

Test til slutt den negative banen bevisst: nekt testidentiteten tilgang til SQLite eller en støttet ekstern database, samt korrekt plassering av skriptet på klientsiden. Bekreft at Fathom Lite feiler synlig uten å ødelegge state, gjenopprett den korrekte tilstanden og gjenta den vellykkede transaksjonen. En release-oppføring som inneholder disse fire resultatene, er sterkere dokumentasjon enn skjermbilder av et kontrollpanel eller en enkelt curl-respons.

Hold interne og eksterne URL-er adskilt

Den offentlige grensen for Fathom Lite bør være ett kanonisk hostname, automatisk TLS og ett internt mål på 8080. Angi serveradressen og det offentlige HTTPS-endepunktet som brukes av sporingsskriptet, slik at klientene går tilbake til en adresse tjenesten kjenner igjen.

Hvis akseptansetransaksjonen feiler, klassifiserer du den første feilen. DNS-, sertifikat- og 502-problemer hører hjemme i sjekklisten for TLS-validering. Tilstanden «sporingsskriptet peker på feil hostname, eller databasebanen er ephemeral» hører hjemme på applikasjonssiden etter at en forespørsel har nådd Fathom Lite.

Feiløvelser for Fathom Lite

Kapasitetstester bør utøve skrivehastigheten for sidevisninger, databaseindekser, retention og nettverksbanen fra besøkendes nettlesere – ikke sende den samme forespørselen til / gjentatte ganger. Kjør scenarioet «legg til et nettsted, last inn sporingsskriptet på en testside, generer besøk og bekreft at kontrollpanelet registrerer dem uten cookies» med realistisk samtidighet, og registrer latenstid, feilrate og vekst i lagringsforbruket.

Planlegging av oppgraderinger må ta høyde for denne risikoen: Fathoms databaseskjema og sporingsskript bør testes sammen for å unngå at hendelser forsvinner i det stille. Test den nye releasen med representative inndata, gjenta deretter akseptansetransaksjonen og sammenlign resultatet. Hvis sporingsskriptet peker på feil hostname, eller databasebanen er ephemeral, registrerer du den mislykkede transaksjonen og undersøker den første involverte grensen i stedet for å anta at ingress er ansvarlig.

Bevis at Fathom Lite overlever en utskifting

Et container-image kan lastes ned på nytt; analysedatabasen, nettstedskonfigurasjonen og administratorstatusen kan ikke det. Mount /app før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Kontroller det effektive mountet i stedet for å stole på et Compose-filnavn, og sjekk at runtime-brukeren kan skrive der Fathom Lite forventer det.

Velg retention og et mål utenfor verten, og øv på gjenoppretting uten å berøre produksjon. Øvelsen består bare når nettsteder, brukere og historiske sidevisninger kommer tilbake, og et nytt testbesøk vises etter gjenopprettingen. For databasebasert state kombinerer du lagringssnapshots med applikasjonskonsistente eksporter, som beskrevet i point-in-time recovery versus snapshots.

Koble Fathom Lite til Dockups livssyklus

Dockups ettklikksdistribusjon av Fathom Lite bør gjøre utskifting trygg: Ruten fortsetter å peke på 8080, hemmeligheter bygges ikke inn i imaget, og persistente stier kommer tilbake i den nye containeren. Den samme distribusjonen kan kjøre på Dockup compute eller en tilkoblet maskin.

Fullfør det applikasjonsspesifikke arbeidet ved å koble til og teste SQLite eller en støttet ekstern database, samt korrekt plassering av skriptet på klientsiden. Bruk den kanoniske offentlige adressen og kjør denne akseptansesjekken: legg til et nettsted, last inn sporingsskriptet på en testside, generer besøk og bekreft at kontrollpanelet registrerer dem uten cookies. Legg inn resultatet fra gjenopprettingen i runbooken før de reelle brukerne kommer til.

Vanlige spørsmål

Hva trenger Fathom Lite for en produksjonsdistribusjon?

Rout Fathom Lite-containeren via port 8080 gjennom én HTTPS-origin. Det støttende nettverkskravet er SQLite eller en støttet ekstern database, samt korrekt plassering av skriptet på klientsiden. Ikke regn Fathom Lite som klart før du kan legge til et nettsted, laste inn sporingsskriptet på en testside, generere besøk og bekrefte at kontrollpanelet registrerer dem uten cookies.

Hvilke Fathom Lite-data bør inngå i en sikkerhetskopi?

Gjør /app persistent, og inkluder analysedatabasen, nettstedskonfigurasjonen og administratorstatusen i det samme recovery-manifestet. En ren Fathom Lite-gjenoppretting består bare når nettsteder, brukere og historiske sidevisninger kommer tilbake, og et nytt testbesøk vises etter gjenopprettingen.

Krever Fathom Lite HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Fathom Lite-origin-en, og behold port 8080 på den interne ruten. Bruk Fathom Lite-innstillingen korrekt: angi serveradressen og det offentlige HTTPS-endepunktet som brukes av sporingsskriptet. For Fathom Lite beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for at opprinnelsessensitiv klientatferd forblir konsistent.

Hvordan bør en Fathom Lite-oppgradering testes?

Gjenopprett gjeldende Fathom Lite-state i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på dette, fordi Fathoms databaseskjema og sporingsskript bør testes sammen for å unngå at hendelser forsvinner i det stille. Behold det forrige Fathom Lite-imaget til grensen for datamigrering og rollback er forstått.