Det här sätter du upp
GlitchTip samlar in felen som dina appar kastar, grupperar dem i ärenden och visar vart och ett med stack trace, vilken release det kom från och hur ofta det inträffar. Den mäter också hur lång tid anrop och jobb tar, kontrollerar att dina webbplatser är uppe och skickar larm via e-post eller till en chatt. Dina appar pratar med den via Sentrys officiella SDK:er, för Python, JavaScript, PHP, Go, Java, Ruby och många fler, så en app som redan rapporterar till Sentry behöver bara en ny adress.
GlitchTip görs av Burke Software and Consulting, ett litet mjukvaruföretag som också säljer den som en färdig tjänst, och utvecklas öppet på GitLab. Den är öppen källkod under MIT-licensen. Sentry, som den är kompatibel med, går också att köra på en egen server, men det är ett annat slags projekt. Koden ligger under Functional Source License, som Sentry själva kallar Fair Source och inte öppen källkod: du får köra den för eget bruk, varje version blir Apache 2.0 efter två år, och du får inte erbjuda den som en konkurrerande tjänst. Den egeninstallerade versionen kör Kafka, ClickHouse, Redis, PostgreSQL och många andra containrar, och Sentrys dokumentation kräver minst 4 CPU-kärnor, 16 GB minne plus 16 GB swap och 20 GB ledigt diskutrymme (kontrollerat den 14 oktober 2026). Den har också funktioner som GlitchTip saknar, som session replay, profilering och release health. För ett litet team som vill ha fel, prestanda och driftkontroller klarar GlitchTip det med en container och en databas.
Här körs GlitchTip som en pod under en egen användare som heter glitchtip, med PostgreSQL för dess data, bakom Caddy från Podman-guiden.
Varje steg nedan har körts på en nyinstallerad Melonslab VC-P Alloy (2 vCPU, 8 GB) med Debian 13:
- GlitchTip 6.2.6 startade med PostgreSQL 18 och utan Valkey eller Redis. Det första kontot och organisationen skapades via en SSH-tunnel innan Caddy sattes upp. Efter det sa registreringssidan "Registration is currently unavailable", och en andra användare kunde inte skapa någon organisation.
- Ett team, ett Python-projekt och ett Node.js-projekt skapades, och en kollega gick med via en inbjudan per e-post.
- En liten Python-app skickade ett fel med Sentrys officiella SDK. GlitchTip visade det med stack trace, källkodsraderna och de lokala variablerna, och appens jobb på 200 ms under Performance. Ärendet löstes, öppnades igen när samma fel kom från en ny release och utlöste ett larm via e-post och webhook.
- En minifierad Node.js-app skickade ett fel, och med dess source maps uppladdade av
sentry-clivisade GlitchTip originalfilen, funktionsnamnen och raderna. - Driftkontroller bevakade en app på samma server och en heartbeat från ett schemalagt jobb, och skickade larm när var och en gick ner och kom tillbaka.
- En avlyssning av serverns trafik visade inga anslutningar som vi inte själva hade satt upp, och webbläsaren laddade inget från andra webbplatser.
- En uppdatering från GlitchTip 6.2.3 till 6.2.6 gick igenom med
podman auto-updateoch körde databasmigreringarna av sig själv. GlitchTip återställdes från en säkerhetskopia till tomma volymer, och allt startade igen av sig självt efter en omstart av servern.
Podden använde omkring 250 MB minne: omkring 200 MB för GlitchTip och resten för PostgreSQL. Gränssnittet finns bara på engelska.
Innan du börjar
Du behöver:
- en server uppsatt som i Podman-guiden, med Caddy igång;
- en A-post och en AAAA-post för
errors.example.comsom pekar på din server; - ett e-postkonto som GlitchTip kan skicka från, för inbjudningar, återställning av lösenord och larm (steg 7).
Exemplen använder errors.example.com för GlitchTip, 203.0.113.10 för serverns IPv4-adress, Example för organisationen, anna@example.com för dig och bob@example.com för en kollega. Byt ut dem genomgående.
1. Skapa användaren
Som root:
useradd -m -s /bin/bash glitchtip
loginctl enable-linger glitchtip
machinectl shell glitchtip@
Allt fram till steg 6 körs som glitchtip.
2. Låt GlitchTip nå den här servern
En rootless container delar normalt serverns egna adresser, så en driftkontroll eller en webhook mot en app på den här servern, till exempel https://wiki.example.com, skulle nå containern själv i stället för Caddy. Ge den här användarens containrar egna adresser i stället. Skapa ~/.config/containers/containers.conf:
[network]
# Give containers their own address, so that the server's public address, and the apps behind Caddy, can be reached from them.
pasta_options = ["-a", "10.0.2.0", "-n", "24", "-g", "10.0.2.2", "--dns-forward", "10.0.2.3", "-a", "fd00::2", "-g", "fd00::1"]
Samma inställning låter testapparna i steg 9 och 10 skicka sina fel till https://errors.example.com från den här servern. Det är den andra lösningen i steg 8 i Podman-guiden, och ingen av förändringarna som står där påverkar GlitchTip.
3. Skapa hemligheterna
openssl rand -hex 32 | tr -d '\n' | podman secret create glitchtip-secret-key -
openssl rand -hex 24 | tr -d '\n' | podman secret create glitchtip-db-password -
Den första är GlitchTips hemliga nyckel, som signerar inloggningar och länkarna i dess e-post. Den andra är databaslösenordet. Båda lagras av Podman, inte i filerna nedan.
4. Definiera podden
mkdir -p ~/.config/containers/systemd
cd ~/.config/containers/systemd
Skapa glitchtip.pod:
[Pod]
PodName=glitchtip
# Only Caddy, on this server, can reach GlitchTip: the port is not open to the internet.
PublishPort=127.0.0.1:8191:8000
[Install]
WantedBy=default.target
Skapa glitchtip-db.container:
[Container]
ContainerName=glitchtip-db
Image=docker.io/library/postgres:18
Pod=glitchtip.pod
Volume=glitchtip-db:/var/lib/postgresql
Environment=POSTGRES_USER=glitchtip POSTGRES_DB=glitchtip
Secret=glitchtip-db-password,type=env,target=POSTGRES_PASSWORD
HealthCmd=pg_isready -h 127.0.0.1 -U glitchtip -d glitchtip
HealthInterval=10s
Notify=healthy
AutoUpdate=registry
[Service]
Restart=always
Och glitchtip-web.container:
[Unit]
Requires=glitchtip-db.service
After=glitchtip-db.service
[Container]
ContainerName=glitchtip-web
Image=docker.io/glitchtip/glitchtip:6
Pod=glitchtip.pod
Volume=glitchtip-uploads:/code/uploads
Environment=SERVER_ROLE=all_in_one VALKEY_URL=
Environment=GLITCHTIP_DOMAIN=https://errors.example.com ALLOWED_HOSTS=errors.example.com,localhost
Environment=DATABASE_HOST=127.0.0.1 DATABASE_NAME=glitchtip DATABASE_USER=glitchtip
Environment=ENABLE_USER_REGISTRATION=false ENABLE_ORGANIZATION_CREATION=false
Environment=GLITCHTIP_RETENTION_DAYS=90
Secret=glitchtip-db-password,type=env,target=DATABASE_PASSWORD
Secret=glitchtip-secret-key,type=env,target=SECRET_KEY
AutoUpdate=registry
[Service]
Restart=always
TimeoutStartSec=300
Vad inställningarna gör:
SERVER_ROLE=all_in_onekör webbservern och bakgrundsprocessen, som tar hand om händelser och skickar larm, i samma container. GlitchTip kan dela upp dem i separata containrar förwebochworkerför att klara mer trafik; det behöver ett litet team inte.VALKEY_URL=lämnat tomt säger åt GlitchTip att inte använda Valkey eller Redis. Sedan GlitchTip 6 håller PostgreSQL både uppgiftskön och cachen, och äldre guider som startar en Redis-container är inaktuella. GlitchTips exempeluppsättning har fortfarande Valkey som ett val för servrar med mer trafik.GLITCHTIP_DOMAINär den publika adressen som GlitchTip sätter i länkar, e-post och dina projekts DSN.ALLOWED_HOSTSgör att den bara svarar på det namnet, och pålocalhostför steg 5.ENABLE_USER_REGISTRATION=falsestänger registreringssidan, ochENABLE_ORGANIZATION_CREATION=falsehindrar användare från att skapa egna organisationer. GlitchTip låter ändå det allra första kontot registrera sig, och därför skapar steg 5 det innan webbplatsen är ute på nätet.GLITCHTIP_RETENTION_DAYSär hur länge händelser, prestandadata och driftkontroller sparas. Steg 14 har mer.- Databaslösenordet når GlitchTip som
DATABASE_PASSWORD, skilt från de andra databasinställningarna, så att det stannar i hemligheten. Source maps och andra uppladdade filer hamnar i volymenglitchtip-uploads; allt annat ligger i databasen.
Starta den:
systemctl --user daemon-reload
systemctl --user start glitchtip-pod
systemctl --user enable --now podman-auto-update.timer
Vid första starten laddas omkring 1,2 GB avbilder ner, och GlitchTip behöver en minut för att sätta upp sin databas. Den är klar när det här skriver ut 200:
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8191/
podman logs glitchtip-web börjar med en sammanfattning av inställningarna, till exempel Email: disabled (no transport configured), Cache/Queue: Database och Event retention: 90 days.
5. Skapa ditt konto
Det första kontot på en ny GlitchTip kan alltid registrera sig, och det gäller även den första organisationen, oavsett vem som skapar dem. Skapa båda innan webbplatsen är ute på nätet, via en SSH-tunnel. På din egen dator:
ssh -L 8191:localhost:8191 root@203.0.113.10
Låt anslutningen vara öppen och öppna http://localhost:8191 i webbläsaren. Välj Sign Up, ange din e-postadress och ett lösenord och välj Register. GlitchTip loggar in dig och ber om en organisation: ange dess Name, till exempel Example, och välj Create Organization. Namnet blir en del av adresserna, som /example/issues.
Stäng tunneln med exit.
6. Sätt Caddy framför
Gå tillbaka till root med exit, byt till Caddys användare med machinectl shell caddy@ och lägg till det här blocket sist i ~/Caddyfile:
errors.example.com {
reverse_proxy 127.0.0.1:8191
}
Starta om Caddy med systemctl --user restart caddy, öppna https://errors.example.com och logga in. https://errors.example.com/register säger nu "Registration is currently unavailable. Contact your server administrator."
Under Profile > MFA kan du lägga till en autentiseringsapp eller en säkerhetsnyckel för ditt konto. GlitchTip ber dig då först bekräfta din e-postadress, vilket kräver e-post från steg 7.
7. E-post
GlitchTip skickar e-post för inbjudningar, återställning av lösenord, bekräftelse av e-postadresser och larm. Utan e-post startar GlitchTip och fungerar, men:
- en inbjudan säger "An email invite has been sent" utan att något skickas, så personen kan inte gå med;
- Reset Password på inloggningssidan skickar ingenting;
- tvåfaktorsinloggning går inte att sätta upp, eftersom e-postadressen inte kan bekräftas;
- larm kan bara gå till webhooks.
Skicka via din e-postleverantörs SMTP-server. Som glitchtip sparar du lösenordet som en hemlighet:
printf %s 'the-smtp-password' | podman secret create glitchtip-mail-password -
Lägg sedan till de här raderna i glitchtip-web.container, efter de andra Environment=-raderna, med din egen server, ditt konto och din avsändaradress:
Environment=EMAIL_HOST=smtp.example.com EMAIL_PORT=587 EMAIL_USE_TLS=true
Environment=EMAIL_HOST_USER=errors@example.com DEFAULT_FROM_EMAIL=errors@example.com
Secret=glitchtip-mail-password,type=env,target=EMAIL_HOST_PASSWORD
Och starta om:
systemctl --user daemon-reload
systemctl --user restart glitchtip-web
Loggen visar nu Email: SMTP. Port 587 med EMAIL_USE_TLS=true använder STARTTLS; för port 465, som använder TLS från början, sätter du EMAIL_PORT=465 och EMAIL_USE_SSL=true i stället för EMAIL_USE_TLS. Kontrollera det med Reset Password på inloggningssidan och din egen adress. Vi testade att skicka mot en e-postfångare på servern, där inbjudan, återställningen av lösenord, bekräftelsen av adressen och varje larm kom fram; vi skickade inte via en riktig leverantör.
8. Team, projekt och personer
I GlitchTip har en organisation team, och varje projekt, oftast en app, hör till ett team. Larm via e-post går till medlemmarna i projektets team.
Välj Projects och sedan Create new project in Example. Välj Platform, till exempel Python, och ge projektet ett Name, till exempel shop-api. Under namnet skapar Create a team ett team, till exempel backend, och lägger till dig i det. Välj Create Project. GlitchTip visar sedan hur du installerar SDK:n, med projektets DSN ifyllt, en adress som https://4f1c…@errors.example.com/1. DSN:en talar om för SDK:n vart händelserna ska skickas; det är inget lösenord, och den hamnar i frontend-kod som vem som helst kan läsa. Du hittar den igen under projektets Settings, i Client Keys (DSN).
Med registreringen stängd bjuder GlitchTip bara in personer som redan har ett konto. Skapa Bobs konto som glitchtip, utan lösenord:
podman exec glitchtip-web ./manage.py shell -c 'from apps.users.models import User; User.objects.create_user("bob@example.com", None)'
Välj sedan Organization > Members > Invite Member, ange hans adress, välj en Role och ett Team, och välj Add Member(s). Bob får en inbjudan per e-post. Han sätter sitt lösenord med Reset Password på inloggningssidan, loggar in och öppnar länken i inbjudan för att gå med. Member kan se och hantera ärenden; Admin, Manager och Owner kan också ändra projekt, team och medlemmar.
9. Skicka ditt första fel från Python
För att se att det fungerar innan du ändrar i en riktig app skickar du ett fel från ett litet skript i en tillfällig Python-container på servern. Som glitchtip:
mkdir -p ~/sdk-test && cd ~/sdk-test
Skapa app.py:
import os, time
import sentry_sdk
sentry_sdk.init(
dsn=os.environ["SENTRY_DSN"],
release=os.environ.get("RELEASE", "shop-api@1.0.0"),
environment="production",
traces_sample_rate=1.0,
)
def average(values):
return sum(values) / len(values)
def nightly_report(orders):
return {"average": average([o["total"] for o in orders])}
with sentry_sdk.start_transaction(op="task", name="nightly-report"):
with sentry_sdk.start_span(op="db.query", name="load orders"):
time.sleep(0.2)
orders = []
nightly_report(orders)
Kör det med DSN:en för ditt Python-projekt:
podman run --rm -v ./app.py:/app.py:ro -e RELEASE -e SENTRY_DSN='https://4f1c…@errors.example.com/1' \
docker.io/library/python:3.13-slim sh -c 'pip install -q --root-user-action=ignore sentry-sdk && python /app.py'
Skriptet slutar med ZeroDivisionError: division by zero, och SDK:n skickar felet när det avslutas. Under Issues visar GlitchTip ZeroDivisionError: division by zero. Öppna det för att se stack trace, från <module> via nightly_report till average, med källkodsraderna runt varje anrop och värdet på values, som var [], plus release, miljö och Python-version. Performance listar jobbet nightly-report och hur lång tid det tog.
I en riktig app placerar du anropet sentry_sdk.init() där appen startar. traces_sample_rate är andelen anrop och jobb vars tider skickas: 1.0 skickar alla, vilket går bra för ett test; använd något som 0.1 i produktion, eftersom varje mätning sparas. GlitchTip visar sina egna instruktioner för varje plattform när du skapar ett projekt.
10. JavaScript och source maps
Minifierad JavaScript ger stack traces fulla av namn på en bokstav. Ladda upp source maps från ditt bygge, så visar GlitchTip originalkoden. Det fungerar med Sentrys sentry-cli, på samma sätt som mot Sentry.
Skapa först en token för uppladdningar: Profile > Auth Tokens > Create New Token, ge den en Label, kryssa i project:read, project:releases och org:read, och välj Create Token. Skapa sedan ett projekt med plattformen Node.js och namnet shop-web, som i steg 8.
Som glitchtip gör du en liten app:
mkdir -p ~/js-test/src && cd ~/js-test
Skapa src/app.js:
const Sentry = require("@sentry/node");
Sentry.init({
dsn: process.env.SENTRY_DSN,
release: "shop-web@1.0.0",
environment: "production",
tracesSampleRate: 1.0,
});
function parsePrice(text) {
return Number(text.trim().replace(",", "."));
}
function cartTotal(items) {
return items.reduce((sum, item) => sum + parsePrice(item.price) * item.qty, 0);
}
Sentry.startSpan({ name: "checkout", op: "task" }, () => {
cartTotal([{ price: "12,50", qty: 2 }, { price: undefined, qty: 1 }]);
});
Klistra in token när det här väntar på den, så att den inte hamnar i skalets historik:
read -rs SENTRY_AUTH_TOKEN && export SENTRY_AUTH_TOKEN
Bygg sedan appen minifierad, med source maps, och ladda upp dem:
podman run --rm -v .:/app -w /app -e SENTRY_AUTH_TOKEN -e SENTRY_URL=https://errors.example.com \
-e SENTRY_ORG=example -e SENTRY_PROJECT=shop-web docker.io/library/node:22-slim sh -c '
npm init -y >/dev/null
npm install --silent @sentry/node
npm install --silent --save-dev esbuild @sentry/cli
npx esbuild src/app.js --bundle --minify --sourcemap --platform=node --packages=external --outfile=dist/app.js
npx sentry-cli sourcemaps inject dist
npx sentry-cli sourcemaps upload --release shop-web@1.0.0 dist'
sourcemaps inject skriver ett debug-ID i den byggda filen och dess source map, och sourcemaps upload skickar båda till GlitchTip och avslutar med en Source Map Upload Report. Kör nu den minifierade appen med projektets DSN:
podman run --rm -v .:/app -w /app -e SENTRY_DSN='https://9a2e…@errors.example.com/2' \
docker.io/library/node:22-slim node dist/app.js
På servern säger felet at c (/app/dist/app.js:3:167). I GlitchTip visar samma fel ../src/app.js in parsePrice at line 11, med originalkoden. I ett riktigt projekt kör du de två sentry-cli-kommandona i bygget efter varje release, med token som en hemlighet i din CI. För appar i webbläsaren använder du @sentry/browser eller SDK:n för ditt ramverk i stället för @sentry/node.
11. Lös ärenden, regressioner och releaser
Öppna ett ärende och använd menyn Unresolved högst upp:
- Resolved stänger det. Om samma fel kommer tillbaka öppnar GlitchTip det igen. Vi löste Python-ärendet, körde skriptet igen med
RELEASE=shop-api@1.0.1framförpodman runfrån steg 9, och ärendet var olöst igen, med två händelser ochshop-api@1.0.1som senaste release. - Resolve in next release stänger det tills en händelse kommer från en nyare release.
- Ignored döljer det, för fel som du har bestämt dig för att leva med.
Releases listar varje release som har skickat händelser eller source maps. Det är release i SDK:n, som i exemplen, som låter dig se vilken version som tog tillbaka ett fel.
12. Driftkontroller
Välj Uptime Monitors > Add monitor. Typerna:
- GET och POST skickar ett anrop till en Site URL och väntar sig en lyckad statuskod; du kan också kräva ett ord i svaret.
- Ping skickar ett HTTP-anrop med
HEAD, inte en ICMP-ping. - TCP Port kontrollerar att en port svarar.
- Heartbeat fungerar åt andra hållet: ditt jobb anropar GlitchTip, och bevakningen går ner när anropet inte kommer i tid.
Varje bevakning hör till ett projekt, under Associated Project, och larmen går till det projektets team. Interval (seconds) är hur ofta den kontrollerar.
GlitchTip vägrar bevakningar av privata adresser, som http://127.0.0.1:8191/, med "There was an error saving your monitor details", så att användare inte kan undersöka ditt interna nätverk. Peka i stället bevakningarna mot webbplatsens publika adress; det är steg 2 som gör att det fungerar för webbplatser på den här servern.
En heartbeat passar för säkerhetskopiering och andra schemalagda jobb. Skapa en bevakning av typen Heartbeat med ett intervall som är lite längre än jobbets, och kopiera Endpoint URL från bevakningens sida. Låt sedan jobbet anropa den när det lyckas, till exempel i en crontab:
30 2 * * * /usr/local/bin/backup.sh && curl -fsS -X POST https://errors.example.com/api/0/organizations/example/heartbeat_check/160bc2c5-…/
I våra tester skickade en ny bevakning ett "back up"-mejl efter sin första kontroll, en stoppad app på den här servern gav "Test site is down" inom en minut, och en heartbeat som inte kom fram gav "Nightly backup is down".
13. Larm
Larm ställs in per projekt, under projektets Settings > Project Alerts > Create New Alert:
- Kryssa i If an event happens och ställ in Quantity och Timespan, till exempel
1gång på1minut för att få veta om varje nytt fel, eller högre för att bara få veta om fel som händer ofta. - Kryssa i If an uptime monitor is triggered för att också få projektets larm från driftkontrollerna.
- Recipients börjar med email, som går till medlemmarna i projektets team. Add An Alert Recipient lägger till en webhook: General (slack-compatible) Webhook, som också passar Mattermost och Rocket.Chat, Discord, Google Chat, ntfy, Microsoft Teams, Zulip eller Feishu (Lark) Webhook, med dess Webhook URL.
Välj submit. Med en händelse på en minut gav regressionen i steg 11 ett mejl, "Error in shop-api: ZeroDivisionError: division by zero", och skickade GlitchTip Alert med ärendets titel, länk, projekt, miljö och release till webhooken, omkring en minut efter händelsen. Larm från driftkontrollerna skickas som GlitchTip Uptime Alert. För pushnotiser i mobilen fungerar ntfy som mottagare.
Webhooks kan inte heller peka mot privata adresser, och GlitchTip följer inte omdirigeringar för dem. Varje användare kan också stänga av larmmejlen för ett projekt under Profile > Notifications.
14. Lagringstid och gränser
GlitchTip raderar händelser, prestandadata och driftkontroller som är äldre än GLITCHTIP_RETENTION_DAYS, 90 dagar som standard. Äldre guider kallar den GLITCHTIP_MAX_EVENT_LIFE_DAYS, som fortfarande fungerar. För att spara 30 dagar ändrar du raden i glitchtip-web.container, kör sedan daemon-reload och startar om glitchtip-web som i steg 7. Loggen visar då Event retention: 30 days. GLITCHTIP_EVENT_RETENTION_DAYS, GLITCHTIP_TRANSACTION_RETENTION_DAYS och GLITCHTIP_UPTIME_RETENTION_DAYS ställer in varje sort för sig.
Varje händelse kontrolleras för storlek när den kommer in. I våra tester avvisades en komprimerad händelse som blev större än 5 MB uppackad med Cannot parse request body, och ett anrop större än 15 MB fick 413. Den första gränsen är GLITCHTIP_MAX_UNZIPPED_PAYLOAD_SIZE. SDK:erna komprimerar det de skickar och kortar stora värden innan de gör det.
GlitchTip begränsar inte själv hur många händelser ett projekt får skicka på din egen server: 60 händelser som skickades samtidigt togs alla emot. En loop som kastar fel fyller databasen. Håll nere antalet i SDK:n, med sample_rate för fel och traces_sample_rate för prestanda, och håll koll på disken med df -h och podman system df.
15. Externa anslutningar
GlitchTip gör inga egna anslutningar. Vi avlyssnade serverns DNS-uppslagningar och utgående anslutningar medan GlitchTip startade, tog emot händelser och source maps och skickade larm. De enda var de vi själva hade satt upp: driftkontrollerna, webhookarna, e-postservern och testapparna som skickade till errors.example.com. Den letade inte efter uppdateringar och skickade inga användningsdata. I webbläsaren laddades varje sida bara från errors.example.com.
SDK:erna i dina appar skickar sina händelser bara till adressen i DSN:en. Varje händelse kan innehålla anropsdata, lokala variabler och uppgifter om användaren. Python-SDK:n utelämnar personuppgifter om du inte sätter send_default_pii=True, och GlitchTip kan ta bort hemligheter ur händelser när de kommer in; se GLITCHTIP_PII_SCRUB_DEFAULT i dess dokumentation, som vi inte har testat.
16. Säkerhetskopiera
Som glitchtip:
umask 077
mkdir -p ~/backup
podman exec glitchtip-db pg_dump -U glitchtip -Fc glitchtip > ~/backup/glitchtip-db.dump
podman volume export glitchtip-uploads > ~/backup/glitchtip-uploads.tar
podman secret inspect --showsecret --format '{{.SecretData}}' glitchtip-secret-key > ~/backup/secret-key.txt
Databasen innehåller användare, organisationer, projekt, ärenden, händelser, bevakningar och larm. Volymen innehåller de uppladdade source maps. Dumpen körs medan GlitchTip fortsätter att fungera. Kopiera ~/backup till en annan maskin, till exempel med restic, och förvara den säkert: händelserna kan innehålla dina användares data.
För att återställa till en tom pod, som glitchtip, med säkerhetskopian i ~/backup:
systemctl --user stop glitchtip-pod
podman volume rm glitchtip-db glitchtip-uploads
podman volume create glitchtip-uploads
podman volume import glitchtip-uploads ~/backup/glitchtip-uploads.tar
systemctl --user start glitchtip-db
podman exec -i glitchtip-db pg_restore -U glitchtip -d glitchtip --no-owner < ~/backup/glitchtip-db.dump
systemctl --user start glitchtip-web
Genom att bara starta databasen först läses säkerhetskopian in innan GlitchTip sätter upp en tom databas. På en ny server sätter du upp allt som i steg 1 till 4, men före den första starten skapar du den hemliga nyckeln från säkerhetskopian i stället för en ny i steg 3:
tr -d '\n' < ~/backup/secret-key.txt | podman secret create glitchtip-secret-key -
17. Uppdatera
podman auto-update letar en gång om dagen efter nya avbilder av GlitchTip och PostgreSQL och startar om podden när någon har ändrats. GlitchTip kör sina databasmigreringar när den startar, vilket syns som rader med Applying … i loggen. För att uppdatera direkt:
podman auto-update
Taggen 6 följer varje version av GlitchTip 6, och 18 varje version av PostgreSQL 18. En ny huvudversion, som GlitchTip 7, kräver att du byter tagg, vilket GlitchTip meddelar på sin blogg. Läs ändringsloggen innan du byter, och säkerhetskopiera först. Vissa uppdateringar ändrar lagrade data: uppdateringen från 6.2.3 till 6.2.6 tömde historiken för driftkontrollerna, som ändringsloggen sa, medan bevakningar och larm fortsatte att fungera.
Felsökning
curl http://localhost:8191/ skriver ut 400. Namnet du använde finns inte i ALLOWED_HOSTS. Även http://127.0.0.1:8191/ får 400; använd localhost.
"Only existing users may be invited". Registreringen är stängd, så personen behöver ett konto först. Skapa det som i steg 8.
En inbjudan säger att den har skickats, men inget kommer fram. E-post är inte uppsatt, eller inställningarna är fel. De första raderna i podman logs glitchtip-web visar Email: disabled eller Email: SMTP, och fel från e-postservern syns längre ner.
En driftkontroll eller en webhook för en app på den här servern misslyckas, medan appen fungerar i din webbläsare. containers.conf från steg 2 saknas, eller skapades efter att podden startade: starta om den med systemctl --user restart glitchtip-pod.
SDK:n körs, men inget ärende syns. DSN:en måste vara https://-adressen från projektets inställningar, och appen måste kunna nå errors.example.com. Korta skript måste ge SDK:n tid att skicka innan de avslutas; Python-SDK:n gör det själv, och Sentry.flush() gör det i JavaScript.
Stack trace visar fortfarande minifierade namn. Source maps laddades upp efter felet, eller för en annan fil. Kontrollera att sentry-cli sourcemaps inject kördes innan bygget driftsattes, och att uppladdningsrapporten listar samma debug-ID som filen du kör.