Mbadala wa Sentry kwa ajili ya ufuatiliaji wa makosa

Gharama za ufuatiliaji wa makosa (error tracking) unaojiendeshea kabla ya kuhifadhi tukio moja

Ufuatiliaji wa makosa unaojiendeshea (self-hosted) una namba moja inayoamua chaguo zima, nayo ni kiwango cha chini cha RAM kinachohitajika. Nyaraka za Sentry zenyewe kwa ajili ya toleo la self-hosted zinahitaji CPU cores 4, 16 GB ya RAM pamoja na 16 GB ya swap, na 20 GB ya nafasi ya diski, kabla hata programu yako haijatuma tukio moja. GlitchTip inahitaji 512 MB. Chaguzi zote hapa zinakubali matukio kutoka kwa Sentry SDKs zilezile, kwa hivyo huu si uamuzi kuhusu jinsi unavyoweka instrumentation kwenye code yako. Huu ni uamuzi kuhusu ukubwa wa seva unayotaka kulipia na kuiweka ikiwa hai.

Takwimu za rasilimali zilizochapishwa, kando kwa kando

Hizi ni namba ambazo kila mradi huchapisha kujihusu, kufikia Agosti 2026. Hizi si aina moja ya vipimo, kwa hivyo soma dokezo kwenye kila mstari kabla ya kuzilinganisha.

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

Kiasi cha 16 GB cha Sentry ni kiwango cha chini kilichoorodheshwa, na ukurasa huo huo unapendekeza 32 GB. Kiasi cha 0.5 GB cha GlitchTip ni pendekezo, na mradi huo unasema 256 MB ndicho kiwango cha chini cha kufanyia kazi, au 128 MB pamoja na swap ukiwa na usanidi makini. Kiasi cha 4 GB cha Bugsink si mojawapo ya hayo: ni ukubwa wa seva iliyotumiwa na mtoa huduma kwa ajili ya kipimo chake cha throughput. Takwimu iliyochapishwa ni mahali pa kuanzia, si ahadi kuhusu kiasi chako cha matukio (event volume).

Sentry self-hosted: bidhaa nzima, na gharama zake zote

Stack rasmi ni getsentry/self-hosted, mradi wa Docker Compose unaoendesha vipengele vilevile ambavyo Sentry hutumia katika uzalishaji. Nyaraka zake zenyewe zinaielezea kama "iliyokamilika kwa vipengele na iliyofungashwa kwa ajili ya deployments ndogo na majaribio ya dhana". Sentensi hiyo ndiyo muhtasari wa kweli. Unapata kila kipengele, na unapata kila sehemu inayofanya vipengele hivyo kufanya kazi.

Sakinisha kutoka kwenye release iliyowekewa tag badala ya kutoka 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

Kisha ianzishe:

docker compose up --wait

Sentry husikiliza kwenye http://127.0.0.1:9000 kwa chaguo-msingi. Docker Engine 19.03.6 au toleo jipya zaidi na Docker Compose 2.32.2 au toleo jipya zaidi vinahitajika, na Compose ya zamani hushindwa kutokana na syntax ya faili badala ya kitu chochote ambacho Sentry hufanya.

Angalia kile ulichokianzisha kweli:

docker compose ps
free -h

docker compose ps huorodhesha kila huduma kwenye stack, na orodha hiyo ni ndefu: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, na michakato kadhaa ya worker na cron. Ihesabu mara moja, kwa sababu namba hiyo ndiyo mzigo wako wa matengenezo. Kila ingizo ni mchakato unaoweza kuanguka, kujaza diski, au kushindwa kufanya migration.

Ikiwa huduma inakaa katika hali ya Restarting, angalia kumbukumbu (memory) kabla ya kitu kingine chochote:

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

Mstari kama Out of memory: Killed process 3412 (java) unamaanisha kuwa OOM killer (out of memory killer) wa kernel umechukua container kwa sababu mashine imeishiwa RAM, kwa hivyo huduma hiyo haifikii hali ya afya na stack haimalizi kuanza. Hii ndiyo matokeo ya kawaida ya kuendesha stack nzima chini ya kiwango cha chini kilichoelezwa kwenye nyaraka. Nyaraka pia huashiria kasi ya diski: iowait zaidi ya 10% inamaanisha mashine haiwezi kwenda sambamba na pipeline ya kuingiza data. Isome kutoka kwenye safu ya wa katika top, au kutoka iostat -x 5 ikiwa umesakinisha sysstat.

Uboreshaji (upgrades) ni sehemu ambayo watu huipuuza

Sentry self-hosted hutolewa kila mwezi chini ya CalVer, mfumo wa toleo unaozingatia kalenda, na release kuu tarehe 15 ya kila mwezi. Huwezi kuruka kutoka toleo la zamani moja kwa moja hadi la hivi karibuni. Mradi hufafanua matoleo ya "hard stop", na lazima uweke kila moja ili kuchukua database migrations zake. Kufikia Agosti 2026, hard stops zilizochapishwa ni 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 na 26.7.0. Nyaraka pia huorodhesha releases za kuruka kwa sababu ya matatizo ya migration, ikiwemo 23.7.0, 25.9.0, 25.12.0 na masafa ya 26.3.0 hadi 26.4.0.

Uboreshaji ni checkout pamoja na kurudia kuanzisha kisakinishi:

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

Chukua snapshot ya seva kabla ya kuanza, kwa sababu migration juu ya dataset kubwa ya ClickHouse inaweza kuchukua saa nyingi na kushindwa katikati huacha database ikiwa kati ya schemas mbili. Sababu kuu ya uboreshaji mwingi wa Sentry self-hosted kushindwa: mashine ilikaa kwenye toleo moja kwa mwaka mzima, kwa hivyo kuruka huko kunavuka hard stops kadhaa kwa wakati mmoja na moja ya migrations iliyorukwa ndiyo iliyokuwa muhimu.

Jambo moja zaidi la kujua kabla ya kujitolea. Sentry self-hosted iko chini ya Functional Source License (FSL), ambayo Sentry yenyewe ilianzisha. Ni "fair source" badala ya open source iliyoidhinishwa na OSI: unaweza kuiendesha kwa ajili yako mwenyewe, na huwezi kuiuza kama huduma shindani. Kila release hubadilika kuwa Apache 2.0 miaka miwili baada ya kutolewa.

GlitchTip: jibu la 512 MB

GlitchTip ina leseni ya MIT na hupokea matukio kutoka kwa SDK za chanzo huria za Sentry, kwa hivyo programu iliyosanidiwa huhamia kwa kubadilisha thamani moja: DSN (data source name, URL ambayo SDK yako hutuma matukio). Inahitaji PostgreSQL 14 au toleo jipya zaidi. Valkey au Redis 7 au toleo jipya zaidi ni hiari, na hufanya mifumo mikubwa kuwa ya haraka zaidi.

Usakinishaji ni Docker pamoja na faili moja ya compose:

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

Hariri sehemu ya environment kabla ya kuanza jambo lolote. Thamani unazopaswa kuweka ni secret, domain na njia ya barua pepe:

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

Sampuli hiyo tayari imeunganisha DATABASE_URL kwenye huduma yake yenyewe ya postgres, kwa hivyo acha mstari huo kama ulivyo isipokuwa kama unaelekeza kwenye database unayoiendesha mahali pengine. GLITCHTIP_DOMAIN lazima ijumuishe scheme. Bila https:// mwanzoni, viungo katika barua pepe za tahadhari hujengwa vibaya na kutua kwenye URL isiyojibu.

Ianzishe na ufuatilie boot ya kwanza:

docker compose up -d
docker compose logs -f web

Tag za image katika sampuli hiyo kufikia Agosti 2026 ni postgres:18, valkey/valkey:9 na glitchtip/glitchtip:6. Ziweke zikiwa zimefungwa (pinned). Faili ya compose inayosema latest itaboresha database engine yako kwenye docker compose pull inayofuata, na kuruka kwa toleo kuu la Postgres wakati mfumo unafanya kazi ndiyo njia ambayo kifuatiliaji makosa kinachoanza kufanya kazi huacha kuanza.

Ili kufikia kiwango cha 256 MB hadi 512 MB, maoni ya faili ya sampuli yenyewe yanakuambia nini cha kuzima, kuanzia Valkey na vipengele vya hiari vya log na uptime. Kuendesha bila Valkey inamaanisha GlitchTip hutumia database yake kwa kazi za cache na queue badala yake, jambo ambalo ni polepole lakini bado ni sahihi. Hali ya "all in one" huendesha worker ndani ya mchakato wa web, kwa hivyo unadumisha container moja ya programu badala ya mbili.

Weka proxy mbele yake. Nyaraka za GlitchTip zinaomba proxy au load balancer inayohifadhi maombi (buffer) na kushughulikia chunked Transfer-Encoding, na inatoa nginx kama mfano uliothibitishwa. Bila buffering, mteja wa polepole huweka worker wa programu wazi kwa muda wote wa upload, kwa hivyo watumaji wachache wa polepole wanaweza kuchukua kila worker uliyo nayo na wateja wenye afya huanza kupata muda wa kuisha (timeout).

Uboreshaji ni sehemu rahisi:

docker compose pull
docker compose stop
docker compose up -d

Uhamiaji wa database (migrations) hufanyika kiotomatiki wakati wa kuanza. Hata hivyo, chukua dump kwanza, kwa sababu uhamiaji wa kiotomatiki bado ni uhamiaji.

Bugsink: kontena moja, na leseni unayopaswa kuisoma

Bugsink ndiyo nyepesi zaidi kati ya hizo tatu. Inatumia itifaki ya Sentry SDK, na inaendeshwa bila foleni ya ujumbe (message queue) wala huduma yoyote ya nje isipokuwa database. SQLite ndiyo chaguo-msingi, huku MySQL na PostgreSQL zikikubalika pindi unapohitaji uwezo mkubwa zaidi.

Mfano wa muda (throwaway instance), ili kuona kiolesura kabla ya kuamua kuitumia:

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

Fungua http://localhost:8000/ na uingie kwa kutumia anwani na nenosiri ulivyoweka katika CREATE_SUPERUSER. Kontena hilo halihifadhi chochote likisimamishwa. Kwa mfano wa kudumu, chukua sampuli ya compose ya mradi huo, inayooanisha bugsink/bugsink:2 na postgres:17-alpine na kuweka DATABASE_URL, BASE_URL na BEHIND_HTTPS_PROXY. Tengeneza siri (secret) ipasavyo:

openssl rand -base64 50

BASE_URL lazima ilingane na URL ambayo watumiaji wako na SDK wanaitumia kikweli, ikijumuisha scheme. Ikiachwa katika http://localhost:8000 kwenye seva unayoifikia kupitia https://errors.example.com, kila kiungo katika barua pepe ya taarifa kitaelekeza kwenye host ambayo haitambuliki kwa mtu anayesoma barua hiyo. Weka BEHIND_HTTPS_PROXY kuwa true wakati Nginx au Caddy inafanya TLS (transport layer security) termination mbele yake, kwa sababu vinginevyo Bugsink itajenga URL za http:// nyuma ya proxy yako ya https:// na vivinjari vitazuia maudhui hayo mchanganyiko (mixed content).

Muuzaji anachapisha takwimu zake za throughput: matukio 18 kwa sekunde kila moja ikiwa na KB 50, ambayo ni sawa na matukio milioni 1.5 kwa siku, kwenye VPS ya 2 vCPU na 4 GB. Ichukulie hiyo kama muundo wa zana hiyo badala ya dhamana kwa mzigo wako wa kazi. Hata hivyo, inaonyesha kuwa uwezo wake wa juu uko mbali zaidi ya kile ambacho programu moja ndogo huzalisha.

Sasa kuhusu leseni, na hii ndiyo sehemu ya kuisoma kabla haijaingia kwenye stack yako. Bugsink imetolewa chini ya leseni ya PolyForm Shield License 1.0.0. Hiyo ni "source available", si "open source": unaweza kuiendesha na kuibadilisha, lakini huwezi kuitumia kujenga kitu kinachoshindana na Bugsink. Kwa kifuatiliaji cha makosa cha ndani (internal error tracker), kizuizi hicho hakijitokezi kamwe. Ikiwa kampuni yako inauza zana za watengenezaji programu, mtafute mtu asome maandishi ya leseni hiyo kwanza.

Ufuatiliaji wa makosa na uwezo wa kuona LLM bado ni zana mbili tofauti

Tafuta zana moja inayofanya ufuatiliaji wa makosa na uwezo wa kuona (observability) wa large language model (LLM) kwa pamoja, na utapata bidhaa zinazodai kufanya yote mawili. Maumbo ya data ni tofauti, ndiyo maana muunganiko huu haujatokea. Kifuatiliaji cha makosa hupokea exception yenye stack trace, huhesabu fingerprint kutoka humo, na kukusanya maelfu ya matukio kuwa tatizo moja lenye kaunta. Zana ya kufuatilia LLM hupokea span iliyo na prompt, response, idadi ya token na latency, na ni lazima ihifadhi kila moja, kwa sababu wito mbili zenye pembejeo zinazofanana bado ni matukio tofauti yanayostahili kusomwa.

Kwa hiyo, tumia zote mbili. Tuma exceptions kwenye kifuatiliaji cha makosa, na utume wito wa model mahali palipojengwa kwa ajili hiyo: Langfuse inayojiendesha yenyewe kwa ajili ya kufuatilia wakala inashughulikia upande huo, na observability ya AI inayojiendesha yenyewe inashughulikia kazi hiyo hiyo kwa mtazamo tofauti. Programu yako tayari inazalisha aina zote mbili za hitilafu. Wito wa model unaorejesha maelezo yasiyo na maana lakini kwa kujiamini hautoi exception yoyote, kwa hivyo kifuatiliaji cha makosa hakitakuonyesha kamwe.

Ukuaji wa diski ni hitilafu inayokupata baadaye

Kila kifuatiliaji cha hitilafu ni hifadhidata inayopokea data nyingi (write-heavy) na yenye ingizo lisilo na kikomo. Programu yako huamua kiasi cha data inayoandika, na mdudu mmoja mpya katika sehemu ya msimbo inayotumika sana anaweza kuzalisha matukio milioni moja kwa usiku mmoja.

GlitchTip hutoa takwimu inayofaa kuzingatiwa wakati wa kupanga: mfano unaoshughulikia matukio milioni moja kwa mwezi unaweza kuhitaji 30 GB ya diski. Hiyo inatosha kwa mwezi mmoja wa kupokea data kwa kiwango hicho, na muda wa kuhifadhi (retention window) ndio unaoamua ni miezi mingapi unayohifadhi kwa wakati mmoja.

Bugsink inashughulikia hili kwa njia tofauti. Badala ya kufuata kiasi maalum, inatumia algoriti ya kuhifadhi kulingana na idadi ya matukio na umri wa tukio, na inaweka mipaka hiyo wazi: MAX_RETENTION_EVENT_COUNT kwa usakinishaji mzima, MAX_RETENTION_PER_PROJECT_EVENT_COUNT kwa kila mradi, na MAX_EVENT_AGE_DAYS kama kikomo cha mwisho. Kuweka bajeti ya matukio kwa usakinishaji mzima ndiyo njia sahihi ya kukadiria ukubwa wa diski, kwa sababu bajeti hiyo ndiyo diski yenyewe.

Fuatilia namba halisi kwenye seva:

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

docker system df -v huonyesha ukubwa wa kila volume, ili uweze kuona ni huduma ipi inayokua. Volume inayoongezeka kwa gigabytes kadhaa kwa wiki bila mabadiliko katika trafiki mara nyingi inamaanisha kuwa retention haikuwahi kusanidiwa, hivyo hakuna kinachofutwa na kikomo pekee ni partition yenyewe.

Kumbukumbu (memory) ni tatizo lilelile lililojivika sura nyingine. Stack isiyo na mipaka itachukua kila kitu kinachotolewa na kernel, na mashine ikikosa nafasi, OOM killer huchagua mchakato mkubwa zaidi, ambao unaweza kuwa seva yako ya wavuti badala ya kifuatiliaji kilichosababisha tatizo. Ipe kila huduma kikomo: memory limits in Docker Compose inaonyesha sintaksia na kile ambacho kontena hufanya linapofikia kikomo chake. Kontena linalositishwa kwenye kikomo chake ni hitilafu iliyodhibitiwa. Kontena linalositishwa na kernel linaweza kusababisha huduma jirani kufeli pia.

Ni stack ipi inafaa kwa VPS ipi

• 1 GB, au 2 GB yenye nafasi ya ziada: GlitchTip katika hali ya all-in-one huku Valkey ikiwa imezimwa, au Bugsink kwenye SQLite. Zote hufanya kazi vizuri hapa kwa ajili ya programu chache.
• 4 GB: Bugsink yenye PostgreSQL, au GlitchTip ikiwa Valkey imewashwa na huduma ya worker tofauti. Hii ndiyo saizi ambayo huwezi kuhitaji kufanya tuning, unaiendesha tu.
• 8 GB: bado haitoshi kwa stack rasmi ya Sentry. Itumie kwa ajili ya muda mrefu wa kuhifadhi data (retention window) na diski kubwa zaidi kwa chaguo lolote jepesi ulilochagua.
• 16 GB kiwango cha chini, 32 GB inapendekezwa: stack rasmi ya Sentry inayojiendesha (self-hosted), na hii ni pale tu unapohitaji kipengele cha Sentry ambacho miradi midogo haijatekeleza. Kagua kipengele hicho mahususi dhidi ya nyaraka za kila mradi kwanza, kwa sababu miradi inayooana inashughulikia vipengele vya kawaida.

Chochote unachoendesha, kifuatiliaji makosa (error tracker) hakiwezi kuripoti kifo chake chenyewe. Kiwekee ufuatiliaji kutoka kwenye mashine nyingine: Uptime Kuma ikifuatilia kutoka kwenye mashine nyingine itakuambia kuwa kifuatiliaji kimezimika, jambo ambalo ndilo hasa wakati programu yako inapoanza kutoa makosa ambayo hakuna anayeyarekodi.

Wakati mpango wa hosting unaolipwa unapokuwa chaguo nafuu

Kujihostia mfumo wa kufuatilia hitilafu (error tracker) kunalipa pale sheria za uhifadhi wa data zinapokulazimisha kufanya hivyo, au pale kiasi cha matukio (event volume) kinapokuwa kikubwa kiasi kwamba bei ya kila tukio inakuwa ghali. Nje ya hali hizo, fanya hesabu kwa uaminifu. Mahitaji ya chini yaliyoandikwa na Sentry ni seva ya 16 GB yenye cores 4 na diski ya haraka, na VPS ya ukubwa huo si VPS ya bei nafuu. Kisha ongeza kazi ya uendeshaji: kupitia kila hatua ngumu kwa mpangilio, na kuchukua snapshot kabla ya kila migration, mara chache kwa mwaka.

GlitchTip na Bugsink hubadilisha hesabu hiyo kabisa, kwa sababu 512 MB hadi 4 GB ni mashine ya bei nafuu na upgrade yake ni docker compose pull. Hiyo ndiyo sababu watu wengi wanaouliza swali hili huishia kwenye moja ya miradi inayooana badala ya stack rasmi. Walitaka ufuatiliaji wa hitilafu, si mfumo wa data uliosambazwa (distributed data pipeline) wa kuulea.

Ikiwa bado unafanya maamuzi kuhusu kipi kinachostahili kuwa kwenye seva, orodha pana ya huduma zinazostahili kujihostiwa inaweka ufuatiliaji wa hitilafu sambamba na huduma nyingine zinazogombea RAM hiyo hiyo.

FAQ

Je, ninaweza ku-host Sentry kwenye VPS ya 2 GB?

Hapana. Nyaraka za Sentry zinazojihostia zinasema kiwango cha chini ni CPU 4, 16 GB ya RAM pamoja na 16 GB ya swap, na 20 GB ya nafasi ya diski. Stack hiyo huendesha Postgres, ClickHouse, Kafka, Redis na michakato mingi ya worker kwa wakati mmoja, kwa hivyo kwenye seva ndogo kernel huua containers kabla ya usakinishaji kukamilika. Thibitisha hili kwa dmesg -T | grep -i 'out of memory', ambayo huchapisha mstari unaotaja mchakato uliouawa. Kwa VPS ya 2 GB tumia GlitchTip, ambayo inahitaji 512 MB, au Bugsink, inayofanya kazi kama container moja kwenye SQLite.

Je, lazima nibadilishe code ya programu yangu ili kuhama kutoka Sentry kwenda GlitchTip au Bugsink?

Hapana. Zote mbili hukubali matukio kutoka kwa SDK za Sentry zilizo wazi (open source), kwa hivyo unahifadhi SDK uliyosakinisha tayari na kubadilisha thamani moja tu: DSN, ambayo ni URL ambapo SDK hutuma matukio. Ihamishe kwenye environment variable ikiwa bado imewekwa moja kwa moja kwenye code, ielekeze kwenye host mpya, kisha anzisha exception ya majaribio na uone kama inafika. Ikiwa hakuna kinachoonekana, hakikisha kitambulisho cha mradi (project identifier) kwenye DSN kinalingana na mradi uliopo kwenye seva mpya, na kwamba firewall yako inaruhusu programu kufikia host na port hiyo.

Ufuatiliaji wa makosa (error tracking) unaojihostia unahitaji diski kiasi gani?

Hiyo inategemea kiasi cha matukio yako na muda wa kuhifadhi data (retention window) badala ya zana yenyewe. GlitchTip inashauri 30 GB kwa instance inayoshughulikia matukio milioni moja kwa mwezi. Bugsink inakuruhusu kuweka bajeti moja kwa moja kwa MAX_RETENTION_EVENT_COUNT na MAX_EVENT_AGE_DAYS, kwa hivyo unachagua ukomo na mahitaji ya diski yatafuata kulingana na hapo. Sanidi retention siku ya kwanza. Tracker isiyo na sera ya retention hukua hadi df -h isome 100%, na wakati huo uingizaji wa data husimama na unapoteza makosa uliyotaka kuyaona zaidi.

Kwa nini uboreshaji (upgrade) wa Sentry inayojihostia unashindwa kila mara?

Kwa sababu uboreshaji huo umeruka hatua muhimu ya kusimama (hard stop). Sentry inayojihostia ina matoleo maalum yenye database migrations ambayo lazima uyapitie, na kufikia Agosti 2026 hayo ni 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 na 26.7.0. Kwenda moja kwa moja kutoka toleo la zamani hadi jipya zaidi huruka migrations hizo, kwa hivyo schema na code hazipatani na uboreshaji husimama katikati. Angalia kila hard stop kwa mpangilio na uendeshe ./install.sh kwenye kila hatua, chukua snapshot ya seva kabla ya kuanza, na usome orodha ya matoleo yaliyotajwa ambayo unapaswa kuyaepuka, ambayo ni pamoja na 23.7.0, 25.9.0 na 25.12.0.