Monit memantau halaman dinamis situs web dan mendeteksi bahwa kode status bukan 200, dan secara otomatis memulai ulang php8.3-fpm

🚀 Ketika halaman dinamis pada situs web tiba-tiba memiliki kode status non-200, bagaimana PHP8.3-FPM dapat menyembuhkan dirinya sendiri dalam hitungan detik?​​

​​🔥 Konfigurasi penyelamat PHP90-FPM yang tidak diketahui 8.3% operator! Pengajaran praktis sistem penyembuhan otomatis halaman dinamis Monit.

Apakah menurut Anda pemantauan terhadap kelangsungan proses PHP-FPM sudah cukup? Benar-benar salah!
Ketika PHP-FPM di server tiba-tiba bermasalah, sekadar mengamati kelangsungan hidup proses ibarat menggunakan termometer untuk mengukur kanker - tidak mendeteksi masalah fatal sama sekali.

Aku melihat terlalu banyak orang yang menjagaphp-fpm.sockPemantauannya kurang maksimal dan akibatnya situs web tersebut sudah lama menjadi kuburan 404. Hari ini saya ingin menghancurkan ilusi operasi dan pemeliharaan ini dan menunjukkan kepada Anda kebenaran yang sebenarnya: proses yang langsung ≠ layanan yang normal.

🌪️ Skenario yang merusak: Soket terhubung, tetapi situs web mati

tertentuE-commercePemantauan situs web menunjukkan bahwa proses PHP-FPM berjalan normal, tetapi pengguna mengeluh tentang kegagalan pembayaran.

Setelah pencarian yang lama, saya menemukan bahwa kebocoran memori pada pustaka pihak ketiga menyebabkan proses PHP tetap hidup tetapi sama sekali tidak dapat memproses permintaan.

Saat ini, hanya mengandalkan deteksi soket seperti memeriksa denyut nadi zombie - Anda tidak dapat menemukan otaknya sama sekaliKematian.

💥 Solusi pemantauan double-kill yang menumbangkan kognisi

Buang saja pemantauan satu dimensi yang sudah ketinggalan zaman itu! Semua pakar terbaik menggunakan strategi pencekikan ganda: lapisan proses + lapisan bisnis.

Konfigurasi berikut akan memungkinkan server Anda memulihkan dirinya sendiri lebih cepat daripada personel operasi dan pemeliharaan dapat bangun dari tempat tidur ketika masalah terjadi:

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"

🔍 Detail fatal tersembunyi dalam parameter

• hostheaderParameter adalah jimat penyelamat dalam skenario CDN/penyeimbangan beban. Tanpa mereka, ini seperti mencari pesawat tempur siluman dengan kacamata penglihatan malam - Anda tidak dapat menangkap status ditangguhkan yang disebabkan oleh hilangnya header Host.

• for 3 cyclesDesain periode penyangga ini dengan sempurna menghindari positif palsu yang disebabkan oleh jitter jaringan. Itu seperti memasang peredam kejut pada sistem pengawasan untuk mencegah getaran tangan yang memicu tombol nuklir.

• Terakhirexec "/usr/bin/systemctl restart hestia"Ini adalah jurus pembunuh ulung. Ketika PHP-FPM gagal dihidupkan kembali selama 5 kali berturut-turut, saya membalik tabel dan memulai ulang seluruh panel hosting. Ini adalah trik yang saya curi dari mekanisme pemutus arus sistem perdagangan Wall Street.

🚨 Pelajaran yang dipetik dari rasa sakit dan penderitaan: 3 perangkap yang dapat merusak kesuksesan Anda

1. Penipuan sertifikat SSL: Setelah peningkatan,protocol httpsTidak menuliskannya menyebabkan pemantauan selalu salah menilainya sebagai hal yang normal. Kemudian saya mengetahui bahwa Monit versi lama tidak memverifikasi sertifikat secara default, yang membuat saya kehilangan bonus akhir tahun saya
2. Perangkap 401 pada halaman login: lupa menambahkan saat memantau halaman loginBasic AuthenticationHasilnya, setiap pengujian memicu permulaan ulang. Ini seperti menyiram taman dengan hidran kebakaran - cukup kuat tetapi sepenuhnya salah
3. Log Lubang Hitam: Sekali/var/log/monit.logKetika ukurannya meroket hingga 50G, kami menemukan bahwa beberapa orang idiot telah mengatur periode deteksi menjadi 1 detik. Ingat, log pemantauan itu sendiri adalah objek yang perlu dipantau!

💡 Langkah verifikasi dan debugging

1. Pemeriksaan sintaksis konfigurasi:

   monit -t
   

2. Konfigurasi kelebihan beban:

   monit reload

Tes Akhir

1. Tes Bunuh Diri: Langsungkill -9Matikan proses PHP-FPM dan lihat catatan kebangkitan dalam log pemantauan. Rasanya seperti menonton film zombi!
2. Penyuntikan racun: Sengaja memodifikasi halaman login untuk mengembalikan kode status 503 dan amati apakah sistem pemantauan dapat menyerang secara akurat. Saya menyebut metode ini "vaksin digital" - menyuntikkan sejumlah kecil virus ke dalam sistem terlebih dahulu untuk memaksakan respons imun dari sistem pemantauan. Saat alarm menyala liar dan layanan menyembuhkan dirinya sendiri, Anda akan melihat keinginan terkuat untuk bertahan hidup di dunia kode membara!