Opsgenie وGrafana OnCall: ركيزتان تتلاشيان
استحوذت Atlassian على Opsgenie عام 2018 ودمجته تدريجياً في مجموعة Jira. نُشر إعلان نهاية دورة الحياة على صفحة الحالة الرسمية لـ Atlassian: يتوقف الخدمة في 5 أبريل 2027. يتوفر لدى المستخدمين أكثر من عام قليلاً لترحيل سياسات الاستنفار وعمليات التكامل وسجلات الحوادث. من جهة أخرى، أُرشف مستودع Grafana OnCall OSS على GitHub في 24 مارس 2026. أعلن فريق Grafana Labs أن النسخة السحابية لا تزال متاحة، لكن مستودع الاستضافة الذاتية لم يعد يتلقى تصحيحات أو ميزات جديدة. تتقارب هذا الحدثان في أقل من اثني عشر شهراً مما يفرض نافذة ترحيل ينبغي للفرق التخطيط لها الآن بدلاً من انتظار ضغط الأسابيع الأخيرة قبل موعد أبريل 2027.
ما يجب أن تغطيه حل إدارة الحوادث
- استقبال التنبيهات وإزالة تكرارها من Prometheus وGrafana وZabbix أو أي webhook HTTP
- توجيه التنبيهات إلى الفرق المناسبة وفق قواعد قابلة للتهيئة (الخطورة، الخدمة، الجدول الزمني)
- إدارة جداول الاستنفار مع دورات أسبوعية أو مخصصة
- التصعيد التلقائي إذا لم يُقرَّ التنبيه في الوقت المحدد
- إشعارات متعددة القنوات: بريد إلكتروني، رسائل SMS، مكالمات صوتية، Slack، Microsoft Teams
- صفحة حالة عامة لإبقاء المستخدمين على اطلاع في الوقت الفعلي
- سجل حوادث قابل للبحث والتصدير لمراجعات ما بعد الحادثة
- واجهة REST API للتكامل مع مسارات CI/CD وأدوات الأتمتة
OneUptime مقابل IncidentRelay مقابل PagerDuty
مرّر الجدول أفقيًا
| المعيار | OneUptime | IncidentRelay | PagerDuty (SaaS) |
|---|---|---|---|
| الرخصة | Apache 2.0 | MIT | ملكية خاصة |
| الاستضافة | استضافة ذاتية (Docker Compose) | استضافة ذاتية (Docker Compose) | سحابي فقط |
| التقنية المستخدمة | Node.js / TypeScript, PostgreSQL | Go, SQLite/PostgreSQL | غير مُفصح عنها |
| الحد الأدنى من RAM الموصى به | 4 GB (إنتاج خفيف)، 8 GB مُوصى به | 512 MB (SQLite)، 2 GB (PostgreSQL) | غير مُطبَّق |
| صفحة حالة مدمجة | نعم، عامة وقابلة للتخصيص | نعم، أساسية | نعم، عبر Statuspage (مدفوع منفصل) |
| السعر الأساسي | مجاني (استضافة ذاتية) | مجاني (استضافة ذاتية) | يبدأ من 21 دولار/مستخدم/شهر |
متطلبات VPS لـ OneUptime
يعتمد OneUptime على بنية متعددة الحاويات مُنسَّقة بواسطة Docker Compose. للفرق التي تضم أقل من عشرين شخصاً مع حجم تنبيهات معتدل (أقل من ألف حدث يومياً)، يُعدّ VPS بـ 4 vCPU و8 GB من RAM أساساً مناسباً. تحت 4 GB من RAM تتنافس عدة حاويات عند الإقلاع مما يُسبب إعادات تشغيل متكررة. يجب أن يكون التخزين على قرص SSD، إذ يكتب OneUptime بتكرار في PostgreSQL وفي ناقل أحداثه الداخلي. احتسب 40 GB على الأقل للسجلات وقاعدة البيانات لمدة ستة أشهر. يجب أن يكشف الخادم المنفذين 80 و443؛ يمكن وضع وكيل عكسي nginx أو Caddy أمامه إذا كان VPS يستضيف خدمات أخرى. مطلوب Docker Engine الإصدار 24 أو أعلى وDocker Compose الإصدار 2.20 أو أعلى. عنوان IP ثابت واسم نطاق مع سجل DNS A ضروريان لشهادة TLS ولكي تكون webhooks الواردة قابلة للوصول.
نشر OneUptime على VPS في 7 خطوات
اتصل بالـ VPS عبر SSH وثبّت Docker Engine وDocker Compose v2 من المستودع الرسمي لـ Docker:
curl -fsSL https://get.docker.com | sh، ثم تحقق من النجاح بالأمرdocker compose version.استنسخ مستودع OneUptime:
git clone https://github.com/OneUptime/oneuptime.git ثم ادخل إلى الدليلcd oneuptime.انسخ ملف الإعداد النموذجي:
cp .env.example .env ثم افتحه في محرر نصوص. أدخل على الأقلDOMAIN (نطاقك أو نطاقك الفرعي) وDISABLE_TELEMETRY=true إذا لم ترغب في إرسال بيانات الاستخدام، ومتغيرات SMTP (SMTP_HOST وSMTP_PORT وSMTP_USERNAME وSMTP_PASSWORD وSMTP_FROM_EMAIL) لإشعارات البريد الإلكتروني.شغّل الحاويات في الخلفية:
docker compose up -d. عند الإقلاع الأول تُحمَّل الصور وتُنفَّذ ترحيلات قاعدة البيانات؛ اترك ثلاث إلى خمس دقائق بحسب النطاق الترددي.تحقق من أن جميع الخدمات تعمل بشكل سليم:
docker compose ps. يجب أن تُظهر حاوياتoneuptime-app وoneuptime-worker وoneuptime-postgres وoneuptime-redis الحالةrunning. عند حدوث خطأ في حاوية ما، راجع سجلاتها بـdocker compose logs <اسم-الحاوية> --tail=100.افتح المتصفح على
https://نطاقك وأنشئ حساب المسؤول الأولي. ثم انتقل إلى *Settings → On-Call Duty → Policies* لإنشاء سياستك الأولى: حدد الفريق والنوافذ الزمنية وقنوات الإشعار.فعّل التحديث التلقائي للصور باستخدام Watchtower، أو جدوِل أمر
docker compose pull && docker compose up -d أسبوعياً عبر cron لجلب تصحيحات الأمان دون انقطاع مطوّل.
ضبط التنبيهات: webhook Prometheus إلى OneUptime
يكشف OneUptime نقطة نهاية webhook واردة لكل مراقب أو تكامل يُنشأ. في الواجهة، اذهب إلى *Integrations → Incoming Webhooks* وأنشئ تكاملاً جديداً من نوع Prometheus Alertmanager. تُنتج الواجهة رابطاً بالشكل https://نطاقك/api/v1/incoming-request/<uuid>. في إعداد Alertmanager في Prometheus، أضف متلقياً من نوع webhook يشير إلى هذا الرابط. يتيح الحقل send_resolved: true لـ OneUptime إغلاق الحادثة تلقائياً عندما يُرسل Alertmanager إشعار الحل. للتكامل من Grafana، استخدم نوع الاتصال *Webhook* وأدخل نفس الرابط. يحلل OneUptime JSON الوارد ويستخرج تلقائياً العنوان والخطورة وعلامات تنبيه Prometheus. إذا أرسلت تنبيهات من أداة مخصصة، فإن التنسيق المطلوب موثق في صفحة التكامل: حقل title وحقل description كافيان لإنشاء حادثة.
إدارة جداول الاستنفار والتصعيد
تحدد جداول الاستنفار (On-Call Schedules) في OneUptime من يكون متاحاً، في أي وقت، ولأي خدمة. يرتبط الجدول بطبقة أو أكثر: كل طبقة تمثل دورة فريق. يمكن أن تكون الدورة يومية أو أسبوعية أو على فترة مخصصة. يستطيع كل عضو في الفريق تعيين تفضيلات الإشعار في ملفه الشخصي: بريد إلكتروني فوري، رسالة SMS بعد دقيقتين، مكالمة صوتية إذا لم يُقرَّ الحادث بعد خمس دقائق. يُهيَّأ التصعيد في سياسات التنبيه (Alert Policies): إذا لم يستجب شخص الاستنفار في المستوى 1 خلال النافذة المحددة، تصعد التنبيه تلقائياً إلى المستوى 2 الذي قد يكون شخصاً آخر أو فريقاً مختلفاً أو قناة Slack مشتركة. تسلسل التصعيد هذا مرئي في سجل كل حادثة مما يسهّل مراجعات ما بعد الحادثة.
كشف صفحة الحالة خلف nginx
يُنشئ OneUptime صفحة حالة عامة قابلة للوصول على نطاق فرعي مخصص، مثل status.نطاقك.com. لكشفها بشكل نظيف خلف nginx كوكيل عكسي، أنشئ vhost يُحيل الطلبات إلى المنفذ الداخلي 3105 الذي تستخدمه حاوية صفحة الحالة: proxy_pass http://127.0.0.1:3105;. فعّل رأس X-Forwarded-Proto ليُنشئ OneUptime روابط HTTPS صحيحة في الإشعارات. يمكن الحصول على شهادة TLS عبر Certbot مع إضافة nginx: certbot --nginx -d status.نطاقك.com. تتيح صفحة الحالة للعملاء متابعة حالة الخدمات في الوقت الفعلي دون الوصول إلى واجهة الإدارة.
استكشاف الأخطاء — مشاكل شائعة عند الإقلاع
أكثر مشكلة شيوعاً عند الإقلاع الأول هي حاوية PostgreSQL غير جاهزة قبل أن تحاول الحاوية التطبيقية الاتصال بها. يتضمن OneUptime توجيهات healthcheck في ملف docker-compose.yml الرسمي؛ إذا استخدمت نسخة معدّلة، تأكد من أن الخدمة app تحتوي على إدخال depends_on بالشرط service_healthy على خدمة postgres. مشكلة ثانية شائعة تتعلق بمتغيرات SMTP: إذا لم تُرسَل رسائل التحقق من الحساب، تحقق من أن SMTP_PORT يساوي 587 (STARTTLS) وليس 465 (SSL مباشر) إذا كان مزود SMTP يتطلب ذلك. لتشخيص الأخطاء الصامتة، راقب سجلات العامل في الوقت الفعلي بـ docker compose logs -f oneuptime-worker. أخيراً، إذا كان المنفذ 443 محتلاً بخدمة أخرى، سيُقلع OneUptime لكنه سيكون غير قابل للوصول: عدّل تعيين المنفذ في docker-compose.yml أو أوقف الخدمة المنافسة قبل تشغيل الحزمة.
التخطيط للترحيل من Opsgenie إلى OneUptime قبل أبريل 2027
يتيح Opsgenie تصدير سياسات التنبيه وجداول الاستنفار وسجل الحوادث بتنسيق JSON أو CSV من *Settings → Export*. تحتوي هذه الصادرات على قواعد التوجيه وأعضاء الفرق وعمليات التكامل النشطة. الاستيراد إلى OneUptime ليس تلقائياً: يجب إعادة إنشاء السياسات يدوياً أو عبر OneUptime REST API باستخدام البيانات المُصدَّرة. البدء بعمليات التكامل الحرجة (Prometheus وGrafana وDatadog) ثم الانتقال إلى جداول الاستنفار وأخيراً الإشعارات الثانوية هو النهج الموصى به. خطط لفترة تشغيل موازٍ لمدة أسبوعين على الأقل: يتلقى كلا النظامين نفس التنبيهات بينما تتحقق الفرق من السياسات الجديدة. يترك موعد 5 أبريل 2027 وقتاً كافياً لترحيل منظم إذا بدأ قبل يناير 2027. انتظار الأسابيع الأخيرة يُعرّض الفرق لتحول قسري دون إمكانية التراجع إذا فاتت أي عملية تكامل.
