خرابی‌های مکرر آپاچی۲ با HestiaCP؟ راهنمای نظارت و عیب‌یابی خودکار Monit (به همراه پیکربندی کامل)

خرابی‌های مکرر آپاچی۲ یا خرابی‌های راه‌اندازی مجدد خودکار Monit در محیط‌های HestiaCP ؟ این مقاله یک راهنمای عملی برای جلوگیری از مشکلات رایج هنگام نظارت بر آپاچی۲ با Monit ارائه می‌دهد، مسائل رایج مانند ناهماهنگی مسیر PID و مسدود کردن مجوز را عمیقاً تجزیه و تحلیل می‌کند و فایل‌های پیکربندی اتوماسیون Monit را در سطح تولید ارائه می‌دهد. اکنون بر تکنیک‌های نگهداری سرور با دسترسی بالا مسلط شوید و به بازیابی خودکار سطح دوم از خرابی‌ها دست یابید!

مشکلاتی که هنگام استفاده از Monit برای نظارت بر Apache2 با آنها مواجه شدم

جمعه‌ی گذشته، سرور نیمه‌شب به من هشدار Monit داد.

با گیجی نگاهی به پنل انداختم و در ستون وضعیت apache2، عبارت قرمز رنگ Timeout نوشته شده بود.

کمی در موردش فکر کردم. من همین الان مانیتورینگ Monit را در طول روز به سرور اضافه کردم و پیکربندی را از یک آموزش آنلاین کپی و پیست کردم. نباید مشکلی وجود داشته باشد، درست است؟

صبح روز بعد، دوباره زمانش تمام شد. بعد از بار سوم، مانیتور تسلیم شد و پنل عبارت «نظارت نمی‌شود» را نمایش داد.

من...

اعتراف می‌کنم، اولش جدی نگرفتم. مانیتورینگ آپاچی۲؟ کلی تنظیمات قالب آنلاین هست که فقط کافیه کپی و پیست کنید. اما این فرآیند پیست کردن واقعاً من رو عصبانی کرد.

علت اصلی اختلاف بین معماری پیش‌فرض 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

به نظر خوب میاد، درسته؟ پورت ۸۰ رو بررسی می‌کنه و اگه از کار بیفته، دوباره راه‌اندازی می‌شه. اگه بعد از ۵ بار راه‌اندازی دوباره هنوز از کار بیفته، timeout می‌شه.

مشکل این است که آپاچی۲ شما حتی روی پورت ۸۰ هم اجرا نمی‌شود.

این یکی از مشکلات HestiaCP است و دلیل اصلی افتادن بسیاری از افراد در آن. معماری پیش‌فرض HestiaCP یک پروکسی معکوس از Nginx + Apache2 است، که در آن Nginx پورت‌های ۸۰ و ۴۴۳ را در جلو اشغال می‌کند و Apache2 روی پورت محلی ۸۰۸۱ در پشت اجرا می‌شود.

اگر از مونیت بخواهید که فعال بودن آپاچی۲ روی پورت ۸۰ را بررسی کند، مثل این است که برای پیدا کردن کی‌اف‌سی به مک‌دونالد بروید. سرور با تعجب به شما نگاه می‌کند و شما دو نفر هم به یکدیگر خیره شده‌اید. در نهایت، مونیت تشخیص می‌دهد که شما از کار افتاده‌اید و شروع به راه‌اندازی مجدد سراسیمه می‌کند.

پس از راه‌اندازی مجدد، پورت هنوز ۸۰۸۱ است. سپس مونیت سعی می‌کند پورت ۸۰ را بررسی کند که آن هم ناموفق است، بنابراین دوباره راه‌اندازی می‌شود. این چرخه تا زمانی که مونیت تصمیم بگیرد که این مشکل قابل تعمیر نیست و زمان آن تمام می‌شود، تکرار می‌شود.

وقتی برای اولین بار با این موضوع مواجه شدم، واقعاً شوکه شدم. از هر ده آموزشی که به صورت آنلاین پیدا کردم، نه تای آنها از پورت ۸۰ استفاده می‌کردند. اگر آنها را دنبال کرده باشید، مشکل از شما نیست، بلکه از منبع اطلاعات است.

یک فایل PID خراب Apache2 باعث شد که Monit به اشتباه این فرآیند را ناموجود تشخیص دهد.

بعد از تغییر پورت از ۸۰ به ۸۰۸۱، از نظر تئوری، Monit باید بتواند آن را تشخیص دهد، درست است؟

با این حال، در واقعیت، هنوز هم گاهی اوقات گزارش می‌دهد: «اجرا ناموفق بود ».

بعد از مدت‌ها کلنجار رفتن، بالاخره فهمیدم دلیلش ساده است: فایل PID خراب شده بود.

در موردش فکر کنید، مونیت داشت دیوانه‌وار آپاچی۲ را دوباره راه‌اندازی می‌کرد، هر بار به زور آن را متوقف و دوباره راه‌اندازی می‌کرد، چندین بار این کار را تکرار می‌کرد. در طول این فرآیند، ممکن بود فایل /var/run/apache2/apache2.pid به ۰ بایت برسد.

به عبارت دیگر، فایل هنوز وجود دارد، اما خالی است.

وقتی مونیت این فایل را می‌خواند، چیزی پیدا نمی‌کند. آپاچی۲ شما را تشخیص نمی‌دهد، حتی اگر آپاچی۲ شما در پس‌زمینه کاملاً خوب اجرا شود؛ مونیت فکر نمی‌کند که این فرآیند وجود دارد.

وقتی اینو دیدم یه لحظه مات و مبهوت موندم.

این یک بن‌بست است. مونیت در شناسایی نمونه آپاچی ۲ شکست می‌خورد، آپاچی ۲ را مجدداً راه‌اندازی می‌کند، فایل PID را در طول فرآیند راه‌اندازی مجدد خراب می‌کند، در شناسایی بعدی شکست می‌خورد و دوباره راه‌اندازی مجدد می‌شود. این چرخه تا زمان وقوع timeout ادامه می‌یابد.

مراحل عیب‌یابی و تعمیر مانیتورینگ Apache2 در محیط HestiaCP

راستش را بخواهید، روند تحقیق پیچیده نیست، اما باید بدانید که از کدام جهت باید تحقیق کنید.

اولین قدم این است که مشخص کنید آپاچی۲ شما روی کدام پورت در حال گوش دادن است. کافیست یک دستور در ترمینال تایپ کنید.

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 خراب را به جا بگذارد، که همان مشکلی است که من به آن اشاره کردم.

تجربه شخصی من این است که محدود کردن تعداد فرآیندهای فرزند در یک پیکربندی تهاجمی واقعاً مفید است. وقتی آپاچی۲ شما توسط یک حمله CC از کار می‌افتد، محدود کردن تعداد فرآیندهای فرزند می‌تواند از پر شدن حافظه سرور جلوگیری کند. با این حال، رویکرد `killall -9` واقعاً غیرقابل استفاده است.

بنابراین در نهایت من مصالحه کردم و مزایای هر دو پیکربندی را با هم ترکیب کردم.

پیکربندی بهترین شیوه مانیتورینگ آپاچی ۲ HestiaCP

فایل /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

بگذارید منطق پشت این چند خط پیکربندی را به طور خلاصه توضیح دهم.

پورت ۸۰۸۱ را طوری بنویسید که دقیقاً با معماری پروکسی معکوس HestiaCP مطابقت داشته باشد؛ از نوشتن احمقانه پورت ۸۰ دست بردارید.

برای جلوگیری از خراب شدن فایل PID، به جای دستور `killall -9` از دستور `systemctl stop` استفاده کنید.

محدودیتی برای تعداد پردازش‌های فرزند اضافه شده است: اگر تعداد پردازش‌های فرزند از ۱۲۰ عدد بیشتر شود، پردازش پس از دو چرخه متوالی مجدداً راه‌اندازی می‌شود تا از حملات CC جلوگیری شود، اما این محدودیت خیلی تهاجمی نیست.

منطق تشخیص خطاها اصلاح شده است تا از رویکرد «برای ۲ چرخه» استفاده کند، به این معنی که راه‌اندازی مجدد فقط پس از دو خطای متوالی انجام می‌شود و موارد مثبت کاذب را کاهش می‌دهد. پیکربندی قبلی که تنها پس از یک تشخیص مجدداً راه‌اندازی می‌شد، صادقانه بگویم کمی بیش از حد حساس بود.

آستانه‌ی زمان پایان نهایی به ۵ راه‌اندازی مجدد در عرض ۱۰ سیکل کاهش می‌یابد و تحمل خطای کافی را حفظ می‌کند.

HestiaCP نظارت بر نظارتخلاصه عیب‌یابی پیکربندی و به اشتراک‌گذاری تجربه

بعد از ایجاد تغییرات پیکربندی، apache2 را زیر نظر گرفتم و در نهایت پنل یک نشانگر سبز "OK" نشان داد.

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

مونیت به خودی خود چیز خوبی است و نظارت بر دیمن‌ها چیزی است که هر سروری باید انجام دهد. اما مشکل این است که بسیاری از آموزش‌های آنلاین بر اساس این فرض هستند که "آپاچی۲ منحصراً از پورت ۸۰ استفاده می‌کند"، در حالی که HestiaCP از یک پروکسی معکوس استفاده می‌کند، به این معنی که این فرض درست نیست.

اگر دستورالعمل‌ها را دنبال کنید، مشکل از شما نیست؛ مشکل این است که این آموزش برای سناریویی متفاوت از سناریوی شما قابل اجرا است.

بنابراین اگر شما هم از HestiaCP استفاده می‌کنید و با Monit برای نظارت بر Apache2 سر و کله می‌زنید، فقط دو نکته را به خاطر داشته باشید: پورت را به ۸۰۸۱ تغییر دهید و از دستور `systemctl` برای متوقف کردن آن استفاده کنید، نه `killall -9`. اگر این دو کار را انجام دهید، باید بتوانید از مشکلات بیشتر جلوگیری کنید.

از آنجایی که تا اینجا را خوانده‌اید، اگر برایتان مفید بود، لطفاً آن را لایک کنید و به اشتراک بگذارید. اگر می‌خواهید زودتر از بقیه از به‌روزرسانی‌ها مطلع شوید، می‌توانید من را دنبال کنید!

ممنون که مقاله من را خواندید. دفعه بعد می‌بینمتان.