Dealownia
Menu
sprawdzono – jak sprawdzamy oferty

GlitchTip zamiast Sentry: zbieranie błędów na małym VPS

GlitchTip 6 w Docker Compose: wymagania pamięci, tryb all-in-one, nginx, konto administratora i konfiguracja SDK Sentry dla JavaScriptu oraz Pythona.

Aplikacje na własnym serwerzezaktualizowano 6 min czytania

Redakcja serwisu Dealownia · ceny i fakty ze stron dostawców, jak sprawdzamy

GlitchTip pod adresem https://errors.example.pl zbiera błędy JavaScriptu z Twoich stron i wyjątki z backendu, grupuje je i pokazuje stos wywołań. GlitchTip przyjmuje dane z oficjalnych bibliotek Sentry, więc w kodzie zmieniasz tylko adres DSN. Oprogramowanie jest darmowe, a w trybie all-in-one mieści się na małym VPS-ie obok strony. Jeden GlitchTip obsłuży projekty wielu stron. W tym poradniku dostaje własny kontener Postgres 18, jak w oficjalnym przykładzie z dokumentacji; jak podłączyć go do Postgresa, który już masz, piszemy w „Co dalej”.

Czego potrzebujesz

  • VPS z Ubuntu 24.04 LTS, nginx, certbot i Docker – jak w poradniku od zera.
  • Pamięć: dokumentacja GlitchTip zaleca 512 MB RAM dla samej aplikacji, a minimum to 256 MB w trybie all-in-one. Do tego dochodzą Postgres i system, więc realne minimum serwera to 1 vCPU i 1 GB RAM ze swapem, a wygodnie 2 GB. Orientacyjnie kontener GlitchTip zajmuje ok. 170 MiB RAM po starcie przy obniżonej liczbie zadań w tle – sprawdź u siebie docker stats.
  • 10 GB wolnego dysku na start; zajętość rośnie z liczbą zdarzeń, a ogranicza ją czas przechowywania.
  • Subdomenę, np. errors.example.pl, i (opcjonalnie) konto SMTP do wysyłki powiadomień e-mail.

Krok 1. Sekrety

bash
sudo mkdir -p /opt/apps/glitchtip && sudo chown deploy:deploy /opt/apps/glitchtip
cd /opt/apps/glitchtip
cat > .env <<EOF
GLITCHTIP_DB_PASSWORD=$(openssl rand -hex 24)
GLITCHTIP_SECRET_KEY=$(openssl rand -hex 32)
EOF
chmod 600 .env

Krok 2. Plik compose.yaml

Plik opiera się na oficjalnym przykładzie z dokumentacji GlitchTip, z hasłem do bazy zamiast trybu trust i portem dostępnym tylko lokalnie:

yaml
x-environment: &glitchtip-env
  DATABASE_URL: postgres://glitchtip:${GLITCHTIP_DB_PASSWORD}@postgres:5432/glitchtip
  VALKEY_URL: redis://valkey:6379
  SECRET_KEY: ${GLITCHTIP_SECRET_KEY}
  GLITCHTIP_DOMAIN: https://errors.example.pl
  DEFAULT_FROM_EMAIL: glitchtip@example.pl
  EMAIL_URL: consolemail://
  ENABLE_USER_REGISTRATION: "False"
  VTASKS_CONCURRENCY: "2"

services:
  postgres:
    image: postgres:18
    command: -c max_locks_per_transaction=512
    environment:
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: ${GLITCHTIP_DB_PASSWORD}
      POSTGRES_DB: glitchtip
    volumes:
      - ./data/postgres:/var/lib/postgresql
    restart: unless-stopped

  valkey:
    image: valkey/valkey:9
    restart: unless-stopped

  web:
    image: glitchtip/glitchtip:6
    depends_on:
      - postgres
      - valkey
    environment:
      <<: *glitchtip-env
      SERVER_ROLE: all_in_one
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - ./data/uploads:/code/uploads
    restart: unless-stopped

Wyjaśnienia:

  • SERVER_ROLE: all_in_one uruchamia serwer WWW i zadania w tle w jednym kontenerze – to tryb dla jednego małego serwera.
  • max_locks_per_transaction=512 jest wymagane: tabele GlitchTip są partycjonowane i zapytania biorą więcej blokad, niż Postgres domyślnie pozwala.
  • Postgres 18 trzyma dane pod /var/lib/postgresql (wcześniejsze wersje: /var/lib/postgresql/data).
  • VTASKS_CONCURRENCY domyślnie wynosi 20 równoległych zadań; na małym serwerze obniżenie tej wartości zmniejsza zużycie pamięci. W pliku jest 2 – przy kilku małych stronach to wystarcza, a przy dużym ruchu zdarzeń możesz ją podnieść.
  • Valkey jest opcjonalny. Jeśli brakuje pamięci, usuń usługę valkey i ustaw VALKEY_URL: "" – wtedy kolejka i cache idą do Postgresa. Dokumentacja wymienia jeszcze GLITCHTIP_ENABLE_LOGS: "False" i GLITCHTIP_ENABLE_UPTIME: "False" jako sposób na zejście do 256–512 MB.
  • EMAIL_URL: consolemail:// wypisuje maile do logu kontenera. Gdy masz SMTP, użyj formatu smtp://login:hasło@serwer:587.
bash
docker compose up -d
docker compose logs -f web

Pierwszy start wykonuje migracje bazy i trwa dłużej. Potem curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/_health/ powinno zwrócić 200.

Krok 3. nginx i HTTPS

nginx
server {
    listen 80;
    listen [::]:80;
    server_name errors.example.pl;
    client_max_body_size 40M;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

client_max_body_size 40M pochodzi z przykładu w dokumentacji – zdarzenia z dużym stosem i mapy źródeł przekraczają domyślny limit nginx (1 MB).

bash
sudo ln -s /etc/nginx/sites-available/errors.example.pl /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d errors.example.pl

Krok 4. Konto, organizacja, projekt

Zarejestruj się na https://errors.example.pl i załóż organizację. Przy ENABLE_USER_REGISTRATION: "False" rejestracja działa tylko dla pierwszego użytkownika – potem nikt obcy nie założy konta na Twoim serwerze. Zrób to zaraz po uruchomieniu. Konto superużytkownika możesz też założyć z konsoli:

bash
docker compose exec web ./manage.py createsuperuser

Następnie utwórz projekt (platforma JavaScript albo Python) i skopiuj jego DSN z ustawień projektu (Client Keys). DSN jest z natury publiczny – trafia do kodu strony.

Krok 5. SDK w przeglądarce

bash
npm install @sentry/browser
javascript
import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://KLUCZ@errors.example.pl/1",
  tracesSampleRate: 0.01,
  environment: "production",
  release: "strona@1.0.0",
  integrations: (defaults) => defaults.filter((i) => i.name !== "BrowserSession"),
});

GlitchTip nie obsługuje sesji Sentry. Jego dokumentacja pokazuje opcję autoSessionTracking: false, ale w SDK Sentry od wersji 9 tej opcji już nie ma – sesje włącza integracja BrowserSession, więc wyłączasz ją filtrem jak wyżej. tracesSampleRate trzymaj nisko (dokumentacja proponuje 1–10%), bo każda transakcja to zapis w bazie.

Sprawdzenie: wywołaj w konsoli przeglądarki nieistniejącą funkcję z poziomu strony albo dodaj tymczasowo setTimeout(() => brakFunkcji(), 0). Zdarzenie powinno pojawić się w GlitchTip w ciągu kilku sekund.

Krok 6. Backend w Pythonie

bash
pip install sentry-sdk
python
import sentry_sdk

sentry_sdk.init(
    dsn="https://KLUCZ@errors.example.pl/2",
    traces_sample_rate=0.01,
    environment="production",
)

Dla Node.js odpowiednikiem jest pakiet @sentry/node z tym samym Sentry.init({ dsn }).

Krok 7. Przechowywanie i kopie

Czas przechowywania zdarzeń ustawia GLITCHTIP_EVENT_RETENTION_DAYS (domyślnie 90 dni). Na małym dysku skróć go, np. do 30. Bazę kopiuj tak samo jak każdą bazę Postgres – zrzut trafia do /opt/apps/glitchtip/backup, tak jak w pozostałych poradnikach o aplikacjach:

bash
cd /opt/apps/glitchtip
sudo install -d -m 700 backup
docker compose exec -T postgres pg_dump -U glitchtip -Fc glitchtip | sudo tee "backup/glitchtip-$(date +%F).dump" >/dev/null
sudo ls -lh backup

Katalog ma prawa 700, więc zrzut czyta tylko root. Do nocnego uruchamiania użyj skryptu i wpisu w /etc/cron.d jak w poradniku o Umami, a kopie wysyłaj też poza serwer.

Valkey nie wymaga kopii – według dokumentacji trzyma dane potrzebne w trakcie pracy, ale niewarte archiwizacji.

Najczęstsze problemy

  • Błąd CSRF przy logowaniu. GLITCHTIP_DOMAIN nie zgadza się z adresem, którego używasz (inna subdomena albo http zamiast https), albo nginx nie przekazuje X-Forwarded-Proto.
  • Błędy Postgresa „out of shared memory” i „max_locks_per_transaction”. Brak parametru -c max_locks_per_transaction=512. Po dodaniu zrestartuj kontener bazy.
  • 413 Request Entity Too Large przy wysyłaniu zdarzeń lub map źródeł. Brak client_max_body_size 40M; w bloku server.
  • Setki błędów, których nie da się odtworzyć. Często to boty i skanery ze starymi przeglądarkami. Typowy przykład to fałszywe SyntaxError od skanera udającego bardzo stary Chrome; pomaga ładowanie SDK tylko w przeglądarkach obsługujących moduły (<script type="module">). Możesz też użyć opcji ignoreErrors albo beforeSend w SDK.
  • Nie przychodzą maile z powiadomieniami. Przy consolemail:// nic nie wychodzi – maile są tylko w docker compose logs web. Ustaw prawdziwy EMAIL_URL.

Co dalej

Błędy aplikacji to jedna warstwa; dostępność stron sprawdza Uptime Kuma. Jeśli chcesz uruchamiać GlitchTip razem z analityką i monitoringiem, zobacz stack Docker Compose. Tamten plik ma jeden Postgres 17 dla Umami; GlitchTip możesz dopisać do niego jako kolejne usługi i zamiast osobnego kontenera postgres utworzyć na tym serwerze Postgres osobną bazę glitchtip z osobnym użytkownikiem. Pamiętaj wtedy o parametrze -c max_locks_per_transaction=512 dla wspólnego Postgresa. Dokumentacja GlitchTip wymaga PostgreSQL 14 lub nowszego, więc działa i na 17, i na 18. Serwer z zapasem pamięci znajdziesz w rankingu VPS, a porównanie z planem Sentry Team – w kalkulatorze self-hosting czy abonament.

Powiązane poradniki