الانحدارات في Sentry 26.4.x التي تدفع إلى الترحيل
في أغسطس 2026، تراكمت ثلاث مشكلات في مستودع getsentry/self-hosted بما يكفي من التقارير لتشكّل إشارة ترحيل واضحة. توثّق المشكلة #4301 تعطّلًا في المستهلك Kafka ingest-monitors بعد الترقية إلى 26.4.1: تبقى مجموعة المستهلكين متصلة لكن CURRENT-OFFSET يتوقف عن التقدم. النتيجة المباشرة أن جميع مراقبي المهام المجدولة تتحوّل إلى حالة خطأ مع فقدان البيانات الخلفية، وتصبح ميزة Crons غير قابلة للاستخدام على مستوى المؤسسة بأكملها. تظهر المشكلة فقط في الحالات التي تحتوي على بيانات متراكمة (أكثر من 1.2 مليون صف في sentry_monitorcheckin). المشكلة #4306 تُفيد بأن جميع مستهلكي Snuba يطبعون الخطأ 'Failed to read directory /etc/sentry-options/values' في حلقة لا نهائية — أُغلقت دون إصلاح رسمي بحالة 'not planned'. المشكلة #4321 تخص الإصدار 26.4.2: تُبلَّغ حاويات seaweedfs-1 وweb-1 على أنها غير صحية عند بدء التشغيل.
ما يقدمه GlitchTip v6 كبديل
- توافق SDK على مستوى البروتوكول — ينفّذ GlitchTip البروتوكول ذاته الذي يستخدمه Sentry. صيغة DSN هي نفسها (
https://<key>@your-domain.com/<project-id>)، وتعمل حزم@sentry/browserوsentry-sdkبلغة Python وsentry-goدون تعديل في الكود. - ترخيص AGPL-3.0، مفتوح المصدر — GlitchTip v6 (صدر في 3 فبراير 2026) تحتفظ به فريق مستقل بتمويل من المستخدمين. لا ترخيص مزدوج ولا مكوّنات مملوكة.
- بصمة Docker مخففة — تستبدل النسخة 6 Celery بـ django-vtasks، وUvicorn/Gunicorn بـ Granian (خادم HTTP مكتوب بـ Rust)، وتوفر وضع الكل في واحد المستقر للحالات المتواضعة.
- UUIDv7 وتقسيم محسّن للجداول — راجعت النسخة 6 إدارة المفاتيح الأساسية (UUIDv7) وتقسيم الجداول لاستعلامات أسرع على أحجام الأحداث الكبيرة.
- دعم السجلات والتتبع (v6.1) — أضافت النسخة 6.1، الصادرة في 23 مارس 2026، استيعاب السجلات عبر sentry-sdk وتخزينًا باردًا اختياريًا بـ DuckDB.
- تكلفة مقتصرة على البنية التحتية — يكفي VPS بذاكرة 2 غيغابايت للأحمال المعتدلة. تكلفة خطة Sentry Team هي 26 دولارًا شهريًا مقابل 50,000 خطأ.
- تبديل DSN قابل للعكس — إذا احتجت للعودة إلى Sentry، يكفي تبديل متغيّر آخر. لا يُضاف أي اعتماد في الكود.
المتطلبات الأساسية قبل الترحيل
يفترض هذا الدليل أن GlitchTip منشور وجاهز على VPS خاص بك. إن لم يكن كذلك، راجع أولًا مقال 'استضافة GlitchTip v6 على VPS'. للترحيل تحتاج ثلاثة أشياء: وصول المسؤول إلى Sentry (لقراءة DSN الحالية وتصدير تكوين التنبيهات)، وصول المسؤول إلى GlitchTip (لإنشاء المشاريع المعادلة واسترداد DSN الجديدة)، وقائمة متغيرات البيئة أو ملفات التكوين لكل تطبيق يحتوي على قيمة SENTRY_DSN. يتم الترحيل مشروعًا بمشروع. إن كان لديك خمسة مشاريع في Sentry، ستنشئ خمسة في GlitchTip وتبدّل خمسة متغيرات. خصّص نحو عشر دقائق للمشروع الأول؛ اللاحقة تأخذ دقيقتين إلى ثلاث.
إجراء الترحيل — من المشروع الأول إلى إيقاف Sentry
جرد مشاريع Sentry وDSN الخاصة بها.
في واجهة Sentry، انتقل إلى الإعدادات > المشاريع. لكل مشروع، دوّن الاسم والمنصة (Python أو JavaScript أو PHP) وDSN الكامل (الإعدادات > مفاتيح العميل). صدّر أيضًا قواعد التنبيه (التنبيهات > القواعد): ستحتاج إلى إعادة إنشائها يدويًا في GlitchTip.
أنشئ المشاريع المعادلة في GlitchTip.
في واجهة GlitchTip، انتقل إلى مؤسستك ثم مشاريع > مشروع جديد. اختر المنصة المقابلة. بعد إنشاء المشروع، يعرض GlitchTip فورًا DSN المشروع بالصيغة https://<public-key>@your-domain.com/<numeric-id>.
انسخ DSN الجديد من GlitchTip وسجّله.
من صفحة المشروع في GlitchTip: الإعدادات > مفاتيح العميل > DSN. انسخ القيمة الكاملة. هذه هي المعلومة الوحيدة التي تحتاجها للتبديل.
أعد تكوين التنبييهات في GlitchTip.
قبل تحويل حركة المرور، أعد إنشاء قواعد التنبيه في GlitchTip: حدود الخطأ، الإشعارات بالبريد الإلكتروني أو webhook، التكرار. يدعم GlitchTip webhooks الواردة لتغطية معظم التكاملات.
بدّل DSN في تطبيقك.
استبدل قيمة متغير SENTRY_DSN (أو معامل dsn في تهيئة SDK) بـ DSN الجديد من GlitchTip. أعد النشر أو أعد تشغيل عملية التطبيق. لا يوجد كود آخر يتغيّر.
تحقق من استلام الأحداث في GlitchTip.
أطلق خطأ اختباريًا يدويًا (Sentry.captureException(new Error('test')) أو ما يعادله). في GlitchTip، يجب أن يظهر الحدث في مشكلات المشروع خلال ثوانٍ. إن لم يظهر، راجع قسم استكشاف الأخطاء.
كرّر العملية لكل مشروع.
بعد التحقق من المشروع الأول، كرّر الخطوات 1 إلى 6 لكل مشروع Sentry. أبقِ Sentry يعمل خلال فترة الانتقال — يبقى السجل التاريخي متاحًا طالما النظام يعمل.
أوقف Sentry بعد انتهاء فترة التحقق.
بعد أسبوعين من التشغيل الطبيعي في GlitchTip، أوقف حاويات Sentry (docker compose down). يبقى السجل التاريخي متاحًا إن أعدت تشغيل النظام مؤقتًا، لكن الأخطاء الجديدة لن تصله.
توافق SDK — الأطر والأنظمة المدعومة
لا يعيد GlitchTip تنفيذ SDKs: يستهلك البروتوكول ذاته الذي يستخدمه Sentry، مما يعني أن أي SDK رسمي لـ Sentry يعمل دون تعديل. اللغات والأطر الأكثر شيوعًا مدعومة بشكل أصلي. في Python، يتكامل sentry-sdk مع Django وFlask وFastAPI وCelery. في JavaScript وTypeScript، تعمل @sentry/browser و@sentry/node و@sentry/nextjs و@sentry/vue مباشرةً. في Ruby مدعوم sentry-rails وsentry-ruby. Go لديه getsentry/sentry-go. PHP يمكنه استخدام sentry/sentry-laravel أو sentry/sentry-symfony. Java وAndroid لديهما SDKs رسمية. الخيار الوحيد الذي يجب تعطيله في بعض SDKs هو auto_session_tracking — لا يدعم GlitchTip تتبع الجلسة في الوقت الفعلي، لكن هذا لا يؤثر على إبلاغ الأخطاء.
إبقاء Sentry يعمل بالتوازي خلال فترة التحقق
حتى لو جعلت تراجعات 26.4.x من Sentry غير موثوق، لا توقف النظام فورًا بعد أول تبديل. أبقِ النظامين يعملان بالتوازي لمدة أسبوع إلى أسبوعين: Sentry للرجوع إلى السجل التاريخي، وGlitchTip لاستقبال الأخطاء الجديدة. ملاحظة مهمة: الأحداث السابقة لا تنتقل من Sentry إلى GlitchTip. لا توجد أداة لاستيراد السجل التاريخي — وهذا مقصود إذ تختلف التنسيقات الداخلية. هدف هذا الترحيل ليس الحفاظ على ستة أشهر من السجلات، بل استعادة استيعاب الأخطاء اليوم.
استكشاف الأخطاء — أكثر ثلاث مشكلات شيوعًا بعد التبديل
الأحداث لا تصل إلى GlitchTip. تحقق أولًا من صحة صياغة DSN: الصيغة المتوقعة هي https://<key>@your-domain.com/<id>. إذا كانت نسختك من GlitchTip خلف reverse proxy، تأكد من تمرير ترويسات X-Forwarded-For وX-Forwarded-Proto — قد يُرسل proxy مُعدٌّ بشكل خاطئ أخطاء 400 أو 413 بصمت. راجع سجلات حاوية GlitchTip (docker compose logs web) لتأكيد الاستلام. DSN مرفوض بخطأ 401 أو 403. في الغالب، المفتاح العام في DSN لا يتطابق مع مشروع GlitchTip المستهدف. تأكد من نسخ DSN من المشروع الصحيح. تجميع الأخطاء لا يشبه Sentry. يستخدم GlitchTip خوارزمية بصمة خاصة به. ستُجمَّع الأخطاء من النوع ذاته، لكن التطابق مع مجموعات Sentry غير مضمون — خاصة للاستثناءات ذات stacktraces الديناميكية. هذا سلوك متوقع.
Sentry cloud مقابل GlitchTip self-hosted — ما الذي يتغير فعلًا
| Sentry Team (cloud) | GlitchTip self-hosted | |
|---|---|---|
| التكلفة الأساسية | {{sentry.team.price}}/شهر (سنوي) — 50,000 خطأ مضمّن | تكلفة VPS فقط — 99 درهم/شهر/شهر |
| حد الأخطاء | حصة صارمة، يُفوتر الزائد | لا حصة — محدود بتخزين VPS |
| توافق SDK | بروتوكول Sentry الأصلي | نفس بروتوكول السلك — لا تعديل في الكود |
| استيراد السجل | لا ينطبق | غير متاح — الأحداث السابقة تبقى في Sentry |
| التنبيهات والتكاملات | واجهة كاملة، Slack وPagerDuty وJira أصليًا | Webhooks واردة، بريد إلكتروني — يغطي الحالات الشائعة |
| الصيانة | تديرها Sentry (تحديثات تلقائية) | على عاتقك — `docker compose pull && docker compose up -d` |
| الترخيص | مملوك (BSL 1.1 للسحابة) | AGPL-3.0 — كود مصدر قابل للمراجعة |
البدء من الصفر مع GlitchTip على VPS من ServOrbit
إذا لم يكن لديك نسخة GlitchTip في الإنتاج بعد وترغب في مغادرة Sentry self-hosted، يكفي VPS بذاكرة 2 غيغابايت لتشغيل GlitchTip v6 بتكوين الكل في واحد. التثبيت الكامل — Docker Compose، وnginx كـ reverse proxy، وشهادة TLS، ومتغيرات البيئة — موثّق في المقال المخصص. بعد جاهزية النسخة، يتبع الترحيل من Sentry الإجراء الموضّح في هذا المقال: إنشاء المشاريع، واسترداد DSN، وتبديل المتغيرات. الوقت الإجمالي من إنشاء VPS حتى استلام أول حدث في GlitchTip يقل عادةً عن ساعة.
