بهترین جایگزین‌های Sentry برای میزبانی شخصی

هزینهٔ میزبانی شخصی ابزار ردیابی خطا پیش از ذخیرهٔ اولین رویداد

در ابزار ردیابی خطای self-hosted، یک عدد وجود دارد که کل تصمیم‌گیری را تعیین می‌کند و آن حداقل میزان RAM مورد نیاز است. مستندات رسمی Sentry برای نسخهٔ self-hosted، پیش از آنکه برنامهٔ شما حتی یک رویداد ارسال کند، به 4 هسته CPU، مقدار 16 GB رم به همراه 16 GB فضای swap و 20 GB فضای دیسک خالی نیاز دارد. در مقابل، GlitchTip به 512 MB رم بسنده می‌کند. تمام گزینه‌های موجود در اینجا رویدادها را از طریق SDKهای مشابه Sentry دریافت می‌کنند، بنابراین این تصمیم به نحوهٔ پیاده‌سازی کد شما مربوط نمی‌شود؛ بلکه تصمیمی است دربارهٔ اینکه برای چه ابعاد سروری مایل به پرداخت هزینه و نگهداری آن هستید.

ارقام منابع منتشرشده، در کنار هم

این‌ها اعدادی هستند که هر پروژه تا اوت 2026 دربارهٔ خود منتشر کرده است. این ارقام از یک نوع اندازه‌گیری یکسان نیستند، بنابراین پیش از مقایسه، یادداشت مربوط به هر ردیف را مطالعه کنید.

[
  {
    "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 برای Sentry یک حداقلِ مستندشده است و همان صفحه، 32 GB را توصیه می‌کند. مقدار 0.5 GB برای GlitchTip یک توصیه است و این پروژه 256 MB را به‌عنوان حداقلِ عملیاتی، یا 128 MB به‌همراه swap با پیکربندی دقیق اعلام کرده است. مقدار 4 GB برای Bugsink هیچ‌کدام از این‌ها نیست: این عددی است که فروشنده برای بنچمارک توان عملیاتی خود استفاده کرده است. رقم منتشرشده یک نقطهٔ شروع است، نه تضمینی برای حجم رویدادهای شما.

Sentry self-hosted: کل محصول و تمام هزینه‌های آن

پشتهٔ رسمی، getsentry/self-hosted است؛ یک پروژه Docker Compose که دقیقاً همان مؤلفه‌هایی را اجرا می‌کند که Sentry در محیط عملیاتی (production) استفاده می‌کند. مستندات خودِ پروژه، آن را «دارای تمامی قابلیت‌ها و بسته‌بندی‌شده برای استقرار با حجم پایین و اثبات مفهوم (PoC)» توصیف می‌کند. این جمله، خلاصه‌ای صادقانه است. شما تمام قابلیت‌ها و تمام قطعات متحرکی که باعث کارکرد این قابلیت‌ها می‌شوند را دریافت می‌کنید.

نصب را از یک نسخه تگ‌شده (tagged release) انجام دهید، نه از 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

سپس آن را اجرا کنید:

docker compose up --wait

Sentry به‌صورت پیش‌فرض روی http://127.0.0.1:9000 گوش می‌دهد. Docker Engine نسخه 19.03.6 یا بالاتر و Docker Compose نسخه 2.32.2 یا بالاتر مورد نیاز است؛ نسخه‌های قدیمی‌تر Compose به دلیل سینتکس فایل دچار خطا می‌شوند، نه به دلیل عملکرد Sentry.

ببینید دقیقاً چه چیزی را اجرا کرده‌اید:

docker compose ps
free -h

docker compose ps تمام سرویس‌های موجود در پشته را فهرست می‌کند و این فهرست طولانی است: Postgres، ClickHouse، Kafka، Redis، Relay، Snuba، Symbolicator و چندین پردازش worker و cron. آن‌ها را یک‌بار بشمارید، زیرا این تعداد، بار نگهداری شماست. هر ورودی، پردازشی است که می‌تواند کرش کند، دیسک را پر کند یا در مهاجرت (migration) شکست بخورد.

اگر سرویسی در وضعیت Restarting باقی می‌ماند، پیش از هر چیز حافظه (RAM) را بررسی کنید:

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

خطی مانند Out of memory: Killed process 3412 (java) به این معنی است که OOM killer (قاتل کمبود حافظه) هسته، یک کانتینر را از بین برده است، زیرا سرور با کمبود RAM مواجه شده؛ بنابراین آن سرویس هرگز سالم (healthy) نمی‌شود و پشته هرگز راه‌اندازی‌اش را به پایان نمی‌رساند. این نتیجهٔ معمولِ اجرای پشتهٔ کامل زیر حداقل‌های مستندشده است. مستندات همچنین سرعت دیسک را گوشزد می‌کنند: iowait بالای 10 درصد به این معنی است که ماشین نمی‌تواند همگام با خط لولهٔ دریافت داده (ingest pipeline) پیش برود. آن را از ستون wa در top، یا اگر sysstat را نصب دارید، از iostat -x 5 بخوانید.

ارتقاها بخشی هستند که افراد دست‌کم می‌گیرند

Sentry self-hosted به‌صورت ماهانه تحت CalVer (طرح نسخه‌گذاری مبتنی بر تقویم) منتشر می‌شود و نسخه اصلی در پانزدهم هر ماه عرضه می‌گردد. شما نمی‌توانید مستقیماً از یک نسخه قدیمی به آخرین نسخه بپرید. پروژه، نسخه‌های توقف اجباری (hard stop) را تعیین کرده است و شما باید برای اعمال مهاجرت‌های دیتابیس، تک‌تک آن‌ها را به ترتیب بررسی و نصب کنید. تا اوت 2026، نسخه‌های توقف اجباری اعلام‌شده عبارتند از: 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. مستندات همچنین نسخه‌هایی را که باید به دلیل مشکلات مهاجرت نادیده گرفته شوند فهرست کرده‌اند، از جمله 23.7.0، 25.9.0، 25.12.0 و بازه 26.3.0 تا 26.4.0.

یک ارتقا شامل checkout کردن نسخه و اجرای مجدد نصب‌کننده است:

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

پیش از شروع، از سرور اسنپ‌شات بگیرید، زیرا مهاجرت روی یک مجموعه داده بزرگ ClickHouse ممکن است ساعت‌ها طول بکشد و شکست در میانه راه، دیتابیس را در وضعیتی بین دو طرح (schema) رها می‌کند. دلیل اصلی اکثر شکست‌های ارتقای Sentry self-hosted این است: سرور یک سال روی یک نسخه باقی مانده، بنابراین جهش از چندین نقطه توقف اجباری به‌طور همزمان صورت می‌گیرد و یکی از مهاجرت‌های نادیده گرفته شده، همان مهاجرت حیاتی بوده است.

یک نکته دیگر که باید پیش از تعهد بدانید: Sentry self-hosted تحت مجوز Functional Source License (FSL) قرار دارد که خودِ Sentry آن را معرفی کرده است. این مجوز «منبع منصفانه» (fair source) است و نه «متن‌باز» (open source) مورد تأیید OSI: شما می‌توانید آن را برای خودتان اجرا کنید، اما نمی‌توانید آن را به عنوان یک سرویس رقیب بفروشید. هر نسخه دو سال پس از انتشار، به Apache 2.0 تبدیل می‌شود.

GlitchTip: پاسخ 512 مگابایتی

نرم‌افزار GlitchTip دارای مجوز MIT است و رویدادها را از SDKهای متن‌باز Sentry دریافت می‌کند. بنابراین، انتقال یک برنامهٔ مجهز به ابزارهای مانیتورینگ تنها با تغییر یک مقدار انجام می‌شود: DSN (نام منبع داده، همان URL که SDK شما رویدادها را به آن ارسال می‌کند). این برنامه به PostgreSQL نسخه 14 یا بالاتر نیاز دارد. استفاده از Valkey یا Redis نسخه 7 یا بالاتر اختیاری است و باعث افزایش سرعت در نمونه‌های بزرگ‌تر می‌شود.

نصب آن شامل Docker و یک فایل compose است:

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

پیش از شروع هر کاری، بخش environment را ویرایش کنید. مقادیری که باید تنظیم کنید عبارتند از secret، دامنه و مسیر ایمیل:

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 خود متصل کرده است؛ بنابراین اگر از دیتابیسی که در جای دیگری اجرا می‌کنید استفاده نمی‌کنید، این خط را تغییر ندهید. GLITCHTIP_DOMAIN باید شامل طرح (scheme) باشد. بدون وجود https:// در ابتدای آن، لینک‌های موجود در ایمیل‌های هشدار به‌درستی ساخته نمی‌شوند و به URLای هدایت می‌شوند که پاسخی نمی‌دهد.

آن را اجرا کنید و اولین بوت را زیر نظر بگیرید:

docker compose up -d
docker compose logs -f web

تگ‌های image در نمونهٔ موجود تا اوت 2026 عبارتند از postgres:18، valkey/valkey:9 و glitchtip/glitchtip:6. آن‌ها را ثابت نگه دارید. فایل composeای که از latest استفاده می‌کند، موتور دیتابیس شما را در docker compose pull بعدی ارتقا می‌دهد و جهش نسخهٔ اصلی Postgres در یک نمونهٔ در حال اجرا، باعث توقف فعالیت ردیاب خطا می‌شود.

برای رسیدن به محدوده 256 تا 512 مگابایت، توضیحات داخل فایل نمونه به شما می‌گوید چه مواردی را غیرفعال کنید؛ از Valkey و ویژگی‌های اختیاری log و uptime شروع کنید. اجرای برنامه بدون Valkey به این معنی است که GlitchTip از دیتابیس خود برای کارهای مربوط به cache و queue استفاده می‌کند که کندتر است اما همچنان درست عمل می‌کند. حالت all in one، پردازشگر (worker) را درون فرآیند وب اجرا می‌کند، بنابراین به‌جای دو کانتینر، تنها یک کانتینر برنامه را مدیریت می‌کنید.

یک پروکسی در مقابل آن قرار دهید. مستندات GlitchTip استفاده از یک پروکسی یا load balancer را توصیه می‌کند که درخواست‌ها را بافر کرده و Transfer-Encoding تکه‌تکه (chunked) را مدیریت کند؛ این مستندات nginx را به‌عنوان نمونهٔ عملی پیشنهاد می‌دهند. بدون بافرینگ، یک کلاینت کند، worker برنامه را برای کل مدت آپلود اشغال می‌کند؛ بنابراین چند فرستندهٔ کند می‌توانند تمام workerهای شما را اشغال کنند و کلاینت‌های سالم با خطای timeout مواجه شوند.

ارتقاها بخش سادهٔ کار هستند:

docker compose pull
docker compose stop
docker compose up -d

مهاجرت‌های دیتابیس به‌صورت خودکار در هنگام شروع اجرا می‌شوند. با این حال، ابتدا یک dump تهیه کنید، زیرا مهاجرت خودکار همچنان یک عملیات مهاجرت محسوب می‌شود.

Bugsink: یک کانتینر و مجوزی که باید بخوانید

Bugsink سبک‌ترین گزینه در میان این سه ابزار است. این ابزار از پروتکل Sentry SDK پشتیبانی می‌کند و بدون نیاز به صف پیام (message queue) یا سرویس خارجی، تنها با یک پایگاه داده اجرا می‌شود. SQLite گزینه پیش‌فرض است، اما در صورت نیاز به مقیاس‌پذیری بیشتر، از MySQL و PostgreSQL نیز پشتیبانی می‌کند.

یک نمونه موقت برای مشاهده رابط کاربری پیش از تصمیم‌گیری نهایی:

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 تعیین کردید، وارد شوید. این کانتینر پس از توقف، هیچ داده‌ای را ذخیره نمی‌کند. برای راه‌اندازی یک نمونه واقعی، از نمونه فایل compose پروژه استفاده کنید که bugsink/bugsink:2 را با postgres:17-alpine جفت کرده و متغیرهای DATABASE_URL، BASE_URL و BEHIND_HTTPS_PROXY را تنظیم می‌کند. مقدار secret را به درستی تولید کنید:

openssl rand -base64 50

مقدار BASE_URL باید دقیقاً با URLای که کاربران و SDKهای شما استفاده می‌کنند (شامل طرح یا scheme) مطابقت داشته باشد. اگر آن را روی http://localhost:8000 رها کنید در حالی که از طریق https://errors.example.com به سرور دسترسی دارید، تمام لینک‌های موجود در ایمیل‌های اطلاع‌رسانی به میزبانی اشاره می‌کنند که برای خواننده ایمیل قابل حل (resolve) نیست. زمانی که Nginx یا Caddy وظیفه TLS termination را در مقابل آن بر عهده دارند، BEHIND_HTTPS_PROXY را روی true تنظیم کنید؛ در غیر این صورت، Bugsink لینک‌های http:// را پشت proxy شما (https://) می‌سازد و مرورگرها محتوای mixed content را مسدود می‌کنند.

تولیدکننده، آمار توان عملیاتی (throughput) خود را منتشر کرده است: 18 رویداد در ثانیه با حجم 50 کیلوبایت برای هر کدام، که معادل 1.5 میلیون رویداد در روز روی یک VPS با 2 هسته vCPU و 4 گیگابایت رم است. این ارقام را به عنوان الگوی عملکرد ابزار در نظر بگیرید، نه تضمینی برای بار کاری خاص شما. با این حال، این آمار نشان می‌دهد که سقف توانایی ابزار بسیار فراتر از خروجی یک برنامه کوچک است.

و اما در مورد مجوز؛ این بخشی است که باید پیش از افزودن ابزار به stack خود مطالعه کنید. Bugsink تحت مجوز PolyForm Shield License 1.0.0 منتشر شده است. این یک مجوز source available است، نه open source: شما اجازه دارید آن را اجرا و اصلاح کنید، اما اجازه ندارید از آن برای ساخت محصولی که با Bugsink رقابت می‌کند استفاده کنید. برای یک ردیاب خطای داخلی (internal error tracker)، این محدودیت هرگز مشکل‌ساز نخواهد شد. اگر شرکت شما در زمینه ابزارهای توسعه‌دهنده فعالیت می‌کند، حتماً پیش از هر اقدامی متن مجوز را توسط فردی متخصص بررسی کنید.

ردیابی خطا و مشاهده‌پذیری LLM همچنان دو ابزار مجزا هستند

اگر به دنبال ابزاری بگردید که هم ردیابی خطا و هم مشاهده‌پذیری مدل‌های زبانی بزرگ (LLM) را با هم انجام دهد، با محصولاتی مواجه می‌شوید که ادعای انجام هر دو را دارند. ساختار داده‌ها در این دو حوزه متفاوت است و به همین دلیل است که ادغام آن‌ها همچنان محقق نشده است. یک ابزار ردیابی خطا، یک استثنا (exception) را همراه با stack trace دریافت می‌کند، از آن یک اثر انگشت (fingerprint) می‌سازد و هزاران رخداد مشابه را در قالب یک مسئله واحد با یک شمارنده تجمیع می‌کند. در مقابل، یک ابزار ردیابی LLM، یک span شامل prompt، پاسخ، تعداد توکن‌ها و میزان تأخیر (latency) را دریافت می‌کند و باید تک‌تک آن‌ها را حفظ کند؛ زیرا دو فراخوانی با ورودی‌های کاملاً یکسان، همچنان دو رخداد مجزا هستند که بررسی هر کدام اهمیت دارد.

بنابراین از هر دو ابزار استفاده کنید. استثناها را به ابزار ردیابی خطا بفرستید و فراخوانی‌های مدل را به جایی بفرستید که برای این کار ساخته شده است: میزبانی شخصی Langfuse برای ردیابی عامل‌ها این بخش را پوشش می‌دهد و مشاهده‌پذیری هوش مصنوعی به صورت self-hosted از زاویه‌ای متفاوت به همین وظیفه می‌پردازد. برنامه شما در حال حاضر هر دو نوع شکست را تولید می‌کند. یک فراخوانی مدل که خروجی بی‌معنی اما با اعتمادبه‌نفس بالا برمی‌گرداند، هیچ استثنایی ایجاد نمی‌کند؛ بنابراین ابزار ردیابی خطا هرگز آن را به شما نشان نخواهد داد.

رشد دیسک خطایی است که دیر یا زود با آن مواجه می‌شوید

هر ردیاب خطا (error tracker) یک پایگاه داده با حجم نوشتن بالا و ورودی نامحدود است. برنامهٔ شما تصمیم می‌گیرد چه مقدار داده بنویسد و یک باگ جدید در مسیر اجرای پرکاربرد کد، می‌تواند در طول یک شب یک میلیون رویداد تولید کند.

GlitchTip رقمی را منتشر کرده که ارزش برنامه‌ریزی دارد: نمونه‌ای که یک میلیون رویداد در ماه را پردازش می‌کند، ممکن است به 30 GB فضای دیسک نیاز داشته باشد. این مقدار، یک ماه دریافت داده با آن نرخ را پوشش می‌دهد و پنجرهٔ نگهداری (retention window) شما تعیین می‌کند که همزمان چند ماه داده را ذخیره می‌کنید.

Bugsink از سمت دیگر به این موضوع نگاه می‌کند. به‌جای سهمیهٔ ثابت، یک الگوریتم نگهداری بر اساس تعداد و عمر رویدادها اعمال می‌کند و محدودیت‌ها را مستقیماً در دسترس قرار می‌دهد: MAX_RETENTION_EVENT_COUNT برای کل نصب، MAX_RETENTION_PER_PROJECT_EVENT_COUNT برای هر پروژه و MAX_EVENT_AGE_DAYS به عنوان یک سقف مطلق. تعیین بودجهٔ رویداد برای کل نصب، روشی صادقانه برای تعیین اندازهٔ دیسک است، زیرا آن بودجه در واقع همان دیسک شماست.

اعداد واقعی روی سرور را زیر نظر داشته باشید:

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

docker system df -v اندازهٔ هر volume را چاپ می‌کند تا بتوانید ببینید کدام سرویس در حال رشد است. volumeای که بدون تغییر در ترافیک، هر هفته چندین گیگابایت رشد می‌کند، معمولاً به این معنی است که retention هرگز پیکربندی نشده است؛ بنابراین هیچ‌چیز حذف نمی‌شود و تنها محدودیت، فضای پارتیشن است.

حافظه (RAM) نیز همان مشکل است که با لباسی متفاوت ظاهر شده است. پشته‌ای (stack) که هیچ محدودیتی ندارد، هر چه هسته (kernel) ارائه دهد را مصرف می‌کند و وقتی ماشین با کمبود مواجه شود، OOM killer بزرگ‌ترین پردازش را انتخاب می‌کند؛ که ممکن است وب‌سرور شما باشد، نه ردیابی که باعث این وضعیت شده است. برای هر سرویس یک سقف تعیین کنید: محدودیت‌های حافظه در Docker Compose سینتکس و رفتار کانتینر هنگام رسیدن به سقف تعیین‌شده را نشان می‌دهد. کانتینری که در محدودیت خود کشته می‌شود، یک شکست محدودشده است. کانتینری که توسط هسته کشته می‌شود، همسایه‌اش را نیز با خود پایین می‌کشد.

کدام پشته برای کدام VPS مناسب است

• 1 گیگابایت، یا 2 گیگابایت با فضای خالی: GlitchTip در حالت all-in-one با Valkey غیرفعال، یا Bugsink روی SQLite. هر دو برای تعداد کمی برنامه در این سطح مناسب هستند.
• 4 گیگابایت: Bugsink با PostgreSQL، یا GlitchTip با Valkey فعال و یک سرویس worker جداگانه. در این ظرفیت، دیگر نیازی به بهینه‌سازی نیست و می‌توانید به‌سادگی از آن استفاده کنید.
• 8 گیگابایت: همچنان کمتر از پشته رسمی Sentry است. این منابع را صرف بازه نگهداری طولانی‌تر و دیسک بزرگ‌تر برای هر گزینه سبکی که انتخاب کرده‌اید، کنید.
• حداقل 16 گیگابایت، 32 گیگابایت توصیه می‌شود: پشته رسمی Sentry برای self-hosted، و تنها زمانی که به قابلیتی از Sentry نیاز دارید که پروژه‌های سبک‌تر آن را پیاده‌سازی نکرده‌اند. ابتدا قابلیت مورد نظر را در مستندات هر پروژه بررسی کنید، زیرا پروژه‌های سازگار، موارد رایج را پوشش می‌دهند.

هر چه را اجرا می‌کنید، ابزار ردیابی خطا نمی‌تواند از کار افتادن خودش را گزارش دهد. از یک ماشین دیگر بر آن نظارت کنید: Uptime Kuma که از یک دستگاه دیگر نظارت می‌کند به شما اطلاع می‌دهد که ابزار ردیابی از دسترس خارج شده است؛ دقیقاً در همان لحظه‌ای که برنامه شما شروع به تولید خطا می‌کند و هیچ‌کس آن‌ها را ثبت نمی‌کند.

چه زمانی استفاده از طرح‌های میزبانی‌شده (Hosted) به‌صرفه‌تر است

میزبانی شخصی (Self-hosting) یک ابزار ردیابی خطا زمانی توجیه اقتصادی دارد که قوانین اقامت داده‌ها (Data residency) آن را الزامی کنند، یا حجم رویدادهای شما به قدری بالا باشد که مدل قیمت‌گذاری بر اساس هر رویداد، هزینه‌های سنگینی تحمیل کند. خارج از این موارد، محاسبات را صادقانه انجام دهید. حداقل سخت‌افزار مستندشده برای Sentry یک سرور با 16 GB رم، 4 هسته پردازنده و دیسک پرسرعت است؛ یک VPS با این مشخصات، ارزان نیست. سپس هزینه‌های عملیاتی را اضافه کنید: عبور از تمام مراحل دشوار به‌ترتیب، و گرفتن snapshot پیش از هر migration، که چند بار در سال تکرار می‌شود.

پروژه‌های GlitchTip و Bugsink این محاسبات را کاملاً تغییر می‌دهند، زیرا یک سرور با 512 MB تا 4 GB رم، یک گزینه ارزان‌قیمت محسوب می‌شود و ارتقای آن یک docker compose pull است. به همین دلیل است که اکثر افرادی که این پرسش را مطرح می‌کنند، در نهایت به جای استفاده از پشته (Stack) رسمی، به سراغ یکی از پروژه‌های سازگار می‌روند. آن‌ها به دنبال ردیابی خطا بودند، نه یک خط لوله داده توزیع‌شده که نیاز به مراقبت دائمی داشته باشد.

اگر هنوز در حال تصمیم‌گیری هستید که چه سرویس‌هایی را روی سرور خود میزبانی کنید، لیست جامع‌تری از سرویس‌های ارزشمند برای میزبانی شخصی، ردیابی خطا را در کنار سایر سرویس‌هایی قرار می‌دهد که برای استفاده از رم محدود سرور با یکدیگر رقابت می‌کنند.

FAQ

آیا می‌توانم Sentry را روی یک VPS با 2 گیگابایت رم میزبانی کنم؟

خیر. مستندات نسخهٔ self-hosted نرم‌افزار Sentry حداقل 4 هسته CPU، 16 گیگابایت رم به همراه 16 گیگابایت swap و 20 گیگابایت فضای دیسک خالی را الزامی می‌داند. این پشته (stack) به‌طور هم‌زمان Postgres، ClickHouse، Kafka، Redis و چندین پردازش worker را اجرا می‌کند؛ بنابراین روی یک سرور کوچک، هستهٔ سیستم‌عامل (kernel) پیش از پایان نصب، کانتینرها را متوقف (kill) می‌کند. این وضعیت را با dmesg -T | grep -i 'out of memory' تأیید کنید که خطی شامل نام پردازش متوقف‌شده را چاپ می‌کند. برای یک VPS با 2 گیگابایت رم، از GlitchTip استفاده کنید که 512 مگابایت رم نیاز دارد، یا Bugsink که به‌عنوان یک کانتینر واحد روی SQLite اجرا می‌شود.

آیا برای تغییر از Sentry به GlitchTip یا Bugsink باید کد برنامه را تغییر دهم؟

خیر. هر دو سرویس رویدادها را از SDKهای متن‌باز Sentry می‌پذیرند؛ بنابراین می‌توانید SDK نصب‌شده را حفظ کرده و فقط یک مقدار را تغییر دهید: DSN، یعنی همان URL که SDK رویدادها را به آن ارسال می‌کند. اگر DSN در کد سخت‌کد شده است، آن را به یک متغیر محیطی (environment variable) منتقل کنید، به میزبان جدید اشاره دهید، سپس یک استثنای آزمایشی (test exception) ایجاد کنید و رسیدن آن را بررسی کنید. اگر چیزی دریافت نشد، مطمئن شوید که شناسهٔ پروژه در DSN با پروژه‌ای که در سرور جدید ایجاد کرده‌اید مطابقت دارد و فایروال شما اجازهٔ دسترسی برنامه به آن میزبان و پورت را می‌دهد.

سیستم ردیابی خطای self-hosted به چه مقدار فضای دیسک نیاز دارد؟

این موضوع بیش از آنکه به ابزار بستگی داشته باشد، به حجم رویدادها و بازهٔ نگهداری (retention window) شما وابسته است. GlitchTip برای نمونه‌ای که ماهانه یک میلیون رویداد را پردازش می‌کند، 30 گیگابایت فضا پیشنهاد می‌دهد. Bugsink به شما اجازه می‌دهد بودجهٔ دیسک را مستقیماً با MAX_RETENTION_EVENT_COUNT و MAX_EVENT_AGE_DAYS تعیین کنید؛ بنابراین شما سقف را انتخاب می‌کنید و نیاز دیسک بر اساس آن مشخص می‌شود. سیاست نگهداری را از همان روز اول پیکربندی کنید. یک ردیاب بدون سیاست نگهداری تا زمانی رشد می‌کند که df -h عدد 100% را نشان دهد؛ در آن نقطه، دریافت رویدادها متوقف شده و خطاهایی که بیش از همه به دیدن آن‌ها نیاز داشتید، از دست می‌روند.

چرا ارتقای Sentry نسخهٔ self-hosted مدام با شکست مواجه می‌شود؟

زیرا در ارتقا، توقف‌های اجباری (hard stop) نادیده گرفته شده‌اند. نسخهٔ self-hosted نرم‌افزار Sentry نسخه‌های خاصی را تعریف می‌کند که حاوی مهاجرت‌های دیتابیس (database migrations) هستند و باید حتماً از آن‌ها عبور کنید. تا اوت 2026، این نسخه‌ها عبارتند از: 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. پریدن مستقیم از یک نسخهٔ قدیمی به جدیدترین نسخه باعث می‌شود این مهاجرت‌ها انجام نشوند، در نتیجه ساختار دیتابیس (schema) و کد با هم ناسازگار شده و ارتقا نیمه‌کاره می‌ماند. هر توقف اجباری را به‌ترتیب بررسی کنید و در هر مرحله ./install.sh را اجرا نمایید. پیش از شروع، از سرور snapshot بگیرید و لیست نسخه‌هایی که باید از آن‌ها اجتناب کرد (شامل 23.7.0، 25.9.0 و 25.12.0) را در مستندات مطالعه کنید.