Uptime Kuma أداة مراقبة مفتوحة المصدر تستضيفها بنفسك، وتدعم فحوصات HTTP(S) وTCP وping وDNS وWebSocket وغيرها. وعند تشغيلها على خادم VPS منفصل، تواصل الفحص عند تعطل خادم الإنتاج بدلاً من أن تتعطل معه.
يعتمد إعداد Uptime Kuma هذا على نشر الإصدار v2 عبر Docker Compose، مع إبقاء المنفذ 3001 على العنوان المحلي، وإضافة HTTPS من خلال Caddy، وتوجيه التنبيهات إلى Telegram وDiscord وSlack، ونشر صفحة حالة.
المتطلبات المسبقة وما ستحتاج إليه
- خادم VPS بمواصفات لا تقل عن 1 vCPU و1 غيغابايت من الذاكرة و10 غيغابايت من تخزين SSD المحلي
- Ubuntu 24.04 LTS أو إصدار حديث آخر من Ubuntu يدعمه Docker
- Docker Engine وDocker Compose مثبَّتان على الخادم
- نطاق أو نطاق فرعي يشير إلى الخادم عبر سجل A (مثل status.example.com)
- وصول عبر SSH وإلمام أساسي بسطر الأوامر
إذا لم يكن Docker مثبَّتاً بعد، فاتبع دليل تثبيت Docker على Ubuntu. فهو يثبّت Docker Engine وإضافة Compose المستخدمة أدناه.
لماذا يجب فصل خادم المراقبة عن الأنظمة التي يراقبها
عندما يعمل الإنتاج والمراقبة على الخادم نفسه، فإنهما يتشاركان نطاق الأعطال ذاته. وإذا توقف ذلك الخادم، يختفي التطبيق والنظام المسؤول عن إرسال التنبيه معاً.
هناك تصميمان عمليان يحسّنان هذا الوضع:
- المزوّد نفسه، موقع مختلف. ضع الإنتاج والمراقبة على مضيفين منفصلين في موقعين مختلفين. يقلّل هذا من التعرّض لعطل خادم واحد أو مركز بيانات واحد، لكنه لا يحمي من كل حوادث الشبكة أو مستوى التحكّم التي تصيب المزوّد بأكمله.
- مزوّد مختلف تماماً. استضافة أداة المراقبة في مكان آخر تضيف حماية من الحوادث التي تصيب المزوّد بأكمله. والمقابل هو حساب وفاتورة وسطح تشغيلي إضافي عليك إدارته.
تبقى نسخة Uptime Kuma الواحدة بلا رقيب خارجي. أضف فحص HTTP(S) خارجياً واحداً لصفحة الحالة العامة الخاصة بها. الخطة المجانية من UptimeRobot تتضمن حالياً 50 عملية مراقبة بفواصل زمنية مدتها خمس دقائق. لن يجعل هذا Uptime Kuma عالي التوافر، لكنه سيخبرك عندما تختفي أداة المراقبة نفسها.
تنطبق القاعدة نفسها على صفحات الحالة العامة: ما يخبرك بالعطل يجب ألا يتشارك نطاق الأعطال مع ما يتعطل.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxتحديد حجم الخادم
لا توجد في Uptime Kuma معادلة موثوقة تربط عدد عمليات المراقبة بحجم الذاكرة، لأن الحِمل يتغيّر بحسب نوع المراقبة والفاصل الزمني وإعدادات إعادة المحاولة ومدة الاحتفاظ بالسجل. الفحوصات البسيطة عبر HTTP(S) وTCP وping وDNS أخف من فحوصات Browser Engine التي تشغّل Chromium.
لمجموعة صغيرة من الفحوصات الأساسية، ابدأ بـ 1 vCPU و1 غيغابايت من الذاكرة وتخزين SSD محلي. راقب الاستهلاك الفعلي عبر docker stats uptime-kuma ونمو قاعدة البيانات عبر du -sh /opt/uptime-kuma/data. أضف ذاكرة عندما يبقى الاستهلاك مرتفعاً، أو عندما تُبلّغ الحاوية عن إنهاء بسبب نفاد الذاكرة (OOM kill)، أو عندما تبدأ باستخدام فحوصات Browser Engine.
تتضمن صورة v2 الكاملة كلاً من Chromium وقاعدة MariaDB المدمجة؛ ويوضح توثيق وسوم Docker الفرق بين صورتَي full وslim.
نشر Uptime Kuma باستخدام Docker Compose
احفظ هذا الملف باسم docker-compose.yml داخل /opt/uptime-kuma/:
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
# Bind to localhost only. The reverse proxy will expose it on 443.
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
ثلاثة أسطر تستحق التوقف عندها:
- image: louislam/uptime-kuma:2 يثبّت الإصدار الرئيسي. والوسم :2 يتتبّع خط الإصدارات المستقر 2.x. لا تستخدم :latest.
- 127.0.0.1:3001:3001 يربط الحاوية بـ localhost فقط. يجب ألا تصل الإنترنت العامة إلى المنفذ 3001 مباشرةً أبداً. فالوكيل العكسي هو من يحمل شهادة TLS واسم المضيف العام.
- يحتوي وحدة تخزين البيانات على قاعدة البيانات وإعدادات المراقبة والسجل. أبقِها على تخزين محلي، لأن توثيق تثبيت Uptime Kuma يحذّر من أن أنظمة الملفات التي تفتقر إلى قفل POSIX موثوق، ومنها كثير من إعدادات NFS، قد تُتلف SQLite. أوقف المنظومة قبل أخذ نسخة على مستوى نظام الملفات.
شغّلها ثم تحقّق:
sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps
المخرجات المتوقعة من docker compose ps:
NAME IMAGE STATUS PORTS
uptime-kuma louislam/uptime-kuma:2 Up (healthy) 127.0.0.1:3001->3001/tcp
للوصول إلى لوحة التحكم لأول مرة، لا تفتح المنفذ 3001 للإنترنت العامة، ولو للحظة. استخدم نفق SSH:
ssh -L 3001:127.0.0.1:3001 [email protected]
افتح http://localhost:3001 في متصفحك، وأنشئ حساب المدير، وعيّن كلمة مرور قوية، ثم أغلق النفق. من الآن فصاعداً تصلك لوحة التحكم عبر HTTPS من خلال الوكيل العكسي.
إذا لم تكن بحاجة إلى إعداد Compose يدوياً، فنحن نوفّر أيضاً Uptime Kuma كتطبيق بنقرة واحدة. تشير صفحة التطبيق الحالية إلى الإصدار v1، لذا فهي لا تطابق إعداد v2 الوارد في هذا الدليل. استخدم مسار Compose اليدوي إذا كنت تحتاج تحديداً إلى v2.
الوكيل العكسي وTLS
لا تعرّض Uptime Kuma مباشرةً. ضع أمامه وكيلاً عكسياً من أجل TLS ومعالجة سليمة للعناوين ونقطة دخول عامة واحدة. أمامك مساران.
Caddy. إذا لم يكن Caddy مثبَّتاً بعد، فاتبع خطوات حزمته الرسمية لـ Ubuntu. وعند تشغيل Caddy كخدمة على المضيف، يوجّه ملف Caddyfile أدناه الطلبات إلى Uptime Kuma عبر العنوان المحلي، ويتولى إصدار الشهادة وتجديدها تلقائياً.
نصيحة: عندما لا يستضيف خادم المراقبة سوى Uptime Kuma، استخدم Caddy. فملف Caddyfile من ثلاثة أسطر، ويتولى Caddy إصدار الشهادة وتجديدها تلقائياً. لا Certbot ولا مؤقت تجديد منفصل تسهر عليه في الرابعة فجراً.
احفظ هذا في /etc/caddy/Caddyfile:
status.example.com {
reverse_proxy 127.0.0.1:3001
}
أعد تحميل Caddy:
sudo systemctl reload caddy
تحقّق:
curl -I https://status.example.com
يُفترض أن تحصل على استجابة ناجحة 2xx أو 3xx مع شهادة صالحة. وإذا فشل الاتصال، فتأكد من أن سجل A أو AAAA للنطاق يشير إلى هذا الخادم، وأن المنفذين 80 و443 قابلان للوصول، وأن Caddy يستطيع الارتباط بهما. هذه كلها جزء من متطلبات HTTPS التلقائي في Caddy.
Nginx Proxy Manager. إذا كان NPM يعمل مباشرةً على المضيف، فأضف Proxy Host للنطاق status.example.com، ووجّهه إلى 127.0.0.1 على المنفذ 3001، واطلب شهادة Let's Encrypt، وفعّل Websockets Support. أما إذا كان NPM يعمل داخل Docker، فإن 127.0.0.1 يشير إلى حاوية NPM نفسها. في هذه الحالة اربط NPM وUptime Kuma بالشبكة نفسها في Docker، ثم وجّه المضيف الوكيل إلى uptime-kuma على المنفذ 3001.
توجيه التنبيهات: Telegram وDiscord وSlack
يستطيع Uptime Kuma توجيه الحدث نفسه إلى عدة قنوات تنبيه. اضبط كل مزوّد مرة واحدة، ثم اربط قناة أو أكثر بكل عملية مراقبة بحسب من يحتاج إلى التنبيه.
تُضبط التنبيهات بشكل عام من Settings > Notifications، ثم تُسند إلى كل عملية مراقبة على حدة. ويمكن لكل مراقبة أن تُطلق قناة واحدة أو عدة قنوات. فالتنبيه نفسه قد يصل إلى Telegram للمهندس المناوب، وإلى Slack للفريق، وإلى البريد الإلكتروني لسجل التدقيق، كله انطلاقاً من حدث واحد.
Telegram
- في Telegram، راسِل @BotFather ونفّذ الأمر /newbot. اختر اسماً واسم مستخدم. سيردّ BotFather برمز البوت (token). احفظه.
- أرسل أي رسالة إلى البوت الجديد. ثم افتح https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates في المتصفح. ابحث عن الحقل chat.id، فهو معرّف المحادثة الخاص بك.
- في Uptime Kuma: Settings > Notifications > Setup Notification > Telegram. الصق رمز البوت ومعرّف المحادثة. ثم انقر اختبار. وتأكّد من أن البوت يرسل التنبيه التجريبي.
- إذا لم تصل رسالة الاختبار، فتحقّق من صحة رمز البوت ومعرّف المحادثة، وتأكّد من أن جدار حماية الخادم يسمح باتصالات HTTPS الصادرة إلى api.telegram.org.
Discord
- افتح خادم Discord الذي تريد وصول التنبيهات إليه. انقر بزر الفأرة الأيمن على القناة المستهدفة، ثم Edit Channel > Integrations > Webhooks > New Webhook. امنحه اسماً (مثل «Uptime Kuma»)، واختر القناة، وانسخ رابط الويب هوك.
- في Uptime Kuma: Settings > Notifications > Setup Notification > Discord. الصق رابط الويب هوك. ويمكنك اختيارياً ضبط اسم المستخدم والصورة الرمزية.
- انقر على اختبار. وتأكّد من أن الويب هوك ينشر التنبيه التجريبي في القناة.
Slack
- في Slack، أنشئ Incoming Webhook للقناة التي تريد وصول التنبيهات إليها. سيعيد Slack رابط ويب هوك بالصيغة https://hooks.slack.com/services/T.../B.../....
- في Uptime Kuma: Settings > Notifications > Setup Notification > Slack. الصق رابط الويب هوك. ويمكنك اختيارياً ضبط الأيقونة وتجاوز القناة.
- انقر على اختبار.
بعد نجاح كل الاختبارات، حرّر كل عملية مراقبة واختر قنوات التنبيه التي ستستخدمها. واضبط Max Retries (أقصى عدد للمحاولات) و Retry Interval (الفاصل بين المحاولات) بحيث لا يؤدي عطل قصير واحد إلى إطلاق تنبيه فوراً.
صفحة الحالة المدمجة (ومتى ستتجاوز إمكاناتها)
يتضمن Uptime Kuma صفحات حالة عامة مع روابط مخصصة، ومراقبات مجمّعة، ونطاقات خاصة، ومنشورات للأعطال، ورسائل صيانة مجدولة. كما يمكنك نشر عدة صفحات حالة من نسخة واحدة، لخدمات أو جمهور مختلف.
أكبر قيودها يتعلق بالتواصل مع العملاء. فالزوار لا يستطيعون حالياً الاشتراك بالبريد الإلكتروني في التحديثات مباشرةً من صفحة الحالة، كما أن الصفحة العامة تبقى جزءاً من تطبيق Uptime Kuma نفسه الذي يضم لوحة المشغّل. ولا يزال اشتراك الزوار الذاتي مسجَّلاً بوصفه طلب ميزة مفتوحاً.
إذا كنت بحاجة إلى اشتراكات العملاء أو إلى نظام حالة منفصل عن لوحة المراقبة، فإن Kener أحد البدائل. ويشرح دليلنا عن منظومة المراقبة المستضافة ذاتياً كيف يمكن الجمع بين الأداتين.
المشكلات الشائعة
تفشل التنبيهات بصمت عندما يحجب جدار حماية الخادم اتصالات HTTPS الصادرة. العَرَض: زر Test يعمل مع بعض القنوات دون غيرها. الحل: تأكّد من أن اتصالات HTTPS الصادرة مسموح بها وأن الأمر curl -I https://api.telegram.org ينجح من داخل الخادم.
المتصفح يعرض «ERR_TOO_MANY_REDIRECTS» بعد تفعيل الوكيل. ابحث عن عمليات إعادة توجيه مكررة من HTTP إلى HTTPS في Caddy أو Nginx Proxy Manager أو أي شبكة CDN أمامية. ينبغي أن يستمر Uptime Kuma في تقديم HTTP على المنفذ 3001 بينما يتولى الوكيل العكسي العام إنهاء TLS. وإذا فعّلت ترويسات الوكيل الموثوق، فالمسار الحالي هو Settings > Reverse Proxy > HTTP Headers > Trust Proxy.
الحاوية تُعاد تشغيلها كل بضع دقائق. تحقّق مما إذا كانت الحاوية قد أُنهيت بسبب نفاد الذاكرة، ثم راقب استهلاكها الحالي عبر docker stats uptime-kuma. فإذا كانت الحاوية قد قُتلت بسبب OOM أو ظلت الذاكرة قريبة من حد الخادم، فأضف ذاكرة، أو قلّل الفحوصات الثقيلة، أو وسّع الفواصل الزمنية بينها.
صفحة الحالة تعمل على localhost لكنها لا تعمل عبر اسم المضيف العام. تأكّد من أن الوكيل العكسي يمرّر المسار الجذري دون تغيير، ويحافظ على ترويسة Host، ويدعم WebSockets. لا يدعم Uptime Kuma التثبيت تحت مجلد فرعي، لذا استخدم نطاقاً أو نطاقاً فرعياً مخصصاً بدلاً من مسار مثل example.com/uptime-kuma.
الخلاصة
يمنحك تشغيل Uptime Kuma على خادم منفصل تحكماً في الفحوصات وتوجيه التنبيهات وصفحة الحالة العامة، لكنك تتحمّل أيضاً التحديثات والنسخ الاحتياطية وترقيع نظام التشغيل والرقيب الخارجي على أداة المراقبة نفسها. اختر خادماً في موقع مختلف عن الإنتاج، وانشر الإصدار v2 عبر Docker Compose أو استخدم التطبيق بنقرة واحدة بعد التحقق من الإصدار المذكور، وضع Caddy في المقدمة، ثم اربط القنوات التي يتابعها فريقك.
الأسئلة الشائعة
كم من الذاكرة يحتاج Uptime Kuma؟
لا توجد في Uptime Kuma معادلة موثوقة تربط عدد عمليات المراقبة بحجم الذاكرة، لأن الاستهلاك يتغيّر بحسب نوع المراقبة وفاصل الفحص وإعدادات إعادة المحاولة ومدة الاحتفاظ بالسجل واستخدام Browser Engine. لمجموعة صغيرة من الفحوصات الأساسية، ابدأ بـ 1 غيغابايت من الذاكرة وراقب الاستهلاك الفعلي عبر docker stats uptime-kuma. وأضف ذاكرة إذا بقي الاستهلاك قريباً من الحد أو إذا قُتلت الحاوية بسبب OOM.
هل ينبغي تشغيل Uptime Kuma على الخادم نفسه الذي يستضيف تطبيقي؟
لا. إذا تشارك تطبيقك وأداة المراقبة الخادم نفسه، فإن عطل الخادم يوقفهما معاً في اللحظة ذاتها، فتفقد التنبيه في أشد الأوقات حاجةً إليه. شغّل Uptime Kuma على خادم VPS منفصل، ويفضّل أن يكون في مركز بيانات آخر.
هل يستطيع Uptime Kuma إرسال التنبيهات إلى Telegram وDiscord وSlack؟
نعم. فـ Telegram وDiscord وSlack من خدمات التنبيه المدمجة، إلى جانب البريد الإلكتروني والويب هوك العام وPagerDuty وntfy وMattermost وغيرها الكثير. يستخدم Telegram رمز بوت ومعرّف محادثة، بينما يستخدم Discord وSlack روابط ويب هوك. ويمكنك ربط عدة قنوات تنبيه بالمراقبة نفسها.
ما الفرق بين Uptime Kuma وUptimeRobot؟
Uptime Kuma تستضيفه بنفسك، أي أنك تتولى الخادم والتحديثات والنسخ الاحتياطية وتوجيه التنبيهات. وهو يدعم فواصل فحص تصل إلى 20 ثانية. أما UptimeRobot فخدمة SaaS مستضافة، وخطته المجانية الحالية تشمل 50 عملية مراقبة بفحص كل خمس دقائق. اختر Uptime Kuma إذا أردت التحكم، أو UptimeRobot إذا لم تكن ترغب في تشغيل خادم المراقبة.
هل يوفّر Uptime Kuma صفحة حالة عامة؟
نعم. يمكنك اختيار عمليات المراقبة الظاهرة، وتجميعها، ونشر عدة صفحات حالة، وربطها بنطاقات مخصصة، وجدولة رسائل الصيانة. أما اشتراك الزوار بالبريد الإلكتروني فغير مدمج، لذا استخدم أداة صفحات حالة مخصصة للعملاء عندما يحتاجون إلى الاشتراك في التحديثات.
