Sentry alternatives: GlitchTip sa 512 MB RAM

Magkano ang gastos ng self-hosted error tracking bago ito mag-store ng kahit isang event

May isang numero sa self-hosted error tracking na pangunahing batayan ng buong pagpili: ang RAM floor. Ayon sa sariling self-hosted documentation ng Sentry, kailangan nito ng 4 CPU cores, 16 GB RAM, 16 GB swap, at 20 GB na libreng disk bago pa magpadala ng kahit isang event ang application mo. Nakatala naman sa documentation ng GlitchTip ang 512 MB. Tumatanggap ang lahat ng option dito ng mga event mula sa parehong Sentry SDKs, kaya hindi ito usapin ng kung paano mo i-instrument ang code mo. Usapin ito ng laki ng server na handa mong bayaran at panatilihing gumagana.

Mga inilathalang resource figure ng bawat project, magkatabi

Ito ang mga numerong inilalathala ng bawat project tungkol sa sarili nito, noong August 2026. Hindi pare-pareho ang uri ng measurement ng mga ito, kaya basahin ang note sa bawat row bago ikumpara ang mga ito.

[
  {
    "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"
  }
]

Ang 16 GB ng Sentry ay isang documented minimum, at nagrerekomenda ang parehong page ng 32 GB. Ang 0.5 GB ng GlitchTip ay recommendation, at sinasabi ng project na 256 MB ang working minimum, o 128 MB kasama ang swap kapag maingat ang configuration. Ang 4 GB ng Bugsink ay hindi alinman sa dalawang iyon: ito ang box na ginamit ng vendor para sa sarili nitong throughput benchmark. Ang published figure ay panimulang batayan lamang, hindi garantiya tungkol sa dami ng event mo.

Sentry self-hosted: ang buong produkto at ang buong bill

Ang opisyal na stack ay getsentry/self-hosted, isang Docker Compose project na nagpapatakbo ng parehong mga component na ginagamit ng Sentry sa production. Inilalarawan ito ng sariling documentation nito bilang “kumpleto ang mga feature at naka-package para sa low-volume deployments at proofs-of-concept.” Iyan ang tapat na buod. Makukuha mo ang bawat feature, pati ang bawat moving part na nagpapatakbo sa mga feature na iyon.

Mag-install mula sa isang tagged release sa halip na mula sa 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

Pagkatapos, simulan ito:

docker compose up --wait

Nakikinig ang Sentry sa http://127.0.0.1:9000 bilang default. Kailangan ang Docker Engine 19.03.6 o mas bago at Docker Compose 2.32.2 o mas bago. Nagfa-fail ang mas lumang Compose sa file syntax, hindi dahil sa anumang ginagawa ng Sentry.

Tingnan kung ano talaga ang sinimulan mo:

docker compose ps
free -h

Inililista ng docker compose ps ang bawat service sa stack, at mahaba ang listahan: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, at ilang worker at cron process. Bilangin ang mga ito nang isang beses, dahil iyon ang maintenance load mo. Bawat entry ay isang process na maaaring mag-crash, magpuno sa disk, o mag-fail sa migration.

Kung nasa Restarting state ang isang service, memory muna ang tingnan bago ang iba:

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

Ang linyang tulad ng Out of memory: Killed process 3412 (java) ay nangangahulugang pinatay ng kernel's OOM killer (out of memory killer) ang isang container dahil naubusan ng RAM ang machine. Dahil dito, hindi nagiging healthy ang service at hindi natatapos ang pagsisimula ng stack. Karaniwan itong nangyayari kapag pinapatakbo ang buong stack gamit ang documented minimum nito. Tinutukoy rin ng documentation ang bilis ng disk: kapag lampas 10% ang iowait, hindi makasabay ang machine sa ingest pipeline. Basahin ito mula sa column na wa sa top, o mula sa iostat -x 5 kung naka-install ang sysstat.

Ang upgrades ang bahaging minamaliit ng mga tao

Naglalabas ang Sentry self-hosted buwan-buwan gamit ang CalVer, isang calendar-based version scheme, na may pangunahing release tuwing ika-15 ng buwan. Hindi ka maaaring direktang lumipat mula sa lumang version papunta sa pinakabago. Tinutukoy ng project ang mga hard stop version, at kailangan mong mag-checkout sa bawat isa ayon sa pagkakasunod-sunod upang mailapat ang mga database migration nito. Noong August 2026, ang mga na-publish na hard stop ay 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 at 26.7.0. Inililista rin ng documentation ang mga release na dapat laktawan dahil sa mga problema sa migration, kabilang ang 23.7.0, 25.9.0, 25.12.0 at ang range mula 26.3.0 hanggang 26.4.0.

Ang upgrade ay isang checkout na sinusundan ng muling pag-run ng installer:

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

Gumawa ng snapshot ng server bago magsimula, dahil maaaring tumagal nang ilang oras ang migration sa malaking ClickHouse dataset. Kapag nag-fail ito sa kalagitnaan, maiiwan ang database sa pagitan ng dalawang schema. Ang karaniwang sanhi ng mga nagfa-fail na self-hosted Sentry upgrade ay ang isang taon na pananatili ng machine sa iisang version. Dahil dito, sabay-sabay na nalalampasan ng jump ang ilang hard stop, at maaaring isa sa mga migration na dapat laktawan ang kritikal.

May isa pang dapat malaman bago ka mag-commit. Saklaw ang Sentry self-hosted ng Functional Source License (FSL), na ipinakilala mismo ng Sentry. Fair source ito at hindi open source na aprubado ng OSI: maaari mo itong patakbuhin para sa sarili mong gamit, ngunit hindi mo ito maaaring ibenta bilang competing service. Nagko-convert ang bawat release sa Apache 2.0 makalipas ang dalawang taon mula nang ilabas ito.

GlitchTip: ang sagot para sa 512 MB

MIT-licensed ang GlitchTip at tumatanggap ito ng mga event mula sa open source SDK ng Sentry. Kaya maililipat ang isang instrumented application sa pamamagitan ng pagpapalit ng isang value: ang DSN (data source name, ang URL na pinapadalhan ng SDK ng mga event). Kailangan nito ng PostgreSQL 14 o mas bago. Opsyonal ang Valkey o Redis 7 o mas bago, at pinapabilis nito ang mas malalaking instance.

Docker at isang compose file lang ang kailangan para sa installation:

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

I-edit ang environment section bago ka magsimula. Ang mga value na kailangan mong itakda ay ang secret, domain, at 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

Ang sample ay naka-configure na para gamitin ang DATABASE_URL kasama ng sarili nitong postgres service, kaya huwag baguhin ang linyang iyon maliban kung gumagamit ka ng database na pinapatakbo sa ibang lugar. Dapat kasama sa GLITCHTIP_DOMAIN ang scheme. Kapag walang https:// sa unahan, mali ang mabubuong links sa alert emails at mapupunta ang mga ito sa URL na hindi sumasagot.

Simulan ito at i-monitor ang unang boot:

docker compose up -d
docker compose logs -f web

Ang image tags sa sample noong August 2026 ay postgres:18, valkey/valkey:9, at glitchtip/glitchtip:6. Panatilihing pinned ang mga ito. Ang compose file na may latest ay mag-a-upgrade ng database engine sa susunod na docker compose pull. Kapag nagkaroon ng major version jump ang Postgres habang tumatakbo ang instance, maaaring hindi na magsimula ang dating gumaganang error tracker.

Para umabot sa 256 MB hanggang 512 MB na range, ipinapakita mismo sa comments ng sample file kung ano ang dapat i-switch off. Unahin ang Valkey at ang optional na log at uptime features. Kapag walang Valkey, database nito ang ginagamit ng GlitchTip para sa cache at queue work. Mas mabagal ito, pero tama pa rin ang paggana. Sa all in one mode, tumatakbo ang worker sa loob ng web process. Dahil dito, isang application container lang ang mina-manage mo sa halip na dalawa.

Maglagay ng proxy sa harap nito. Inirerekomenda ng documentation ng GlitchTip ang proxy o load balancer na nagba-buffer ng requests at humahawak sa chunked Transfer-Encoding. Nginx ang ginagamit nitong halimbawa. Kapag walang buffering, mananatiling bukas ang application worker habang ina-upload ng mabagal na client ang buong file. Dahil dito, maaaring maubos ng ilang mababagal na sender ang lahat ng worker, at magsimulang mag-timeout ang mga normal na client.

Madali ang upgrades:

docker compose pull
docker compose stop
docker compose up -d

Awtomatikong tumatakbo ang database migrations sa pagsisimula. Gayunman, gumawa muna ng dump dahil migration pa rin ang isang automatic migration.

Bugsink: isang container, at lisensiyang dapat mong basahin

Ang Bugsink ang pinakamagaan sa tatlo. Gumagamit ito ng Sentry SDK protocol, at tumatakbo ito nang walang message queue at walang external service maliban sa database. SQLite ang default, habang sinusuportahan ang MySQL at PostgreSQL kapag hindi na ito sapat para sa iyo.

Isang panandaliang instance para makita ang interface bago ka magpasya:

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

Buksan ang http://localhost:8000/ at mag-sign in gamit ang address at password na ipinasa mo sa CREATE_SUPERUSER. Walang pinapanatili ang container na iyon kapag huminto ito. Para sa aktuwal na instance, gamitin ang compose sample ng proyekto. Ipinapares nito ang bugsink/bugsink:2 sa postgres:17-alpine at sine-set ang DATABASE_URL, BASE_URL, at BEHIND_HTTPS_PROXY. Bumuo ng secret nang tama:

openssl rand -base64 50

Dapat tumugma ang BASE_URL sa URL na aktuwal na ginagamit ng iyong mga user at SDK, kasama ang scheme. Iwanan ito sa http://localhost:8000 sa isang box na ina-access mo sa https://errors.example.com, at ang bawat link sa notification email ay tuturo sa host na hindi ma-resolve ng taong nagbabasa nito. Itakda ang BEHIND_HTTPS_PROXY sa true kapag si nginx o Caddy ang nagte-terminate ng TLS (transport layer security) sa harap nito. Kung hindi, bubuo ang Bugsink ng http:// URLs sa likod ng iyong https:// proxy, at ibablock ng mga browser ang mixed content.

Inilalathala ng vendor ang sarili nitong throughput figures: 18 events bawat segundo, na tig-50 KB. Katumbas ito ng 1.5 million events bawat araw sa isang 2 vCPU at 4 GB VPS. Ituring ito bilang tinatayang kapasidad ng tool, hindi bilang garantiya para sa iyong workload. Ipinapakita pa rin nito na mas mataas nang malaki ang ceiling nito kaysa sa kayang likhain ng isang maliit na application.

Ngayon, tungkol sa licence. Ito ang bahaging dapat basahin bago ito maisama sa iyong stack. Inilabas ang Bugsink sa ilalim ng PolyForm Shield License 1.0.0. Source available ito, hindi open source: maaari mo itong patakbuhin at baguhin, ngunit hindi mo ito maaaring gamitin upang bumuo ng produktong nakikipagkumpitensya sa Bugsink. Para sa internal error tracker, hindi karaniwang nagiging isyu ang restriction na ito. Kung nagbebenta ang iyong kumpanya ng developer tooling, ipabasa muna sa isang tao ang teksto ng licence.

Error tracking at LLM observability ay dalawang magkahiwalay na tool

Maghanap ng isang tool na sabay na gumagawa ng error tracking at large language model (LLM) observability, at makakakita ka ng mga product na nagsasabing kaya nila pareho. Magkaiba ang anyo ng data, kaya hindi nagtatagumpay ang pagsasama ng mga ito. Tumatanggap ang error tracker ng exception na may stack trace, kumukuwenta ng fingerprint mula rito, at pinagsasama-sama ang libo-libong occurrence bilang isang issue na may counter. Tumatanggap naman ang LLM tracing tool ng span na naglalaman ng prompt, response, bilang ng token, at latency. Kailangan nitong panatilihin ang bawat isa dahil kahit magkapareho ang input ng dalawang call, magkahiwalay pa rin ang mga itong event na mahalagang basahin.

Gamitin ang dalawang tool. Ipadala ang mga exception sa error tracker, at ipadala ang mga model call sa tool na ginawa para sa mga ito: sakop ng self-hosted Langfuse para sa agent tracing ang bahaging iyon, habang tinutugunan ng self-hosted AI observability ang parehong gawain mula sa ibang paraan. Gumagawa na ang application mo ng parehong uri ng failure. Ang model call na nagbabalik ng kumpiyansang walang-katuturang sagot ay hindi nagti-throw ng exception, kaya hindi ito kailanman ipapakita ng error tracker.

Ang paglaki ng disk ang problemang mahuhuli mo kapag huli na

Ang bawat error tracker ay isang database na maraming sinusulat at tumatanggap ng walang limitasyong input. Ang application mo ang nagpapasya kung gaano karami ang isusulat nito, at maaaring makagawa ng isang milyong event sa loob ng isang gabi ang isang bagong bug sa bahaging madalas tawagin ng code.

Naglalabas ang GlitchTip ng isang numerong dapat isaalang-alang sa pagpaplano: ang instance na humahawak ng isang milyong event bawat buwan ay maaaring mangailangan ng 30 GB na disk. Saklaw nito ang isang buwan ng ingest sa ganoong rate, at ang retention window ang magpapasya kung ilang buwan ang sabay-sabay mong iniimbak.

Sa kabilang direksiyon naman nakatuon ang Bugsink. Sa halip na fixed quota, gumagamit ito ng retention algorithm batay sa bilang at edad ng event, at direktang ipinapakita nito ang mga limitasyon: MAX_RETENTION_EVENT_COUNT para sa buong installation, MAX_RETENTION_PER_PROJECT_EVENT_COUNT bawat project, at MAX_EVENT_AGE_DAYS bilang absolute cut. Ang pagtatakda ng installation-wide event budget ang tamang paraan ng pag-size ng disk, dahil ang budget na iyon ang kumakatawan sa disk.

Subaybayan ang aktuwal na mga numero sa server:

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

Ipinapakita ng docker system df -v ang laki ng bawat volume, kaya makikita mo kung aling service ang lumalaki. Kapag nadaragdagan ng ilang gigabyte bawat linggo ang isang volume nang walang pagbabago sa traffic, karaniwan itong nangangahulugang hindi na-configure ang retention. Dahil dito, walang nade-delete at ang partition ang nagiging tanging limitasyon.

Pareho ang problema sa memory, iba lang ang anyo. Kapag walang limitasyon ang isang stack, kukunin nito ang lahat ng iniaalok ng kernel. Kapag naubusan ng resource ang machine, pipili ang OOM killer ng pinakamalaking process, na maaaring ang web server mo sa halip na ang tracker na sanhi ng problema. Magtakda ng ceiling para sa bawat service: ipinapakita ng mga limitasyon sa memory sa Docker Compose ang syntax at ang ginagawa ng container kapag naabot nito ang limitasyon. Ang container na pinatay dahil naabot nito ang sariling limitasyon ay isang failure na nakapaloob sa container. Ang container na pinatay ng kernel ay maaaring magpabagsak ng katabing service.

Aling stack ang angkop sa bawat VPS

• 1 GB, o 2 GB na may sapat pang natitirang resources: GlitchTip sa all-in-one mode na naka-off ang Valkey, o Bugsink sa SQLite. Parehong sapat ang mga ito para sa ilang application.
• 4 GB: Bugsink na may PostgreSQL, o GlitchTip na naka-on ang Valkey at may hiwalay na worker service. Sa ganitong laki, hindi mo na kailangang mag-tune nang husto; patakbuhin mo na lang ito.
• 8 GB: kulang pa rin para sa official Sentry stack. Gamitin ito para sa mas mahabang retention window at mas malaking disk, ayon sa light option na pinili mo.
• 16 GB minimum, 32 GB recommended: ang official Sentry self-hosted stack, at gamitin lamang kapag kailangan mo ng Sentry feature na hindi na-implement ng mga light project. Suriin muna ang partikular na feature sa documentation ng bawat project, dahil nasasaklaw ng mga compatible project ang mga karaniwang kailangan.

Anuman ang patakbuhin mo, hindi maiuulat ng error tracker ang sarili nitong pag-crash. Maglagay ng check mula sa ibang machine: magsusubaybay ang Uptime Kuma mula sa ibang machine at sasabihin nitong down ang tracker. Ito mismo ang oras na nagsisimulang mag-throw ng errors ang application mo na walang nagre-record.

Kapag mas mura ang hosted plan

Sulit ang self-hosting ng error tracker kapag hinihingi ito ng mga panuntunan sa data residency, o kapag sapat na kalaki ang event volume mo para maging mabigat ang per-event pricing. Sa ibang sitwasyon, kalkulahin nang maayos ang kabuuang gastos. Ang dokumentadong minimum ng Sentry ay server na may 16 GB RAM, 4 cores, at mabilis na disk. Hindi mura ang VPS na ganito ang laki. Idagdag pa ang operational work: lampasan nang sunod-sunod ang bawat hard stop at gumawa ng snapshot bago ang bawat migration, ilang beses bawat taon.

Lubos na binabago ng GlitchTip at Bugsink ang kalkulasyong ito dahil mura ang box na may 512 MB hanggang 4 GB, at ang upgrade ay isang docker compose pull. Kaya karamihan sa mga nagtatanong nito ay nauuwi sa isa sa mga compatible project sa halip na sa official stack. Error tracking ang kailangan nila, hindi distributed data pipeline na kailangan nilang bantayan.

Kung inaayos mo pa kung ano talaga ang dapat ilagay sa server, inilalagay ng mas malawak na listahan ng mga serbisyong sulit i-self-host ang error tracking katabi ng iba pang serbisyong nakikipag-agawan sa parehong RAM.

FAQ

Maaari ko bang i-self-host ang Sentry sa isang 2 GB VPS?

Hindi. Ayon sa self-hosted documentation ng Sentry, kailangan nito ng minimum na 4 CPU cores, 16 GB RAM kasama ang 16 GB swap, at 20 GB na libreng disk space. Sabay-sabay na tumatakbo ang Postgres, ClickHouse, Kafka, Redis, at ilang worker process, kaya sa maliit na server ay pinapatay ng kernel ang mga container bago matapos ang installation. Kumpirmahin ito gamit ang dmesg -T | grep -i 'out of memory', na nagpi-print ng linyang naglalaman ng pangalan ng process na pinatay. Para sa 2 GB VPS, gamitin ang GlitchTip, na nagdodokumento ng 512 MB, o ang Bugsink, na tumatakbo bilang iisang container sa SQLite.

Kailangan ko bang baguhin ang application code para lumipat mula Sentry papunta sa GlitchTip o Bugsink?

Hindi. Parehong tumatanggap ang mga ito ng events mula sa open source SDK ng Sentry, kaya maaari mong panatilihin ang SDK na naka-install na at isang value lang ang baguhin: ang DSN, o ang URL kung saan ipinapadala ng SDK ang events. Ilipat ito sa isang environment variable kung hardcoded pa rin ito, ituro ito sa bagong host, pagkatapos ay magtaas ng test exception at i-monitor kung dumarating ito. Kung walang lumilitaw, tingnan kung ang project identifier sa DSN ay tumutugma sa project na umiiral sa bagong server, at kung pinapayagan ng firewall na maabot ng application ang host at port na iyon.

Gaano karaming disk space ang kailangan ng self-hosted error tracking?

Nakasalalay ito sa dami ng events at sa retention window, hindi sa mismong tool. Naglalathala ang GlitchTip ng 30 GB para sa instance na humahawak ng isang milyong events bawat buwan. Hinahayaan ka ng Bugsink na direktang itakda ang budget gamit ang MAX_RETENTION_EVENT_COUNT at MAX_EVENT_AGE_DAYS, kaya ikaw ang pumipili ng ceiling at sumusunod dito ang disk requirement. I-configure ang retention sa unang araw. Ang tracker na walang retention policy ay patuloy na lalaki hanggang umabot sa 100% ang df -h; kapag nangyari iyon, hihinto ang ingest at mawawala ang mga error na pinakamahalagang makita.

Bakit paulit-ulit na nabibigo ang pag-upgrade ng self-hosted Sentry?

Dahil nalaktawan ng upgrade ang isang hard stop. Tinutukoy ng self-hosted Sentry ang mga partikular na version na naglalaman ng database migration na kailangan mong daanan, at hanggang August 2026, ang mga ito ay 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0, at 26.7.0. Kapag dumiretso ka mula sa lumang release papunta sa pinakabago, nalalaktawan ang mga migration na iyon, kaya hindi nagtutugma ang schema at code at humihinto ang upgrade sa kalagitnaan. Mag-check out ng bawat hard stop ayon sa pagkakasunod at patakbuhin ang ./install.sh sa bawat isa. Gumawa ng snapshot ng server bago magsimula, at basahin ang dokumentadong listahan ng mga release na dapat iwasan, kabilang ang 23.7.0, 25.9.0, at 25.12.0.