تثبيت GlitchTip على VPS: تتبع الأخطاء بشكل مستقل

لماذا الترحيل إلى 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 في جدار الحماية.

على خوادم ServOrbit VPS، يأتي 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/glitchtip
REDIS_URL=redis://redis:6379/0
GLITCHTIP_DOMAIN=https://glitchtip.your-domain.com
[email protected]
EMAIL_URL=smtp://user:[email protected]:587

استبدل القيم ببياناتك الخاصة. يجب أن يتطابق GLITCHTIP_DOMAIN تماماً مع النطاق الذي ستؤمّنه بـ HTTPS — يُدمج في الـ DSNs التي ينشئها GlitchTip.

إنشاء ملف docker-compose.yml

أنشئ ملف docker-compose.yml بالمحتوى التالي (مستوحى من التوثيق الرسمي لـ GlitchTip):

version: "3.8"
x-environment: &default-environment
  env_file: .env
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: glitchtip
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: password
    volumes:
      - pg_data:/var/lib/postgresql/data
  redis:
    image: redis:7
    volumes:
      - redis_data:/data
  web:
    image: glitchtip/glitchtip:latest
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8000:8080"
    <<: *default-environment
  worker:
    image: glitchtip/glitchtip:latest
    command: ./bin/run-celery-with-beat.sh
    depends_on: [db, redis]
    <<: *default-environment
volumes:
  pg_data:
  redis_data:

لاحظ أن المنفذ 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 بكتلة server تستمع على المنفذ 80، وتضع server_name glitchtip.your-domain.com، وتُعيد توجيه الطلبات إلى http://127.0.0.1:8000 عبر proxy_pass. فعّل الإعداد ثم احصل على الشهادة:

certbot --nginx -d glitchtip.your-domain.com

يُحدّث Certbot ملف vhost تلقائياً لإعادة توجيه HTTP إلى HTTPS ويضيف كتلة SSL.

توصيل SDK Sentry من تطبيقاتك

في واجهة GlitchTip، أنشئ منظمة ثم مشروعاً. يُنشئ GlitchTip DSN بالتنسيق https://<مفتاح>@glitchtip.your-domain.com/<معرّف-المشروع>.

في كل تطبيق من تطبيقاتك، استبدل قيمة SENTRY_DSN (أو المعامل dsn الممرَّر إلى Sentry.init()) بهذا الـ DSN الجديد. أعد تشغيل العمليات. تظهر الأحداث في GlitchTip بدون أي تعديل آخر.

الإعداد بعد التثبيت

بعد أول تشغيل، اضبط هذه النقاط في واجهة الإدارة:

متغيرات بيئة إضافية. فعّل إرسال التنبيهات بالبريد الإلكتروني بتعريف EMAIL_URL في ملف .env. أضف GLITCHTIP_MAX_EVENT_LIFE_DAYS=90 للتحكم في مدة الاحتفاظ بالأحداث وضبط حجم قاعدة البيانات.

الوصول متعدد الفرق. يدير GlitchTip منظمات وأعضاء بمستويات صلاحيات مختلفة. أنشئ فرقك من الإعدادات ← الأعضاء وادعُ المطورين بالبريد الإلكتروني.

مراقبو الإتاحة. في قسم Monitors لمشروعك، أنشئ مراقب ping لكل خدمة تُعرضها: يُرسل GlitchTip طلب HTTP على فترات منتظمة ويُنشئ issue إذا لم تستجب الخدمة خلال المهلة المحددة.

تصليب المجموعة

قيّد الوصول إلى المنفذ 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: يجب أن يُرجع الأمر curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8000/api/0/ القيمة 200.

تظهر الأحداث في سجلات 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.

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 واختيار نظام التشغيل.