أتمتة مراقبة الـ Uptime لمواقعك عبر Uptime Kuma و Telegram

لو موقعك وقع الساعة 3 الفجر وعرفت من عميل غضبان الصبح، المقال ده هيوفرلك النظام اللي بيديك التنبيه في أقل من 90 ثانية من لحظة الـ downtime، بدون ما تدفع اشتراك شهري لخدمة SaaS.

المشكلة باختصار

الأدوات الجاهزة زي UptimeRobot أو Pingdom ممتازة لكن فيها قيود واضحة. الخطة المجانية فحص كل 5 دقايق فقط، وأول إشعار بيوصل بعد دقيقتين إضافيين على الأقل. يعني ممكن يعدي على موقعك 7 دقايق كاملة downtime قبل ما تعرف. لو عندك أكتر من 50 endpoint، المجانية مش كفاية، والمدفوع بيبدأ من 7$ شهرياً ويزيد مع كل monitor. Uptime Kuma أداة مفتوحة المصدر بتشتغل عندك على VPS صغير، بتعمل نفس الشغل مع Telegram push في ثواني.

فكرة سريعة للمبتدئين قبل ما ندخل في التقني

تخيّل إنك مشغّل صديق يدق على باب محلك كل دقيقة يتأكد إنه لسه فاتح. طالما فيه رد من جوه، كل حاجة تمام. أول ما يدق ومحدش رد، بيبعتلك رسالة على تلغرام: "المحل قفل يا بشمهندس". ده بالظبط مفهوم الـ uptime monitoring.

بشكل علمي: أداة خارجية بتعمل HTTP GET على Endpoint معيّن في فترات دورية محددة (polling). بتقيس الـ status_code، الـ response_time_ms، وأحياناً محتوى الرد (Keyword matching). لو الرد طلع خارج النطاق المقبول (مثلاً مش 2xx) أو ماجاش في الـ timeout، بيُعتبر الـ service down، وبيتم تنفيذ notification pipeline. Uptime Kuma بيدعم أنواع فحص إضافية: TCP (للبورتات زي DB)، Ping (ICMP)، DNS، وPush (اللي فيه الجهاز المراقَب هو اللي بيبعت heartbeat للسيرفر — مفيد للـ cron jobs).

ليه Uptime Kuma بالذات

• الفحص كل 20 ثانية كحد أدنى بدل 5 دقايق في الخطة المجانية لمعظم المنافسين.
• أكتر من 90 قناة تنبيه مبنية جاهزة: Telegram، Discord، Slack، Email (SMTP)، Webhook مخصص، Gotify، ntfy.
• Status Page عامة قابلة للنشر على دومين فرعي زي status.yourdomain.com لعملائك.
• استهلاك خفيف: حوالي 120MB RAM لـ 50 monitor، يشتغل مرتاح على VPS بـ 4–5$ شهرياً.
• SQLite كقاعدة بيانات افتراضية، يعني مفيش تنصيب إضافي.

الخطوة 1 — تشغيل Uptime Kuma بـ Docker

الافتراض: عندك سيرفر Linux (Ubuntu 22.04 LTS أو Debian 12) مع Docker و docker compose متنصبين. لو لسه، ركّبهم بسطر واحد:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER   # وبعدها اعمل logout/login

بعد كده أنشئ ملف المشروع:

# /opt/kuma/docker-compose.yml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1.23.13
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped

mkdir -p /opt/kuma && cd /opt/kuma
# ضع الملف أعلاه هنا باسم docker-compose.yml
docker compose up -d
docker ps --filter name=uptime-kuma

افتح المتصفح على http://SERVER_IP:3001، أنشئ حساب الـ admin، وخلاص الـ service شغّال.

الخطوة 2 — إنشاء Telegram Bot في 4 خطوات

1. افتح تلغرام وابحث عن @BotFather.
2. ابعتله /newbot، اختار اسم و username ينتهي بـ bot.
3. هيرجّعلك HTTP API token شكله: 7423...:AAH.... احتفظ بيه في مكان آمن.
4. ابعت رسالة "hi" للبوت من حسابك الشخصي، وبعدها افتح في المتصفح:
   https://api.telegram.org/bot<TOKEN>/getUpdates
   دوّر على chat.id في الـ JSON — ده معرّف محادثتك مع البوت، وهتحتاجه في الخطوة الجاية.

الخطوة 3 — ربط Kuma بالبوت

من داخل Uptime Kuma اذهب إلى Settings → Notifications → Setup Notification، واختر Telegram:

• Bot Token: الـ token اللي جبته من BotFather.
• Chat ID: الرقم اللي طلع من getUpdates.
• اضغط Test. لو وصلتك رسالة فوراً، الـ integration تمام.
• فعّل خيار Apply on all existing monitors عشان ميتكررش العمل.

الخطوة 4 — إضافة أول Monitor بإعدادات ذكية

اضغط Add New Monitor، نوع HTTP(s)، وحط URL الموقع. الإعدادات اللي فعلاً بتفرق:

• Heartbeat Interval: 60 ثانية (ماتنزلش تحت 30 ثانية عشان متستهلكش CPU ولا تعمل load على الـ target).
• Retries: 2 — لازم يفشل الفحص مرتين متتاليتين قبل ما يُعتبر Down.
• Heartbeat Retry Interval: 30 ثانية.
• Accepted Status Codes: 200-299. لو موقعك بيعمل redirect دائم، ضيف 301.
• فعّل Certificate Expiry Notification. هيحذّرك قبل انتهاء الـ SSL بـ 14 يوم — ده لوحده بيوفرلك كارثة.

تقليل ضوضاء التنبيهات — الجزء اللي بيفرق

لو ضبطت النظام بدون فلترة، أول glitch بسيط لـ 30 ثانية هيصحيك الفجر. اللي بيحصل فعلاً: حوالي 35–45% من الـ downtimes الأقل من دقيقة بترجع لوحدها (hiccups من CDN، GC pause، أو DB connection drop). الحل عملي وبسيط:

• استخدم Retries = 2 مع Retry Interval = 30s. ده معناه إن التنبيه ميوصلش إلا بعد 90 ثانية فعلية down.
• اعمل Status Page عامة وحط لينكها في نص التنبيه على تلغرام. العميل الغاضب هيفتحها بدل ما يفتح تيكت.
• قسّم المراقبة على مجموعتين: critical (الموقع الرئيسي، الـ API) بـ 60s interval، وsecondary (CMS admin، docs) بـ 5 دقايق.

الـ trade-offs صريحة

• بتكسب: تنبيه في 60–90 ثانية، فحص لحد 20 ثانية، monitors غير محدودة، تحكم كامل في الداتا، مفيش vendor lock-in.
• بتخسر: مسؤولية تشغيل السيرفر بنفسك (حوالي 4$ شهرياً على Hetzner CX11 أو DigitalOcean Basic)، ولازم تعمل backup يدوي لمجلد ./data أسبوعياً.
• مشكلة meta-monitoring: لو السيرفر اللي عليه Kuma هو اللي وقع، مفيش حد يعرّفك. الحل الرخيص: استخدم UptimeRobot مجاناً على monitor واحد بس — يراقب سيرفر Kuma نفسه. بكده عندك مراقب خارجي بدون تكلفة.

متى لا تستخدم هذه الطريقة

لو بتدير أكتر من 500 monitor، أو بتحتاج فحص حقيقي من أكتر من 10 مناطق جغرافية في نفس الوقت، Kuma مش الأنسب. هتحتاج خدمات enterprise زي Datadog Synthetics أو Checkly. كمان لو عندك متطلبات compliance صارمة (HIPAA، SOC2) بتشترط audit logs معتمدة و MFA داخلي، self-hosted open source هيحتاج شغل إضافي كتير.

الخطوة التالية

شغّل الـ docker compose اللي فوق على أي VPS عندك دلوقتي، اربط بوت تلغرام، وضيف monitor واحد بس على موقعك الرئيسي. بعد ما يشتغل، نفّذ docker stop للموقع يدوياً وقِس كام ثانية ياخد التنبيه يوصل. لو أقل من 90 ثانية، ركّب باقي الـ monitors. لو أكتر، راجع Retries و Retry Interval.

المصادر

• التوثيق الرسمي لـ Uptime Kuma على GitHub: github.com/louislam/uptime-kuma
• Telegram Bot API Reference: core.telegram.org/bots/api
• خطط UptimeRobot للمقارنة: uptimerobot.com/pricing
• Docker install script الرسمي: get.docker.com
• Hetzner Cloud Pricing: hetzner.com/cloud