تثبيت Uptime Kuma للمراقبة الذاتية عبر Docker

ما الذي ستبنيه

حاوية صغيرة واحدة تراقب خوادمك ومواقعك الأخرى من خارجها، وتخبرك فور توقف أحدها عن الاستجابة، عبر البريد الإلكتروني أو Telegram أو Discord أو webhook. يعمل Uptime Kuma كعملية Node واحدة تعتمد على ملف SQLite، لذلك يعمل بسهولة ضمن 256-512 MB من الذاكرة، ويوفّر لوحة معلومات مباشرة، ورسومات بيانية للسجل، وصفحة حالة عامة. يتكوّن التثبيت من ملف Compose من عشرة أسطر؛ لكن العامل المهم فعلياً هو مكان تشغيله وما إذا كانت تنبيهاتك قد أُرسلت في اختبار من قبل، لأن أداة مراقبة لم تثبت قدرتها على الوصول إليك أسوأ من عدم وجود أداة على الإطلاق: فهي تمنحك شعوراً زائفاً بالحماية بينما لا تراقب شيئاً.

شغّل نظام المراقبة في مكان لا يمكن للعطل الوصول إليه

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

لذلك شغّل Uptime Kuma على VPS مختلف عن الخادم الذي يراقبه، ويفضل أن يكون لدى مزود مختلف أو في منطقة مختلفة. اجعله يصل إلى خدماتك بالطريقة التي يصل بها المستخدمون، أي عبر الإنترنت العام وباستخدام اسم المضيف. تكفي نسخة منخفضة التكلفة، ويمكن لـVPS صغير واحد للمراقبة متابعة جميع خوادمك. تزداد أهمية هذا الفصل مع التطبيقات الثقيلة التي تستضيفها، لأن شيئاً مثل مكتبة صور PhotoPrism أو Immich قد يشغل وحدة المعالجة المركزية لساعات أثناء فهرسة استيراد جديد. إذا شارك نظام المراقبة العتاد نفسه، فقد يعلن توقف خدمة مشغولة فقط. لاكتشاف توقف Kuma نفسه، أضف نبضة heartbeat عبر push من cron يعمل في مكان آخر.

المتطلبات الأساسية وتقدير الموارد

• خادم VPS جديد يعمل بنظام Ubuntu 24.04، مع Docker Engine وملحق Compose v2، مثبّتين من مستودع apt الخاص بـDocker، وليس حزمة التوزيعة docker.io التي تتأخر تحديثاتها.
• تكفي ذاكرة RAM بسعة 256 MB لتشغيل عدد قليل من أدوات المراقبة. وتوفر سعة من 512 MB إلى 1 GB موارد مريحة لتشغيل عشرات الأدوات، إضافة إلى الـReverse Proxy. ويكون استهلاك CPU شبه معدوم بين عمليات التحقق.
• نطاق وسجل DNS من نوع A، بحيث يشير status.example.com إلى خادم VPS، وذلك فقط إذا كنت تريد استخدام TLS وإنشاء صفحة حالة عامة. يمكن للتثبيت الخاص الاستغناء عن DNS واستخدام VPN أو نفق SSH.
• اتصال شبكة صادر إلى الوجهات التي تُرسل إليها التنبيهات: SMTP إلى مزود البريد، أو HTTPS إلى Telegram وDiscord.

ملف Compose

ضع ما يلي في /srv/uptime-kuma/compose.yaml.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

شغّله وراقب الإقلاع الأول:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

يسجّل الإقلاع الصحيح Listening on 3001 ثم يتوقف عن تسجيل الرسائل. هناك 3 عناصر مقصودة في هذا الملف.

127.0.0.1:3001:3001، وليس 3001:3001. ينشر Docker المنافذ باستخدام قواعد DNAT تُقيَّم قبل أن يرى ufw الحزمة، لذلك يعرّض 3001:3001 المجرّد لوحة التحكم للإنترنت العام، بغض النظر عن جدارك الناري. يحافظ الربط بواجهة loopback على خصوصية الخدمة، مع تعريض الـreverse proxy فقط؛ ويمكن لمثيل خاص تجاوز الـproxy والوصول إلى 3001 عبر VPN WireGuard مستضاف ذاتياً بدلاً من ذلك.

وحدة تخزين مسمّاة في /app/data. توجد فيها كل البيانات التي يتذكرها Uptime Kuma، بما في ذلك قاعدة بيانات SQLite، وأجهزة المراقبة، وإعدادات الإشعارات، وشعارات صفحة الحالة. إذا فقدتها، فستبدأ من شاشة إدارة فارغة؛ وهي الشيء الوحيد الذي يجب عليك نسخه احتياطياً.

الصورة مثبتة على وسم إصدار رئيسي، :2. هذا هو خط الإصدارات المستقرة الحالي؛ تحقّق من Docker Hub من أحدث إصدار رئيسي قبل نسخه، ولا تتبع أبداً وسمًا متغيراً مثل latest، إذ يهمله المشروع. الانتقال إلى إصدار رئيسي أحدث لهذه الصورة هو ترحيل أحادي الاتجاه لقاعدة البيانات، ويجب أن تبدأه عمداً، لا أن يحدث دون قصد أثناء سحب اعتيادي.

هناك قيد واحد: يجب أن يكون /app/data على نظام ملفات يدعم أقفال ملفات POSIX. وحدة تخزين Docker المحلية مناسبة؛ أما على NFS فتتلف قاعدة بيانات SQLite، وتحصل على SQLITE_BUSY وdatabase disk image is malformed، لذلك لا تستخدم مشاركة شبكية أبداً.

التشغيل الأول: إنشاء حساب المسؤول

افتح المثيل عبر الـproxy لديك على العنوان https://status.example.com، أو عبر نفق SSH: شغّل ssh -L 3001:127.0.0.1:3001 user@your-vps ثم افتح http://localhost:3001. الصفحة الأولى هي نموذج إعداد لاسم مستخدم المسؤول وكلمة المرور؛ لا توجد بيانات دخول افتراضية. اختر كلمة مرور قوية وحقيقية: تعرض لوحة المعلومات هذه العناوين الداخلية والرموز المميزة لكل ما تراقبه. هل نسيتها لاحقاً؟ أعد تعيينها من المضيف، وليس من المتصفح:

sudo docker compose exec uptime-kuma npm run reset-password

أضف قنوات الإشعارات أولاً واختبرها

أعدّ التنبيهات قبل إضافة المراقبات، حتى تتمكن من إرفاق قناة عند إنشاء كل مراقب. انتقل إلى Settings ثم Notifications ثم Setup Notification، واستخدم زر Test لكل قناة للتأكد من وصول الرسالة، لأن الإشعار غير المختبَر هو ثاني أكثر أسباب فشل الإعداد بصمت.

البريد الإلكتروني (SMTP). املأ الحقول الخاصة بالمضيف والمنفذ والتشفير واسم المستخدم وكلمة المرور وFrom وTo. التركيبان العاملان هما 465 مع ضبط "Secure" على TLS/SSL، أو 587 مع STARTTLS. بالنسبة إلى Gmail ومعظم مزوّدي الخدمة الذين يستخدمون المصادقة الثنائية، يجب إنشاء app password؛ إذ تُرجع كلمة مرور الحساب العادية Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. أرسل رسالة إلى @BotFather، وأرسل /newbot، ثم انسخ رمز bot. للحصول على معرّف المحادثة، أرسل رسالة إلى bot الجديد مرة واحدة، وافتح https://api.telegram.org/bot<token>/getUpdates، واقرأ chat.id من JSON. يكون لدى bot الذي لم تراسله أولاً getUpdates فارغاً، ولن يجد وجهة يرسل إليها.

Discord. في القناة، افتح Edit Channel ثم Integrations ثم Webhooks ثم New Webhook، وانسخ URL، ثم الصقه كإشعار من نوع Discord.

Webhook عام. بالنسبة إلى أي خدمة أخرى، مثل webhook الوارد في Slack أو endpoint مخصص أو hook لأتمتة المنزل، يرسل النوع Webhook حمولة JSON عبر POST إلى URL تحدده، كما يغطي تكامل Apprise المضمّن معظم الخدمات التسعين الأخرى تقريباً الموجودة في القائمة. وإذا كنت تفضّل ألا يتوسط طرف ثالث بين حدوث العطل ووصول الإشعار إلى هاتفك، فاختر النوع المضمّن ntfy ووجّهه إلى خادم ntfy تديره بنفسك، حيث يرسل الإشعارات إلى هاتفك عبر قناة تتحكم بها من البداية إلى النهاية.

أضف شاشات المراقبة، نوعاً واحداً في كل مرة

انقر على Add New Monitor، واختر نوعاً، ثم اضبط Friendly Name وCheck Interval ‏(60 ثانية قيمة مناسبة) وRetries ‏(عدد حالات الفشل المتتالية قبل اعتبار الخدمة «متوقفة»؛ استخدم 2 أو 3 حتى لا يؤدي فقدان حزمة واحدة إلى إرسال تنبيه) والإشعارات المطلوب تشغيلها. ستستخدم الأنواع التالية:

• HTTP(s). عنوان URL كاملاً. تعني حالة التشغيل قبول رمز الحالة ‏(200-299 افتراضياً؛ وسّع النطاق ضمن Accepted Status Codes إذا كان 301 أو 401 طبيعياً لديك). هذا هو الخيار الأساسي لمواقع الويب وواجهات API.
• HTTP(s) - Keyword. يرسل الطلب نفسه، لكن لا تُعد الخدمة «عاملة» إلا إذا كانت السلسلة النصية موجودة في محتوى الاستجابة، أو غير موجودة عند تفعيل Invert. يلتقط ذلك حالة يعيد فيها الموقع 200 OK مع عرض الرسالة "Error establishing a database connection"، وهي حالة يَعُدّها فحص HTTP العادي سليمة. وهذا هو الفحص المناسب أيضاً لواجهة أمامية في المتصفح تتصل بخلفية منفصلة، مثل واجهة متجر فيديو Halcyon فوق Jellyfin، إذ تعيد هيكل الصفحة 200 بنجاح بينما يتعذر الوصول إلى خادم الوسائط خلفها.
• TCP Port. اتصال TCP مباشر بمضيف ومنفذ، للخدمات التي لا تستخدم HTTP، مثل SSH على 22 وPostgres على 5432 وخادم SMTP على 25 وخادم ألعاب.
• Ping. طلب صدى عبر ICMP لقياس إمكانية الوصول وزمن الاستجابة بتكلفة منخفضة. لكن العديد من الشبكات وجدران الحماية السحابية تحظر ICMP، لذلك قد يعني ظهور شاشة Ping باللون الأحمر أن «المضيف متوقف» أو أن «موفر الخدمة يحظر Ping»؛ أكّد النتيجة باستخدام شاشة مراقبة TCP.
• DNS. يحل سجلاً مثل A أو AAAA أو MX أو TXT وغير ذلك باستخدام محلل تحدده، ويمكنه التحقق من الإجابة، ما يساعد على اكتشاف انقطاع خدمة المسجل أو DNS مبكراً.
• Push. شاشة المراقبة التي تعمل من الداخل إلى الخارج، وسنغطيها في القسم التالي.

مراقبة مهمة cron باستخدام مراقب push (نبضات الحياة)

كل مراقب أعلاه يتصل بخدمتك من الخارج. أما مراقب push فيعمل بالعكس: ينتظر Uptime Kuma، ثم تستدعيه مهمتك لتقول: «لقد نُفِّذت». هذه هي الطريقة الوحيدة الموثوقة لمراقبة النسخ الاحتياطي أو مهمة cron؛ إذ يعرف فحص HTTP أن عنوان URL يستجيب، لكن المهمة وحدها تعرف أنها اكتملت.

أنشئ مراقباً من النوع Push. ينشئ Uptime Kuma عنوان URL فريداً مثل:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

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

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

إذا فشلت المهمة، يتوقف set -e قبل تنفيذ curl؛ وإذا كان الخادم متوقفاً، فلن تُنفَّذ المهمة أصلاً. في كلتا الحالتين تتوقف نبضات الحياة، وبعد انقضاء الفترة الزمنية مضافاً إليها محاولات إعادة التشغيل، يغيّر Uptime Kuma حالة المراقب إلى down ويرسل تنبيهاً. تعامل مع رمز push هذا على أنه سر؛ إذ يمكن لأي شخص يملكه تزوير نبضة سليمة.

إنشاء صفحة حالة عامة

صفحة الحالة هي الواجهة التي يراها العملاء. تعرض الخدمات العاملة وسجلها الأخير، من دون كشف لوحة المعلومات لديك. انتقل إلى Status Pages ثم New Status Page، وأدخل اسماً وslug ‏(المسار العام، مثل /status/main). اسحب أدوات المراقبة التي تريدها إلى مجموعات مثل "Websites" و"APIs"، وأضف شعاراً ووصفاً قصيراً، ثم اختر Save. يمكنك أيضاً ربط الصفحة بنطاقها الخاص، بحيث يعرض status.example.com الصفحة مباشرة.

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

ضعه خلف reverse proxy مع TLS، وانتبه إلى WebSocket

بالنسبة إلى مثيل عام، ضع reverse proxy أمام الحاوية المرتبطة بـloopback لتوفير TLS واسم مضيف. التفصيل الذي يسبب المشكلات للجميع هو أن واجهة Uptime Kuma هي تطبيق Socket.IO مباشر، لذلك يجب أن يرقّي الـproxy اتصال WebSocket. إذا غاب هذا الإعداد، تُحمَّل الصفحة لكنها لا تتصل أبداً؛ وتبقى لوحة المعلومات على الحالة "جارٍ الاتصال..."، ولا تتحدث نبضات الحالة المباشرة، وتعرض وحدة تحكم المتصفح WebSocket connection to 'wss://.../socket.io/...' failed.

ثبّت nginx وcertbot، ثم اكتب vhost يوجّه الطلبات إلى منفذ loopback. استخدم المنفذ 80 في الوقت الحالي، ودَع certbot يضيف TLS لاحقاً؛ يوضّح إصدار شهادات Let's Encrypt باستخدام certbot وnginx التحدي، ومؤقت التجديد، وحالات الفشل المرتبطة به.

sudo apt install -y nginx certbot python3-certbot-nginx

احفظ هذا باسم /etc/nginx/sites-available/status.example.com؛ سطرا WebSocket هما المهمان:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

فعّل الموقع، واختبر الإعداد، ثم دع certbot يعيد كتابة الكتلة للاستماع على 443، ويضيف الشهادة، ويضبط إعادة التوجيه من HTTP إلى HTTPS:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

يشكّل الزوج Upgrade وConnection "upgrade" الإعداد الأساسي، بينما يمنع proxy_read_timeout 3600s nginx من إنهاء اتصال socket طويل الأمد؛ وينسخ certbot السطرين إلى كتلة 443 التي ينشئها. إذا كنت تشغّل عدة حاويات خلف proxy واحد، فإن توجيهها عبر Traefik مع TLS تلقائي يحقق النتيجة نفسها باستخدام labels للحاويات، ويمرّر ترقيات WebSocket تلقائياً.

لا تضع vhost بالكامل خلف basic auth، لأن ذلك سيمنع الوصول أيضاً إلى صفحة الحالة العامة ونقطة النهاية /api/push. استخدم تسجيل الدخول المدمج في Uptime Kuma، وأضف fail2ban لمراقبة محاولات تسجيل الدخول الفاشلة المتكررة إذا كان المثيل متاحاً عبر الإنترنت. وإذا لم تكن لوحة المعلومات بحاجة إلى أن تكون عامة، فأزل proxy والوصول إليها عبر VPN.

مراقبة انتهاء صلاحية الشهادة بالطريقة الصحيحة

يمكن لمراقب HTTP(s) تحذيرك أيضاً قبل انتهاء صلاحية شهادة TLS: فعّل Certificate Expiry Notification، وسيرسل Uptime Kuma تنبيهاً قبل عدد محدد من الأيام. هناك خطآن يجعلان المراقب يقرأ الشهادة بشكل غير صحيح. راقب اسم المضيف، وليس عنوان IP، لأن الطلب الذي لا يتضمن SNI يحصل على الشهادة الافتراضية للخادم، وسترى Hostname/IP does not match certificate's altnames. ولا تفعّل Ignore TLS/SSL Error في مراقب تريد الحصول منه على تحذيرات انتهاء الصلاحية. فهذا الخيار مخصص للمضيفين الداخليين ذوي الشهادات الموقّعة ذاتياً (unable to verify the first certificate، DEPTH_ZERO_SELF_SIGNED_CERT)، لكنه يمنع Uptime Kuma من فحص الشهادة أساساً، بما في ذلك انتهاء صلاحيتها.

النسخ الاحتياطية: كل شيء في دليل واحد

بما أن كل شيء موجود في /app/data، فالنسخة الاحتياطية هي نسخة من وحدة التخزين تُؤخذ أثناء إيقاف الحاوية، لذلك يكون ملف SQLite متسقاً:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

تحقّق أولاً من الاسم الفعلي لوحدة التخزين باستخدام docker volume ls | grep kuma، لأن Compose يضيف بادئة إليه باستخدام دليل المشروع. ثم انسخ ملف tarball إلى خارج الخادم، لأن النسخة الاحتياطية الموجودة على VPS نفسه هي نسخة، وليست نسخة احتياطية. الاستعادة هي العملية العكسية: أوقف المكدس، واستخرج الملفات إلى وحدة تخزين /app/data فارغة، ثم شغّله.

الترقيات

الترقيات تعني سحب صورة:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

ينفّذ الحاوي الجديد أي ترحيل لقاعدة البيانات عند بدء تشغيله أول مرة؛ راقب docker compose logs -f. نفّذ النسخة الاحتياطية المذكورة أعلاه قبل السحب، والتزم بالوسم الرئيسي نفسه: الانتقال من :1 إلى :2 عملية ترحيل باتجاه واحد، لذا أنشئ نسخة احتياطية أولاً وراجع ملاحظات الإصدار.

أوضاع الفشل، والعبارات التي ستظهر لك

حالة "متوقف" خاطئة في مراقب موجّه إلى localhost. يتحول المراقب إلى اللون الأحمر مع timeout of 48000ms exceeded أو connect ETIMEDOUT، مع أن الخدمة تستجيب من حاسوبك المحمول. إذا كان المراقب يستهدف المضيف نفسه الذي يعمل عليه Uptime Kuma، فقد أدّى ارتفاع استهلاك CPU أو الذاكرة إلى حرمان الفحص من الموارد، وليس إلى تعطل الهدف. انقل المراقب إلى VPS منفصل واستهدف اسم المضيف العام.

connect ECONNREFUSED 127.0.0.1:443 (أو أي منفذ). لم تكن هناك خدمة تستمع على ذلك المنفذ. إما أن الخدمة متوقفة، أو أنك راقبت localhost من داخل الحاوية، حيث يشير 127.0.0.1 إلى الحاوية وليس إلى خادمك. راقب اسم المضيف العام، وليس loopback.

Invalid login: 535-5.7.8 Username and Password not accepted في اختبار البريد الإلكتروني. بيانات اعتماد SMTP غير صحيحة، أو أن موفّر الخدمة يطلب كلمة مرور خاصة بالتطبيق بينما أُدخلت كلمة مرور حسابك. أنشئ كلمة مرور للتطبيق والصقها.

connect ETIMEDOUT أو queryA ETIMEDOUT <host> في اختبار البريد الإلكتروني. المنفذ غير صحيح، أو أن موفّر الخدمة يحظر SMTP الصادر. تأكد من أن 465 أو 587 يطابق إعداد Secure/STARTTLS، واختبر من المضيف باستخدام nc -vz smtp.example.com 587. يحظر العديد من موفّري الخدمة 25 الصادر، ويحظر بعضهم منافذ الإرسال إلى أن تطلب تفعيلها.

self signed certificate أو unable to verify the first certificate في اختبار البريد الإلكتروني. يقدّم خادم SMTP شهادة لا يثق بها Node. أصلح شهادة خادم البريد بدلاً من تجاوز التحقق منها.

لوحة التحكم عالقة عند "Connecting..."، وتعرض وحدة التحكم WebSocket connection ... failed. لا يرقّي الـreverse proxy اتصال WebSocket. أضف الرأسيْن Upgrade وConnection "upgrade" في nginx، أو استخدم proxy يمررهما افتراضياً مثل Traefik أو Caddy. تُحمَّل HTML لأن ذلك طلب HTTP GET عادي؛ أما اتصال socket المباشر وحده فيحتاج إلى الترقية.

لا يرسل مراقب انتهاء الشهادة أي تحذير، أو يرسل تحذيراً خاطئاً. إما أن خيار Ignore TLS/SSL Error محدد، ما يعطّل التحقق من الشهادة، أو أن المراقب يستهدف عنوان IP ويقرأ الشهادة الخاطئة بسبب غياب SNI، فيعرض Hostname/IP does not match certificate's altnames. ألغِ تحديد خيار التجاهل، وراقب باستخدام اسم المضيف.

SQLITE_BUSY أو database disk image is malformed في السجلات. وحدة التخزين /app/data موجودة على نظام ملفات لا يوفّر قفل الملفات بصورة صحيحة، وغالباً ما يكون NFS. انقلها إلى Docker volume محلي واستعد البيانات من النسخة الاحتياطية.

FAQ

أين ينبغي أن أشغّل أداة مراقبة uptime؟

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

كيف أحصل على تنبيهات في Telegram أو عبر البريد الإلكتروني؟

أضف القناة ضمن Settings ثم Notifications، ثم اربطها بكل أداة مراقبة. بالنسبة إلى Telegram، أنشئ bot باستخدام @BotFather واقرأ chat.id من https://api.telegram.org/bot<token>/getUpdates؛ وبالنسبة إلى البريد الإلكتروني، استخدم 465 مع SSL أو 587 مع STARTTLS، واستخدم كلمة مرور للتطبيق إذا كان مزود الخدمة يستخدم المصادقة الثنائية. اضغط على Test وتأكد من وصول الرسالة قبل الاعتماد عليها.

هل يستطيع Uptime Kuma مراقبة cron job أو script للنسخ الاحتياطي؟

نعم، هذا هو monitor من نوع Push: يمنحك Uptime Kuma عنوان URL، وتنفّذ curl في نهاية script لكي يُرسل الإشعار فقط عند نجاحه. إذا فشلت المهمة أو كان الجهاز متوقفاً، فلن تصل إشارة heartbeat، وستتلقى تنبيهاً بعد انقضاء interval. هذه هي الطريقة الموثوقة الوحيدة لمعرفة أن مهمة مجدولة نُفذت فعلاً، لأن الفحص الخارجي لا يستطيع رؤية ما يحدث داخلها.

Uptime Kuma أم Zabbix، أيهما ينبغي أن أشغّل؟

يجيب Uptime Kuma عن السؤال: «هل الخدمة تعمل من الخارج، وهل أرسلت إليّ تنبيهاً؟» خلال عشر دقائق وباستهلاك شبه معدوم للموارد، كما يوفر status page. لكنه لا يجمع مقاييس تفصيلية مثل اتجاهات CPU والذاكرة والقرص، ولا يطبّق حدوداً على مستوى الأسطول؛ ولهذا الغرض، فإن خادم Zabbix متكامل لمراقبة الأنظمة هو الأداة الأثقل المعتمدة على agent، ويشغّل كثير من المستخدمين الأداتين معاً. هل ما زلت تقرر ما الذي ستشغّله أصلاً؟ يضع دليلنا لما يمكنك استضافته ذاتياً في 2026 المراقبة في سياقها.