HestiaCP سان Apache2 جا بار بار حادثا؟ مانيٽ خودڪار نگراني ۽ مسئلو حل ڪرڻ جي گائيڊ (مڪمل ترتيب سان)

HestiaCP ماحول ۾ بار بار Apache2 ڪريش يا Monit آٽو-ريسٽارٽ ناڪاميون؟ هي مضمون Monit سان Apache2 جي نگراني ڪرڻ وقت عام نقصانن کان بچڻ لاءِ هڪ عملي گائيڊ فراهم ڪري ٿو، عام مسئلن جهڙوڪ PID رستي جي غلط ترتيب ۽ اجازت بلاڪنگ، ۽ پيداوار-گريڊ Monit آٽوميشن ترتيب فائلون پيش ڪرڻ جو گہرا تجزيو ڪري ٿو. هاڻي اعليٰ دستيابي سرور جي سار سنڀال جي طريقن ۾ مهارت حاصل ڪريو ۽ ناڪامين کان ٻئي سطح جي خودڪار بحالي حاصل ڪريو!

Apache2 جي نگراني لاءِ Monit استعمال ڪندي مون کي جيڪي نقصان پهتا

گذريل جمعي تي، سرور مون کي رات جي وچ ۾ هڪ مونٽ الرٽ ڏنو.

مون حيرانگي سان پينل ڏانهن ڏٺو، ۽ apache2 اسٽيٽس ڪالم ۾، هڪ ڳاڙهي ٽائيم آئوٽ هو.

مون ان بابت ٿورو سوچيو. مون ڏينهن دوران سرور ۾ مونيٽ مانيٽرنگ شامل ڪئي، ۽ مون هڪ آن لائن سبق مان ترتيب ڪاپي ۽ پيسٽ ڪئي. ڪا به پريشاني نه هجڻ گهرجي، صحيح؟

ٻئي صبح، ان جو وقت ٻيهر ختم ٿيو. ٽئين دفعي کان پوءِ، مانيٽر بس هار مڃي ورتي، ۽ پينل "مانيٽر نه ڪيو ويو" ڏيکاريو.

مان...

مان تسليم ڪريان ٿو، مون پهرين ان کي سنجيدگي سان نه ورتو. Apache2 مانيٽرنگ؟ توهان آن لائن ڪيتريون ئي ٽيمپليٽ ترتيبون ڳولي سگهو ٿا، صرف ڪاپي ۽ پيسٽ ڪريو. پر ان پيسٽنگ جي عمل مون کي واقعي ڪاوڙائي ڇڏيو.

هيسٽيا سي پي جي ڊفالٽ آرڪيٽيڪچر ۽ مونٽ پورٽس جي وچ ۾ تڪرار جو بنيادي سبب

پهريان مان توهان کي اها ترتيب ڏيکاريان جنهن مون کي تمام گهڻي تڪليف ڏني، ته جيئن توهان ڏسي سگهو ته اهو بلڪل ان ورجن وانگر آهي جيڪو توهان ڏٺو آهي.

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 تي هلي ٿو.

جيڪڏهن توهان مونٽ کي پورٽ 80 تي Apache2 جي لائيونس جي جاچ ڪرڻ لاءِ چئو ٿا، ته اهو KFC ڳولڻ لاءِ ميڪ ڊونلڊز وڃڻ جهڙو آهي. سرور توهان کي خالي نظرن سان ڏسي ٿو، ۽ توهان ٻئي هڪ ٻئي کي ڏسندا آهيو. آخر ۾، مونٽ اهو طئي ڪري ٿو ته توهان هيٺ آهيو ۽ بيچيني سان ٻيهر شروع ڪرڻ شروع ڪري ٿو.

ٻيهر شروع ڪرڻ کان پوءِ، پورٽ اڃا تائين 8081 آهي. پوءِ مونٽ پورٽ 80 کي جانچڻ جي ڪوشش ڪندو آهي، جيڪو پڻ ناڪام ٿئي ٿو، تنهن ڪري اهو ٻيهر شروع ٿئي ٿو. هي چڪر ان وقت تائين ورجائيندو آهي جيستائين مونٽ فيصلو نه ڪري ته اهو مرمت کان ٻاهر آهي ۽ وقت ختم ٿي ويندو آهي.

جڏهن مون پهريون ڀيرو هن سان منهن ڏنو، ته مان واقعي حيران ٿي ويس. ڏهن مان نو سبق مون کي آن لائن استعمال ٿيل پورٽ 80 مليا. جيڪڏهن توهان انهن جي پيروي ڪئي، ته مسئلو توهان سان نه هو، پر معلومات جي ذريعن سان هو.

هڪ خراب ٿيل Apache2 PID فائل جي ڪري Monit غلطي سان عمل کي غير موجود طور سڃاڻي ورتو.

پورٽ کي 80 کان 8081 ۾ تبديل ڪرڻ کان پوءِ، مونٽ کي نظرياتي طور تي ان کي ڳولڻ جي قابل هوندو، صحيح؟

جڏهن ته، حقيقت ۾، اهو اڃا تائين ڪڏهن ڪڏهن "عمل درآمد ناڪام " جي رپورٽ ڪري ٿو.

گهڻي وقت تائين جدوجهد ڪرڻ کان پوءِ، آخرڪار مون کي خبر پئي ته سبب سادو هو: PID فائل خراب ٿي وئي هئي.

سوچيو، مونٽ بي رحمي سان Apache2 کي ٻيهر شروع ڪري رهيو هو، هر ڀيري زبردستي ان کي ماريندو ۽ ٻيهر شروع ڪندو رهيو، ڪيترائي ڀيرا اڳتي پوئتي ويندو رهيو. هن عمل دوران، فائل /var/run/apache2/apache2.pid 0 بائيٽ ٿي سگهي ٿي.

ٻين لفظن ۾، فائل اڃا تائين اتي آهي، پر اها خالي آهي.

جڏهن مونٽ هن فائل کي پڙهي ٿو، ته ان کي ڪجهه به نه ملي ٿو. اهو توهان جي Apache2 کي نٿو سڃاڻي، جيتوڻيڪ توهان جو Apache2 پس منظر ۾ بلڪل ٺيڪ هلي رهيو آهي؛ مونٽ کي اهو نه ٿو لڳي ته اهو عمل موجود آهي.

جڏهن مون هي ڏٺو، ته مان هڪ لمحي لاءِ بي زبان ٿي ويس.

هي هڪ ڊيڊ لاڪ آهي. مونٽ اپاچي 2 انسٽنس کي ڳولڻ ۾ ناڪام ٿئي ٿو، اپاچي 2 کي ٻيهر شروع ڪري ٿو، ٻيهر شروع ڪرڻ جي عمل دوران PID فائل کي خراب ڪري ٿو، ايندڙ ڳولا ۾ ناڪام ٿئي ٿو، ۽ ٻيهر شروع ٿئي ٿو. هي چڪر جاري رهي ٿو جيستائين وقت ختم نه ٿئي.

HestiaCP ماحول ۾ Apache2 مانيٽرنگ لاءِ مسئلا حل ڪرڻ ۽ مرمت جا مرحلا

سچ پڇو ته، جاچ جو عمل پيچيده ناهي، پر توهان کي ڄاڻڻ جي ضرورت آهي ته ڪهڙي طرف جاچ ڪجي.

پهريون قدم اهو طئي ڪرڻ آهي ته توهان جو 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

اهو 80 نه پر 8081 هجڻ جي تصديق ٿيل آهي. اها ئي مسئلي جي جڙ آهي.

ٻيو قدم خراب ٿيل PID فائل جي مرمت ڪرڻ آهي. هي آسان آهي.

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

پهرين، مونٽ مانيٽرنگ کي روڪيو ته جيئن توهان شيون درست ڪرڻ دوران ان کي مداخلت ڪرڻ کان روڪيو وڃي. پوءِ، Apache2 کي ٻيهر شروع ڪريو ته جيئن ان کي صاف PID ٻيهر لکڻ جي اجازت ملي سگهي. آخرڪار، فائل جي مواد کي چيڪ ڪرڻ لاءِ `cat` استعمال ڪريو؛ ان ۾ انگن جي هڪ تار هجڻ گهرجي، خالي تار نه.

هڪ دفعو هي قدم مڪمل ٿي ويندو، مسئلو بنيادي طور تي حل ٿي ويندو.

مانيٽ روايتي موافقت ۽ جارحاڻي حفاظتي ترتيبن جو تقابلي تجزيو

Apache2 کي Monit سان ترتيب ڏيڻ تي آن لائن سبق عام طور تي ٻن قسمن ۾ ورهايل آهن.

هڪ قسم "روايتي موافقت جو قسم" آهي، جيڪو خدمتن کي منظم ڪرڻ ۽ مقامي بندرگاهن کي چيڪ ڪرڻ لاءِ "سروس" ڪمانڊ استعمال ڪري ٿو بغير تمام گهڻيون پيچيده پابنديون شامل ڪرڻ جي. هي ترتيب صرف پورٽ کي تبديل ڪندي 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

مون کي مختصر طور تي ترتيب جي انهن چند لائينن جي پويان منطق جي وضاحت ڪرڻ ڏيو.

HestiaCP جي ريورس پراڪسي آرڪيٽيڪچر سان صحيح طور تي ملائڻ لاءِ پورٽ 8081 لکو؛ بيوقوفي سان پورٽ 80 لکڻ بند ڪريو.

PID فائل کي روڪڻ لاءِ `killall -9` جي بدران `systemctl stop` ڪمانڊ استعمال ڪريو، ته جيئن ان کي خراب نه ٿئي.

ٻارن جي عمل جي حد شامل ڪئي وئي آهي: جيڪڏهن ٻارن جو تعداد 120 کان وڌيڪ آهي، ته پوءِ اهو عمل ٻن لڳاتار چڪرن کان پوءِ ٻيهر شروع ٿيندو ته جيئن CC حملن کي روڪي سگهجي، پر اهو تمام گهڻو جارحاڻو نه آهي.

ناڪامين جي سڃاڻپ لاءِ منطق کي "2 چڪرن لاءِ" طريقو استعمال ڪرڻ لاءِ تبديل ڪيو ويو آهي، مطلب ته ٻيهر شروع ڪرڻ صرف ٻن مسلسل ناڪامين کان پوءِ شروع ٿئي ٿو، غلط مثبت کي گهٽائي ٿو. پوئين ترتيب، جيڪا صرف هڪ ڳولا کان پوءِ ٻيهر شروع ٿي، واضح طور تي ٿورو گهڻو حساس هو.

آخري ٽائم آئوٽ جي حد کي 10 چڪرن اندر 5 ٻيهر شروع ڪرڻ تائين آرام ڏنو ويو آهي، ڪافي غلطي برداشت ڪرڻ ڇڏيندي.

HestiaCP نگراني جي نگرانيترتيب جي مسئلي جي حل جو خلاصو ۽ تجربو شيئرنگ

ترتيب ۾ تبديليون ڪرڻ کان پوءِ، مون apache2 کي مانيٽر ڪيو، ۽ پينل آخرڪار هڪ سائو "OK" اشارو ڏيکاريو.

ان وقت پنهنجن احساسن کي ڪيئن بيان ڪريان؟ اهو هڪ بگ سان جدوجهد ڪندي ٻه ڏينهن گذارڻ جهڙو هو، صرف سبب ڳولڻ لاءِ ترتيب جي هڪ لائن هئي جيڪا غلط هئي. اهو مايوس ڪندڙ ۽ کلڻ وارو ٻئي هو.

مونيٽ پاڻ ۾ هڪ سٺي شيءِ آهي، ۽ ڊيمن جي نگراني هڪ اهڙي شيءِ آهي جيڪا هر سرور کي ڪرڻ گهرجي. پر مسئلو اهو آهي ته ڪيترائي آن لائن سبق ان مفروضي تي ٻڌل آهن ته "Apache2 خاص طور تي پورٽ 80 استعمال ڪري ٿو،" جڏهن ته HestiaCP هڪ ريورس پراڪسي استعمال ڪري ٿو، جنهن جو مطلب آهي ته هي مفروضو سچ نٿو رهي.

جيڪڏهن توهان هدايتن تي عمل ڪريو ٿا، ته مسئلو توهان جو ناهي؛ اهو آهي ته سبق توهان جي ڀيٽ ۾ مختلف منظرنامي تي لاڳو ٿئي ٿو.

تنهن ڪري جيڪڏهن توهان HestiaCP استعمال ڪري رهيا آهيو ۽ Apache2 جي نگراني لاءِ Monit سان راند ڪري رهيا آهيو، ته پوءِ صرف ٻه شيون ياد رکو: پورٽ کي 8081 ۾ تبديل ڪريو، ۽ ان کي روڪڻ لاءِ `systemctl` ڪمانڊ استعمال ڪريو، `killall -9` نه. جيڪڏهن توهان اهي ٻه شيون ڪندا آهيو، ته توهان کي وڌيڪ مسئلن کان بچڻ گهرجي.

جيئن ته توهان هن وقت تائين پڙهيو آهي، جيڪڏهن توهان کي اهو مددگار لڳو، مهرباني ڪري ان کي پسند ڪريو ۽ شيئر ڪريو. جيڪڏهن توهان پهرين اپڊيٽ حاصل ڪرڻ چاهيو ٿا، ته توهان مون کي فالو پڻ ڪري سگهو ٿا!

منهنجو مضمون پڙهڻ لاءِ مهرباني. ايندڙ ڀيري ملنداسين.