Kerap kali Apache2 mengalami ranap sistem dengan HestiaCP? Panduan pemantauan dan penyelesaian masalah automatik Monitor (dengan konfigurasi lengkap)

Kerap mengalami ranap Apache2 atau kegagalan mula semula automatik Monit dalam persekitaran HestiaCP ? Artikel ini menyediakan panduan praktikal untuk mengelakkan perangkap biasa semasa memantau Apache2 dengan Monit, menganalisis isu biasa secara mendalam seperti salah jajaran laluan PID dan penyekatan kebenaran, serta menawarkan fail konfigurasi automasi Monit gred pengeluaran. Kuasai teknik penyelenggaraan pelayan ketersediaan tinggi sekarang dan capai pemulihan automatik peringkat kedua daripada kegagalan!

Perangkap yang saya temui semasa menggunakan Monit untuk memantau Apache2

Jumaat lalu, pelayan memberi saya amaran Monit pada tengah malam.

Saya melirik panel itu dengan bingung, dan dalam lajur status apache2, terdapat Timeout berwarna merah.

Saya terfikir sejenak. Saya baru sahaja menambah pemantauan Monit ke pelayan pada siang hari, dan saya menyalin serta menampal konfigurasi daripada tutorial dalam talian. Sepatutnya tiada sebarang masalah, bukan?

Keesokan paginya, masa tamat sekali lagi. Selepas kali ketiga, Monitor berputus asa, dan panel memaparkan "Tidak dipantau".

saya...

Saya akui, saya tidak menganggapnya serius pada mulanya. Pemantauan Apache2? Anda boleh menemui banyak konfigurasi templat dalam talian, hanya salin dan tampal. Tetapi proses menampal itu benar-benar membuatkan saya berang.

Punca utama konflik antara seni bina lalai HestiaCP dan port Monit

Pertama sekali, izinkan saya tunjukkan konfigurasi yang menyebabkan saya begitu banyak masalah, supaya anda dapat melihat sama ada ia sama persis dengan versi yang telah anda lihat.

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

Nampaknya ok, kan? Ia menyemak port 80, dan jika ia ranap, ia akan dimulakan semula. Jika ia masih ranap selepas 5 kali dimulakan semula, ia akan tamat tempoh masa.

Masalahnya, Apache2 anda tidak berjalan pada port 80.

Ini merupakan perangkap HestiaCP, dan punca utama ramai orang terjerumus ke dalamnya. Seni bina lalai HestiaCP ialah proksi songsang Nginx + Apache2, dengan Nginx menempati port 80 dan 443 di hadapan, dan Apache2 berjalan pada port tempatan 8081 di belakang.

Jika anda meminta Monit untuk menyiasat keaktifan Apache2 pada port 80, ia seperti pergi ke McDonald's untuk mencari KFC. Pelayan memandang anda dengan pandangan kosong, dan anda berdua saling berpandangan. Akhirnya, Monit mendapati bahawa anda telah tergendala dan mula memulakan semula dengan tergesa-gesa.

Selepas dimulakan semula, port tersebut masih 8081. Monit kemudian cuba menyiasat port 80, yang juga gagal, jadi ia dimulakan semula. Kitaran ini berulang sehingga Monit memutuskan ia tidak dapat dibaiki dan tamat tempoh.

Apabila saya mula-mula menemui perkara ini, saya benar-benar terkejut. Sembilan daripada sepuluh tutorial yang saya temui dalam talian menggunakan port 80. Jika anda mengikutinya, masalahnya bukan pada anda, tetapi pada sumber maklumat itu sendiri.

Fail PID Apache2 yang rosak menyebabkan Monit tersilap mengenal pasti proses tersebut sebagai tidak wujud.

Selepas menukar port daripada 80 kepada 8081, Monit secara teorinya sepatutnya dapat mengesannya, bukan?

Walau bagaimanapun, pada hakikatnya, ia masih kadangkala melaporkan "Pelaksanaan gagal ".

Setelah bergelut untuk masa yang lama, saya akhirnya mendapati sebabnya mudah: fail PID telah rosak.

Fikirkanlah, Monit sedang memulakan semula Apache2 dengan tergesa-gesa, setiap kali mematikan dan memulakannya semula secara paksa, berulang-alik beberapa kali. Semasa proses ini, fail /var/run/apache2/apache2.pid mungkin menjadi 0 bait.

Dalam erti kata lain, fail itu masih ada di sana, tetapi ia kosong.

Apabila Monit membaca fail ini, ia tidak menemui apa-apa. Ia tidak mengenali Apache2 anda, walaupun Apache2 anda berjalan dengan baik di latar belakang; Monit berpendapat proses itu tidak wujud.

Apabila saya melihat ini, saya tergamam seketika.

Ini adalah kebuntuan. Monit gagal mengesan tika Apache 2, memulakan semula Apache2, merosakkan fail PID semasa proses mula semula, gagal dalam pengesanan seterusnya dan memulakan semula. Kitaran ini berterusan sehingga tamat masa berlaku.

Langkah Penyelesaian Masalah dan Pembaikan untuk Pemantauan Apache2 dalam Persekitaran HestiaCP

Sejujurnya, proses siasatan tidaklah rumit, tetapi anda perlu tahu arah mana yang hendak disiasat.

Langkah pertama adalah menentukan port mana yang digunakan oleh Apache2 anda untuk mendengar. Taip sahaja arahan di terminal.

netstat -tulpn | grep apache2

Sebagai alternatif, anda boleh menggunakan arahan `ss`; kesannya adalah sama.

ss -tulpn | grep apache2

Anda akan melihat output yang serupa dengan ini.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

Ia disahkan 8081, bukan 80. Itulah punca masalahnya.

Langkah kedua ialah membaiki fail PID yang rosak. Ini lebih mudah.

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

Pertama, jeda pemantauan Monit untuk mengelakkannya daripada mengganggu semasa anda membaiki sesuatu. Kemudian, mulakan semula Apache2 untuk membolehkannya menulis semula PID yang bersih. Akhir sekali, gunakan `cat` untuk menyemak kandungan fail; ia sepatutnya mengandungi rentetan nombor, bukan rentetan kosong.

Sebaik sahaja langkah ini selesai, masalahnya pada dasarnya diselesaikan.

Analisis Perbandingan Konfigurasi Perlindungan Adaptif dan Agresif Tradisional Monit

Tutorial dalam talian tentang mengkonfigurasi Apache2 dengan Monit secara amnya terbahagi kepada dua kategori.

Satu jenis ialah "jenis penyesuaian tradisional", yang menggunakan arahan `perkhidmatan` untuk mengurus perkhidmatan dan menyemak port tempatan tanpa menambah terlalu banyak sekatan yang rumit. Konfigurasi ini boleh digunakan pada HestiaCP hanya dengan menukar port, dan ia agak stabil.

Satu lagi pendekatan ialah kaedah "perlindungan agresif", yang menggunakan systemctl untuk mengurus perkhidmatan, menambah sekatan proses anak dan menggunakan logik pengesanan yang lebih ketat. Ia kelihatan hebat, tetapi mempunyai kelemahan yang fatal: arahan berhenti yang digunakan ialah `killall -9`.

Apakah maksud `killall -9`? Ia bermaksud membunuh peranti secara paksa tanpa mengira apa yang dilakukannya. Operasi kekerasan ini boleh meninggalkan fail PID yang rosak dengan mudah, iaitu masalah yang baru saya sebutkan.

Pengalaman peribadi saya ialah mengehadkan bilangan proses anak dalam konfigurasi yang agresif sememangnya berguna. Apabila Apache2 anda diserang oleh serangan CC, mengehadkan bilangan proses anak boleh menghalang pelayan daripada kehabisan memori. Walau bagaimanapun, pendekatan `killall -9` benar-benar tidak boleh digunakan.

Jadi pada akhirnya saya berkompromi dan menggabungkan kelebihan kedua-dua konfigurasi.

Konfigurasi Amalan Terbaik HestiaCP Apache2 Monit

Ubah suai fail /etc/monit/conf.d/apache2 dengan kandungan berikut.

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

Izinkan saya menerangkan secara ringkas logik di sebalik beberapa baris konfigurasi ini.

Tulis port 8081 untuk dipadankan dengan tepat dengan seni bina proksi songsang HestiaCP; berhenti menulis port 80 secara bodoh.

Gunakan arahan `systemctl stop` dan bukannya `killall -9` untuk menghentikan fail PID, supaya tidak merosakkannya.

Had proses anak telah ditambah: jika bilangan anak melebihi 120, proses akan dimulakan semula selepas dua kitaran berturut-turut untuk mencegah serangan CC, tetapi ia tidak terlalu agresif.

Logik untuk mengesan kegagalan telah diubah suai untuk menggunakan pendekatan "untuk 2 kitaran", yang bermaksud permulaan semula hanya dicetuskan selepas dua kegagalan berturut-turut, sekali gus mengurangkan positif palsu. Konfigurasi sebelumnya, yang dimulakan semula selepas hanya satu pengesanan, secara terus terang agak terlalu sensitif.

Ambang tamat masa terakhir dilonggarkan kepada 5 permulaan semula dalam 10 kitaran, meninggalkan toleransi kesalahan yang mencukupi.

HestiaCP Pemantauan monitRingkasan Penyelesaian Masalah Konfigurasi dan Perkongsian Pengalaman

Selepas membuat perubahan konfigurasi, saya memantau apache2, dan panel akhirnya menunjukkan penunjuk "OK" hijau.

Bagaimana untuk menggambarkan perasaan saya pada masa itu? Ia seperti menghabiskan dua hari bergelut dengan pepijat, hanya untuk mengetahui puncanya hanyalah satu baris konfigurasi yang salah. Ia mengecewakan dan menggelikan hati.

Monit sendiri merupakan satu perkara yang baik, dan pemantauan daemon adalah sesuatu yang perlu dilakukan oleh setiap pelayan. Tetapi masalahnya ialah banyak tutorial dalam talian adalah berdasarkan andaian bahawa "Apache2 secara eksklusif menggunakan port 80," manakala HestiaCP menggunakan proksi songsang, yang bermaksud andaian ini tidak benar.

Jika anda mengikuti arahan, masalahnya bukan anda; tetapi tutorial ini boleh digunakan untuk senario yang berbeza daripada anda.

Jadi, jika anda juga menggunakan HestiaCP dan bermain-main dengan Monit untuk memantau Apache2, ingat dua perkara: Tukar port kepada 8081, dan gunakan arahan `systemctl` untuk menghentikannya, bukan `killall -9`. Jika anda melakukan dua perkara ini, anda sepatutnya dapat mengelakkan sebarang masalah lagi.

Memandangkan anda telah membaca setakat ini, jika anda mendapati ia membantu, sila suka dan kongsikannya. Jika anda ingin menerima kemas kini terlebih dahulu, anda juga boleh mengikuti saya!

Terima kasih kerana membaca artikel saya. Jumpa lagi di lain masa.