HestiaCP সহ Apache2 ঘন ঘন ক্র্যাশ করছে? Monit স্বয়ংক্রিয় মনিটরিং এবং সমস্যা সমাধানের নির্দেশিকা (সম্পূর্ণ কনফিগারেশন সহ)

HestiaCP পরিবেশে Apache2 ঘন ঘন ক্র্যাশ করছে বা Monit অটো-রিস্টার্ট ব্যর্থ হচ্ছে? এই নিবন্ধটি Monit দিয়ে Apache2 মনিটর করার সময় সাধারণ ভুলগুলো এড়ানোর জন্য একটি কার্যকরী নির্দেশিকা প্রদান করে, PID পাথ মিসঅ্যালাইনমেন্ট এবং পারমিশন ব্লকিং-এর মতো সাধারণ সমস্যাগুলো গভীরভাবে বিশ্লেষণ করে এবং প্রোডাকশন-গ্রেড 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

এটা ঠিকই মনে হচ্ছে, তাই না? এটি পোর্ট ৮০ পরীক্ষা করে এবং ক্র্যাশ করলে আবার চালু হয়। পাঁচবার রিস্টার্ট করার পরেও যদি এটি ক্র্যাশ করে, তাহলে এর টাইম আউট হয়ে যায়।

সমস্যাটি হলো, আপনার Apache2 পোর্ট ৮০-তে চলছেই না।

এটি HestiaCP-এর একটি দুর্বলতা, এবং বহু মানুষের এই ফাঁদে পড়ার মূল কারণ। HestiaCP-এর ডিফল্ট আর্কিটেকচার হলো Nginx + Apache2-এর একটি রিভার্স প্রক্সি, যেখানে সামনে Nginx ৮০ এবং ৪৪৩ পোর্ট ব্যবহার করে এবং পেছনে Apache2 লোকাল পোর্ট ৮০৮১-এ চলে।

আপনি যদি মনিটকে পোর্ট ৮০-তে অ্যাপাচি২-এর সচলতা পরীক্ষা করতে বলেন, তবে তা অনেকটা ম্যাকডোনাল্ডসে কেএফসি খুঁজতে যাওয়ার মতো। সার্ভারটি আপনার দিকে ফ্যালফ্যাল করে তাকিয়ে থাকে, আর আপনারা দুজন একে অপরের দিকে একদৃষ্টে চেয়ে থাকেন। অবশেষে, মনিট বুঝতে পারে যে আপনার সার্ভারটি ডাউন হয়ে গেছে এবং পাগলের মতো রিস্টার্ট করতে শুরু করে।

রিস্টার্ট করার পরেও পোর্টটি ৮০৮১-ই থাকে। এরপর মনিট ৮০ নম্বর পোর্ট প্রোব করার চেষ্টা করে, যা-ও ব্যর্থ হয়, তাই এটি আবার রিস্টার্ট হয়। এই চক্রটি চলতে থাকে যতক্ষণ না মনিট এটিকে মেরামতের অযোগ্য মনে করে এবং টাইম আউট হয়ে যায়।

যখন আমি প্রথম এর সম্মুখীন হলাম, আমি সত্যিই হতবাক হয়ে গিয়েছিলাম। অনলাইনে আমি যে দশটি টিউটোরিয়াল খুঁজে পেয়েছিলাম, তার মধ্যে নয়টিতেই পোর্ট ৮০ ব্যবহার করা হয়েছিল। আপনি যদি সেগুলো অনুসরণ করতেন, তাহলে সমস্যাটা আপনার ছিল না, বরং তথ্যের উৎসটিরই ছিল সমস্যা।

একটি ত্রুটিপূর্ণ Apache2 PID ফাইলের কারণে Monit ভুলবশত প্রসেসটিকে অস্তিত্বহীন হিসেবে চিহ্নিত করেছিল।

পোর্ট ৮০ থেকে ৮০৮১-এ পরিবর্তন করার পর, তত্ত্বগতভাবে মনিট এটি শনাক্ত করতে পারার কথা, তাই না?

তবে বাস্তবে, এটি এখনও মাঝে মাঝে "Execution failed " রিপোর্ট করে।

অনেকক্ষণ চেষ্টার পর আমি অবশেষে কারণটা খুঁজে পেলাম, যা ছিল খুবই সহজ: পিআইডি ফাইলটি নষ্ট হয়ে গিয়েছিল।

ভেবে দেখুন, মনিট পাগলের মতো অ্যাপাচি২ রিস্টার্ট করছিল, প্রতিবারই জোর করে কিল করে আবার রিস্টার্ট করছিল, এভাবে বেশ কয়েকবার করা-নেওয়া করছিল। এই প্রক্রিয়ার সময়, /var/run/apache2/apache2.pid ফাইলটির সাইজ ০ বাইট হয়ে যেতে পারত।

অন্য কথায়, ফাইলটি এখনও আছে, কিন্তু সেটি খালি।

যখন মনিট এই ফাইলটি পড়ে, তখন এটি কিছুই খুঁজে পায় না। এটি আপনার Apache2-কে চিনতে পারে না, এমনকি যদি আপনার Apache2 ব্যাকগ্রাউন্ডে পুরোপুরি ঠিকঠাকভাবে চলেও; মনিট মনে করে যে প্রসেসটির কোনো অস্তিত্ব নেই।

এটা দেখে আমি মুহূর্তের জন্য নির্বাক হয়ে গিয়েছিলাম।

এটি একটি অচলাবস্থা। মনিট অ্যাপাচি ২ ইনস্ট্যান্সটি শনাক্ত করতে ব্যর্থ হয়, অ্যাপাচি২ রিস্টার্ট করে, রিস্টার্ট প্রক্রিয়ার সময় পিআইডি ফাইলটি নষ্ট করে ফেলে, পরবর্তী শনাক্তকরণে ব্যর্থ হয় এবং আবার রিস্টার্ট করে। টাইমআউট না হওয়া পর্যন্ত এই চক্রটি চলতে থাকে।

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

এটা নিশ্চিত যে সংখ্যাটি ৮০৮১, ৮০ নয়। এটাই সমস্যার মূল কারণ।

দ্বিতীয় ধাপ হলো ত্রুটিপূর্ণ পিআইডি ফাইলটি মেরামত করা। এটি তুলনামূলকভাবে সহজ।

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

প্রথমে, Monit মনিটরিং থামিয়ে দিন, যাতে আপনি সমস্যা সমাধানের সময় এটি কোনো বাধা সৃষ্টি না করে। তারপর, Apache2 রিস্টার্ট করুন, যাতে এটি একটি নতুন PID পুনরায় লিখতে পারে। সবশেষে, `cat` ব্যবহার করে ফাইলের বিষয়বস্তু পরীক্ষা করুন; এতে সংখ্যার একটি স্ট্রিং থাকা উচিত, কোনো খালি স্ট্রিং নয়।

এই ধাপটি সম্পন্ন হলেই সমস্যাটি মূলত সমাধান হয়ে যায়।

মনিটের ঐতিহ্যবাহী অভিযোজিত এবং আক্রমণাত্মক প্রতিরক্ষামূলক বিন্যাসের তুলনামূলক বিশ্লেষণ

Monit-এর সাথে Apache2 কনফিগার করার অনলাইন টিউটোরিয়ালগুলো সাধারণত দুটি শ্রেণীতে বিভক্ত।

এক ধরনের কনফিগারেশন হলো "প্রচলিত অভিযোজন পদ্ধতি", যা খুব বেশি জটিল বিধিনিষেধ যোগ না করেই সার্ভিস পরিচালনা করতে এবং স্থানীয় পোর্ট পরীক্ষা করতে `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

এই কয়েকটি কনফিগারেশন লাইনের পেছনের যুক্তিটি আমি সংক্ষেপে ব্যাখ্যা করছি।

HestiaCP-এর রিভার্স প্রক্সি আর্কিটেকচারের সাথে হুবহু মিল রেখে পোর্ট ৮০৮১ লিখুন; নির্বোধের মতো পোর্ট ৮০ লেখা বন্ধ করুন।

PID ফাইলটি যাতে নষ্ট না হয়, সেজন্য এটিকে বন্ধ করতে `killall -9` এর পরিবর্তে `systemctl stop` কমান্ডটি ব্যবহার করুন।

একটি চাইল্ড প্রসেস সীমা যোগ করা হয়েছে: যদি চাইল্ডের সংখ্যা ১২০ ছাড়িয়ে যায়, তাহলে সিসি অ্যাটাক প্রতিরোধ করার জন্য প্রসেসটি পরপর দুটি চক্রের পর রিস্টার্ট হবে, তবে এটি খুব বেশি কঠোর নয়।

ব্যর্থতা শনাক্ত করার লজিকটি '২ সাইকেলের জন্য' পদ্ধতি ব্যবহার করার জন্য পরিবর্তন করা হয়েছে, যার অর্থ হলো পরপর দুটি ব্যর্থতার পরেই কেবল রিস্টার্ট ট্রিগার হবে, যা ফলস পজিটিভ কমিয়ে দেয়। আগের কনফিগারেশনটি, যা মাত্র একটি শনাক্তকরণের পরেই রিস্টার্ট হতো, সত্যি বলতে একটু বেশিই সংবেদনশীল ছিল।

চূড়ান্ত টাইমআউটের সীমা শিথিল করে ১০ সাইকেলের মধ্যে ৫ বার রিস্টার্টের সুযোগ রাখা হয়েছে, যা পর্যাপ্ত ফল্ট টলারেন্স বজায় রাখে।

HestiaCP মনিটরিংকনফিগারেশন সমস্যা সমাধানের সারাংশ এবং অভিজ্ঞতা বিনিময়

কনফিগারেশন পরিবর্তনগুলো করার পর, আমি apache2 পর্যবেক্ষণ করলাম এবং প্যানেলটিতে অবশেষে একটি সবুজ "OK" নির্দেশক দেখা গেল।

সেই সময়ের অনুভূতিটা কীভাবে বর্ণনা করব? ব্যাপারটা ছিল অনেকটা এমন যে, একটা বাগ নিয়ে দু'দিন ধরে যুদ্ধ করার পর অবশেষে জানা গেল যে, এর কারণ ছিল কনফিগারেশনের মাত্র একটি ভুল লাইন। ব্যাপারটা একই সাথে হতাশাজনক এবং হাস্যকর ছিল।

Monit নিজে থেকেই একটি ভালো জিনিস, এবং ডেমন মনিটর করা প্রতিটি সার্ভারেরই উচিত। কিন্তু সমস্যা হলো, অনেক অনলাইন টিউটোরিয়াল এই অনুমানের উপর ভিত্তি করে তৈরি যে "Apache2 শুধুমাত্র পোর্ট ৮০ ব্যবহার করে," অথচ HestiaCP একটি রিভার্স প্রক্সি ব্যবহার করে, যার মানে এই অনুমানটি সঠিক নয়।

আপনি যদি নির্দেশনাগুলো অনুসরণ করেন, তাহলে সমস্যাটা আপনার নয়; সমস্যা হলো টিউটোরিয়ালটি আপনার পরিস্থিতি থেকে ভিন্ন একটি পরিস্থিতির জন্য প্রযোজ্য।

সুতরাং, আপনিও যদি HestiaCP ব্যবহার করেন এবং Apache2 মনিটর করার জন্য Monit নিয়ে কাজ করেন, তাহলে দুটি জিনিস মনে রাখবেন: পোর্টটি পরিবর্তন করে 8081 করুন, এবং এটিকে বন্ধ করার জন্য `systemctl` কমান্ড ব্যবহার করুন, `killall -9` নয়। এই দুটি কাজ করলে, আপনি আর কোনো সমস্যা এড়াতে পারবেন।

যেহেতু আপনি এতদূর পড়েছেন, যদি এটি আপনার উপকারে এসে থাকে, তবে অনুগ্রহ করে লাইক ও শেয়ার করুন। সবার আগে আপডেট পেতে চাইলে আমাকে ফলোও করতে পারেন!

আমার লেখাটি পড়ার জন্য ধন্যবাদ। আবার দেখা হবে।