بدائل Sentry المستضافة ذاتيًا: مقارنة الموارد والتحديثات

تكلفة تتبّع الأخطاء المستضاف ذاتياً قبل تخزين حدث واحد

هناك رقم واحد يحسم اختيار نظام تتبّع الأخطاء المستضاف ذاتياً بالكامل، وهو الحد الأدنى من ذاكرة RAM. تتطلب وثائق Sentry الرسمية للاستضافة الذاتية 4 أنوية CPU، و16 GB من RAM إضافة إلى 16 GB من swap، و20 GB من مساحة القرص الحرة، وذلك قبل أن يرسل تطبيقك حدثاً واحداً. وتوثّق GlitchTip متطلباً قدره 512 MB. تقبل جميع الخيارات هنا الأحداث من Sentry SDKs نفسها، لذا لا يتعلق القرار بطريقة إضافة أدوات الرصد إلى التعليمات البرمجية. بل يتعلق بحجم الخادم الذي تقبل دفع تكلفته وإبقائه قيد التشغيل.

أرقام الموارد المنشورة، جنباً إلى جنب

هذه هي الأرقام التي ينشرها كل مشروع عن نفسه، حتى أغسطس 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 المستضاف ذاتياً: المنتج بالكامل، والفاتورة بالكامل

الحزمة الرسمية هي getsentry/self-hosted، وهي مشروع Docker Compose يشغّل المكوّنات نفسها التي يشغّلها Sentry في بيئة الإنتاج. وتصفها وثائق المشروع بأنها «مكتملة الميزات ومُحزَّمة للنشرات منخفضة الحجم وإثباتات المفهوم». هذه خلاصة صادقة. تحصل على كل ميزة، وتحصل أيضاً على كل المكوّنات المتحركة التي تجعل هذه الميزات تعمل.

ثبّت إصداراً موسوماً بدلاً من 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، إضافة إلى عدة عمليات للعاملين وcron. احسبها مرة واحدة، لأن هذا العدد يمثل عبء الصيانة لديك. كل عنصر منها عملية يمكن أن تتعطل، أو تملأ القرص، أو تفشل أثناء ترحيل قاعدة البيانات.

إذا بقيت خدمة في حالة Restarting، فتحقق من الذاكرة قبل أي شيء آخر:

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

تعني سطر مثل Out of memory: Killed process 3412 (java) أن قاتل OOM في النواة (قاتل نفاد الذاكرة) أنهى حاوية لأن الخادم نفدت منه ذاكرة RAM. لذلك لا تصبح تلك الخدمة سليمة، ولا تكتمل عملية بدء الحزمة. هذه هي النتيجة المعتادة لتشغيل الحزمة الكاملة على خادم يطابق الحد الأدنى الموثق. تشير الوثائق أيضاً إلى سرعة القرص: تعني قيمة iowait التي تتجاوز 10% أن الجهاز لا يستطيع مواكبة مسار استقبال البيانات. اقرأها من عمود wa في top، أو من iostat -x 5 إذا كان sysstat مثبتاً لديك.

الترقيات هي الجزء الذي يستهين به الناس

يصدر Sentry المستضاف ذاتياً شهرياً وفق CalVer، وهو مخطط لإصدارات تعتمد على التقويم، مع إصدار رئيسي في اليوم 15 من كل شهر. لا يمكنك الانتقال مباشرة من إصدار قديم إلى أحدث إصدار. يحدد المشروع إصدارات توقف إلزامية، ويجب تسجيل الخروج إلى كل إصدار منها بالترتيب لتطبيق عمليات ترحيل قاعدة البيانات الخاصة به. حتى August 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.

الترقية عبارة عن تسجيل خروج ثم إعادة تشغيل المثبّت:

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

أنشئ نسخة snapshot للخادم قبل البدء، لأن ترحيل مجموعة بيانات كبيرة في ClickHouse قد يستغرق ساعات، وقد يؤدي الفشل في منتصف العملية إلى ترك قاعدة البيانات بين مخططين. السبب المباشر لمعظم ترقيات Sentry المستضاف ذاتياً الفاشلة هو بقاء الخادم على إصدار واحد لمدة عام، فتتجاوز القفزة عدة إصدارات توقف إلزامية دفعة واحدة، ويكون أحد الترحيلات التي يجب تجاوزها هو الترحيل المهم.

هناك أمر آخر يجب معرفته قبل الالتزام. يخضع Sentry المستضاف ذاتياً إلى Functional Source License (FSL)، وهي رخصة قدمها Sentry نفسه. وهي مصدر متاح للاستخدام وليست برمجية مفتوحة المصدر معتمدة من OSI: يمكنك تشغيله لاستخدامك، ولا يمكنك بيعه كخدمة منافسة. يتحول كل إصدار إلى Apache 2.0 بعد عامين من إصداره.

GlitchTip: الإجابة هي 512 MB

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

عدّل قسم البيئة قبل بدء أي شيء. يجب ضبط السر والنطاق ومسار البريد:

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 المخطط. من دون https:// في بدايته، تُنشأ الروابط في رسائل التنبيه بشكل خاطئ، وتؤدي إلى عنوان URL لا يستجيب.

شغّل التطبيق وراقب الإقلاع الأول:

docker compose up -d
docker compose logs -f web

علامات الصور في النموذج، حتى August 2026، هي postgres:18 وvalkey/valkey:9 وglitchtip/glitchtip:6. أبقِها محددة. ملف compose الذي يحتوي على latest سيحدّث محرّك قاعدة البيانات في عملية docker compose pull التالية، بينما يؤدي الانتقال إلى إصدار رئيسي أحدث من Postgres أثناء تشغيل المثيل إلى منع متتبّع الأخطاء العامل من بدء التشغيل.

للوصول إلى نطاق 256 MB إلى 512 MB، توضّح التعليقات الموجودة في الملف النموذجي نفسه ما يجب تعطيله، بدءاً من Valkey وميزات السجل ووقت التشغيل الاختيارية. عند التشغيل من دون Valkey، يستخدم GlitchTip قاعدة البيانات بدلاً منه للتخزين المؤقت وأعمال قائمة الانتظار. يكون ذلك أبطأ، لكنه يظل صحيحاً. في وضع All in one، يُشغّل العامل داخل عملية الويب، لذلك تدير حاوية تطبيق واحدة بدلاً من حاويتين.

ضع Proxy أمامه. تطلب وثائق GlitchTip استخدام Proxy أو موازن تحميل يقوم بتخزين الطلبات مؤقتاً ويتعامل مع Transfer-Encoding المقسّم إلى أجزاء، وتستخدم nginx مثالاً تطبيقياً. من دون التخزين المؤقت، يُبقي عميل بطيء أحد عمال التطبيق مشغّلاً طوال مدة الرفع. لذلك قد يشغل عدد قليل من المرسلين البطيئين جميع العمال المتاحين، وتبدأ العملاء السليمون بتجاوز مهلة الانتظار.

الترقية هي الجزء الأسهل:

docker compose pull
docker compose stop
docker compose up -d

تُجرى عمليات ترحيل قاعدة البيانات تلقائياً عند بدء التشغيل. مع ذلك، أنشئ تفريغاً احتياطياً أولاً، لأن الترحيل التلقائي يظل عملية ترحيل.

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. أنشئ السر بالطريقة الصحيحة:

openssl rand -base64 50

يجب أن يطابق BASE_URL عنوان URL الذي يستخدمه المستخدمون وSDKs فعلياً، بما في ذلك scheme. إذا تركته على http://localhost:8000 في خادم تصل إليه عبر https://errors.example.com، فسيشير كل رابط في رسالة إشعار بالبريد الإلكتروني إلى مضيف لا يمكن للمستلم الوصول إليه. اضبط BEHIND_HTTPS_PROXY على true عندما ينهي nginx أو Caddy اتصال TLS (أمان طبقة النقل) أمامه، وإلا فسيُنشئ Bugsink عناوين http:// خلف وكيل https:// الخاص بك، وتحظر المتصفحات المحتوى المختلط.

تنشر الجهة المطوّرة أرقام الأداء الخاصة بها: 18 حدثاً في الثانية، بحجم 50 KB لكل حدث، أي ما يعادل 1.5 مليون حدث يومياً، على VPS يحتوي على 2 vCPU و4 GB من الذاكرة. تعامل مع ذلك على أنه وصف لحجم الأداة، وليس ضماناً لأحمال العمل لديك. لكنه يوضح أن الحد الأقصى للأداة يتجاوز بكثير ما ينتجه تطبيق صغير واحد.

والآن نأتي إلى الترخيص. يجب قراءة هذا الجزء قبل إدخال الأداة إلى مجموعة خدماتك. يُطرح Bugsink بموجب PolyForm Shield License 1.0.0. هذا ترخيص يتيح الوصول إلى المصدر، وليس ترخيصاً مفتوح المصدر: يمكنك تشغيله وتعديله، لكن لا يجوز لك استخدامه لإنشاء أداة تنافس Bugsink. لا يظهر هذا القيد عادةً عند استخدامه لتتبّع الأخطاء داخلياً. إذا كانت شركتك تبيع أدوات للمطورين، فاطلب من شخص قراءة نص الترخيص أولاً.

تتبّع الأخطاء ورصد LLM ما زالا أداتين منفصلتين

ابحث عن أداة واحدة تتولى تتبّع الأخطاء ورصد نماذج اللغة الكبيرة (LLM) معاً، وستجد منتجات تدّعي الجمع بين الوظيفتين. تختلف بنية البيانات، ولذلك لا ينجح الدمج باستمرار. يستقبل متتبّع الأخطاء استثناءً مع تتبّع مكدس الاستدعاءات، ويحسب بصمة له، ثم يدمج آلاف التكرارات في مشكلة واحدة مع عدّاد. أما أداة تتبّع LLM فتستقبل span يحتوي على prompt واستجابة وعدد الرموز وزمن استجابة، وعليها الاحتفاظ بكل واحد منها، لأن استدعاءين بالمدخلات نفسها يظلان حدثين منفصلين يستحقان القراءة.

لذلك شغّل الأداتين معاً. أرسل الاستثناءات إلى متتبّع الأخطاء، وأرسل استدعاءات النموذج إلى مكان مصمم لها: يغطي Langfuse مستضافاً ذاتياً لتتبّع الوكلاء هذا الجانب، بينما تتناول رصد AI مستضافاً ذاتياً المهمة نفسها من زاوية مختلفة. ينتج تطبيقك النوعين من حالات الفشل بالفعل. قد يعيد استدعاء النموذج هراءً واثقاً من دون أن يرمي أي استثناء، ولذلك لن يعرضه لك متتبّع الأخطاء أبداً.

نمو القرص هو الفشل الذي يظهر لاحقاً

كل متتبّع أخطاء هو قاعدة بيانات كثيفة الكتابة ذات مدخلات غير محدودة. يحدد تطبيقك حجم البيانات التي يكتبها، وقد يتسبب خطأ جديد واحد في مسار برمجي كثير الاستخدام في إنتاج مليون حدث خلال ليلة واحدة.

تنشر GlitchTip رقماً يستحق التخطيط على أساسه: قد تحتاج نسخة تتعامل مع مليون حدث شهرياً إلى 30 GB من مساحة القرص. يغطي ذلك شهراً واحداً من استقبال البيانات بهذا المعدل، بينما تحدد فترة الاحتفاظ عدد الأشهر التي تخزنها في الوقت نفسه.

تتعامل 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 أحجام وحدات التخزين، بحيث يمكنك معرفة الخدمة التي تنمو بياناتها. إذا زاد حجم وحدة تخزين عدة غيغابايت أسبوعياً من دون تغير في حركة الشبكة، فهذا يعني عادةً أن الاحتفاظ لم يُضبط قط، ولذلك لا تُحذف أي بيانات ويصبح القسم هو الحد الوحيد.

الذاكرة هي المشكلة نفسها بشكل مختلف. ستستهلك حزمة بلا حدود كل ما يتيحه kernel، وعندما تنفد الذاكرة من الجهاز، يختار OOM killer أكبر عملية، وقد تكون web server لديك بدلاً من المتتبّع الذي تسبب في المشكلة. ضع حداً أعلى لكل خدمة: يوضح حدود الذاكرة في Docker Compose الصياغة وما يحدث للحاوية عند بلوغها الحد. إيقاف حاوية بسبب بلوغ حدها الخاص هو فشل محصور. أما إيقاف kernel للحاوية، فيؤدي إلى إيقاف خدمة مجاورة معها.

ما الحزمة المناسبة لكل VPS

• 1 GB، أو 2 GB مع هامش كافٍ: شغّل GlitchTip في وضع الكل في واحد مع إيقاف Valkey، أو Bugsink باستخدام SQLite. كلا الخيارين يعمل براحة على هذه الموارد مع عدد قليل من التطبيقات.
• 4 GB: استخدم Bugsink مع PostgreSQL، أو GlitchTip مع تشغيل Valkey وخدمة worker منفصلة. عند هذا الحجم، يمكنك التوقف عن ضبط الإعدادات الدقيقة وتشغيل الخدمة مباشرة.
• 8 GB: لا تزال هذه الموارد أقل من متطلبات حزمة Sentry الرسمية. خصّصها لفترة احتفاظ أطول ومساحة قرص أكبر، أيّاً كان الخيار الخفيف الذي اخترته.
• 16 GB كحد أدنى، و32 GB موصى بها: استخدم حزمة Sentry الرسمية ذاتية الاستضافة، وفقط عندما تحتاج إلى ميزة في Sentry لا تنفذها المشاريع الأخف. تحقّق أولاً من الميزة المحددة في وثائق كل مشروع، لأن المشاريع المتوافقة تغطي الميزات الشائعة.

أياً كان ما تشغّله، لا يستطيع متتبّع الأخطاء الإبلاغ عن توقفه هو نفسه. أضف فحصاً له من جهاز مختلف: سيخبرك Uptime Kuma من جهاز آخر بأن المتتبّع متوقف، وهي اللحظة نفسها التي يبدأ فيها تطبيقك بإلقاء أخطاء لا يسجّلها أحد.

عندما تكون الخطة المُدارة هي الخيار الأرخص

تكون الاستضافة الذاتية لأداة تتبّع الأخطاء مجدية عندما تفرض قواعد إقامة البيانات تشغيلها داخلياً، أو عندما يكون حجم الأحداث كبيراً بما يكفي لتصبح تكلفة كل حدث عبئاً. خارج هاتين الحالتين، احسب التكلفة بصدق. الحد الأدنى الموثّق لـSentry هو خادم بسعة 16 GB و4 أنوية وقرص سريع، والخادم الافتراضي الخاص بهذا الحجم ليس رخيصاً. ثم أضف العمل التشغيلي: تجاوز كل نقطة توقف صعبة بالترتيب، وإنشاء لقطة قبل كل عملية ترحيل، عدة مرات في السنة.

تغيّر GlitchTip وBugsink هذه المعادلة بالكامل، لأن 512 MB إلى 4 GB تكفي لخادم غير مكلف، كما أن الترقية هي docker compose pull. لذلك ينتهي معظم من يطرحون هذا السؤال باستخدام أحد المشاريع المتوافقة بدلاً من الحزمة الرسمية. هم أرادوا تتبّع الأخطاء، لا خط أنابيب بيانات موزعاً يحتاج إلى مراقبة مستمرة.

إذا كنت لا تزال تحدد ما ينبغي وضعه على الخادم أصلاً، فإن القائمة الأوسع لما يستحق الاستضافة الذاتية تضع تتبّع الأخطاء بجانب الخدمات الأخرى التي تتنافس على ذاكرة RAM نفسها.

FAQ

هل يمكنني استضافة Sentry ذاتياً على VPS بسعة 2 GB؟

لا. تذكر وثائق Sentry للاستضافة الذاتية حدّاً أدنى قدره 4 أنوية CPU، و16 GB من RAM، إضافة إلى 16 GB من swap، و20 GB من مساحة القرص الحرة. تشغّل الحزمة Postgres وClickHouse وKafka وRedis وعدة عمليات عامل في الوقت نفسه، لذلك يقتل kernel الحاويات على خادم صغير قبل اكتمال التثبيت. أكّد ذلك باستخدام dmesg -T | grep -i 'out of memory'، الذي يطبع سطراً يذكر اسم العملية التي قُتلت. استخدم GlitchTip على VPS بسعة 2 GB، إذ توثّق حاجته إلى 512 MB، أو استخدم Bugsink، الذي يعمل كحاوية واحدة مع SQLite.

هل يجب أن أغيّر شيفرة تطبيقي للانتقال من Sentry إلى GlitchTip أو Bugsink؟

لا. يقبل كلاهما الأحداث من SDKs مفتوحة المصدر الخاصة بـSentry، لذلك تحتفظ بـSDK المثبّت لديك وتغيّر قيمة واحدة: DSN، وهو عنوان URL الذي يرسل إليه SDK الأحداث. انقل هذه القيمة إلى متغير بيئة إذا كانت لا تزال مضمنة في الشيفرة، ووجّهها إلى الخادم الجديد، ثم ارفع استثناءً تجريبياً وراقب وصوله. إذا لم يظهر شيء، فتحقق من أن معرّف المشروع في DSN يطابق مشروعاً موجوداً على الخادم الجديد، وأن جدارك الناري يسمح للتطبيق بالوصول إلى ذلك المضيف والمنفذ.

ما مقدار مساحة القرص التي تحتاج إليها خدمة تتبّع الأخطاء المستضافة ذاتياً؟

يعتمد ذلك على حجم الأحداث وفترة الاحتفاظ بها، لا على الأداة نفسها. تنشر GlitchTip رقماً قدره 30 GB لمثيل يعالج مليون حدث شهرياً. يتيح لك Bugsink تحديد الميزانية مباشرة باستخدام MAX_RETENTION_EVENT_COUNT وMAX_EVENT_AGE_DAYS، لذلك تختار الحد الأقصى، وتتحدد متطلبات القرص بناءً عليه. اضبط سياسة الاحتفاظ في اليوم الأول. ينمو متتبّع بلا سياسة احتفاظ حتى يقرأ df -h القيمة 100%، وعندها يتوقف إدخال الأحداث وتفقد الأخطاء التي كنت تحتاج إلى رؤيتها أكثر من غيرها.

لماذا يستمر فشل ترقية Sentry المستضاف ذاتياً؟

لأن الترقية تجاوزت نقطة توقف إلزامية. يحدد Sentry المستضاف ذاتياً إصدارات معينة تتضمن ترحيلات قاعدة البيانات التي يجب المرور بها، واعتباراً من August 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. يؤدي الانتقال مباشرة من إصدار قديم إلى أحدث إصدار إلى تجاوز هذه الترحيلات، لذلك لا يتوافق المخطط مع الشيفرة وتتوقف الترقية في منتصفها. انتقل إلى كل نقطة توقف إلزامية بالترتيب وشغّل ./install.sh عند كل نقطة، وأنشئ snapshot للخادم قبل البدء، واقرأ القائمة الموثقة بالإصدارات التي يجب تجنبها، ومنها 23.7.0 و25.9.0 و25.12.0.