لماذا تستضيف Uptime Kuma ذاتيًا على خادم افتراضي VPS
غالبًا ما تفرض خدمات المراقبة بنظام SaaS رسومها بحسب عدد المراقبات أو تواتر الفحص، وتحدّ الفاصل الزمني عند دقيقة واحدة أو 5 دقائق في العروض المجانية. بنشر Uptime Kuma على خادمك الافتراضي VPS الخاص، يمكنك مراقبة عدد غير محدود من المواقع وواجهات API ومنافذ TCP وحاويات Docker أو خوادم DNS، بفواصل زمنية قصيرة تصل إلى 20 ثانية. استضافة المسبار على خادم VPS منفصل عن خوادم الإنتاج لديك تمثّل ميزة: إذا توقّف خادم التطبيقات، يبقى خادم المراقبة قائمًا ويطلق التنبيه. كما يوفّر Uptime Kuma صفحة حالة عامة يمكنك إتاحتها لعملائك، وأكثر من 90 قناة إشعار (Telegram، البريد الإلكتروني، Discord، webhook). يبقى كل شيء ضمن بنيتك التحتية، دون إرسال روابط URL الداخلية إلى طرف ثالث.
الفوائد الملموسة لهذا القالب
- مراقبات غير محدودة: HTTP(s)، TCP، ping، DNS، حاويات Docker، شهادات SSL وكلمات مفتاحية للصفحات.
- تنبيهات متعددة القنوات (Telegram، البريد الإلكتروني، Discord، Slack، webhook) مع أكثر من 90 تكاملًا.
- صفحة حالة عامة قابلة للتخصيص لمشاركتها مع عملائك أو فريقك.
- مراقبة انتهاء صلاحية شهادات SSL حتى لا تُفاجأ مجددًا.
- سجل وإحصاءات التوفّر محفوظة محليًا، دون احتفاظ مدفوع.
- فحوصات تصل إلى كل 20 ثانية، وهو أمر متعذّر في معظم العروض المجانية.
المتطلبات اللازمة لاستضافتها
Uptime Kuma اقتصادية جدًا: يكفي خادم VPS بمعالج vCPU واحد وذاكرة RAM من 512 ميغابايت إلى 1 غيغابايت لمراقبة عشرات المراقبات. تشغل قاعدة بيانات SQLite المدمجة مساحة قليلة، فاحسب من 2 إلى 5 غيغابايت من القرص حسب السجل المحتفظ به. تحتاج إلى تثبيت Docker، واسم نطاق أو نطاق فرعي (status.mydomain.com) موجَّه إلى الخادم VPS، والمنفذين 80/443 مفتوحين للوكيل العكسي و SSL. لمراقبة موثوقة، يُفضَّل استضافة Uptime Kuma على خادم VPS منفصل عن خوادم الإنتاج لديك.
نشر Uptime Kuma باستخدام Docker و SSL
إنشاء وحدة التخزين وتشغيل الحاوية
على خادم VPS، أنشئ وحدة تخزين دائمة ثم شغّل الحاوية:
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1. تكون الواجهة متاحة على المنفذ 3001.إعداد حساب المسؤول
افتح
http://IP_DU_VPS:3001وأنشئ حساب المسؤول عند أول تسجيل دخول. اختر كلمة مرور قوية: ستمتلك هذه الواجهة صلاحية الوصول إلى جميع روابط URL التي تراقبها.وضع وكيل عكسي و SSL في المقدمة
قم بإعداد Nginx أو Caddy لإتاحة
status.mydomain.comنحوlocalhost:3001. مع Caddy، يكفي سطران للحصول على شهادة Let's Encrypt تلقائية:status.mydomain.com { reverse_proxy localhost:3001 }.إضافة مراقباتك الأولى
أنشئ مراقبات HTTP(s) لمواقعك، ومراقبة TCP لقاعدة بياناتك، وفحص SSL لمراقبة انتهاء صلاحية الشهادات، وكلمة مفتاحية لاكتشاف صفحات الخطأ التي تُقدَّم برمز HTTP 200.
ربط الإشعارات وصفحة الحالة
في الإعدادات > الإشعارات، أضف Telegram أو البريد الإلكتروني واختبر الإرسال. ثم فعّل صفحة حالة عامة تجمع خدمات عملائك، مع اسم نطاق مخصّص عند الحاجة.
أول تسجيل دخول
افتح الرابط دون تأخير: تطلب منك الشاشة الأولى إنشاء حساب المدير (اسم مستخدم + كلمة مرور)، ثم تصل إلى لوحة التحكم. ولا توجد أي بيانات دخول افتراضية.
لتفادي التنبيهات الكاذبة أثناء حادث شبكي بسيط، اضبط حقل Retries (على سبيل المثال 3 حالات فشل متتالية قبل التنبيه) وقيمة Heartbeat Interval مناسبة. اجمعه مع إشعار جماعي: يستطيع Uptime Kuma إرسال رسالة مجمَّعة بدلًا من تنبيه لكل مراقبة، ما يتجنّب إغراق قناة Telegram الخاصة بك أثناء انقطاع شبكي شامل يُسقط عشر خدمات دفعة واحدة.
ما لا تراه مراقبة Docker
تستعلم مراقبة نوع Docker Container من محرك Docker وتقرأ حالة الحاوية. هذا عملي، لكنّ هذه الحالة تصف العملية لا الخدمة. تعرض مشكلة مفتوحة في مستودع الأداة (#7956، أُبلغ عنها في الإصدار 1.23.17) حالة واضحة: حاوية أُطلقت بسياسة إعادة تشغيل (restart: always أو unless-stopped أو الخيار --restart=always في أمر النشر أعلاه) وتتعطل في حلقة متكررة تظهر بحالة UP مع الرسالة «restarting». يربط صاحب البلاغ هذا السلوك بفحص State.Running الذي يبقى صحيحًا خلال المهلة بين إعادتي تشغيل. تبقى المراقبة خضراء، ولا يُرسل أي إشعار، بينما لا يستجيب تطبيقك. عند إعادة قراءة النقاش كانت المشكلة ما زالت مفتوحة دون إصلاح مدمج: لا توجد فيها سوى تصحيحات مقترحة. تجيب مراقبة Docker عن سؤال «هل الحاوية قيد التشغيل؟» لا عن سؤال «هل يخدم التطبيق مستخدميه كما يجب؟».
لماذا لا تكفي إشارة واحدة
- العملية تعمل والخدمة لا تعمل — قد تبدأ الحاوية ثم تتعطل بعد ثانيتين وتعيد التشغيل: ففي كل استعلام قد يصفها محرك Docker بأنها قيد التشغيل.
- بلا healthcheck لا يوجد حكم — من دون تعليمة
HEALTHCHECKفي الصورة أو كتلةhealthcheckفي ملف compose لديك، لا يملك المحرك سوى الحالة الخام ليمررها إلى Uptime Kuma. - حالة unhealthy لا تنبّه في كل مكان — بحسب نقاش المشكلة، دُمج اعتبار حالة «unhealthy» حالة DOWN في فرع 2.1.0 (طلب الدمج #6292)، بينما يترك فرع 1.x هذه الحالة معلّقة (PENDING) أي دون تنبيه. ويستخدم النشر أعلاه الصورة
louislam/uptime-kuma:1. - سياسة إعادة التشغيل تُخفي العطل — يساعد
restart: alwaysعلى التعافي من حادث معزول، لكنه يحوّل العطل الصريح إلى عطل متقطع لا تلتقطه الاستعلامات المتباعدة. - قد تكون لأداة المراقبة نقاط عمياء خاصة بها — ميزة تعمل شهرًا قد تتراجع في التحديث التالي: تحقق من تنبيهاتك باختبار حقيقي لا بقراءة الواجهة فقط.
استكمال مراقبة Docker بعدة إشارات
مراقبة التطبيق نفسه
أضف مراقبة HTTP(s)، أو «HTTP(s) - Keyword» إذا كان يجب أن تحتوي الصفحة على كلمة محددة، على رابط التطبيق (العام أو الداخلي للخادم VPS). الحاوية العالقة في حلقة تعطل لا تستجيب: تفشل هذه المراقبة بينما تبقى مراقبة Docker خضراء. أبقِ Retries عند 3 لتفادي التنبيهات الكاذبة.
تعريف healthcheck في ملف compose
في الخدمة المراقبة، أضف مثلًا
healthcheck: test: ["CMD-SHELL", "wget -q --spider http://localhost:3000/ || exit 1"]معinterval: 10sوtimeout: 3sوretries: 3وstart_period: 30s. عدّل المنفذ والأداة: يجب أن تحتوي الصورة علىwgetأوcurl. يعرض Docker عندئذ حالة healthy أو unhealthy، وتقرؤها فيdocker ps.قراءة عدّاد إعادة التشغيل
على الخادم VPS، يسرد الأمر
docker ps --filter status=restartingالحاويات التي تعيد التشغيل، ويعطي الأمرdocker inspect mon-app | grep -E "RestartCount|Status"عدد مرات إعادة التشغيل والحالة. ارتفاعRestartCountمن فحص إلى آخر يدل على حلقة، حتى لو كانت الحالة المعروضة running.إرسال نبضة بمراقبة Push
أنشئ في Uptime Kuma مراقبة من نوع Push، ثم شغّل عبر cron على الخادم VPS سكربتًا صغيرًا يقرأ
RestartCountولا يستدعي رابط Push إلا إذا لم يتغير منذ الفحص السابق. إذا ارتفع العدّاد تغيب النبضة وتنتقل المراقبة إلى DOWN: يستند التنبيه إلى معطى لا تنظر إليه مراقبة Docker.اختبار سلسلة التنبيه فعليًا
شغّل حاوية تتعطل عمدًا:
docker run -d --name crash-test --restart unless-stopped alpine sh -c "sleep 2; exit 1". أنشئ مراقبة Docker علىcrash-test: إذا بقيت UP بينما يسردها الأمرdocker ps --filter status=restartingفأنت تعيد إنتاج الحالة الموصوفة في المشكلة. تحقق من أن مراقبة HTTP أو Push تطلق الإشعار فعلًا، ثم احذف الحاوية بالأمرdocker rm -f crash-test.
إعادة المحاولة في مراقبة TCP: حالة صُحّحت، تحقق منها في إصدارك
تناولت مشكلة ثانية (#7979) حقل Retries. في الإصدار 2.5.6 كانت مراقبة TCP Port المضبوطة على SSL أو StartTLS تتجاهل هذا الإعداد: عند أول فشل تنتقل مباشرة إلى الأحمر، بينما تنتقل مراقبات HTTP(s) ذات عدد المحاولات نفسه إلى حالة الانتظار أولًا. الحالة أضيق مما يوحي به العنوان: فهي تخص صيغة TCP مع TLS لا كل مراقبات TCP. أُغلقت المشكلة بإصلاح طلب الدمج #7989 الذي تدرجه ملاحظات الإصدار 2.5.7. إذا كنت تراقب منفذ TLS (بريد أو XMPP أو قاعدة بيانات مشفّرة) بإصدار أقدم، فستصلك تنبيهات عند كل فشل معزول. حدّث الأداة ثم تحقق من السلوك بإيقاف الخدمة المختبرة: يجب أن تنتقل المراقبة إلى الانتظار قبل أن تسقط. وهناك توضيح آخر من النقاش: حقل Down Count عدّاد مرتبط بإعادة إرسال الإشعارات، وليس عدّاد محاولات.
تنبيه واحد، عدة إشارات
اربط مراقبة HTTP ومراقبة Push ومراقبة Docker بإشعار المجموعة نفسه، واحتفظ برسالة الطوارئ للإشارة الخاصة بالتطبيق: الصفحة التي لا تستجيب عطل، أما ارتفاع RestartCount فتحذير يُعالج خلال ساعة. وهكذا لا يترك فشل مراقبة واحدة قناة Telegram الخاصة بك صامتة.
الوثائق الرسمية
للإعداد المتقدّم والخيارات الخاصة بالأداة، ارجع إلى الوثائق الرسمية لـ Uptime Kuma. يغطّي هذا الدليل النشر على خادم VPS؛ وتبقى وثائق الناشر المرجع للضبط الدقيق والتحديثات الكبرى وحالات الاستخدام الخاصة.
