Kesalahan HTTP 503. Layanan Tidak Tersedia: Kasus dalam Dukungan Hosting

Pekerjaan dukungan hosting pada dasarnya adalah jenis yang sama, sebagian besar permintaan dari klien diselesaikan sesuai dengan skema yang dikembangkan dengan baik, tetapi kadang-kadang Anda masih harus menghadapi masalah non-sepele. Maka tugas utama sang insinyur adalah menemukan satu - satunya jalan yang benar yang akan mengarah ke solusinya. Pada artikel ini saya ingin berbicara tentang bagaimana kami menjumpai kesalahan mengambang "Kesalahan HTTP 503. Layanan Tidak Tersedia" di hosting bersama kami, bagaimana kami mencoba menangkapnya, mendiagnosisnya, dan mendapatkan akhir yang tidak terduga.

Mulailah

Hosting menyediakan pengguna dengan tumpukan Linux + Apache + Mysql + PHP dan bungkus manajemen. Dalam kasus kami, ini adalah bisnis ISP Manager 5 berdasarkan Centos 7 dengan konversi ke CloudLinux. Dari sisi administrasi, CloudLinux menyediakan alat untuk mengelola batas, serta pemilih PHP dengan berbagai mode operasi (CGI, FastCGI, LSAPI).



Kali ini seorang klien menghubungi kami dengan masalah berikut. Situsnya di mesin Wordpress secara berkala mulai memberikan 503 kesalahan, yang ia informasikan kepada kami.



Kode respons dimulai dengan 50x merujuk ke masalah sisi server. Ini bisa menjadi masalah dari situs itu sendiri dan server web yang melayani mereka.



Situasi umum di mana kami menerima kesalahan berikut:

• 500 Internal Server Error - cukup sering dikaitkan dengan kesalahan sintaksis dalam kode situs, atau dengan pustaka yang hilang / versi PHP yang tidak didukung. Mungkin juga ada masalah dengan menghubungkan ke database situs atau izin yang salah pada file / direktori
• 502 Bad Gateway - misalnya, jika Nginx merujuk ke port webserver Apache yang salah, atau proses Apache berhenti bekerja karena suatu alasan
• 504 Gateway Timeout - respons dari Apache tidak diterima dalam waktu yang ditentukan dalam konfigurasi server web
• 508 Batas sumber daya tercapai - batas sumber daya yang dialokasikan untuk pengguna telah terlampaui

Daftar ini hanya berisi beberapa kasus yang paling umum. Perlu juga dicatat bahwa ketika batas terlampaui, pengguna dapat menerima 500 dan 503 kesalahan.



Saat mendiagnosis kesalahan ini, langkah pertama adalah memeriksa log server web. Ini biasanya cukup untuk mengidentifikasi pelakunya dan memperbaiki masalahnya.



Mengenai kesalahan 503 dalam kasus kami, kami melihat entri di log:

[lsapi: error] [pid 49817] [client xxxx: 6801] [host XXX.XX] Kesalahan saat mengirim permintaan (GET /index.php HTTP / 1.0); uri (/index.php) panjang konten (0): ReceiveAckHdr: tidak ada yang dibaca dari backend (LVE ID 8514), periksa docs.cloudlinux.com/mod_lsapi_troubleshooting.html

Hanya berdasarkan pada log ini, tidak mungkin untuk menentukan apa masalahnya.

Diagnosis primer

Awalnya, kami memeriksa statistik pengguna yang melampaui batas. Kelebihan kecil dicatat pada hari-hari sebelumnya, tetapi kesalahan dalam log masih segar, apalagi, mereka muncul di log pada interval dari satu hingga beberapa menit.



Kami juga mempelajari rekomendasi CloudLinux menggunakan tautan yang disediakan di log kesalahan.

Mengubah parameter apa pun tidak membawa hasil apa pun.



Situs ini menggunakan database pada server Mysql 5.7 yang berjalan pada server yang sama dalam wadah Docker. Log kontainer berisi pesan:

[Note] Aborted connection 555 to db: 'dbname' user: 'username' host: 'x.x.x.x' (Got an error reading communication packets)

Di antara pesan-pesan ini ada pesan tentang koneksi terputus dari situs yang diselidiki. Ini memberi asumsi bahwa koneksi ke DBMS tidak dilakukan dengan benar. Untuk memeriksanya, kami menyebarkan salinan situs pada domain uji, mengonversi database situs ke versi Centos 7 asli dari DBMS 5.5.65-MariaDB. Di situs pengujian, beberapa ratus permintaan dieksekusi menggunakan utilitas curl. Kesalahan tidak dapat direproduksi. Tetapi hasil ini adalah permulaan dan setelah konversi database di situs produksi, masalahnya tetap ada.



Dengan demikian, masalah koneksi yang salah ke DBMS dihilangkan.



Saran berikutnya adalah untuk memeriksa apakah ada masalah dengan situs itu sendiri. Untuk melakukan ini, kami menyiapkan server virtual terpisah, di atasnya kami mengangkat lingkungan yang paling mirip. Satu-satunya perbedaan signifikan adalah kurangnya CloudLinux. Masalahnya tidak dapat direproduksi di server uji. Jadi, kami telah menentukan bahwa semuanya tertata dalam kode situs. Namun, kami mencoba menonaktifkan plugin Wordpress dengan cara yang sama, tetapi masalahnya tetap ada.



Akibatnya, kami sampai pada kesimpulan bahwa masalahnya ada di hosting kami.



Setelah menganalisis log dari situs lain, ditemukan bahwa masalah diamati pada banyak dari mereka. Sekitar 100 pcs. pada saat verifikasi:

/var/www/httpd-logs# grep -Rl "ReceiveAckHdr: nothing to read from backend" ./ | wc -l
99

Selama pengujian, kami menemukan bahwa CMS Wordpress bersih yang baru diinstal juga secara berkala memberikan kesalahan 503.



Kira-kira 2 bulan sebelumnya, kami melakukan pekerjaan untuk memodernisasi server, khususnya, kami mengubah mode operasi Apache dari Worker ke Prefork, agar dapat menggunakan PHP di LSAPI bukannya CGI lambat. Ada asumsi bahwa ini dapat mempengaruhi, atau beberapa pengaturan Apache tambahan diperlukan, tetapi kami tidak dapat mengembalikan mode Pekerja kembali. Selama perubahan mode operasi Apache, semua konfigurasi situs diubah, prosesnya tidak cepat dan tidak semuanya bisa berjalan dengan lancar.



Koreksi pengaturan Apache juga tidak memberikan hasil yang diinginkan.



Sepanjang jalan, kami mencari masalah serupa di mesin pencari. Di salah satu forum, peserta berpendapat bahwa hoster memiliki masalah dan perlu diubah jika masalah tidak terpecahkan. Kedengarannya tidak terlalu optimis ketika Anda berada di sisi lain, tetapi Anda dapat memahami klien. Mengapa dia membutuhkan hosting yang tidak berfungsi?



Pada tahap ini, kami telah mengumpulkan informasi yang tersedia dan hasil pekerjaan yang dilakukan. Mereka dihubungi untuk mendukung CloudLinux.

Diagnostik terperinci

Selama beberapa hari, staf pendukung CloudLinux menyelidiki masalah ini. Pada dasarnya, rekomendasi tersebut berkenaan dengan batas pengguna yang ditetapkan. Kami juga memeriksa pertanyaan ini. Dengan batas dinonaktifkan (opsi CageFS untuk pengguna) dan dengan batas yang diaktifkan dalam mode PHP sebagai modul Apache, masalahnya tidak diamati. Berdasarkan hal ini, telah disarankan bahwa CloudLinux mempengaruhi dalam beberapa cara. Akibatnya, pada akhir minggu permintaan meningkat ke tingkat dukungan ke-3, tetapi belum ada solusi.



Sepanjang jalan, kami mempelajari dokumentasi Apache pada mode CGI dan LSAPI, mengatur instance Apache kedua pada server hosting pada port yang berbeda dengan situs uji, menghilangkan pengaruh Nginx dengan mengirim permintaan langsung ke Apache dan menerima kode kesalahan yang sama.



Dokumentasi LSAPI membantu keluar dari kesalahan, hanya pada diagnosis 503 kesalahan:

www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki : php: 503-kesalahan

Pada bagian Pemecahan Masalah Lanjut, diusulkan untuk melacak proses yang ditemukan dalam sistem:

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done

Perintah telah disempurnakan untuk merekam semua proses dalam file dengan pengidentifikasi mereka.



Saat melihat file jejak, kami melihat beberapa baris yang sama:

cat trace.* | tail
...
47307 21:33:04.137893 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=42053, si_uid=0} ---
47307 21:33:04.140728 +++ killed by SIGHUP +++
...

Jika kita melihat deskripsi struktur sinyal yang dikirim oleh proses, kita akan melihatnya

pid_t    si_pid;       /* Sending process ID */

Menunjukkan pengidentifikasi proses yang mengirim sinyal.



Pada saat mempelajari jejak, proses dengan PID 42053 tidak lagi dalam sistem, oleh karena itu, dalam proses menangkap jejak, kami memutuskan untuk memantau proses yang mengirim sinyal SIGHUP juga.

Di bawah spoiler, tindakan dijelaskan yang memungkinkan untuk menentukan jenis prosesnya, serta mendapatkan jejaknya dan informasi tambahan tentang proses mana ia mengirimkan sinyal SIGHUP.





Hasilnya, kami mendapatkan nama prosesnya. /opt/alt/python37/bin/python3.7 -sbb /usr/sbin/cagefsctl --rebuild-alt-php-ini



Proses ini dilakukan dalam sistem satu menit sekali.



Kami melacak beberapa proses cagefsctl untuk melacak setidaknya satu dari awal hingga akhir:

for i in `seq 1 100`; do strace -p $(ps ax | grep cagefsctl | grep rebuild-alt-php-ini | grep -v grep | awk '{print $1}') -o /tmp/strace/cagefsctl.trace.$(date +%s); done;

Selanjutnya, kita pelajari apa yang dia lakukan, misalnya:

cat /tmp/strace/cagefsctl.trace.1593197892 | grep SIGHUP

ID proses juga diperoleh yang diakhiri dengan sinyal SIGHUP. Proses yang dihentikan adalah proses PHP yang sedang berjalan.



Data yang diterima ditransfer ke dukungan CloudLinux untuk mengklarifikasi keabsahan proses ini dan apakah harus bekerja dengan frekuensi seperti itu.



Kemudian, kami menerima jawaban bahwa pekerjaan tim /usr/sbin/cagefsctl --rebuild-alt-php-inidilakukan dengan benar, satu-satunya peringatan adalah bahwa tim dieksekusi terlalu sering. Biasanya disebut ketika pembaruan sistem atau pengaturan PHP berubah.



Satu-satunya petunjuk yang tersisa dalam kasus ini adalah untuk memeriksa siapa induk dari proses cagefsctl.



Hasilnya tidak lama datang, dan apa yang mengejutkan kami - proses induk untuk cagefsctl adalah proses ispmgrnode. Agak aneh, karena level logging untuk ISP Manager diatur ke maksimum dan panggilan cagefsctl tidak terlihat di ispmgr.log.



Sekarang ada cukup data untuk menghubungi dukungan Sistem ISP juga.

Ringkasan

Masalah ini dipicu setelah melakukan pembaruan ISP Manager. Secara umum, memperbarui ISP Manager adalah situasi normal, tetapi itu mengarah pada dimulainya proses sinkronisasi, yang berakhir dengan kesalahan dan dimulai kembali setiap menit. Proses sinkronisasi memanggil proses cagefsctl, yang kemudian menghentikan proses PHP.



Alasan untuk gagalnya proses sinkronisasi adalah pekerjaan yang dilakukan pada hosting untuk memodernisasi peralatan. Beberapa bulan sebelum masalah terjadi, drive PCI-e NVMe dipasang di server, partisi XFS dibuat dan dipasang di direktori / var. File pengguna juga ditransfer ke sana, tetapi kuota disk tidak diperbarui. Opsi mount tidak cukup, itu juga diperlukan untuk mengubah tipe sistem file dalam parameter ISP Manager, karena itu meminta perintah untuk memperbarui kuota disk. Untuk Ext4 dan XFS, perintah ini berbeda.



Dengan demikian, masalah itu terasa beberapa bulan setelah bekerja.

kesimpulan

Kami sendiri yang menciptakan masalah, tetapi tidak jelas sampai saat terakhir. Untuk masa depan, kami akan mencoba mempertimbangkan nuansa sebanyak mungkin. Dengan bantuan kolega yang lebih terlatih dari CloudLinux dan dukungan Sistem ISP, masalahnya teratasi. Sekarang hosting kami stabil. Dan kami telah memperoleh pengalaman yang akan bermanfaat bagi kami di pekerjaan mendatang.



PS: Saya harap Anda tertarik membaca artikel, dan itu akan membantu seseorang untuk dengan cepat menyelesaikan masalah yang sama.