مونیت صفحات پویای وب‌سایت را رصد می‌کند و تشخیص می‌دهد که کد وضعیت ۲۰۰ نیست و به‌طور خودکار php200-fpm را مجدداً راه‌اندازی می‌کند.

🚀 وقتی یک صفحه پویا در یک وب‌سایت ناگهان کد وضعیتی غیر از ۲۰۰ دارد، PHP200-FPM چگونه می‌تواند در عرض چند ثانیه خود را ترمیم کند؟

🔥 پیکربندی نجات‌بخش PHP90-FPM که ۹۰٪ اپراتورها نمی‌دانند! آموزش عملی سیستم خودترمیمی صفحات پویای Monit.

آیا فکر می‌کنید نظارت بر بقای فرآیند PHP-FPM کافی است؟ کاملاً اشتباه!
وقتی PHP-FPM روی یک سرور ناگهان از کار می‌افتد، صرفاً نگاه کردن به بقای فرآیند مانند استفاده از دماسنج برای اندازه‌گیری سرطان است - اصلاً مشکل مهلک را تشخیص نمی‌دهد.

من افراد زیادی را دیده‌ام که نگهبانی می‌دهندphp-fpm.sockنظارت سهل‌انگارانه بود و در نتیجه، این وب‌سایت مدت‌هاست که به گورستانی از صفحات ۴۰۴ تبدیل شده است. امروز می‌خواهم این توهم عملیات و نگهداری را از بین ببرم و حقیقت تلخ را به شما نشان دهم: یک فرآیند زنده ≠ یک سرویس عادی.

🌪️ سناریوی مخرب: سوکت متصل است، اما وب‌سایت از کار افتاده است

مسلم - قطعیتجارت الکترونیکیمانیتورینگ وب‌سایت نشان می‌داد که فرآیند PHP-FPM به طور عادی در حال اجرا است، اما کاربران از عدم موفقیت در پرداخت‌ها شکایت داشتند.

بعد از جستجوی طولانی، متوجه شدم که یک نشت حافظه در یک کتابخانه شخص ثالث باعث شده است که فرآیند PHP فعال باشد اما کاملاً قادر به پردازش درخواست‌ها نباشد.

در حال حاضر، تکیه صرف بر تشخیص سوکت مانند بررسی نبض یک زامبی است - شما به هیچ وجه نمی‌توانید مغز را پیدا کنید.مرگ.

💥 یک راهکار نظارتی دوگانه که شناخت را مختل می‌کند

آن نظارت‌های تک‌بعدیِ منسوخ‌شده را دور بیندازید! بهترین متخصصان همگی از استراتژی خفه کردن مضاعف لایه فرآیند + لایه کسب و کار استفاده می‌کنند.

پیکربندی زیر به سرور شما اجازه می‌دهد تا در صورت بروز مشکل، سریع‌تر از زمانی که پرسنل عملیات و نگهداری می‌توانند از رختخواب برخیزند، خود را ترمیم کند:

check process php8.3-fpm with pidfile /run/php/php8.3-fpm.pid
    start program = "/usr/sbin/service php8.3-fpm start"
    stop program  = "/usr/sbin/service php8.3-fpm stop"
    if failed unixsocket /run/php/php8.3-fpm.sock then restart
    if failed 
        host www.chenweiliang.com 
        port 443
        protocol https
        request "/wp-login.php"
        status = 200
        hostheader www.chenweiliang.com
        for 3 cycles
    then restart
    if 5 restarts within 5 cycles then exec "/usr/bin/systemctl restart hestia"

🔍 جزئیات مهلک پنهان در پارامترها

• hostheaderپارامترها در سناریوهای CDN/تعادل بار، طلسم‌های نجات‌بخش هستند. بدون آنها، مثل این است که دنبال یک جنگنده‌ی رادارگریز با عینک دید در شب بگردید - نمی‌توانید حالت تعلیق ناشی از نبود هدر Host را تشخیص دهید.

• for 3 cyclesاین طراحی دوره بافر به طور کامل از مثبت‌های کاذب ناشی از لرزش شبکه جلوگیری می‌کند. مثل این است که یک ضربه‌گیر روی سیستم نظارتی نصب کنیم تا از لرزش دست که باعث فعال شدن دکمه هسته‌ای می‌شود، جلوگیری شود.

• آخرینexec "/usr/bin/systemctl restart hestia"این یک حرکت کشنده‌ی نهایی است. وقتی PHP-FPM برای ۵ بار متوالی نتوانست دوباره راه‌اندازی شود، اوضاع را برعکس کردم و کل پنل هاستینگ را دوباره راه‌اندازی کردم. این ترفندی است که من از مکانیزم قطع کننده مدار سیستم معاملاتی وال استریت دزدیده‌ام.

🚨 درس‌هایی که از درد و رنج آموخته می‌شود: ۳ تله‌ای که می‌تواند شما را شکست دهد

1. کلاهبرداری گواهی SSL: پس از ارتقا،protocol httpsننوشتن آن باعث می‌شود که مانیتورینگ همیشه آن را به عنوان یک امر عادی اشتباه تشخیص دهد. بعداً فهمیدم که نسخه قدیمی Monit به طور پیش‌فرض گواهی را تأیید نمی‌کرد، و این باعث شد پاداش پایان سال خود را از دست بدهم.
2. تله ۴۰۱ صفحه ورود: فراموش کردن اضافه کردن هنگام نظارت بر صفحه ورودBasic Authenticationدر نتیجه، هر آزمایش باعث راه‌اندازی مجدد می‌شود. مثل آبیاری باغچه با شیر آتش نشانی میمونه - به اندازه کافی قویه اما کاملاً اشتباهه
3. سیاه چاله لاگ: یک بار/var/log/monit.logوقتی اندازه به ۵۰ گیگا بایت رسید، متوجه شدیم که یک احمق دوره تشخیص را روی ۱ ثانیه تنظیم کرده است. به یاد داشته باشید، خودِ گزارش مانیتورینگ، شیئی است که باید مانیتور شود!

💡 مراحل تأیید و اشکال‌زدایی

1. بررسی سینتکس پیکربندی:

   monit -t
   

2. پیکربندی اضافه بار:

   monit reload

آزمون نهایی

1. تست خودکشی: مستقیمkill -9فرآیند PHP-FPM را متوقف کنید و رکوردهای احیا شده را در گزارش مانیتورینگ بررسی کنید. انگار داری فیلم زامبی میبینی!
2. تزریق سم: صفحه ورود را عمداً تغییر دهید تا کد وضعیت ۵۰۳ را برگرداند و مشاهده کنید که آیا سیستم مانیتورینگ می‌تواند به طور دقیق حمله کند یا خیر. من این روش را «واکسن دیجیتال» می‌نامم - تزریق مقدار کمی ویروس به سیستم از قبل برای وادار کردن سیستم نظارتی به واکنش ایمنی. وقتی آژیرها به طور وحشیانه‌ای چشمک می‌زنند و سرویس‌ها خود را درمان می‌کنند، خواهید دید که جذاب‌ترین اراده برای زنده ماندن در دنیای کد در حال سوختن است!