Self-hosted Sentry کے متبادل: RAM اور لاگت کا موازنہ

ایک event محفوظ کرنے سے پہلے self-hosted error tracking کی لاگت

self-hosted error tracking میں ایک عدد پورے انتخاب کا فیصلہ کرتا ہے، اور وہ RAM کی کم از کم ضرورت ہے۔ Sentry کی اپنی self-hosted دستاویزات کے مطابق، آپ کی application کی طرف سے ایک بھی event بھیجے جانے سے پہلے 4 CPU cores، 16 GB RAM، 16 GB swap اور 20 GB خالی disk درکار ہوتی ہے۔ GlitchTip کے لیے 512 MB درج ہے۔ یہاں موجود تمام options ایک ہی Sentry SDKs سے events وصول کرتے ہیں، اس لیے یہ فیصلہ اس بات سے متعلق نہیں کہ آپ اپنے code کی instrumentation کیسے کرتے ہیں۔ فیصلہ اس بات پر ہے کہ آپ کتنے بڑے server کے اخراجات برداشت کر سکتے ہیں اور اسے مسلسل چلتا رکھ سکتے ہیں۔

شائع کردہ وسائل کے اعداد و شمار، بالمقابل

یہ وہ اعداد ہیں جو ہر project نے August 2026 تک اپنے بارے میں شائع کیے ہیں۔ یہ ایک ہی قسم کی پیمائش نہیں ہیں، اس لیے موازنہ کرنے سے پہلے ہر row کے ساتھ موجود نوٹ پڑھیں۔

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

Sentry کا 16 GB ایک documented minimum ہے، جبکہ اسی page پر 32 GB کی recommendation دی گئی ہے۔ GlitchTip کا 0.5 GB ایک recommendation ہے، اور project کے مطابق 256 MB ایک working minimum ہے؛ محتاط configuration کے ساتھ 128 MB اور swap بھی استعمال کیا جا سکتا ہے۔ Bugsink کا 4 GB ان دونوں میں سے کوئی نہیں ہے: یہ وہ box ہے جسے vendor نے اپنے throughput benchmark کے لیے استعمال کیا تھا۔ شائع کردہ figure صرف نقطۂ آغاز ہوتا ہے، آپ کے event volume کے بارے میں guarantee نہیں۔

Sentry self-hosted: مکمل product اور مکمل bill

Official stack getsentry/self-hosted ہے۔ یہ Docker Compose project ہے جو وہی components چلاتا ہے جنہیں Sentry production میں چلاتا ہے۔ اس کی documentation اسے "feature-complete and packaged up for low-volume deployments and proofs-of-concept" بیان کرتی ہے۔ یہی اس کا دیانت دار خلاصہ ہے۔ آپ کو ہر feature ملتا ہے، اور ان features کو چلانے والے تمام components بھی ملتے ہیں۔

master سے install کرنے کے بجائے tagged release سے install کریں:

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

پھر اسے start کریں:

docker compose up --wait

Sentry default طور پر http://127.0.0.1:9000 پر listen کرتا ہے۔ Docker Engine 19.03.6 یا اس کے بعد کا ورژن اور Docker Compose 2.32.2 یا اس کے بعد کا ورژن درکار ہے۔ پرانا Compose Sentry کی کسی خرابی کے بجائے file syntax کی وجہ سے fail ہوتا ہے۔

دیکھیں کہ آپ نے حقیقت میں کیا start کیا ہے:

docker compose ps
free -h

docker compose ps stack کی ہر service دکھاتا ہے، اور فہرست طویل ہے: Postgres، ClickHouse، Kafka، Redis، Relay، Snuba، Symbolicator، اور کئی worker اور cron processes۔ انہیں ایک بار گن لیں، کیونکہ یہی تعداد آپ کا maintenance load ہے۔ ہر entry ایک ایسا process ہے جو crash ہو سکتا ہے، disk بھر سکتا ہے، یا migration fail کر سکتا ہے۔

اگر کوئی service Restarting state میں ہو تو سب سے پہلے memory دیکھیں:

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

Out of memory: Killed process 3412 (java) جیسی line کا مطلب ہے کہ kernel کے OOM killer (out of memory killer) نے container کو ختم کر دیا، کیونکہ machine میں RAM ختم ہو گئی تھی۔ اس لیے وہ service کبھی healthy نہیں ہوتی اور stack کا startup مکمل نہیں ہوتا۔ اس کا عام سبب documented minimum سے کم resources کے ساتھ مکمل stack چلانا ہے۔ Documentation disk speed کے بارے میں بھی خبردار کرتی ہے: iowait کا 10% سے زیادہ ہونا اس بات کی علامت ہے کہ machine ingest pipeline کی رفتار برقرار نہیں رکھ سکتی۔ اسے top کے wa column سے دیکھیں، یا iostat -x 5 سے دیکھیں، اگر sysstat installed ہو۔

Upgrades وہ حصہ ہیں جسے لوگ کم سمجھتے ہیں

Sentry self-hosted ہر ماہ CalVer کے تحت release ہوتا ہے۔ CalVer calendar-based version scheme ہے، جس میں بنیادی release ہر ماہ کی 15 تاریخ کو آتی ہے۔ آپ پرانے version سے براہ راست latest version پر jump نہیں کر سکتے۔ Project hard stop versions مقرر کرتا ہے، اور database migrations حاصل کرنے کے لیے آپ کو ہر version کو ترتیب سے checkout کرنا ہوگا۔ August 2026 تک published hard stops یہ ہیں: 9.1.2، 21.5.0، 21.6.3، 23.6.2، 23.11.0، 24.8.0، 25.5.1، 26.5.0 اور 26.7.0۔ Documentation ان releases کو بھی skip کرنے کا کہتی ہے جن میں migration problems ہیں، جن میں 23.7.0، 25.9.0، 25.12.0 اور 26.3.0 سے 26.4.0 تک کی range شامل ہے۔

Upgrade میں checkout کے بعد installer دوبارہ چلانا شامل ہے:

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

شروع کرنے سے پہلے server کا snapshot لیں، کیونکہ بڑے ClickHouse dataset پر migration کئی گھنٹے چل سکتی ہے۔ درمیان میں failure ہونے سے database دو schemas کے درمیان حالت میں رہ سکتا ہے۔ زیادہ تر failed self-hosted Sentry upgrades کی سادہ وجہ یہ ہوتی ہے: machine ایک سال تک ایک ہی version پر رہی، اس لیے jump نے بیک وقت کئی hard stops عبور کیے، اور skip کی گئی migrations میں سے ایک اہم migration تھی۔

Commit کرنے سے پہلے ایک اور بات جان لیں۔ Sentry self-hosted Functional Source License (FSL) کے تحت ہے، جسے Sentry نے خود متعارف کرایا تھا۔ یہ fair source ہے، OSI-approved open source نہیں۔ آپ اسے اپنے لیے چلا سکتے ہیں، لیکن اسے competing service کے طور پر فروخت نہیں کر سکتے۔ ہر release کے ship ہونے کے 2 سال بعد وہ Apache 2.0 میں تبدیل ہو جاتی ہے۔

GlitchTip: 512 MB کا جواب

GlitchTip MIT لائسنس کے تحت دستیاب ہے اور Sentry کے open source SDKs سے events وصول کرتا ہے۔ اس لیے instrumented application کو منتقل کرنے کے لیے صرف ایک value، یعنی DSN (data source name؛ وہ URL جس پر آپ کا SDK events بھیجتا ہے)، تبدیل کرنا ہوتا ہے۔ اسے PostgreSQL 14 یا اس کے بعد کا ورژن درکار ہے۔ Valkey یا Redis 7 یا اس کے بعد کا ورژن اختیاری ہے، اور بڑے instances کو زیادہ تیز بناتا ہے۔

تنصیب کے لیے Docker اور ایک compose file کافی ہیں:

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

کچھ بھی شروع کرنے سے پہلے environment section میں ترمیم کریں۔ آپ کو secret، domain اور mail path کی values مقرر کرنا ضروری ہے:

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

نمونے میں DATABASE_URL پہلے ہی اس کی اپنی postgres service سے منسلک ہے، اس لیے اس line کو اسی وقت تبدیل کریں جب آپ کسی دوسری جگہ چلنے والے database سے منسلک ہونا چاہتے ہوں۔ GLITCHTIP_DOMAIN میں scheme شامل ہونی چاہیے۔ شروع میں https:// نہ ہونے کی صورت میں alert emails کے links غلط بنتے ہیں اور ایسے URL پر پہنچتے ہیں جہاں کوئی response نہیں ملتا۔

اسے شروع کریں اور پہلے boot کی نگرانی کریں:

docker compose up -d
docker compose logs -f web

August 2026 تک نمونے میں image tags postgres:18، valkey/valkey:9 اور glitchtip/glitchtip:6 ہیں۔ انہیں pinned رکھیں۔ جس compose file میں latest لکھا ہو، وہ اگلے docker compose pull پر آپ کے database engine کو upgrade کر دے گی۔ چلتے ہوئے instance کے تحت Postgres major version upgrade کرنے سے working error tracker کا start ہونا بند ہو سکتا ہے۔

256 MB سے 512 MB تک کی memory range حاصل کرنے کے لیے sample file کے comments بتاتے ہیں کہ کن features کو بند کرنا ہے۔ ابتدا Valkey، optional log اور uptime features سے کریں۔ Valkey کے بغیر GlitchTip cache اور queue کے کاموں کے لیے database استعمال کرتا ہے۔ یہ طریقہ سست ہے، لیکن درست رہتا ہے۔ All in one mode میں worker کو web process کے اندر چلایا جاتا ہے۔ اس طرح آپ کو دو کے بجائے ایک application container maintain کرنا پڑتا ہے۔

اس کے سامنے proxy رکھیں۔ GlitchTip کی documentation ایسی proxy یا load balancer کا تقاضا کرتی ہے جو requests کو buffer کرے اور chunked Transfer-Encoding کو handle کرے۔ اس میں nginx کو worked example کے طور پر استعمال کیا گیا ہے۔ Buffering کے بغیر slow client پوری upload کے دوران application worker کو مصروف رکھتا ہے۔ اس طرح چند slow senders آپ کے تمام workers استعمال کر سکتے ہیں، اور صحت مند clients کے requests timeout ہونا شروع ہو جاتے ہیں۔

Upgrades آسان حصہ ہیں:

docker compose pull
docker compose stop
docker compose up -d

Database migrations start کے وقت خودکار طور پر چلتی ہیں۔ اس کے باوجود پہلے dump ضرور لیں، کیونکہ automatic migration بھی migration ہی ہوتی ہے۔

Bugsink: ایک container، اور ایک licence جسے آپ کو پڑھنا چاہیے

Bugsink ان تینوں میں سب سے ہلکا ہے۔ یہ Sentry SDK protocol استعمال کرتا ہے، اور اس کے لیے message queue یا database کے علاوہ کسی external service کی ضرورت نہیں ہوتی۔ SQLite default ہے، جبکہ workload بڑھنے پر MySQL اور PostgreSQL بھی supported ہیں۔

صرف interface دیکھنے کے لیے ایک عارضی instance چلائیں، اس سے پہلے کہ آپ اسے مستقل طور پر استعمال کرنے کا فیصلہ کریں:

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

http://localhost:8000/ کھولیں اور CREATE_SUPERUSER میں فراہم کیے گئے address اور password سے sign in کریں۔ یہ container رکنے کے بعد کوئی data محفوظ نہیں رکھتا۔ حقیقی instance کے لیے project کا compose sample استعمال کریں، جو bugsink/bugsink:2 کو postgres:17-alpine کے ساتھ جوڑتا ہے اور DATABASE_URL، BASE_URL اور BEHIND_HTTPS_PROXY مقرر کرتا ہے۔ secret درست طریقے سے generate کریں:

openssl rand -base64 50

BASE_URL کو اس URL سے مطابقت رکھنی چاہیے جسے آپ کے users اور SDKs حقیقت میں استعمال کرتے ہیں، scheme سمیت۔ اگر آپ کسی ایسے box تک https://errors.example.com کے ذریعے پہنچتے ہیں تو اسے http://localhost:8000 پر چھوڑنے سے notification email کا ہر link ایسے host کی طرف جائے گا جو اسے پڑھنے والے شخص کے لیے resolve نہیں ہوتا۔ جب nginx یا Caddy اس کے سامنے TLS (transport layer security) terminate کرے تو BEHIND_HTTPS_PROXY کو true پر set کریں، کیونکہ بصورت دیگر Bugsink آپ کے https:// proxy کے پیچھے http:// URLs بناتا ہے اور browsers mixed content کو block کر دیتے ہیں۔

Vendor اپنی throughput figures شائع کرتا ہے: 50 KB کے ہر event کے لیے 18 events فی second، جو 2 vCPU اور 4 GB VPS پر روزانہ 1.5 million events بنتے ہیں۔ اسے آپ کے workload کی ضمانت کے بجائے tool کی عمومی capacity سمجھیں۔ اس سے یہ ضرور واضح ہوتا ہے کہ اس کی حد ایک چھوٹی application کی پیداوار سے کافی زیادہ ہے۔

اب licence کی بات، اور یہ وہ حصہ ہے جسے اپنی stack میں شامل کرنے سے پہلے پڑھنا چاہیے۔ Bugsink کو PolyForm Shield License 1.0.0 کے تحت release کیا گیا ہے۔ یہ source available ہے، open source نہیں: آپ اسے چلا اور modify کر سکتے ہیں، لیکن اسے Bugsink کے ساتھ competing کوئی چیز بنانے کے لیے استعمال نہیں کر سکتے۔ Internal error tracker کے لیے یہ پابندی عموماً مسئلہ نہیں بنتی۔ اگر آپ کی company developer tooling فروخت کرتی ہے تو پہلے کسی ماہر سے licence text پڑھوائیں۔

خرابیوں کی tracking اور LLM observability اب بھی دو الگ tools ہیں

ایسا ایک tool تلاش کریں جو error tracking اور large language model (LLM) observability دونوں انجام دے، تو آپ کو ایسے products ملیں گے جو دونوں کا دعویٰ کرتے ہیں۔ ان دونوں کے data shapes مختلف ہیں، اسی لیے یہ انضمام اب تک درست طور پر نہیں ہو سکا۔ ایک error tracker stack trace کے ساتھ exception وصول کرتا ہے، اس سے fingerprint بناتا ہے، اور ہزاروں occurrences کو ایک issue میں شمار کے ساتھ سمیٹ دیتا ہے۔ LLM tracing tool ایک span وصول کرتا ہے جس میں prompt، response، token count اور latency شامل ہوتے ہیں۔ اسے ان سب کو برقرار رکھنا پڑتا ہے، کیونکہ یکساں inputs کے ساتھ کی جانے والی دو calls بھی الگ events ہوتی ہیں جنہیں پڑھنا ضروری ہو سکتا ہے۔

اس لیے دونوں tools چلائیں۔ Exceptions کو error tracker کو بھیجیں، اور model calls کو ایسے system میں بھیجیں جو ان کے لیے بنایا گیا ہو: agents کی tracing کے لیے self-hosted Langfuse اس پہلو کا احاطہ کرتا ہے، جبکہ self-hosted AI observability ایک مختلف زاویے سے یہی کام انجام دیتی ہے۔ آپ کی application پہلے ہی دونوں قسم کی failures پیدا کرتی ہے۔ ایسا model call جو پورے اعتماد کے ساتھ بے معنی جواب دے، کوئی exception نہیں پھینکتا؛ اس لیے error tracker اسے کبھی آپ کے سامنے نہیں لائے گا۔

ڈسک کا بڑھنا وہ خرابی ہے جس کا سامنا بعد میں ہوتا ہے

ہر error tracker ایسی database استعمال کرتا ہے جس میں لکھنے کا عمل زیادہ ہوتا ہے اور input کی کوئی مقررہ حد نہیں ہوتی۔ آپ کی application طے کرتی ہے کہ وہ کتنا data لکھے گی، اور کسی اہم code path میں ایک نیا bug ایک ہی رات میں دس لاکھ events پیدا کر سکتا ہے۔

GlitchTip ایک ایسا عدد شائع کرتا ہے جسے planning میں بنیاد بنانا چاہیے: ہر ماہ دس لاکھ events handle کرنے والی instance کو 30 GB ڈسک درکار ہو سکتی ہے۔ یہ اس شرح پر ایک ماہ کے ingest کے لیے کافی ہے، جبکہ retention window طے کرتی ہے کہ آپ بیک وقت کتنے ماہ کا data محفوظ رکھیں گے۔

Bugsink اس مسئلے کو دوسری سمت سے حل کرتا ہے۔ یہ مقررہ quota کے بجائے event count اور event age پر retention algorithm لاگو کرتا ہے، اور limits براہ راست ظاہر کرتا ہے: مکمل installation کے لیے MAX_RETENTION_EVENT_COUNT، ہر project کے لیے MAX_RETENTION_PER_PROJECT_EVENT_COUNT، اور absolute cut-off کے طور پر MAX_EVENT_AGE_DAYS۔ installation-wide event budget مقرر کرنا ڈسک کا درست حجم طے کرنے کا دیانت دار طریقہ ہے، کیونکہ یہی budget دراصل ڈسک کی ضرورت طے کرتا ہے۔

مشین پر اصل اعداد و شمار دیکھیں:

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

docker system df -v ہر volume کا حجم دکھاتا ہے، اس لیے آپ دیکھ سکتے ہیں کہ کون سی service بڑھ رہی ہے۔ اگر traffic میں تبدیلی کے بغیر کوئی volume ہر ہفتے کئی gigabytes بڑھ رہا ہو تو عموماً اس کا مطلب ہے کہ retention کبھی configure نہیں کی گئی۔ اس صورت میں کچھ بھی delete نہیں ہوتا اور واحد حد partition ہوتی ہے۔

Memory بھی یہی مسئلہ ہے، صرف شکل مختلف ہے۔ Limits کے بغیر stack kernel کی فراہم کردہ تمام memory استعمال کرے گا۔ جب مشین کی memory ختم ہو جائے تو OOM killer سب سے بڑے process کو ختم کرتا ہے، اور یہ process اس tracker کے بجائے آپ کا web server بھی ہو سکتا ہے جس نے مسئلہ پیدا کیا تھا۔ ہر service کے لیے ایک maximum limit مقرر کریں: Docker Compose میں memory limits میں syntax اور container کے اپنی limit تک پہنچنے پر اس کے رویے کی وضاحت ہے۔ اپنی limit کی وجہ سے ختم ہونے والا container محدود failure ہوتا ہے۔ Kernel کے ہاتھوں ختم ہونے والا container اپنے ساتھ کسی پڑوسی container کو بھی گرا سکتا ہے۔

کون سا stack کس VPS کے لیے موزوں ہے

• 1 GB، یا 2 GB جس میں اضافی گنجائش ہو: GlitchTip کو all in one mode میں چلائیں اور Valkey بند رکھیں، یا Bugsink کو SQLite پر چلائیں۔ چند ایپلی کیشنز کے لیے دونوں اس وسائل میں آسانی سے کام کرتے ہیں۔
• 4 GB: Bugsink کو PostgreSQL کے ساتھ چلائیں، یا GlitchTip میں Valkey فعال کرکے الگ worker service استعمال کریں۔ اس سائز پر بار بار tuning کرنے کے بجائے سروس چلا دینا کافی ہوتا ہے۔
• 8 GB: یہ اب بھی official Sentry stack کے لیے کم ہے۔ آپ کے منتخب کردہ light option کے لیے اس وسائل کو زیادہ طویل retention window اور بڑی disk پر خرچ کریں۔
• کم از کم 16 GB، اور 32 GB تجویز کردہ: official Sentry self-hosted stack کے لیے، اور صرف اس وقت جب آپ کو Sentry کی ایسی feature درکار ہو جسے ہلکے projects implement نہیں کرتے۔ پہلے اس مخصوص feature کو ہر project کی documentation کے ساتھ verify کریں، کیونکہ compatible projects عام ضروریات پوری کرتے ہیں۔

آپ کچھ بھی چلائیں، error tracker اپنی خرابی کی اطلاع خود نہیں دے سکتا۔ اسے کسی دوسری machine سے monitor کریں: Uptime Kuma کی نگرانی کسی دوسرے box سے آپ کو بتائے گا کہ tracker بند ہے۔ عین اسی وقت آپ کی application ایسے errors پیدا کرنا شروع کرتی ہے جنہیں کوئی record نہیں کر رہا ہوتا۔

جب hosted plan کم لاگت والا انتخاب ہو

Self-hosting error tracker اس وقت فائدہ مند ہوتا ہے جب data residency کے قواعد اسے لازم بناتے ہوں، یا آپ کا event volume اتنا زیادہ ہو کہ فی event pricing مہنگی پڑے۔ ان حالات کے علاوہ حساب ایمانداری سے کریں۔ Sentry کی دستاویزی minimum requirement 16 GB RAM، 4 cores اور fast disk والا server ہے، اور اس حجم کا VPS سستا نہیں ہوتا۔ پھر operational work بھی شامل کریں: ہر hard stop کو ترتیب سے عبور کرنا، اور سال میں چند بار ہر migration سے پہلے snapshot لینا۔

GlitchTip اور Bugsink یہ حساب مکمل طور پر بدل دیتے ہیں، کیونکہ 512 MB سے 4 GB تک کا server کم لاگت والا ہوتا ہے اور upgrade ایک docker compose pull ہے۔ اسی لیے اس سوال کا جواب تلاش کرنے والے زیادہ تر لوگ official stack کے بجائے compatible projects میں سے کسی ایک کا انتخاب کرتے ہیں۔ انہیں error tracking چاہیے تھی، نہ کہ ایسا distributed data pipeline جس کی مسلسل نگرانی کرنی پڑے۔

اگر آپ اب بھی یہ طے کر رہے ہیں کہ server پر آخر کیا چلنا چاہیے، تو self-hosting کے قابل خدمات کی وسیع فہرست error tracking کو ان دوسری services کے ساتھ رکھتی ہے جو اسی RAM کے لیے مقابلہ کر رہی ہیں۔

FAQ

کیا میں 2 GB VPS پر Sentry کو self-host کر سکتا ہوں؟

نہیں۔ Sentry کی self-hosted دستاویزات کے مطابق کم از کم 4 CPU cores، 16 GB RAM کے ساتھ 16 GB swap، اور 20 GB خالی disk درکار ہے۔ یہ stack بیک وقت Postgres، ClickHouse، Kafka، Redis اور کئی worker processes چلاتا ہے، اس لیے کم وسائل والے server پر install مکمل ہونے سے پہلے kernel containers کو ختم کر دیتا ہے۔ dmesg -T | grep -i 'out of memory' سے اس کی تصدیق کریں؛ یہ ایسی line دکھاتا ہے جس میں ختم کیے گئے process کا نام ہوتا ہے۔ 2 GB VPS کے لیے GlitchTip استعمال کریں، جس کی دستاویزات میں 512 MB درج ہے، یا Bugsink استعمال کریں، جو SQLite پر single container کے طور پر چلتا ہے۔

کیا Sentry سے GlitchTip یا Bugsink پر منتقل ہونے کے لیے مجھے application code تبدیل کرنا ہوگا؟

نہیں۔ دونوں Sentry کے open source SDKs سے events وصول کرتے ہیں، اس لیے پہلے سے installed SDK برقرار رکھیں اور صرف ایک value تبدیل کریں: DSN، یعنی وہ URL جہاں SDK events بھیجتا ہے۔ اگر DSN اب بھی code میں hardcoded ہے تو اسے environment variable میں منتقل کریں، اسے نئے host کی طرف point کریں، پھر test exception پیدا کریں اور monitor کریں کہ وہ موصول ہوتی ہے یا نہیں۔ اگر کچھ ظاہر نہ ہو تو تصدیق کریں کہ DSN میں project identifier نئے server پر موجود project سے match کرتا ہے، اور firewall application کو اس host اور port تک پہنچنے کی اجازت دیتا ہے۔

self-hosted error tracking کے لیے کتنی disk درکار ہوتی ہے؟

اس کا انحصار tool کے بجائے آپ کے event volume اور retention window پر ہوتا ہے۔ GlitchTip ایک ماہ میں 1 million events handle کرنے والے instance کے لیے 30 GB بتاتا ہے۔ Bugsink آپ کو MAX_RETENTION_EVENT_COUNT اور MAX_EVENT_AGE_DAYS کے ذریعے budget براہ راست مقرر کرنے دیتا ہے، اس لیے ceiling آپ طے کرتے ہیں اور disk requirement اسی کے مطابق بنتی ہے۔ پہلے دن ہی retention configure کریں۔ جس tracker کی retention policy نہ ہو، وہ اس وقت تک بڑھتا رہتا ہے جب تک df -h 100% نہ دکھائے؛ اس کے بعد ingest رک جاتا ہے اور وہ errors ضائع ہو جاتے ہیں جنہیں آپ سب سے زیادہ دیکھنا چاہتے تھے۔

self-hosted Sentry کو upgrade کرنا بار بار کیوں ناکام ہوتا ہے؟

کیونکہ upgrade کے دوران ایک ضروری hard stop چھوڑ دیا گیا۔ Sentry self-hosted میں مخصوص versions database migrations شامل کرتے ہیں، اور ان versions سے گزرنا ضروری ہے۔ August 2026 تک یہ versions 9.1.2، 21.5.0، 21.6.3، 23.6.2، 23.11.0، 24.8.0، 25.5.1، 26.5.0 اور 26.7.0 ہیں۔ پرانے release سے براہ راست جدید ترین release پر جانے سے یہ migrations skip ہو جاتی ہیں، اس لیے schema اور code میں مطابقت نہیں رہتی اور upgrade درمیان میں رک جاتا ہے۔ ہر hard stop کو ترتیب سے checkout کریں اور ہر version پر ./install.sh چلائیں۔ شروع کرنے سے پہلے server کا snapshot بنائیں، اور جن releases سے بچنا ہے ان کی documented list پڑھیں؛ اس میں 23.7.0، 25.9.0 اور 25.12.0 شامل ہیں۔