حل مشكلة "لا يوجد ملف أو دليل بهذا الاسم" الناتجة عن عدم الاتساق بين تكوين مراقبة Monit و PHP-FPM.

حمام دم ناجم عن مسار مقبس

القصة كالتالي.

لدي صديق تعطل خادمه مرة أخرى الشهر الماضي.

جاء إليّ وقال إنّ برنامج المراقبة (monit) يُبلغ باستمرار عن أخطاء، مُشيرًا إلى عدم قدرته على العثور على ملف php-fpm socket، ثمّ بدأت الخدمة بإعادة التشغيل بشكل متكرر، وارتفع الحمل عليها بشكل كبير. وقد تلقّى اتصالًا طارئًا في الساعة الثالثة صباحًا لإصلاح الخادم.

قلت لك ألا تذعر وأن تريني سجلات المراقبة.

عندما نظرت إليه، يا للعجب، كان مليئًا بهذه الأنواع من الأخطاء:

خطأ: خطأ في اتصال مقبس يونكس /run/php/php8.4-fpm.sock — لا يوجد ملف أو دليل بهذا الاسم: 'php8.4-fpm' faiاختبار بروتوكول LED [افتراضي] في /run/php/php8.4-fpm.sock — تعذر إنشاء مقبس يونكس لـ /run/php/php8.4-fpm.sock

سألته: "أين ملف المقبس الخاص بك الآن؟"

قال إنه لا يعرف، لذلك قمت بتثبيته بالإعدادات الافتراضية.

قلت لك انتظر، سأتحقق من الأمر بنفسي.

ثم قمت بتسجيل الدخول عبر SSH ورأيت أن ملف المقبس الخاص به كان يسمى... /run/php/php8.4-fpm-etufo.org.sock.

قلت يا صديقي، مسار المقبس الخاص بك عبارة عن شيئين مختلفين، ستكون معجزة لو كان بإمكانه التواصل.

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

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

لنبدأ بالحديث عن أكثر أنواع الأخطاء شيوعاً في سجلات المراقبة.

عندما ترى هذا:

خطأ: خطأ في اتصال مقبس يونكس /run/php/php8.4-fpm.sock — لا يوجد ملف أو دليل بهذا الاسم

يشير هذا إلى أن برنامج monit يحاول اكتشاف خدمة php-fpm من خلال هذا المقبس، لكنه لا يستطيع العثور على الملف.

ما سيحدث بعد ذلك هو أن برنامج monit سيحاول إعادة تشغيل الخدمة، وستظهر السجلات ما يلي:

معلومات: محاولة إعادة تشغيل 'php8.4-fpm' معلومات: إيقاف 'php8.4-fpm': '/usr/sbin/service php8.4-fpm stop' معلومات: بدء 'php8.4-fpm': '/usr/sbin/service php8.4-fpm start'

يبدو ذكياً جداً، أليس كذلك؟ إنه يصلح نفسه تلقائياً.

لكن المشكلة تكمن في أن إعادة التشغيل المتكررة هذه هي الكارثة الحقيقية.

تخيل هذا: عند إعادة تشغيل php-fpm، تتوقف جميع الطلبات قيد المعالجة، وقد تُفقد جميع الجلسات، ويجب إعادة إنشاء جميع الاتصالات. إذا تكررت إعادة التشغيل وفشلت خلال فترة قصيرة، سيرتفع حمل الخادم بشكل فوري.

ستكشف السجلات أيضًا عن مزيد من المعلومات، مثل هذه:

خطأ: 'etجسم غامضمتوسط ​​تحميل موقع .org (خلال 15 دقيقة) هو 8.8، وهو ما يتطابق مع حد الموارد [متوسط ​​التحميل (خلال 15 دقيقة) > 8.0] خطأ: 'etجسم غامضنسبة استخدام وحدة المعالجة المركزية في موقع .org تبلغ 33.9%، وهو ما يتوافق مع حد الموارد [نسبة استخدام وحدة المعالجة المركزية > 30.0%]

كان الخادم مُحمّلاً بالفعل بضغط عالٍ، لكن نظام المراقبة كان لا يزال يُعيد تشغيل الخدمة بشكل متكرر. لم يكن هذا يُطفئ حريقاً، بل كان يُزيد الطين بلة.

جوهر المشكلة: المفتاح والقفل لا يتطابقان.

عند التحليل الدقيق، يتضح أن المشكلة بسيطة للغاية.

مسار المقبس المحدد في ملف تكوين monit هو:/run/php/php8.4-fpm.sock

ومع ذلك، فإن مسار المقبس الفعلي الذي يعمل عليه php-fpm هو:/run/php/php8.4-fpm-etufo.org.sock

إذا كانت إحدى الوظائف مخصصة لاكتشاف الملف A، ولكن الأخرى هي في الواقع الملف B، فمن الواضح أن عملية الاكتشاف ستفشل.

هذا شيء ما.

لديك مفتاح، لكنه محبوس في غرفة أخرى.

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

في الحقيقة، القفل ليس مكسوراً؛ الأمر فقط أن مفتاحك لا يتطابق مع القفل.

يحلمراقبة المراقبةالتكوين غير متوافق مع PHP-FPM

الخيار الأول: تغيير إعدادات المراقبة.

إذا كنت ترغب في الاحتفاظ بتكوين المقبس الحالي لـ php-fpm، فقم بتعديل تكوين monit.

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

if failed unixsocket /run/php/php8.4-fpm.sock then restart

قم بتغييره إلى:

if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart

ثم قم بإعادة التحميل:

sudo monit reload

هذا كل شيء.

الخيار الثاني: تغيير إعدادات php-fpm.

إذا كنت ترغب في استخدام المسار الافتراضي، فقم بتغيير إعدادات مجموعة php-fpm.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confغيّر أمر الاستماع إلى:

listen = /run/php/php8.4-fpm.sock

ثم أعد تشغيل php-fpm:

sudo systemctl restart php8.4-fpm

هذا كل شيء.

كلا الحلين يمكن أن يحل المشكلة؛ ويعتمد اختيارك لأحدهما على ظروفك الخاصة.

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

دعوني أتحدث من صميم قلبي.

أعتقد حقاً أن هذا النوع من مشاكل التكوين هو الأكثر سهولة في التغاضي عنه ولكنه الأكثر تأثيراً على استقرار الخادم أثناء الصيانة.

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

قد تعتقد أن الخادم قديم جدًا ويحتاج إلى ترقية، ولكن قد يكون في الواقع أن المسار في ملف التكوين خاطئ.

وكما قال أحد الزملاء الكبار ذات مرة: "إن دقة المراقبة هي خط الدفاع الأول لضمان استقرار الخدمة".

التفاصيل تحدد النجاح أو الفشل، وهذا صحيح تمامًا في بيئة الخادم.

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

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