Alternatif Sentry Self-Hosted Ringan dan Jimat RAM

Kos pengesanan ralat yang dihoskan sendiri sebelum menyimpan satu acara

Pengesanan ralat yang dihoskan sendiri mempunyai satu angka yang menentukan keseluruhan pilihan, iaitu keperluan minimum RAM. Dokumentasi rasmi Sentry untuk hos sendiri memerlukan 4 teras CPU, 16 GB RAM berserta 16 GB swap, dan 20 GB ruang cakera kosong, sebelum aplikasi anda menghantar satu pun acara. GlitchTip pula mendokumentasikan keperluan sebanyak 512 MB. Semua pilihan di sini menerima acara daripada SDK Sentry yang sama, jadi ini bukanlah keputusan tentang cara anda melakukan instrumentasi pada kod anda. Ini adalah keputusan tentang saiz pelayan yang anda sanggup bayar dan kekalkan operasinya.

Angka sumber yang diterbitkan, bersebelahan

Ini adalah angka yang diterbitkan oleh setiap projek mengenai diri mereka sendiri, setakat Ogos 2026. Ia bukan jenis ukuran yang sama, jadi baca nota pada setiap baris sebelum anda membandingkannya.

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

16 GB bagi Sentry ialah minimum yang didokumentasikan, dan halaman yang sama mengesyorkan 32 GB. 0.5 GB bagi GlitchTip ialah satu syor, dan projek tersebut menyatakan 256 MB sebagai minimum untuk berfungsi, atau 128 MB berserta swap dengan konfigurasi yang teliti. 4 GB bagi Bugsink bukan kedua-duanya: ia adalah spesifikasi pelayan yang digunakan oleh vendor untuk penanda aras throughput mereka sendiri. Angka yang diterbitkan hanyalah titik permulaan, bukan janji mengenai volum acara anda.

Sentry self-hosted: keseluruhan produk dan keseluruhan kos

Struktur rasmi ialah getsentry/self-hosted, iaitu projek Docker Compose yang menjalankan komponen yang sama seperti yang digunakan oleh Sentry dalam pengeluaran. Dokumentasinya sendiri menyifatkan ia sebagai "lengkap dengan ciri dan dibungkus untuk penggunaan volum rendah serta pembuktian konsep". Ayat itu adalah ringkasan yang jujur. Anda mendapat setiap ciri, dan anda mendapat setiap bahagian bergerak yang menjadikan ciri tersebut berfungsi.

Pasang daripada release yang bertanda (tagged release) dan bukannya daripada 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

Kemudian mulakannya:

docker compose up --wait

Sentry mendengar pada http://127.0.0.1:9000 secara lalai. Docker Engine 19.03.6 atau lebih baharu dan Docker Compose 2.32.2 atau lebih baharu diperlukan, dan Compose yang lebih lama akan gagal pada sintaks fail dan bukannya pada apa-apa yang dilakukan oleh Sentry.

Lihat perkara yang sebenarnya anda mulakan:

docker compose ps
free -h

docker compose ps menyenaraikan setiap servis dalam stack tersebut, dan senarainya panjang: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, serta beberapa proses worker dan cron. Kira jumlahnya sekali, kerana nombor itu adalah beban penyelenggaraan anda. Setiap entri ialah proses yang boleh terhenti (crash), memenuhi cakera, atau gagal dalam migrasi.

Jika sesuatu servis berada dalam keadaan Restarting, periksa memori sebelum perkara lain:

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

Baris seperti Out of memory: Killed process 3412 (java) bermakna OOM killer (out of memory killer) kernel telah mengambil bekas (container) kerana mesin kehabisan RAM, jadi servis itu tidak pernah menjadi sihat dan stack tidak pernah selesai dimulakan. Ini adalah hasil biasa apabila menjalankan stack penuh di bawah minimum yang didokumenkan. Dokumentasi juga menandakan kelajuan cakera: iowait melebihi 10% bermakna mesin tidak dapat menampung pipeline ingest. Bacanya daripada lajur wa dalam top, atau daripada iostat -x 5 jika anda telah memasang sysstat.

Naik taraf adalah bahagian yang dipandang remeh oleh orang ramai

Sentry self-hosted dikeluarkan setiap bulan di bawah CalVer, iaitu skim versi berasaskan kalendar, dengan release utama pada hari ke-15 setiap bulan. Anda tidak boleh melompat dari versi lama terus ke versi terkini. Projek ini menetapkan versi hard stop, dan anda mesti melakukan checkout pada setiap satu daripadanya untuk mengambil migrasi pangkalan data. Setakat Ogos 2026, hard stop yang diterbitkan ialah 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 dan 26.7.0. Dokumentasi juga menyenaraikan release yang perlu dilangkau kerana masalah migrasi, termasuk 23.7.0, 25.9.0, 25.12.0 dan julat 26.3.0 hingga 26.4.0.

Naik taraf ialah checkout ditambah dengan menjalankan semula pemasang:

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

Ambil snapshot pelayan sebelum anda bermula, kerana migrasi ke atas dataset ClickHouse yang besar boleh berjalan selama berjam-jam dan kegagalan di pertengahan jalan akan menyebabkan pangkalan data berada di antara dua skema. Punca utama kebanyakan naik taraf Sentry self-hosted yang gagal: mesin dibiarkan pada satu versi selama setahun, jadi lompatan tersebut merentasi beberapa hard stop sekaligus dan salah satu migrasi yang dilangkau adalah migrasi yang penting.

Satu lagi perkara yang perlu diketahui sebelum anda komited. Sentry self-hosted berada di bawah Functional Source License (FSL), yang diperkenalkan oleh Sentry sendiri. Ia adalah sumber yang adil (fair source) dan bukannya sumber terbuka yang diluluskan oleh OSI: anda boleh menjalankannya untuk diri sendiri, dan anda tidak boleh menjualnya sebagai servis yang bersaing. Setiap release akan bertukar kepada Apache 2.0 dua tahun selepas ia dikeluarkan.

GlitchTip: jawapan 512 MB

GlitchTip dilesenkan di bawah MIT dan menerima acara daripada SDK sumber terbuka Sentry. Oleh itu, aplikasi yang telah diinstrumentasi boleh dipindahkan dengan menukar satu nilai sahaja: DSN (data source name, iaitu URL tempat SDK anda menghantar acara). Ia memerlukan PostgreSQL 14 atau lebih baharu. Valkey atau Redis 7 atau lebih baharu adalah pilihan, dan ia menjadikan instans yang lebih besar lebih pantas.

Pemasangan menggunakan Docker dan satu fail compose:

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

Sunting bahagian environment sebelum memulakan apa-apa. Nilai yang wajib ditetapkan ialah secret, domain dan laluan mel:

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

Sampel tersebut sudah menghubungkan DATABASE_URL kepada perkhidmatan postgres miliknya sendiri, jadi jangan ubah baris tersebut kecuali anda menghala ke pangkalan data yang dijalankan di tempat lain. GLITCHTIP_DOMAIN mesti menyertakan skema. Tanpa https:// di hadapan, pautan dalam e-mel makluman akan dibina dengan salah dan menuju ke URL yang tidak memberikan respons.

Mulakan ia dan perhatikan but pertama:

docker compose up -d
docker compose logs -f web

Tag imej dalam sampel setakat Ogos 2026 ialah postgres:18, valkey/valkey:9 dan glitchtip/glitchtip:6. Pastikan ia kekal dipinkan. Fail compose yang menyatakan latest akan menaik taraf enjin pangkalan data anda pada docker compose pull seterusnya, dan lonjakan versi utama Postgres semasa instans sedang berjalan adalah punca pengesan ralat yang berfungsi berhenti bermula.

Untuk mencapai julat 256 MB hingga 512 MB, komen dalam fail sampel itu sendiri memberitahu anda perkara yang perlu dimatikan, bermula dengan Valkey serta ciri log dan uptime pilihan. Berjalan tanpa Valkey bermakna GlitchTip menggunakan pangkalan datanya untuk kerja cache dan baris gilir, yang lebih perlahan tetapi masih tepat. Mod all in one menjalankan worker di dalam proses web, jadi anda menyelenggara satu kontena aplikasi dan bukannya dua.

Letakkan proksi di hadapannya. Dokumentasi GlitchTip meminta proksi atau pengimbang beban yang menimbal (buffer) permintaan dan mengendalikan Transfer-Encoding yang dipecahkan (chunked), dan ia memberikan nginx sebagai contoh yang terbukti berfungsi. Tanpa penimbalan, klien yang perlahan akan membiarkan worker aplikasi terbuka sepanjang tempoh muat naik, jadi beberapa penghantar yang perlahan boleh menduduki setiap worker yang anda ada dan klien yang sihat akan mula mengalami tamat masa (timeout).

Menaik taraf adalah bahagian yang mudah:

docker compose pull
docker compose stop
docker compose up -d

Migrasi pangkalan data berjalan secara automatik semasa permulaan. Walau bagaimanapun, buat dump terlebih dahulu, kerana migrasi automatik tetap merupakan satu migrasi.

Bugsink: satu kontena, dan lesen yang perlu anda baca

Bugsink ialah yang paling ringan antara ketiga-tiganya. Ia menggunakan protokol Sentry SDK, dan ia berjalan tanpa baris gilir mesej serta tiada servis luaran selain pangkalan data. SQLite ialah tetapan lalai, dengan sokongan untuk MySQL dan PostgreSQL apabila keperluan anda melebihi kapasiti SQLite.

Satu instans sementara, untuk melihat antara muka sebelum anda membuat komitmen:

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

Buka http://localhost:8000/ dan daftar masuk dengan alamat serta kata laluan yang anda masukkan dalam CREATE_SUPERUSER. Kontena tersebut tidak menyimpan apa-apa apabila ia dihentikan. Untuk instans sebenar, ambil contoh compose projek tersebut, yang menggandingkan bugsink/bugsink:2 dengan postgres:17-alpine serta menetapkan DATABASE_URL, BASE_URL dan BEHIND_HTTPS_PROXY. Jana rahsia (secret) dengan betul:

openssl rand -base64 50

BASE_URL mestilah sepadan dengan URL yang benar-benar digunakan oleh pengguna dan SDK anda, termasuk skema. Jangan biarkannya pada http://localhost:8000 jika anda mengakses kotak tersebut pada https://errors.example.com, kerana setiap pautan dalam e-mel pemberitahuan akan menghala ke hos yang tidak dapat diselesaikan (resolve) bagi orang yang membacanya. Tetapkan BEHIND_HTTPS_PROXY kepada true apabila Nginx atau Caddy melakukan TLS (transport layer security) termination di hadapannya, kerana jika tidak, Bugsink akan membina URL http:// di sebalik proksi https:// anda dan pelayar akan menyekat kandungan bercampur (mixed content).

Vendor menerbitkan angka throughput mereka sendiri: 18 peristiwa sesaat pada 50 KB setiap satu, yang berjumlah 1.5 juta peristiwa sehari, pada VPS 2 vCPU dan 4 GB. Anggap ini sebagai gambaran keupayaan alat tersebut dan bukannya jaminan untuk beban kerja anda. Ia menunjukkan bahawa had maksimumnya jauh melebihi apa yang dihasilkan oleh satu aplikasi kecil.

Sekarang mengenai lesen, dan ini adalah bahagian yang perlu dibaca sebelum ia dimasukkan ke dalam stack anda. Bugsink dikeluarkan di bawah PolyForm Shield License 1.0.0. Ia adalah source available, bukan open source: anda boleh menjalankannya dan mengubah suainya, tetapi anda tidak boleh menggunakannya untuk membina sesuatu yang bersaing dengan Bugsink. Untuk pengesan ralat dalaman, sekatan ini tidak akan menjadi isu. Jika syarikat anda menjual alatan pembangun, minta seseorang membaca teks lesen tersebut terlebih dahulu.

Penjejakan ralat dan kebolehcerapan LLM masih merupakan dua alat yang berbeza

Cari satu alat yang melakukan penjejakan ralat dan kebolehcerapan large language model (LLM) secara serentak dan anda akan menemui produk yang mendakwa mampu melakukan kedua-duanya. Bentuk data bagi kedua-duanya adalah berbeza, itulah sebabnya penggabungan tersebut tidak pernah berlaku. Penjejak ralat menerima pengecualian (exception) berserta stack trace, mengira cap jari (fingerprint) daripadanya, dan menggabungkan ribuan kejadian menjadi satu isu dengan pembilang. Alat penjejakan LLM menerima span yang mengandungi prompt, respons, kiraan token dan kependaman (latency), dan ia perlu menyimpan setiap satu daripadanya, kerana dua panggilan dengan input yang sama tetap merupakan peristiwa berasingan yang perlu dibaca.

Oleh itu, jalankan kedua-duanya. Hantar pengecualian kepada penjejak ralat, dan hantar panggilan model ke tempat yang dibina khusus untuknya: Langfuse yang dihoskan sendiri untuk penjejakan ejen meliputi bahagian tersebut, dan kebolehcerapan AI yang dihoskan sendiri mendekati tugas yang sama dari sudut yang berbeza. Aplikasi anda sudah pun menghasilkan kedua-dua jenis kegagalan ini. Panggilan model yang mengembalikan maklumat tidak tepat tetapi kelihatan yakin tidak mencetuskan sebarang pengecualian, jadi penjejak ralat tidak akan memaparkannya kepada anda.

Pertumbuhan cakera ialah kegagalan yang akan menjejaskan anda kemudian

Setiap penjejak ralat ialah pangkalan data dengan beban tulis yang tinggi dan input tanpa had. Aplikasi anda menentukan jumlah data yang ditulis, dan satu pepijat baharu dalam laluan kod yang kerap digunakan boleh menghasilkan sejuta peristiwa dalam satu malam.

GlitchTip menerbitkan angka yang wajar dijadikan rujukan perancangan: satu instans yang mengendalikan satu juta peristiwa sebulan mungkin memerlukan 30 GB ruang cakera. Ini merangkumi satu bulan pengambilan data pada kadar tersebut, dan tempoh pengekalan (retention window) anda menentukan berapa banyak bulan yang disimpan pada satu-satu masa.

Bugsink mengambil pendekatan berbeza. Daripada menggunakan kuota tetap, ia menggunakan algoritma pengekalan berdasarkan kiraan dan usia peristiwa, serta mendedahkan had tersebut secara terus: MAX_RETENTION_EVENT_COUNT untuk keseluruhan pemasangan, MAX_RETENTION_PER_PROJECT_EVENT_COUNT bagi setiap projek, dan MAX_EVENT_AGE_DAYS sebagai had mutlak. Menetapkan belanjawan peristiwa untuk keseluruhan pemasangan ialah cara yang jujur untuk menentukan saiz cakera, kerana belanjawan tersebut adalah had cakera itu sendiri.

Pantau angka sebenar pada mesin:

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

docker system df -v memaparkan saiz setiap volum, supaya anda boleh melihat servis mana yang sedang berkembang. Volum yang meningkat beberapa gigabait seminggu tanpa perubahan pada trafik biasanya bermakna pengekalan tidak pernah dikonfigurasikan, jadi tiada data yang dipadamkan dan satu-satunya had ialah saiz partition.

Memori adalah masalah yang sama dalam bentuk berbeza. Stak tanpa had akan mengambil semua sumber yang ditawarkan oleh kernel, dan apabila mesin kehabisan memori, OOM killer akan memilih proses yang paling besar, yang mungkin merupakan pelayan web anda dan bukannya penjejak yang menyebabkannya. Berikan setiap servis had maksimum: had memori dalam Docker Compose menunjukkan sintaks dan tindakan kontena apabila ia mencapai hadnya. Kontena yang dihentikan pada hadnya sendiri merupakan kegagalan yang terpencil. Kontena yang dihentikan oleh kernel akan menyebabkan servis jiran turut terjejas.

Stap yang manakah sesuai untuk VPS yang mana

• 1 GB, atau 2 GB dengan ruang lebihan: GlitchTip dalam mod all-in-one dengan Valkey dimatikan, atau Bugsink menggunakan SQLite. Kedua-duanya selesa digunakan di sini untuk beberapa aplikasi.
• 4 GB: Bugsink dengan PostgreSQL, atau GlitchTip dengan Valkey dihidupkan dan perkhidmatan worker yang berasingan. Ini adalah saiz di mana anda tidak perlu lagi melakukan penalaan dan boleh terus menjalankannya.
• 8 GB: masih tidak mencukupi untuk stap rasmi Sentry. Gunakan sumber ini untuk tempoh pengekalan data yang lebih lama dan cakera yang lebih besar bagi mana-mana pilihan ringan yang anda pilih.
• Minimum 16 GB, disyorkan 32 GB: stap rasmi Sentry yang dihoskan sendiri, dan hanya jika anda memerlukan ciri Sentry yang tidak dilaksanakan oleh projek yang lebih ringan. Semak ciri khusus tersebut berbanding dokumentasi setiap projek terlebih dahulu, kerana projek yang serasi sudah merangkumi ciri-ciri yang biasa digunakan.

Walau apa pun yang anda jalankan, pengesan ralat tidak boleh melaporkan kegagalannya sendiri. Letakkan pemantauan ke atasnya daripada mesin yang berbeza: Uptime Kuma yang memantau dari kotak lain akan memberitahu anda jika pengesan tersebut terhenti, iaitu saat tepat di mana aplikasi anda mula mengeluarkan ralat yang tidak direkodkan oleh sesiapa pun.

Apabila pelan langganan menjadi pilihan yang lebih murah

Self-hosting pengesan ralat (error tracker) berbaloi apabila peraturan residensi data mewajibkannya, atau apabila volum acara anda cukup tinggi sehingga harga per acara menjadi mahal. Selain daripada kes tersebut, lakukan pengiraan dengan jujur. Keperluan minimum yang didokumentasikan oleh Sentry ialah pelayan 16 GB dengan 4 teras dan cakera pantas, dan VPS dengan spesifikasi tersebut bukanlah VPS yang murah. Kemudian, tambahkan beban kerja operasi: melengkapkan setiap langkah kritikal mengikut urutan, dan mengambil snapshot sebelum setiap migrasi, beberapa kali setahun.

GlitchTip dan Bugsink mengubah pengiraan tersebut sepenuhnya, kerana 512 MB hingga 4 GB adalah spesifikasi pelayan yang murah dan naik tarafnya adalah satu docker compose pull. Itulah sebabnya kebanyakan orang yang bertanya soalan ini akhirnya memilih salah satu projek yang serasi berbanding stack rasmi. Mereka mahukan pengesan ralat, bukan saluran data teragih (distributed data pipeline) yang perlu diselia.

Jika anda masih mempertimbangkan apa yang patut diletakkan pada pelayan, senarai lebih luas tentang apa yang berbaloi untuk di-self-host meletakkan pengesan ralat sebaris dengan perkhidmatan lain yang bersaing untuk mendapatkan RAM yang sama.

FAQ

Bolehkah saya melakukan self-hosting Sentry pada VPS 2 GB?

Tidak. Dokumentasi self-hosted Sentry menyatakan keperluan minimum 4 teras CPU, 16 GB RAM berserta 16 GB swap, dan 20 GB ruang cakera kosong. Stak ini menjalankan Postgres, ClickHouse, Kafka, Redis dan beberapa proses pekerja secara serentak, jadi pada pelayan kecil, kernel akan mematikan kontena sebelum pemasangan selesai. Sahkan perkara ini dengan dmesg -T | grep -i 'out of memory', yang akan memaparkan baris yang menamakan proses yang dimatikan. Untuk VPS 2 GB, gunakan GlitchTip yang mendokumentasikan keperluan 512 MB, atau Bugsink yang berjalan sebagai kontena tunggal menggunakan SQLite.

Adakah saya perlu menukar kod aplikasi untuk beralih daripada Sentry kepada GlitchTip atau Bugsink?

Tidak. Kedua-duanya menerima acara daripada SDK sumber terbuka Sentry, jadi anda boleh mengekalkan SDK yang telah dipasang dan hanya menukar satu nilai: DSN, iaitu URL tempat SDK menghantar acara. Pindahkan nilai ini ke dalam pemboleh ubah persekitaran (environment variable) jika ia masih dikodkan secara keras (hardcoded), halakan ia ke hos baharu, kemudian cetuskan pengecualian ujian dan perhatikan ia sampai. Jika tiada apa-apa yang muncul, periksa sama ada pengecam projek dalam DSN sepadan dengan projek yang wujud pada pelayan baharu, dan pastikan firewall anda membenarkan aplikasi mencapai hos dan port tersebut.

Berapakah ruang cakera yang diperlukan untuk penjejakan ralat (error tracking) yang dihoskan sendiri?

Itu bergantung pada jumlah acara dan tempoh pengekalan (retention window) anda, bukannya pada alat tersebut. GlitchTip menetapkan 30 GB untuk satu instans yang mengendalikan satu juta acara sebulan. Bugsink membolehkan anda menetapkan bajet secara terus dengan MAX_RETENTION_EVENT_COUNT dan MAX_EVENT_AGE_DAYS, jadi anda memilih had maksimum dan keperluan cakera akan mengikutinya. Konfigurasikan pengekalan pada hari pertama. Penjejak tanpa polisi pengekalan akan berkembang sehingga df -h membaca 100%, dan pada tahap itu proses kemasukan data akan terhenti dan anda akan kehilangan ralat yang paling penting untuk dilihat.

Mengapakah naik taraf Sentry yang dihoskan sendiri sering gagal?

Kerana naik taraf tersebut melangkaui titik henti wajib (hard stop). Sentry self-hosted menetapkan versi tertentu yang membawa migrasi pangkalan data yang mesti dilalui, dan setakat Ogos 2026, versi tersebut ialah 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 dan 26.7.0. Melompat terus daripada keluaran lama kepada yang terbaharu akan melangkaui migrasi tersebut, menyebabkan skema dan kod tidak selari lalu naik taraf terhenti di tengah jalan. Semak setiap titik henti wajib mengikut urutan dan jalankan ./install.sh pada setiap satu, ambil snapshot pelayan sebelum bermula, dan baca senarai keluaran yang didokumentasikan untuk dielakkan, yang merangkumi 23.7.0, 25.9.0 dan 25.12.0.