هل تواجه أعطالاً متكررة في Apache2 مع HestiaCP؟ دليل المراقبة الآلية واستكشاف الأخطاء وإصلاحها باستخدام Monit (مع إعدادات كاملة).

هل تواجه أعطالًا متكررة في Apache2 أو فشلًا في إعادة التشغيل التلقائي لـ Monit في بيئات HestiaCP ؟ تقدم هذه المقالة دليلًا عمليًا لتجنب الأخطاء الشائعة عند مراقبة Apache2 باستخدام Monit، من خلال تحليل معمق للمشاكل الشائعة مثل عدم توافق مسار PID وحظر الأذونات، بالإضافة إلى توفير ملفات تكوين أتمتة Monit عالية الجودة. أتقن الآن تقنيات صيانة الخوادم عالية التوفر، وحقق استعادة تلقائية من المستوى الثاني في حال حدوث أعطال!

المشاكل التي واجهتها أثناء استخدام Monit لمراقبة Apache2

يوم الجمعة الماضي، أرسل لي الخادم تنبيهًا من نظام المراقبة في منتصف الليل.

ألقيت نظرة خاطفة على اللوحة في حالة ذهول، وفي عمود حالة apache2، كان هناك خطأ مهلة باللون الأحمر.

فكرت في الأمر قليلاً. أضفتُ للتوّ برنامج مراقبة Monit إلى الخادم خلال النهار، ونسختُ الإعدادات من دليل تعليمي على الإنترنت. لا ينبغي أن تكون هناك أي مشاكل، أليس كذلك؟

في صباح اليوم التالي، انقطع الاتصال مرة أخرى. بعد المرة الثالثة، توقف جهاز المراقبة عن العمل، وعرضت اللوحة عبارة "غير مراقب".

أنا...

أعترف أنني لم آخذ الأمر على محمل الجد في البداية. مراقبة Apache2؟ يمكنك العثور على الكثير من قوالب التكوين على الإنترنت، ما عليك سوى نسخها ولصقها. لكن عملية اللصق هذه أغضبتني بشدة.

السبب الجذري للتعارض بين البنية الافتراضية لـ HestiaCP ومنافذ Monit

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

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

يبدو الأمر على ما يرام، أليس كذلك؟ يقوم بفحص المنفذ 80، وإذا تعطل، يُعاد تشغيله. إذا استمر التعطل بعد 5 عمليات إعادة تشغيل، تنتهي مهلة الاتصال.

المشكلة هي أن برنامج Apache2 الخاص بك لا يعمل حتى على المنفذ 80.

هذا أحد عيوب HestiaCP، والسبب الرئيسي لوقوع الكثيرين في فخها. يعتمد تصميم HestiaCP الافتراضي على خادم وكيل عكسي من Nginx + Apache2، حيث يشغل Nginx المنفذين 80 و443 في الواجهة الأمامية، بينما يعمل Apache2 على المنفذ المحلي 8081 في الواجهة الخلفية.

إذا طلبت من برنامج Monit فحص حالة خادم Apache2 على المنفذ 80، فكأنك تذهب إلى ماكدونالدز لتجد KFC. ينظر إليك الخادم بنظرة حائرة، وتتبادلان النظرات. في النهاية، يكتشف Monit أن الخادم معطل ويبدأ بإعادة التشغيل بشكل محموم.

بعد إعادة التشغيل، يبقى المنفذ 8081. ثم يحاول برنامج المراقبة فحص المنفذ 80، لكن محاولته تفشل أيضاً، فيُعاد تشغيله مرة أخرى. تتكرر هذه العملية حتى يقرر برنامج المراقبة أن المشكلة غير قابلة للإصلاح ويتوقف عن العمل.

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

تسبب ملف تعريف العملية التالف في Apache2 في قيام Monit بتحديد العملية بشكل خاطئ على أنها غير موجودة.

بعد تغيير المنفذ من 80 إلى 8081، من المفترض نظرياً أن يكون برنامج Monit قادراً على اكتشافه، أليس كذلك؟

ومع ذلك، في الواقع، لا يزال يُبلغ أحيانًا عن " فشل التنفيذ ".

بعد معاناة طويلة، اكتشفت أخيراً أن السبب بسيط: ملف PID كان تالفاً.

تخيّل الأمر، كان برنامج Monit يُعيد تشغيل Apache2 بشكلٍ محموم، وفي كل مرة كان يُجبره على التوقف ثم يُعيد تشغيله، ذهابًا وإيابًا عدة مرات. خلال هذه العملية، قد يصبح حجم الملف /var/run/apache2/apache2.pid صفر بايت.

بمعنى آخر، الملف لا يزال موجوداً، لكنه فارغ.

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

عندما رأيت هذا، عجزت عن الكلام للحظة.

هذا عطلٌ تام. يفشل برنامج Monit في اكتشاف مثيل Apache 2، فيعيد تشغيل Apache 2، مما يؤدي إلى تلف ملف PID أثناء عملية إعادة التشغيل، ثم يفشل في الاكتشاف التالي، ويعيد التشغيل مرة أخرى. تستمر هذه الدورة حتى يحدث انقطاع في الاتصال.

خطوات استكشاف الأخطاء وإصلاحها لمراقبة Apache2 في بيئة HestiaCP

بصراحة، عملية التحقيق ليست معقدة، ولكن عليك أن تعرف الاتجاه الذي يجب أن تبحث فيه.

الخطوة الأولى هي تحديد المنفذ الذي يستمع إليه خادم Apache2 الخاص بك. ما عليك سوى كتابة أمر في سطر الأوامر.

netstat -tulpn | grep apache2

بدلاً من ذلك، يمكنك استخدام الأمر `ss`؛ والنتيجة هي نفسها.

ss -tulpn | grep apache2

سترى مخرجات مشابهة لما يلي.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

تم التأكد من أن الرقم هو 8081 وليس 80. هذا هو أصل المشكلة.

الخطوة الثانية هي إصلاح ملف PID التالف. هذه الخطوة أبسط.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

أولًا، أوقف مراقبة Monit مؤقتًا لمنعها من التدخل أثناء إصلاح المشاكل. ثم، أعد تشغيل Apache2 للسماح له بكتابة مُعرّف العملية (PID) بشكل صحيح. أخيرًا، استخدم الأمر `cat` للتحقق من محتوى الملف؛ يجب أن يحتوي على سلسلة من الأرقام، وليس سلسلة فارغة.

بمجرد إتمام هذه الخطوة، يتم حل المشكلة بشكل أساسي.

تحليل مقارن لتكوينات الحماية التكيفية والعدوانية التقليدية لأنظمة المراقبة

تندرج الدروس التعليمية عبر الإنترنت حول تكوين Apache2 باستخدام Monit بشكل عام ضمن فئتين.

أحد أنواعها هو "النوع التقليدي للتكيف"، الذي يستخدم الأمر `service` لإدارة الخدمات وفحص المنافذ المحلية دون إضافة قيود معقدة. يمكن استخدام هذا التكوين على HestiaCP ببساطة عن طريق تغيير المنفذ، وهو مستقر نسبيًا.

ثمة نهج آخر يتمثل في أسلوب "الحماية الفعّالة"، الذي يستخدم systemctl لإدارة الخدمات، ويضيف قيودًا على العمليات الفرعية، ويعتمد منطقًا أكثر صرامة للكشف. يبدو هذا الأسلوب رائعًا، لكنه يعاني من عيب جوهري: أمر الإيقاف المستخدم هو `killall -9`.

ماذا يعني الأمر `killall -9`؟ يعني هذا الأمر إيقاف تشغيل الجهاز قسرًا بغض النظر عما يفعله. قد تُخلّف هذه العملية القسرية ملفات PID تالفة، وهي المشكلة التي ذكرتها للتو.

تجربتي الشخصية تُشير إلى أن الحد من عدد العمليات الفرعية في بيئة تشغيل مُكثفة يُعدّ مفيدًا بالفعل. فعندما يتعرض خادم Apache2 لهجوم CC، يُمكن للحد من عدد العمليات الفرعية أن يمنع نفاد ذاكرة الخادم. مع ذلك، فإن استخدام الأمر `killall -9` غير عملي بتاتًا.

لذا في النهاية توصلت إلى حل وسط وجمعت بين مزايا كلا التكوينين.

أفضل ممارسات تكوين HestiaCP Apache2 Monit

قم بتعديل الملف /etc/monit/conf.d/apache2 بالمحتوى التالي.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

دعوني أشرح بإيجاز المنطق الكامن وراء هذه الأسطر القليلة من الإعدادات.

اكتب المنفذ 8081 ليطابق بدقة بنية الوكيل العكسي لـ HestiaCP؛ توقف عن كتابة المنفذ 80 بشكل أحمق.

استخدم الأمر `systemctl stop` بدلاً من `killall -9` لإيقاف ملف PID، وذلك لتجنب تلفه.

تمت إضافة حد للعمليات الفرعية: إذا تجاوز عدد العمليات الفرعية 120، فستتم إعادة تشغيل العملية بعد دورتين متتاليتين لمنع هجمات CC، لكنها ليست عدوانية للغاية.

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

تم تخفيف عتبة المهلة النهائية إلى 5 عمليات إعادة تشغيل في غضون 10 دورات، مما يترك هامشًا كافيًا لتحمل الأعطال.

هيستياCP مراقبة المراقبةملخص استكشاف أخطاء التكوين وإصلاحها ومشاركة الخبرات

بعد إجراء تغييرات التكوين، قمت بمراقبة apache2، وأظهرت اللوحة أخيرًا مؤشرًا أخضر "موافق".

كيف أصف مشاعري حينها؟ كان الأمر أشبه بقضاء يومين في محاولة إصلاح خلل برمجي، لأكتشف في النهاية أن السبب هو سطر واحد خاطئ في الإعدادات. كان الأمر محبطاً ومضحكاً في آن واحد.

يُعدّ برنامج Monit مفيدًا بحد ذاته، ومراقبة البرامج الخدمية أمرٌ ضروري لكل خادم. لكن المشكلة تكمن في أن العديد من الشروحات المتوفرة على الإنترنت تفترض أن "Apache2 يستخدم المنفذ 80 حصريًا"، بينما يستخدم HestiaCP خادم وكيل عكسي، مما يعني أن هذا الافتراض غير صحيح.

إذا اتبعت التعليمات، فالمشكلة ليست فيك؛ بل في أن البرنامج التعليمي ينطبق على سيناريو مختلف عن سيناريوك.

إذا كنت تستخدم HestiaCP وتجرب Monit لمراقبة Apache2، فتذكر أمرين: غيّر المنفذ إلى 8081، واستخدم الأمر `systemctl` لإيقافه، وليس `killall -9`. باتباع هذين الأمرين، ستتجنب أي مشاكل أخرى.

بما أنك قرأت حتى هذه النقطة، إذا وجدت هذا المحتوى مفيدًا، يُرجى الإعجاب به ومشاركته. وإذا كنت ترغب في تلقي التحديثات أولًا، يمكنك أيضًا متابعتي!

شكراً لكم على قراءة مقالتي. أراكم في المرة القادمة.