Self-hosted Sentry alternatywy: porównanie zużycia RAM

Jakie są koszty własnego systemu śledzenia błędów przed zapisaniem pierwszego zdarzenia

Własny system śledzenia błędów posiada jeden parametr, który determinuje całą decyzję: minimalne zapotrzebowanie na pamięć RAM. Oficjalna dokumentacja self-hosted Sentry wymaga 4 rdzeni CPU, 16 GB pamięci RAM oraz 16 GB przestrzeni wymiany (swap), a także 20 GB wolnego miejsca na dysku, zanim aplikacja wyśle choćby jedno zdarzenie. GlitchTip w dokumentacji podaje wartość 512 MB. Wszystkie wymienione tutaj opcje akceptują zdarzenia z tych samych bibliotek Sentry SDK, więc wybór ten nie dotyczy sposobu instrumentacji kodu. Jest to decyzja o tym, jak duży serwer użytkownik jest w stanie opłacić i utrzymywać w działaniu.

Opublikowane dane dotyczące zasobów, zestawienie porównawcze

Są to wartości publikowane przez poszczególne projekty na sierpień 2026 roku. Nie są to tożsame rodzaje pomiarów, dlatego przed porównaniem należy zapoznać się z uwagą przy każdym wierszu.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Wartość 16 GB dla Sentry to udokumentowane minimum, przy czym ta sama strona zaleca 32 GB. Wartość 0.5 GB dla GlitchTip jest rekomendacją; projekt podaje 256 MB jako minimum robocze lub 128 MB z użyciem swap przy starannej konfiguracji. Wartość 4 GB dla Bugsink nie jest żadną z powyższych: jest to specyfikacja jednostki, której dostawca użył do własnych testów wydajnościowych. Opublikowana liczba stanowi punkt wyjścia, a nie gwarancję obsługi określonego wolumenu zdarzeń.

Sentry self-hosted: cały produkt i pełne koszty utrzymania

Oficjalny stos to getsentry/self-hosted, projekt Docker Compose, który uruchamia te same komponenty, których Sentry używa w środowisku produkcyjnym. Dokumentacja opisuje go jako „kompletny funkcjonalnie i spakowany z myślą o wdrożeniach o małym wolumenie oraz weryfikacji koncepcji”. To zdanie stanowi uczciwe podsumowanie. Użytkownik otrzymuje każdą funkcję oraz każdy element składowy, który odpowiada za ich działanie.

Instalację należy przeprowadzić z otagowanego wydania, a nie z master:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

Następnie należy uruchomić stos:

docker compose up --wait

Sentry domyślnie nasłuchuje na http://127.0.0.1:9000. Wymagany jest Docker Engine w wersji 19.03.6 lub nowszej oraz Docker Compose w wersji 2.32.2 lub nowszej; starsze wersje Compose kończą się błędem składni pliku, a nie problemami z samym Sentry.

Należy sprawdzić, co faktycznie zostało uruchomione:

docker compose ps
free -h

docker compose ps wyświetla każdą usługę w stosie, a lista jest długa: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator oraz szereg procesów worker i cron. Należy policzyć je raz, ponieważ ta liczba określa nakład pracy związany z utrzymaniem. Każdy wpis to proces, który może ulec awarii, zapełnić dysk lub nie przejść migracji.

Jeśli usługa znajduje się w stanie Restarting, w pierwszej kolejności należy sprawdzić zużycie pamięci:

dmesg -T | grep -i 'out of memory'

Wiersz typu Out of memory: Killed process 3412 (java) oznacza, że mechanizm OOM killer (out of memory killer) jądra systemu zakończył kontener, ponieważ serwerowi zabrakło pamięci RAM. W rezultacie usługa nigdy nie osiąga stanu gotowości, a stos nie kończy procesu uruchamiania. Jest to typowy skutek uruchamiania pełnego stosu poniżej udokumentowanych wymagań minimalnych. Dokumentacja wskazuje również na szybkość dysku: iowait powyżej 10% oznacza, że maszyna nie nadąża za potokiem przyjmowania danych (ingest pipeline). Wartość tę można odczytać z kolumny wa w top lub z iostat -x 5, jeśli zainstalowano sysstat.

Aktualizacje to element, który jest powszechnie niedoszacowany

Sentry self-hosted jest wydawane co miesiąc w modelu CalVer (schemat wersji oparty na kalendarzu), z głównym wydaniem 15. dnia każdego miesiąca. Nie można przejść bezpośrednio ze starej wersji do najnowszej. Projekt definiuje wersje graniczne (hard stops) i należy przejść przez każdą z nich, aby wykonać migracje bazy danych. Według stanu na sierpień 2026 r. opublikowane wersje graniczne to 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 oraz 26.7.0. Dokumentacja wymienia również wydania, które należy pominąć ze względu na problemy z migracją, w tym 23.7.0, 25.9.0, 25.12.0 oraz zakres od 26.3.0 do 26.4.0.

Aktualizacja polega na pobraniu nowej wersji (checkout) i ponownym uruchomieniu instalatora:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

Przed rozpoczęciem należy wykonać migawkę (snapshot) serwera, ponieważ migracja dużego zbioru danych ClickHouse może trwać wiele godzin, a awaria w trakcie pozostawia bazę danych w stanie pomiędzy dwoma schematami. Główną przyczyną większości nieudanych aktualizacji Sentry self-hosted jest fakt, że serwer przez rok nie był aktualizowany, więc skok obejmuje kilka wersji granicznych jednocześnie, a jedna z pominiętych migracji była kluczowa.

Jeszcze jedna informacja przed podjęciem decyzji. Sentry self-hosted jest objęte licencją Functional Source License (FSL), wprowadzoną przez samo Sentry. Jest to licencja typu „fair source”, a nie oprogramowanie open source zatwierdzone przez OSI: można z niego korzystać na własny użytek, ale nie można go sprzedawać jako konkurencyjnej usługi. Każde wydanie staje się dostępne na licencji Apache 2.0 dwa lata po jego opublikowaniu.

GlitchTip: odpowiedź na 512 MB

GlitchTip jest udostępniany na licencji MIT i odbiera zdarzenia z otwartych SDK Sentry, więc przeniesienie oinstrumentowanej aplikacji wymaga zmiany tylko jednej wartości: DSN (data source name, adres URL, pod który SDK wysyła zdarzenia). Wymagany jest PostgreSQL 14 lub nowszy. Valkey lub Redis 7 lub nowszy jest opcjonalny, ale przyspiesza działanie większych instancji.

Instalacja opiera się na Docker oraz jednym pliku compose:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Przed uruchomieniem czegokolwiek należy edytować sekcję environment. Wartości, które trzeba ustawić, to secret, domain oraz mail path:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

Przykładowa konfiguracja automatycznie łączy DATABASE_URL z własną usługą postgres, więc nie należy zmieniać tej linii, chyba że wskazuje się na bazę danych działającą w innym miejscu. GLITCHTIP_DOMAIN musi zawierać schemat. Bez https:// na początku, linki w wiadomościach e-mail z alertami będą generowane błędnie i prowadzić do adresu URL, który nie odpowiada.

Uruchom usługę i obserwuj pierwsze uruchomienie:

docker compose up -d
docker compose logs -f web

Tagi obrazów w przykładzie na sierpień 2026 to postgres:18, valkey/valkey:9 oraz glitchtip/glitchtip:6. Należy je przypiąć. Plik compose z wartością latest spowoduje aktualizację silnika bazy danych przy następnym docker compose pull, a skok głównej wersji Postgres w działającej instancji to najczęstsza przyczyna awarii trackera błędów.

Aby osiągnąć zakres od 256 MB do 512 MB, należy postępować zgodnie z komentarzami w pliku przykładowym, wyłączając zbędne elementy, począwszy od Valkey oraz opcjonalnych funkcji logowania i monitorowania czasu pracy. Działanie bez Valkey oznacza, że GlitchTip używa bazy danych do zadań związanych z pamięcią podręczną i kolejkami, co jest wolniejsze, ale nadal poprawne. Tryb all in one uruchamia proces roboczy (worker) wewnątrz procesu web, dzięki czemu utrzymuje się jeden kontener aplikacji zamiast dwóch.

Przed aplikacją należy umieścić proxy. Dokumentacja GlitchTip wymaga proxy lub load balancera, który buforuje żądania i obsługuje przesyłanie strumieniowe Transfer-Encoding; jako sprawdzony przykład podawany jest nginx. Bez buforowania wolny klient blokuje proces roboczy aplikacji na czas całego przesyłania, więc kilku wolnych nadawców może zająć wszystkie dostępne procesy, co spowoduje przekroczenie czasu oczekiwania dla poprawnych klientów.

Aktualizacje są proste:

docker compose pull
docker compose stop
docker compose up -d

Migracje bazy danych uruchamiają się automatycznie przy starcie. Mimo to należy najpierw wykonać zrzut danych, ponieważ automatyczna migracja pozostaje migracją.

Bugsink: jeden kontener i licencja, którą należy przeczytać

Bugsink jest najlżejszym z omawianych rozwiązań. Obsługuje protokół Sentry SDK i działa bez kolejki komunikatów oraz usług zewnętrznych poza bazą danych. Domyślnie używa SQLite, z obsługą MySQL i PostgreSQL w przypadku większego obciążenia.

Instancja tymczasowa, pozwalająca na sprawdzenie interfejsu przed wdrożeniem:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Otwórz http://localhost:8000/ i zaloguj się przy użyciu adresu oraz hasła przekazanych w CREATE_SUPERUSER. Ten kontener nie przechowuje żadnych danych po zatrzymaniu. W przypadku instancji produkcyjnej należy użyć przykładowego pliku compose projektu, który łączy bugsink/bugsink:2 z postgres:17-alpine oraz ustawia DATABASE_URL, BASE_URL i BEHIND_HTTPS_PROXY. Wygeneruj klucz w prawidłowy sposób:

openssl rand -base64 50

Wartość BASE_URL musi odpowiadać adresowi URL, którego faktycznie używają użytkownicy i SDK, włącznie ze schematem. Pozostawienie wartości http://localhost:8000 na serwerze dostępnym pod https://errors.example.com spowoduje, że każdy link w powiadomieniu e-mail będzie wskazywał na hosta, który nie zostanie rozpoznany przez odbiorcę. Ustaw BEHIND_HTTPS_PROXY na true, gdy Nginx lub Caddy wykonuje terminację TLS (transport layer security) przed aplikacją. W przeciwnym razie Bugsink wygeneruje adresy URL http:// za proxy https://, co spowoduje blokowanie treści mieszanych (mixed content) przez przeglądarki.

Dostawca publikuje własne dane dotyczące przepustowości: 18 zdarzeń na sekundę przy rozmiarze 50 KB każde, co przekłada się na 1,5 miliona zdarzeń dziennie na serwerze VPS z 2 vCPU i 4 GB pamięci RAM. Należy traktować to jako orientacyjną charakterystykę narzędzia, a nie gwarancję dla konkretnego obciążenia. Wskazuje to jednak, że wydajność znacznie przewyższa potrzeby pojedynczej małej aplikacji.

Teraz kwestia licencji – jest to fragment, który należy przeczytać przed wprowadzeniem oprogramowania do infrastruktury. Bugsink jest udostępniany na licencji PolyForm Shield License 1.0.0. Jest to oprogramowanie typu source available, a nie open source: można je uruchamiać i modyfikować, ale nie wolno wykorzystywać go do tworzenia rozwiązań konkurencyjnych wobec Bugsink. W przypadku wewnętrznego systemu śledzenia błędów ograniczenie to nie ma znaczenia. Jeśli jednak firma zajmuje się sprzedażą narzędzi dla programistów, należy najpierw zlecić analizę treści licencji.

Śledzenie błędów i monitorowanie LLM to nadal dwa osobne narzędzia

Wyszukiwanie jednego narzędzia, które łączy śledzenie błędów z monitorowaniem dużych modeli językowych (LLM), prowadzi do produktów deklarujących obie te funkcje. Struktury danych są jednak odmienne, co sprawia, że ich połączenie wciąż nie następuje. System śledzenia błędów otrzymuje wyjątek wraz ze śladem stosu (stack trace), oblicza na jego podstawie odcisk palca (fingerprint) i scala tysiące wystąpień w jeden problem z licznikiem. Narzędzie do śledzenia LLM otrzymuje zakres (span) zawierający prompt, odpowiedź, liczbę tokenów oraz opóźnienie i musi zachować każdy z tych elementów, ponieważ dwa wywołania o identycznych danych wejściowych pozostają odrębnymi zdarzeniami, które warto przeanalizować.

Dlatego należy korzystać z obu rozwiązań. Wysyłaj wyjątki do systemu śledzenia błędów, a wywołania modeli do narzędzi stworzonych z myślą o nich: self-hosted Langfuse do śledzenia agentów obejmuje ten aspekt, a self-hosted AI observability podchodzi do tego samego zadania z innej perspektywy. Twoja aplikacja generuje już oba rodzaje awarii. Wywołanie modelu, które zwraca pewne siebie, lecz błędne informacje, nie wyrzuca żadnego wyjątku, więc system śledzenia błędów nigdy go nie zarejestruje.

Wzrost zajętości dysku to awaria, która ujawnia się z opóźnieniem

Każdy system śledzenia błędów jest bazą danych o intensywnym zapisie i nieograniczonym strumieniu wejściowym. Aplikacja decyduje o wolumenie zapisywanych danych, a jeden nowy błąd w krytycznej ścieżce kodu może wygenerować milion zdarzeń w ciągu nocy.

GlitchTip podaje wartość, którą warto uwzględnić w planowaniu: instancja obsługująca milion zdarzeń miesięcznie może wymagać 30 GB miejsca na dysku. Wartość ta obejmuje jeden miesiąc przyjmowania danych przy takim natężeniu, a okres retencji decyduje o tym, ile miesięcy danych jest przechowywanych jednocześnie.

Bugsink podchodzi do tego zagadnienia od drugiej strony. Zamiast sztywnego limitu, stosuje algorytm retencji oparty na liczbie i wieku zdarzeń, udostępniając limity bezpośrednio: MAX_RETENTION_EVENT_COUNT dla całej instalacji, MAX_RETENTION_PER_PROJECT_EVENT_COUNT na projekt oraz MAX_EVENT_AGE_DAYS jako limit bezwzględny. Ustalenie budżetu zdarzeń dla całej instalacji to uczciwy sposób na określenie rozmiaru dysku, ponieważ ten budżet stanowi o faktycznym zapotrzebowaniu na przestrzeń.

Monitoruj rzeczywiste wartości na serwerze:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v wyświetla rozmiary poszczególnych wolumenów, co pozwala zidentyfikować usługę, która zajmuje coraz więcej miejsca. Wolumen, który zyskuje kilka gigabajtów tygodniowo przy niezmienionym natężeniu ruchu, zazwyczaj oznacza brak skonfigurowanej retencji, przez co dane nie są usuwane, a jedynym ograniczeniem pozostaje rozmiar partycji.

Pamięć operacyjna stanowi ten sam problem w innej postaci. Stos bez limitów zajmie każdą ilość pamięci oferowaną przez kernel. Gdy maszyna wyczerpie zasoby, OOM killer wybierze proces o największym zużyciu, którym może być serwer WWW, a nie system śledzenia, który spowodował problem. Każdej usłudze należy wyznaczyć górny limit: limity pamięci w Docker Compose przedstawia składnię oraz zachowanie kontenera po osiągnięciu limitu. Kontener zatrzymany przez własny limit to odizolowana awaria. Kontener zatrzymany przez kernel powoduje awarię sąsiednich procesów.

Dobór stosu technologicznego do VPS

• 1 GB lub 2 GB z zapasem: GlitchTip w trybie all-in-one z wyłączonym Valkey lub Bugsink z bazą SQLite. Oba rozwiązania działają stabilnie przy kilku aplikacjach.
• 4 GB: Bugsink z PostgreSQL lub GlitchTip z włączonym Valkey i oddzielnym procesem worker. Jest to rozmiar pamięci, przy którym można zrezygnować z optymalizacji na rzecz wydajności.
• 8 GB: wciąż za mało dla oficjalnego stosu Sentry. Warto przeznaczyć te zasoby na dłuższy okres retencji danych i większy dysk dla wybranego lekkiego rozwiązania.
• Minimum 16 GB, zalecane 32 GB: oficjalny stos Sentry w wersji self-hosted. Wybór ten jest uzasadniony tylko wtedy, gdy wymagana jest funkcja Sentry nieobecna w lżejszych alternatywach. Należy najpierw sprawdzić dostępność danej funkcji w dokumentacji projektów, ponieważ kompatybilne rozwiązania obsługują większość standardowych zastosowań.

Niezależnie od wybranego oprogramowania, system śledzenia błędów nie jest w stanie zgłosić własnej awarii. Należy monitorować go z innej maszyny: Uptime Kuma monitorujący z zewnętrznego serwera powiadomi o niedostępności trackera dokładnie w momencie, gdy aplikacja zacznie generować błędy, które nie są rejestrowane.

Kiedy plan hostowany jest tańszym rozwiązaniem

Samodzielne hostowanie systemu śledzenia błędów opłaca się, gdy wymagają tego zasady przechowywania danych lub gdy wolumen zdarzeń jest na tyle duży, że rozliczenie za każde zdarzenie staje się nieopłacalne. Poza tymi przypadkami należy rzetelnie przeprowadzić kalkulację. Udokumentowane minimum dla Sentry to serwer z 16 GB pamięci RAM, 4 rdzeniami procesora i szybkim dyskiem, a VPS o takich parametrach nie należy do tanich. Należy do tego doliczyć nakład pracy operacyjnej: realizację każdego kroku aktualizacji zgodnie z kolejnością oraz wykonywanie snapshotów przed każdą migracją, co zdarza się kilka razy w roku.

GlitchTip i Bugsink całkowicie zmieniają tę kalkulację, ponieważ serwer o zasobach od 512 MB do 4 GB jest niedrogi, a aktualizacja to docker compose pull. Dlatego większość osób zadających to pytanie kończy z jednym z kompatybilnych projektów zamiast z oficjalnym stosem technologicznym. Użytkownicy oczekiwali śledzenia błędów, a nie rozproszonego potoku danych, który wymaga ciągłego nadzoru.

Jeśli nadal ustalasz, co w ogóle powinno znajdować się na serwerze, szersza lista usług wartych samodzielnego hostowania umieszcza śledzenie błędów obok innych usług rywalizujących o tę samą pamięć RAM.

FAQ

Czy mogę hostować Sentry samodzielnie na VPS z 2 GB RAM?

Nie. Dokumentacja Sentry w wersji self-hosted określa wymagania minimalne na poziomie 4 rdzeni CPU, 16 GB RAM oraz 16 GB swap i 20 GB wolnego miejsca na dysku. Stos technologiczny uruchamia jednocześnie Postgres, ClickHouse, Kafka, Redis oraz szereg procesów roboczych, dlatego na małej maszynie jądro systemu zabija kontenery przed zakończeniem instalacji. Można to potwierdzić za pomocą dmesg -T | grep -i 'out of memory', co wyświetli wiersz wskazujący na zabity proces. W przypadku VPS z 2 GB RAM należy użyć GlitchTip, który wymaga 512 MB, lub Bugsink, który działa jako pojedynczy kontener korzystający z SQLite.

Czy muszę zmieniać kod aplikacji, aby przejść z Sentry na GlitchTip lub Bugsink?

Nie. Oba rozwiązania akceptują zdarzenia z otwartych SDK Sentry, więc można zachować zainstalowane SDK i zmienić tylko jedną wartość: DSN, czyli adres URL, pod który SDK wysyła zdarzenia. Jeśli adres jest wpisany na sztywno, należy przenieść go do zmiennej środowiskowej, wskazać nowy host, a następnie wywołać testowy wyjątek i sprawdzić, czy dotarł. Jeśli nic się nie pojawia, należy zweryfikować, czy identyfikator projektu w DSN odpowiada projektowi istniejącemu na nowym serwerze oraz czy firewall pozwala aplikacji na połączenie z danym hostem i portem.

Ile miejsca na dysku wymaga samodzielnie hostowane śledzenie błędów?

Zależy to od wolumenu zdarzeń i okresu retencji, a nie od samego narzędzia. GlitchTip podaje 30 GB dla instancji obsługującej milion zdarzeń miesięcznie. Bugsink pozwala ustawić budżet bezpośrednio za pomocą MAX_RETENTION_EVENT_COUNT oraz MAX_EVENT_AGE_DAYS, więc użytkownik wybiera limit, a wymagania dyskowe wynikają z tej decyzji. Retencję należy skonfigurować pierwszego dnia. Tracker bez polityki retencji będzie rósł, aż df -h wskaże 100% zajętości, co spowoduje zatrzymanie przyjmowania danych i utratę błędów, które były najważniejsze do zarejestrowania.

Dlaczego aktualizacja samodzielnie hostowanego Sentry kończy się niepowodzeniem?

Ponieważ podczas aktualizacji pominięto tzw. hard stop. Sentry self-hosted definiuje konkretne wersje zawierające migracje bazy danych, przez które należy przejść. Według stanu na sierpień 2026 są to: 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 oraz 26.7.0. Przejście bezpośrednio ze starego wydania do najnowszego pomija te migracje, co prowadzi do niezgodności schematu z kodem i przerwania procesu aktualizacji. Należy przejść przez każdy punkt kontrolny po kolei, uruchamiając ./install.sh na każdym etapie. Przed rozpoczęciem należy wykonać snapshot serwera oraz zapoznać się z udokumentowaną listą wydań, których należy unikać, obejmującą 23.7.0, 25.9.0 oraz 25.12.0.