Alternatif Sentry Self-Hosted: Bandingkan RAM dan Biaya

Biaya pelacakan error self-hosted sebelum menyimpan satu event

Pelacakan error self-hosted memiliki satu angka yang menentukan seluruh pilihan, yaitu kebutuhan RAM minimum. Dokumentasi self-hosted Sentry sendiri menyebutkan kebutuhan 4 core CPU, 16 GB RAM ditambah 16 GB swap, dan 20 GB ruang disk kosong sebelum aplikasi Anda mengirim satu event pun. GlitchTip mendokumentasikan kebutuhan 512 MB. Semua opsi di sini menerima event dari Sentry SDK yang sama. Jadi, ini bukan keputusan tentang cara Anda menginstrumentasikan kode. Ini adalah keputusan tentang seberapa besar server yang bersedia Anda biayai dan pertahankan tetap aktif.

Angka sumber daya yang dipublikasikan, berdampingan

Berikut angka yang dipublikasikan masing-masing proyek tentang dirinya sendiri, per Agustus 2026. Angka tersebut tidak mengukur hal yang sama, jadi baca catatan pada setiap baris sebelum 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"
  }
]

Angka 16 GB milik Sentry adalah batas minimum yang terdokumentasi, dan halaman yang sama merekomendasikan 32 GB. Angka 0.5 GB milik GlitchTip adalah rekomendasi, dan proyek tersebut menyatakan 256 MB sebagai batas minimum yang dapat digunakan, atau 128 MB ditambah swap dengan konfigurasi yang cermat. Angka 4 GB milik Bugsink berbeda dari keduanya: angka tersebut adalah spesifikasi server yang digunakan vendor untuk benchmark throughput miliknya sendiri. Angka yang dipublikasikan merupakan titik awal, bukan jaminan untuk volume event Anda.

Sentry self-hosted: seluruh produk dan seluruh biayanya

Stack resmi adalah getsentry/self-hosted, yaitu proyek Docker Compose yang menjalankan komponen yang sama seperti yang digunakan Sentry di lingkungan production. Dokumentasinya sendiri mendeskripsikannya sebagai "feature-complete and packaged up for low-volume deployments and proofs-of-concept". Kalimat tersebut merupakan ringkasan yang paling tepat. Anda mendapatkan setiap fitur, sekaligus setiap komponen yang diperlukan agar fitur tersebut berfungsi.

Instal dari tagged release, bukan dari 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 jalankan:

docker compose up --wait

Secara default, Sentry mendengarkan pada http://127.0.0.1:9000. Docker Engine 19.03.6 atau yang lebih baru dan Docker Compose 2.32.2 atau yang lebih baru diperlukan. Compose versi lama gagal memproses sintaks file, bukan karena masalah pada Sentry.

Periksa komponen yang benar-benar Anda jalankan:

docker compose ps
free -h

docker compose ps menampilkan setiap service dalam stack. Daftarnya panjang: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, serta beberapa proses worker dan cron. Hitung jumlahnya sekali, karena angka tersebut menunjukkan beban pemeliharaan Anda. Setiap entri adalah proses yang dapat crash, memenuhi disk, atau gagal menjalankan migration.

Jika sebuah service berada dalam status Restarting, periksa penggunaan memory terlebih dahulu:

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

Baris seperti Out of memory: Killed process 3412 (java) berarti kernel OOM killer (out of memory killer) menghentikan sebuah container karena server kehabisan RAM. Akibatnya, service tersebut tidak pernah menjadi sehat dan stack tidak pernah selesai start. Ini merupakan hasil yang umum jika seluruh stack dijalankan dengan spesifikasi minimum yang didokumentasikan. Dokumentasi tersebut juga menyoroti kecepatan disk: iowait di atas 10% berarti mesin tidak mampu mengikuti pipeline ingest. Baca nilainya dari kolom wa di top, atau dari iostat -x 5 jika sysstat telah terpasang.

Upgrade adalah bagian yang sering diremehkan

Sentry self-hosted merilis versi setiap bulan dengan CalVer, yaitu skema versi berbasis kalender, dan rilis utama dilakukan pada tanggal 15 setiap bulan. Anda tidak dapat langsung berpindah dari versi lama ke versi terbaru. Proyek ini menetapkan versi hard stop, dan Anda harus melakukan checkout pada setiap versi tersebut secara berurutan agar seluruh database migration diterapkan. Per Agustus 2026, hard stop yang dipublikasikan adalah 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 tersebut juga mencantumkan rilis yang harus dilewati karena masalah migration, termasuk 23.7.0, 25.9.0, 25.12.0, serta rentang 26.3.0 hingga 26.4.0.

Upgrade dilakukan dengan checkout lalu menjalankan ulang installer:

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

Buat snapshot server sebelum memulai. Migration pada dataset ClickHouse yang besar dapat berjalan selama berjam-jam. Jika gagal di tengah proses, database dapat berada di antara dua schema. Penyebab umum kegagalan upgrade Sentry self-hosted adalah server tetap menggunakan satu versi selama setahun. Akibatnya, proses upgrade melewati beberapa hard stop sekaligus, dan salah satu migration yang harus dilewati justru merupakan migration yang diperlukan.

Ada satu hal lagi yang perlu diketahui sebelum Anda memutuskan untuk menggunakannya. Sentry self-hosted menggunakan Functional Source License (FSL), yang diperkenalkan oleh Sentry sendiri. Lisensi ini merupakan fair source, bukan open source yang disetujui OSI. Anda boleh menjalankannya untuk kebutuhan sendiri, tetapi tidak boleh menjualnya sebagai service yang bersaing. Setiap rilis berubah menjadi Apache 2.0 dua tahun setelah dirilis.

GlitchTip: jawaban untuk 512 MB

GlitchTip berlisensi MIT dan menerima event dari SDK open source milik Sentry. Karena itu, aplikasi yang sudah diinstrumentasi dapat dipindahkan dengan mengubah satu nilai: DSN (data source name, yaitu URL tujuan SDK mengirim event). GlitchTip memerlukan PostgreSQL 14 atau versi lebih baru. Valkey atau Redis 7 atau versi lebih baru bersifat opsional dan dapat mempercepat instance yang lebih besar.

Instalasinya hanya memerlukan Docker dan satu file compose:

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

Edit bagian environment sebelum menjalankan apa pun. Nilai yang harus diatur adalah secret, domain, dan jalur mail:

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

Contoh tersebut sudah menghubungkan DATABASE_URL ke service postgres miliknya sendiri. Biarkan baris itu apa adanya, kecuali Anda menggunakan database yang dijalankan di tempat lain. GLITCHTIP_DOMAIN harus menyertakan scheme. Jika bagian depannya tidak memuat https://, tautan dalam email alert akan dibuat secara keliru dan mengarah ke URL yang tidak merespons.

Jalankan service tersebut dan pantau boot pertama:

docker compose up -d
docker compose logs -f web

Tag image dalam contoh per Agustus 2026 adalah postgres:18, valkey/valkey:9, dan glitchtip/glitchtip:6. Tetapkan tag tersebut. File compose yang berisi latest akan meng-upgrade database engine pada docker compose pull berikutnya. Perubahan versi mayor Postgres pada instance yang sedang berjalan dapat menyebabkan error tracker yang sebelumnya berfungsi tidak dapat start.

Untuk menggunakan 256 MB hingga 512 MB, komentar dalam file contoh menjelaskan fitur yang harus dinonaktifkan. Mulailah dengan Valkey, kemudian nonaktifkan fitur log dan uptime yang bersifat opsional. Jika berjalan tanpa Valkey, GlitchTip menggunakan database untuk cache dan pekerjaan queue. Prosesnya lebih lambat, tetapi tetap benar. Mode all in one menjalankan worker di dalam proses web. Dengan demikian, Anda hanya perlu memelihara satu container aplikasi, bukan dua.

Tempatkan proxy di depannya. Dokumentasi GlitchTip meminta proxy atau load balancer yang melakukan buffering request dan menangani Transfer-Encoding terpotong. Dokumentasi tersebut menggunakan nginx sebagai contoh. Tanpa buffering, client yang lambat membuat worker aplikasi tetap terbuka selama seluruh proses upload. Akibatnya, beberapa pengirim yang lambat dapat memenuhi semua worker, sehingga client yang sehat mulai mengalami timeout.

Upgrade adalah bagian yang mudah:

docker compose pull
docker compose stop
docker compose up -d

Migrasi database berjalan otomatis saat start. Namun, tetap buat dump terlebih dahulu karena migrasi otomatis tetap merupakan migrasi.

Bugsink: satu container dan lisensi yang harus Anda baca

Bugsink adalah yang paling ringan dari ketiganya. Bugsink menggunakan protokol Sentry SDK dan berjalan tanpa message queue atau layanan eksternal selain database. SQLite adalah pilihan default. MySQL dan PostgreSQL juga didukung jika kebutuhan Anda berkembang.

Gunakan instance sementara berikut untuk melihat antarmukanya sebelum menentukan pilihan:

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/, lalu masuk menggunakan alamat dan kata sandi yang Anda masukkan di CREATE_SUPERUSER. Container tersebut tidak menyimpan apa pun setelah berhenti. Untuk instance produksi, gunakan contoh compose dari proyek tersebut. Contoh ini memasangkan bugsink/bugsink:2 dengan postgres:17-alpine serta menetapkan DATABASE_URL, BASE_URL, dan BEHIND_HTTPS_PROXY. Buat secret dengan benar:

openssl rand -base64 50

BASE_URL harus sesuai dengan URL yang benar-benar digunakan oleh pengguna dan SDK Anda, termasuk scheme. Jika server diakses melalui https://errors.example.com, jangan biarkan nilainya tetap http://localhost:8000. Jika tetap demikian, setiap tautan dalam email notifikasi akan mengarah ke host yang tidak dapat di-resolve oleh penerima email. Tetapkan BEHIND_HTTPS_PROXY ke true jika nginx atau Caddy melakukan terminasi TLS (transport layer security) di depannya. Jika tidak, Bugsink akan membuat URL http:// di belakang proxy https:// Anda, lalu browser memblokir mixed content.

Vendor menerbitkan angka throughput-nya sendiri: 18 event per detik dengan ukuran masing-masing 50 KB. Angka ini setara dengan 1.5 juta event per hari pada VPS dengan 2 vCPU dan 4 GB. Anggap angka tersebut sebagai gambaran kapasitas alat, bukan jaminan untuk beban kerja Anda. Angka itu menunjukkan bahwa batas kapasitasnya jauh di atas produksi event dari satu aplikasi kecil.

Berikutnya adalah lisensinya. Bagian ini harus dibaca sebelum Bugsink digunakan dalam stack Anda. Bugsink dirilis berdasarkan PolyForm Shield License 1.0.0. Lisensi ini menyediakan source code, tetapi bukan open source. Anda boleh menjalankan dan memodifikasinya, tetapi tidak boleh menggunakannya untuk membuat produk yang bersaing dengan Bugsink. Untuk pelacak error internal, pembatasan ini biasanya tidak menjadi masalah. Jika perusahaan Anda menjual developer tooling, minta seseorang membaca teks lisensinya terlebih dahulu.

Pelacakan error dan observabilitas LLM masih merupakan dua alat

Cari satu alat yang menggabungkan pelacakan error dan observabilitas large language model (LLM), lalu Anda akan menemukan produk yang mengklaim dapat menangani keduanya. Bentuk datanya berbeda. Karena itu, penggabungan keduanya belum juga terwujud. Pelacak error menerima exception beserta stack trace, menghitung fingerprint darinya, lalu menggabungkan ribuan kemunculan menjadi satu issue dengan sebuah counter. Alat pelacakan LLM menerima span yang berisi prompt, respons, jumlah token, dan latensi. Alat tersebut harus menyimpan setiap data itu, karena dua pemanggilan dengan input yang identik tetap merupakan event terpisah yang perlu dibaca.

Jalankan keduanya. Kirim exception ke pelacak error, dan kirim pemanggilan model ke tempat yang memang dirancang untuk menanganinya: Langfuse self-hosted untuk pelacakan agen menangani sisi tersebut, sedangkan observabilitas AI self-hosted menjalankan fungsi yang sama dari sudut yang berbeda. Aplikasi Anda sudah menghasilkan kedua jenis kegagalan tersebut. Pemanggilan model yang mengembalikan informasi keliru dengan penuh keyakinan tidak menghasilkan exception sama sekali. Karena itu, pelacak error tidak akan pernah menampilkannya kepada Anda.

Kegagalan pertumbuhan disk yang baru terasa kemudian

Setiap pelacak error merupakan database dengan aktivitas penulisan tinggi dan input yang tidak terbatas. Aplikasi Anda menentukan jumlah data yang ditulis. Satu bug baru pada jalur kode yang sering dipanggil dapat menghasilkan satu juta event dalam semalam.

GlitchTip menyediakan angka yang perlu dijadikan dasar perencanaan: instance yang menangani satu juta event per bulan mungkin memerlukan 30 GB disk. Angka tersebut mencakup data yang diterima selama satu bulan pada tingkat itu. Periode retensi menentukan jumlah bulan yang disimpan secara bersamaan.

Bugsink menggunakan pendekatan dari sisi yang berlawanan. Alih-alih menerapkan kuota tetap, Bugsink menjalankan algoritme retensi berdasarkan jumlah event dan usia event. Batasnya ditampilkan secara langsung: MAX_RETENTION_EVENT_COUNT untuk seluruh instalasi, MAX_RETENTION_PER_PROJECT_EVENT_COUNT per project, dan MAX_EVENT_AGE_DAYS sebagai batas absolut. Menetapkan anggaran event untuk seluruh instalasi merupakan cara yang tepat untuk menentukan ukuran disk, karena anggaran tersebut secara langsung menentukan kebutuhan disk.

Pantau angka aktual pada server:

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

docker system df -v menampilkan ukuran per volume. Dengan demikian, Anda dapat melihat service mana yang terus bertambah ukurannya. Jika sebuah volume bertambah beberapa gigabyte per minggu tanpa perubahan trafik, biasanya retensi belum pernah dikonfigurasi. Akibatnya, tidak ada data yang dihapus dan satu-satunya batas adalah partisi.

Memori merupakan masalah yang sama dalam bentuk berbeda. Stack tanpa batasan akan mengambil seluruh memori yang disediakan kernel. Saat mesin kehabisan memori, OOM killer memilih proses terbesar. Proses tersebut bisa saja web server Anda, bukan tracker yang menyebabkan masalah. Tetapkan batas atas untuk setiap service: batas memori di Docker Compose menjelaskan sintaks dan perilaku container saat mencapai batasnya. Container yang dihentikan karena mencapai batasnya sendiri merupakan kegagalan yang terisolasi. Container yang dihentikan oleh kernel dapat menyebabkan service lain ikut berhenti.

Stack yang sesuai untuk setiap VPS

• 1 GB, atau 2 GB dengan ruang yang masih cukup: GlitchTip dalam mode all in one dengan Valkey dinonaktifkan, atau Bugsink pada SQLite. Keduanya dapat berjalan dengan baik untuk beberapa aplikasi.
• 4 GB: Bugsink dengan PostgreSQL, atau GlitchTip dengan Valkey aktif dan service worker terpisah. Pada ukuran ini, Anda tidak perlu lagi melakukan tuning dan dapat langsung menjalankannya.
• 8 GB: masih belum mencukupi untuk stack Sentry resmi. Gunakan kapasitas ini untuk memperpanjang periode retensi dan menambah kapasitas disk pada opsi ringan yang Anda pilih.
• Minimum 16 GB, disarankan 32 GB: stack self-hosted Sentry resmi, dan hanya jika Anda memerlukan fitur Sentry yang tidak diimplementasikan oleh proyek yang lebih ringan. Periksa fitur tersebut pada dokumentasi setiap proyek terlebih dahulu karena proyek-proyek yang kompatibel sudah mencakup fitur yang umum digunakan.

Apa pun yang Anda jalankan, error tracker tidak dapat melaporkan kegagalannya sendiri. Pasang pemeriksaan dari mesin lain: Uptime Kuma yang memantau dari mesin lain akan memberi tahu Anda bahwa tracker tidak aktif. Tepat pada saat itu, aplikasi Anda mungkin mulai menghasilkan error yang tidak tercatat oleh siapa pun.

Kapan paket hosting menjadi pilihan yang lebih murah

Self-hosting pelacak error menguntungkan jika peraturan residensi data mengharuskannya, atau jika volume event Anda cukup tinggi sehingga biaya per event menjadi beban. Di luar kondisi tersebut, hitung biayanya secara realistis. Minimum yang didokumentasikan Sentry adalah server dengan 16 GB RAM, 4 core, dan disk cepat. VPS dengan spesifikasi tersebut bukan VPS murah. Selanjutnya, perhitungkan pekerjaan operasional: melewati setiap hard stop secara berurutan dan membuat snapshot sebelum setiap migrasi, beberapa kali dalam setahun.

GlitchTip dan Bugsink mengubah perhitungan tersebut sepenuhnya, karena server dengan RAM 512 MB hingga 4 GB harganya terjangkau dan upgrade-nya merupakan sebuah docker compose pull. Itu sebabnya sebagian besar orang yang menanyakan hal ini akhirnya menggunakan salah satu proyek yang kompatibel, bukan stack resmi. Mereka menginginkan pelacakan error, bukan pipeline data terdistribusi yang harus terus diawasi.

Jika Anda masih menentukan apa yang sebenarnya perlu ditempatkan di server, daftar lebih luas tentang hal-hal yang layak di-self-host menempatkan pelacakan error bersama layanan lain yang menggunakan RAM yang sama.

FAQ

Apakah saya dapat melakukan self-hosting Sentry pada VPS 2 GB?

Tidak. Dokumentasi self-hosted Sentry menetapkan minimum 4 core CPU, 16 GB RAM ditambah 16 GB swap, serta 20 GB ruang disk kosong. Stack ini menjalankan Postgres, ClickHouse, Kafka, Redis, dan beberapa proses worker secara bersamaan. Karena itu, pada server kecil, kernel menghentikan container sebelum instalasi selesai. Konfirmasikan hal ini dengan dmesg -T | grep -i 'out of memory', yang mencetak baris berisi nama proses yang dihentikan. Untuk VPS 2 GB, gunakan GlitchTip, yang mendokumentasikan kebutuhan 512 MB, atau Bugsink, yang berjalan sebagai satu container dengan SQLite.

Apakah saya harus mengubah kode aplikasi untuk beralih dari Sentry ke GlitchTip atau Bugsink?

Tidak. Keduanya menerima event dari SDK open source Sentry. Anda dapat tetap menggunakan SDK yang sudah terpasang dan hanya mengubah satu nilai, yaitu DSN, URL tempat SDK mengirimkan event. Pindahkan DSN ke environment variable jika saat ini masih ditulis langsung dalam kode. Arahkan DSN ke host baru, lalu buat exception uji dan monitor apakah exception tersebut masuk. Jika tidak ada data yang muncul, periksa apakah project identifier dalam DSN sesuai dengan project yang ada di server baru. Pastikan juga firewall mengizinkan aplikasi terhubung ke host dan port tersebut.

Berapa banyak ruang disk yang dibutuhkan untuk error tracking self-hosted?

Kebutuhan tersebut bergantung pada volume event dan periode retensi, bukan pada tool yang digunakan. GlitchTip memublikasikan kebutuhan 30 GB untuk instance yang menangani satu juta event per bulan. Bugsink memungkinkan Anda menetapkan batas penggunaan secara langsung dengan MAX_RETENTION_EVENT_COUNT dan MAX_EVENT_AGE_DAYS. Dengan demikian, Anda dapat menentukan batas maksimum, dan kebutuhan disk mengikuti batas tersebut. Konfigurasikan retensi sejak hari pertama. Tracker tanpa kebijakan retensi akan terus bertambah hingga df -h menunjukkan 100%. Pada saat itu, ingest berhenti dan error yang paling ingin Anda lihat akan hilang.

Mengapa upgrade self-hosted Sentry terus gagal?

Karena proses upgrade melewati hard stop yang wajib dilalui. Sentry self-hosted menetapkan versi tertentu yang membawa migrasi database dan harus dilewati secara berurutan. Per Agustus 2026, versi tersebut adalah 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. Jika langsung berpindah dari release lama ke release terbaru, migrasi tersebut terlewati. Akibatnya, schema dan kode tidak sesuai, sehingga proses upgrade berhenti di tengah jalan. Checkout setiap hard stop secara berurutan dan jalankan ./install.sh pada setiap versi. Buat snapshot server sebelum memulai. Baca daftar release yang harus dihindari dalam dokumentasi, termasuk 23.7.0, 25.9.0, dan 25.12.0.