لماذا الترحيل إلى GlitchTip الآن
يعاني Sentry self-hosted 26.4.x من خمسة انحدارات موثّقة من المجتمع منذ أغسطس 2026. تصف issues رقم #4301 و#4306 consumers لـ Snuba تعيد التشغيل في حلقة لا نهائية دون معالجة أي أحداث، وتوقف في monitor_consumer يمنع تسجيل المراقبة الدورية. تُشير issue رقم #4321 إلى فشل مصادقة relay على اتصالات HTTP/2، مما يوقف استيعاب الأحداث. دفعت هذه الانحدارات عدة فرق إلى توثيق ترحيلها إلى GlitchTip.
الاعتراض الأكثر شيوعاً هو التوافق: لقد أضفت SDK Sentry (sentry-python أو @sentry/node أو sentry-rails…) إلى تطبيقاتك ولا تريد إعادة كتابة هذه الأدوات. يُطبّق GlitchTip واجهة برمجية متوافقة مع Sentry ويقبل الأحداث المُرسَلة من هذه SDKs ذاتها. يتلخص التبديل في استبدال قيمة متغير البيئة SENTRY_DSN بـ DSN الذي يُنشئه GlitchTip عند إنشاء المشروع. لا تغيير في كود التطبيق.
ما تحصل عليه مع GlitchTip v6 المُستضاف ذاتياً
- بصمة صغيرة — أربعة حاويات فقط (Django وCelery وPostgreSQL وRedis)، مقارنةً بعشرين خدمة في Sentry self-hosted.
- توافق SDK Sentry — جميع SDKs Sentry الرسمية تعمل بدون تعديل؛ المتغير الوحيد المُستبدل هو DSN.
- سيادة البيانات — تبقى آثار الأخطاء وبيانات المستخدمين على بنيتك التحتية وفق سياسة الاحتفاظ التي تختارها.
- رخصة GPL-3.0 — الكود قابل للمراجعة، بدون مكوّن مغلق أو ميزة مقيّدة بخطة مدفوعة.
- مراقبة الإتاحة — يشمل GlitchTip مراقبة الاتصال HTTP بدون أي تبعية خارجية.
- واجهة إدارة الأداء — تتبع المعاملات وآثار N+1 والاستعلامات البطيئة عبر واجهة برمجية متوافقة مع Sentry.
- استهلاك ذاكرة منخفض — تكفي 2 جيجابايت من RAM للاستخدام الفردي أو الفريق الصغير بدون أي ضبط للإعدادات.
المتطلبات قبل البدء
يعتمد GlitchTip v6 على أربع حاويات: Django (خادم الويب والواجهة)، وCelery (معالجة الأحداث بشكل غير متزامن)، وPostgreSQL (قاعدة البيانات الرئيسية)، وRedis (قائمة انتظار المهام). تحتاج إلى:
- خادم VPS يعمل بنظام Linux مع ذاكرة 2 جيجابايت كحد أدنى (4 جيجابايت مريحة لفريق من عشرة مطورين).
- تثبيت Docker وDocker Compose — متاحان على جميع التوزيعات الحديثة.
- اسم نطاق أو نطاق فرعي يُشير إلى عنوان IP الخادم، لتفعيل HTTPS عبر Let's Encrypt.
- فتح المنفذين 80 و443 في جدار الحماية.
على خادم VPS من ServOrbit، يكون Docker مُثبَّتاً مسبقاً. تُغطّي العروض من 2 vCPU وذاكرة 2 جيجابايت هذا النمط من الحمل تماماً.
نشر GlitchTip باستخدام Docker Compose
إنشاء مجلد العمل
اتصل بخادم VPS عبر SSH، ثم أنشئ مجلداً مخصصاً:
mkdir -p /opt/glitchtip && cd /opt/glitchtipإنشاء ملف متغيرات البيئة
أنشئ ملف
.envبقيم الإعدادات:SECRET_KEY=<سلسلة-عشوائية-طويلة>— أنشئها بالأمرopenssl rand -hex 32.DATABASE_URL=postgresql://glitchtip:كلمةالمرور@db:5432/glitchtipREDIS_URL=redis://redis:6379/0GLITCHTIP_DOMAIN=https://glitchtip.نطاقك.comDEFAULT_FROM_EMAIL=no-reply@نطاقك.comEMAIL_URL=smtp://مستخدم:كلمةالمرور@smtp.نطاقك.com:587يجب أن يتطابق حقل
GLITCHTIP_DOMAINتماماً مع النطاق الذي ستؤمّنه بـ HTTPS.إنشاء ملف docker-compose.yml
أنشئ ملف
docker-compose.ymlمع الخدمات:db(postgres:16)، وredis(redis:7)، وwebوworker(صورةglitchtip/glitchtip:latest)، مع ربط المنفذ على127.0.0.1:8000:8080فقط. المنفذ 8000 مرتبط بـ127.0.0.1فحسب، ولا يُعرَّض مباشرةً بل عبر وسيط عكسي.تهيئة قاعدة البيانات
شغّل عمليات هجرة Django لإنشاء المخطط:
docker compose run --rm web ./manage.py migrateشغّل هذا الأمر مرةً واحدة عند التثبيت، ثم عند كل تحديث إلى إصدار جديد من GlitchTip.
إنشاء أول مستخدم مشرف
أنشئ حساب المسؤول:
docker compose run --rm web ./manage.py createsuperuserأدخل عنوان البريد الإلكتروني وكلمة المرور عند طلبهما.
تشغيل المجموعة
ابدأ تشغيل جميع الحاويات في الخلفية:
docker compose up -dتحقق من تشغيل الحاويات الأربع بالأمر
docker compose ps. يستجيب خادم الويب علىhttp://127.0.0.1:8000.إعداد وسيط nginx العكسي مع HTTPS
ثبّت nginx وCertbot إن لم يكونا مُثبَّتَين:
apt install -y nginx certbot python3-certbot-nginxأنشئ vhost في
/etc/nginx/sites-available/glitchtipيستمع على المنفذ 80 ويُحوّل الطلبات إلىhttp://127.0.0.1:8000، ثم احصل على الشهادة:certbot --nginx -d glitchtip.نطاقك.comيُحدّث Certbot الإعداد تلقائياً لإعادة التوجيه من HTTP إلى HTTPS.
توصيل SDK Sentry من تطبيقاتك
في واجهة GlitchTip، أنشئ منظمة ثم مشروعاً. يُنشئ GlitchTip DSN بالصيغة
https://<مفتاح>@glitchtip.نطاقك.com/<معرف-المشروع>.في كل تطبيق، استبدل قيمة
SENTRY_DSN(أو المعاملdsnفيSentry.init()) بهذا DSN الجديد. أعد تشغيل العمليات؛ ستظهر الأحداث في GlitchTip دون أي تعديل آخر.
GlitchTip v6 مقابل البدائل — ما يهم فعلاً
مرّر الجدول أفقيًا
| المعيار | GlitchTip v6 | Sentry self-hosted 26.4.x | Rollbar (SaaS) | Bugsnag (SaaS) |
|---|---|---|---|---|
| البصمة في الذاكرة (إنتاج) | ~500 ميجابايت نشط (4 حاويات) | ~6-8 جيجابايت (20+ خدمة) | لا شيء (SaaS) | لا شيء (SaaS) |
| الرخصة | GPL-3.0 — كود قابل للمراجعة 100% | BSL 1.1 — قيود تجارية | مغلق المصدر | مغلق المصدر |
| مراقبة الإتاحة المدمجة | نعم — ping HTTP، تنبيهات مشمولة | ليس أصلياً (امتداد Crons فقط) | لا | لا |
| توافق SDK Sentry | كامل — استبدال DSN مباشر | أصلي | SDK خاص | SDK خاص |
الإعداد بعد التثبيت
بعد أول تشغيل، اضبط هذه النقاط في واجهة الإدارة:
متغيرات بيئة إضافية. فعّل إرسال التنبيهات بالبريد الإلكتروني بتعريف EMAIL_URL في ملف .env. أضف GLITCHTIP_MAX_EVENT_LIFE_DAYS=90 للتحكم في مدة الاحتفاظ بالأحداث وضبط حجم قاعدة البيانات.
الوصول متعدد الفرق. يدير GlitchTip منظمات وأعضاء بمستويات صلاحيات مختلفة. أنشئ فرقك من الإعدادات ← الأعضاء وادعُ المطورين بالبريد الإلكتروني.
مراقبو الإتاحة. في قسم Monitors لمشروعك، أنشئ مراقب ping لكل خدمة تُعرضها: يُرسل GlitchTip طلب HTTP على فترات منتظمة ويُنشئ issue إذا لم يستجب الخادم في الوقت المحدد.
تنبيهات Webhook إلى Slack أو ntfy. من الإعدادات ← التنبيهات، أضف وجهة من نوع "Webhook". لـ Slack، الصق رابط Incoming Webhook الخاص بك (https://hooks.slack.com/services/…)؛ لـ ntfy، استخدم https://ntfy.sh/<موضوعك> بالطريقة POST. يُرسل GlitchTip JSON منظماً عند كل issue جديدة أو تجاوز عتبة.
دمج SDK — Python. استبدل قيمة DSN فقط؛ يبقى الكود الباقي كما هو:
import sentry_sdk ثم sentry_sdk.init(dsn="https://<مفتاح>@glitchtip.نطاقك.com/<معرف>", traces_sample_rate=1.0)
دمج SDK — React. ذات المنطق على واجهة المستخدم:
import * as Sentry from "@sentry/react" ثم Sentry.init({ dsn: "https://<مفتاح>@glitchtip.نطاقك.com/<معرف>", tracesSampleRate: 1.0 })
يستقبل GlitchTip استثناءات Python/Node وأخطاء JavaScript في المتصفح، مجمّعة في واجهة واحدة.
الاحتفاظ بالبيانات. يتحكم المتغير GLITCHTIP_MAX_EVENT_LIFE_DAYS (الافتراضي: غير محدود) في العمر الأقصى للأحداث المحتفظ بها. على SSD بـ 60 جيجابايت، نادراً ما تتجاوز رتنشن 90 يوماً لبضع مئات من الأخطاء يومياً حاجز 5 جيجابايت — راقب بـ docker system df.
تصليب المجموعة
قيّد الوصول إلى المنفذ 8000 باستخدام ufw: ufw allow 80/tcp && ufw allow 443/tcp && ufw deny 8000/tcp. أضف SECURE_SSL_REDIRECT=True وSESSION_COOKIE_SECURE=True في ملف .env لفرض HTTPS على مستوى Django. جدوِل نسخة احتياطية يومية بـ pg_dump إلى موقع بعيد — يحتوي volume الـ pg_data على جميع بيانات الأخطاء والإعدادات. راجع أيضاً دليل التصليب الأولي لخادم Linux قبل تعريض النسخة للإنتاج.
الأخطاء الشائعة وحلولها
Error: relation "glitchtip_*" does not exist — لم تُشغَّل عمليات الترحيل. شغّل docker compose run --rm web ./manage.py migrate وتحقق من سلامة الحاوية db بالأمر docker compose ps.
CSRF verification failed. Request aborted. — متغير GLITCHTIP_DOMAIN لا يتطابق مع النطاق الذي تصل منه إلى الواجهة. تحقق من أنه بدون شرطة مائلة نهائية وأعد تشغيل الحاويات بالأمر docker compose restart.
Connection refused عبر DSN من تطبيقك — المنفذ 8000 غير متاح من الخارج (وهذا مقصود). تحقق أن nginx يُحوّل حركة HTTPS إلى 127.0.0.1:8000 بشكل صحيح.
تظهر الأحداث في سجلات Celery لكن ليس في الواجهة — بدأ worker Celery قبل اكتمال الهجرات. أعد تشغيله بالأمر docker compose restart worker.
No such file or directory: '/etc/nginx/sites-enabled/glitchtip' — نسيت إنشاء الرابط الرمزي. شغّل ln -s /etc/nginx/sites-available/glitchtip /etc/nginx/sites-enabled/ ثم nginx -t && systemctl reload nginx.
celery.exceptions.WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL) — أنهى kernel OOM killer حاوية worker. خادمك يعاني من نقص في الذاكرة: قلّل CELERY_WORKER_CONCURRENCY إلى 2 في .env، أو انتقل إلى 4 جيجابايت RAM. تحقق بـ docker compose logs worker --tail 50 وdmesg | grep -i oom.
django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections — بلغ PostgreSQL حد max_connections (الافتراضي: 100). أضف CONN_MAX_AGE=60 في .env لتفعيل مجمع اتصالات Django، أو استخدم PgBouncer كوسيط. تحدث هذه الخطأ عادةً عند تشغيل عدة Celery workers بالتوازي بدون مجمع اتصالات.
GlitchTip في الإنتاج على VPS
صدر GlitchTip v6 في فبراير 2026 برخصة GPL-3.0 ويعتمد على أربع حاويات. توافقه مع SDK Sentry يجعله مسار خروج سليم من Sentry self-hosted حين يتراكم الأخير بانحدارات يصعب تجاوزها.
للمزيد، راجع دليلنا حول قائمة تدقيق Docker Compose للإنتاج لتأمين نشرك أكثر، ودليل روتين تصحيح تطبيقات self-hosted للحفاظ على تحديث GlitchTip دون انقطاع الخدمة.
نسخة GlitchTip تعمل ضمن 2 جيجابايت من RAM: خادم VPS بـ 2 vCPU وذاكرة 2 جيجابايت يغطي هذا النمط تماماً، مع وصول root واختيار نظام التشغيل.
