.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
موقعك لا يفتح، وتكتشف بعد ساعات أن Nginx أو قاعدة البيانات أو حاوية Docker توقفت؟ في هذا الدليل الشامل نتعلم الأمرين معًا: كيف تعرف لماذا توقفت الخدمة وتعيد تشغيلها — بل وتجعلها تعود وحدها، وكيف تعرف بالتوقف فورًا عبر مراقبة مجانية بـUptime Kuma مع تنبيهات تيليجرام. «أوقعنا» Nginx عمدًا على سيرفر حقيقي في مرام هوست، ثم أوقفنا موقعًا تجريبيًا وراقبنا كيف اكتشف Uptime Kuma التوقف خلال 14 ثانية.
⚡ الإجابة المختصرة
الحالة والسبب: systemctl status nginx ثم sudo journalctl -u nginx -n 50. التشغيل: sudo systemctl restart nginx. العودة التلقائية: sudo systemctl edit nginx وأضف Restart=on-failure. المراقبة: Uptime Kuma في Docker مع تنبيه تيليجرام من @BotFather.
الجزء 1: هل الخدمة تعمل؟
كل برنامج يعمل في الخلفية على سيرفر لينكس (Nginx وMySQL وDocker وSSH) هو «خدمة» يديرها systemd. أول أمر دائمًا:
مخرجات حقيقية
sudo systemctl restart nginxإيقاف ثم تشغيل (يقطع الاتصالات لحظة)sudo systemctl reload nginxإعادة قراءة الإعداد دون قطع (بعد تعديل ملف)sudo systemctl stop / start nginxإيقاف أو تشغيلsudo systemctl enable nginxتشغيل تلقائي بعد كل إقلاعsystemctl --failedكل الخدمات المتوقفة بخطأالأسماء الشائعة: nginx، apache2، mysql أو mariadb، php8.3-fpm، docker، ssh.
الجزء 2: لماذا توقفت؟ اسأل السجل
لتجربة حقيقية «قتلنا» عملية Nginx الرئيسية بـkill -9 (كما يحدث عند نفاد الذاكرة). هكذا بدت الحالة وماذا قال السجل:
مخرجات حقيقية بعد إيقاع الخدمة عمدًا
status=9/KILL أو Out of memoryقُتلت لنقص الذاكرة — راجع الرام وSwap.emerg أو syntax errorخطأ في ملف الإعداد — افحص بـsudo nginx -t وأصلح السطر المذكور.Address already in useبرنامج آخر يأخذ المنفذ — sudo ss -tlnp.No space left on deviceالقرص ممتلئ — راجع دليل امتلاء القرص.sudo journalctl -u nginx -n 50 --no-pager # آخر 50 سطرًا
sudo journalctl -u mysql --since "1 hour ago" # آخر ساعة
sudo tail -50 /var/log/nginx/error.log # سجل أخطاء Nginx نفسه
sudo journalctl -k | grep -i "killed process" # هل قتل النظام شيئًا لنقص الذاكرة؟الجزء 3: اجعل الخدمة تعود وحدها
أغلب الخدمات لا تعيد تشغيل نفسها افتراضيًا. أضف لها «ملف تعديل» (override) بأمر sudo systemctl edit nginx، والصق السطرين، واحفظ. جرّبناه: قتلنا Nginx مرة ثانية فعاد وحده بعد 5 ثوانٍ:
مخرجات حقيقية
حاويات Docker: شغّلها دائمًا مع --restart unless-stopped (أو restart: unless-stopped في docker-compose) فتعود بعد أي توقف أو إعادة تشغيل للسيرفر. لمعرفة سبب توقف حاوية: sudo docker ps -a ثم sudo docker logs --tail 50 اسم-الحاوية.
الجزء 4: اعرف بالتوقف فورًا — Uptime Kuma وتيليجرام
Uptime Kuma أداة مراقبة مجانية مفتوحة المصدر: تفحص موقعك كل بضع ثوانٍ وترسل تنبيهًا إلى تيليجرام (أو البريد أو واتساب عبر خدمات وسيطة) عند التوقف والعودة. نصّبناها بـDocker على نفس السيرفر، بحيث تعمل على المنفذ الداخلي 3001 فقط، وأمامها Nginx بشهادة SSL:
sudo docker run -d --name uptime-kuma --restart unless-stopped \
-p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data louislam/uptime-kuma:1ثم أضف موقعًا في Nginx يمرر إلى 127.0.0.1:3001 وأصدر له شهادة — الإعداد جاهز في قسم «Nginx أمام تطبيق» من دليل Nginx وSSL. عند أول فتح تنشئ حساب المدير، ثم Add New Monitor:
لقطة حقيقية
تنبيه تيليجرام: في تيليجرام افتح @BotFather وأرسل /newbot، واختر اسمًا، فيعطيك Bot Token. أرسل أي رسالة لبوتك الجديد، ثم افتح في المتصفح https://api.telegram.org/bot<TOKEN>/getUpdates وانسخ رقم chat.id. ضع القيمتين في Uptime Kuma واضغط Test:
لقطة حقيقية
التجربة: جعلنا الموقع التجريبي يرد بخطأ 503، فظهر التوقف في لوحة Uptime Kuma خلال 14 ثانية مع سبب واضح — وهي الرسالة نفسها التي تصلك على تيليجرام:
لقطة حقيقية من التجربة
وعندما أعدنا الموقع، تحولت الحالة إلى Up وبقي أثر التوقف في السجل ونسبة التوفر:
لقطة حقيقية
نصائح المراقبة
- راقب من خارج السيرفر أيضًا: Uptime Kuma على نفس السيرفر لا يستطيع تنبيهك إن توقف السيرفر كله. ضعه على سيرفر آخر صغير، أو أضف لسيرفرك مراقبة خارجية مجانية ثانية.
- Retries 1 أو 2 تمنع الإنذارات الكاذبة من انقطاع لحظي.
- راقب المنافذ المهمة بنوع TCP Port (مثل SSH 2026 أو قاعدة البيانات)، وانتهاء شهادة SSL تلقائيًا.
- ولموارد السيرفر (المعالج والرام) استعمل تنبيهات الموارد في لوحة مرام.
