Sering mengalami crash pada Apache2 dengan HestiaCP? Panduan pemantauan dan pemecahan masalah otomatis Monit (dengan konfigurasi lengkap)

Sering mengalami crash Apache2 atau kegagalan restart otomatis Monit di lingkungan HestiaCP ? Artikel ini memberikan panduan praktis untuk menghindari kesalahan umum saat memantau Apache2 dengan Monit, menganalisis secara mendalam masalah umum seperti ketidaksesuaian jalur PID dan pemblokiran izin, serta menawarkan file konfigurasi otomatisasi Monit tingkat produksi. Kuasai teknik pemeliharaan server ketersediaan tinggi sekarang dan raih pemulihan otomatis tingkat kedua dari kegagalan!

Kendala yang saya temui saat menggunakan Monit untuk memantau Apache2

Jumat lalu, server memberi saya peringatan Monit di tengah malam.

Aku melirik panel itu dengan linglung, dan di kolom status apache2, ada tulisan Timeout berwarna merah.

Saya memikirkannya sejenak. Saya baru saja menambahkan pemantauan Monit ke server siang hari, dan saya menyalin dan menempelkan konfigurasi dari tutorial online. Seharusnya tidak ada masalah, kan?

Keesokan paginya, proses tersebut kembali mengalami timeout. Setelah ketiga kalinya, Monitor akhirnya menyerah, dan panel menampilkan "Tidak dipantau".

SAYA...

Jujur saja, awalnya saya tidak menganggapnya serius. Pemantauan Apache2? Anda bisa menemukan banyak konfigurasi templat secara online, tinggal salin dan tempel. Tapi proses menempel itu benar-benar membuat saya marah.

Akar penyebab konflik antara arsitektur default HestiaCP dan port Monit

Pertama-tama, izinkan saya menunjukkan konfigurasi yang menyebabkan saya banyak masalah, agar Anda dapat melihat apakah konfigurasi tersebut sama persis dengan versi yang pernah 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

Sepertinya baik-baik saja, kan? Program ini memeriksa port 80, dan jika terjadi crash, maka akan memulai ulang. Jika masih terjadi crash setelah 5 kali memulai ulang, maka akan terjadi time out.

Masalahnya adalah, Apache2 Anda bahkan tidak berjalan di port 80.

Inilah kelemahan HestiaCP, dan akar penyebab banyak orang terjebak di dalamnya. Arsitektur default HestiaCP adalah reverse proxy dari Nginx + Apache2, dengan Nginx menempati port 80 dan 443 di depan, dan Apache2 berjalan di port lokal 8081 di belakang.

Jika Anda meminta Monit untuk memeriksa keaktifan Apache2 pada port 80, itu seperti pergi ke McDonald's untuk mencari KFC. Server menatap Anda dengan tatapan kosong, dan Anda berdua saling menatap. Pada akhirnya, Monit menyimpulkan bahwa Anda sedang down dan mulai melakukan restart dengan panik.

Setelah memulai ulang, port masih 8081. Monit kemudian mencoba untuk memeriksa port 80, yang juga gagal, sehingga ia memulai ulang lagi. Siklus ini berulang hingga Monit memutuskan bahwa ia tidak dapat diperbaiki lagi dan mengalami batas waktu.

Saat pertama kali saya menemui hal ini, saya benar-benar terkejut. Sembilan dari sepuluh tutorial yang saya temukan online menggunakan port 80. Jika Anda mengikutinya, masalahnya bukan pada Anda, tetapi pada sumber informasi itu sendiri.

File PID Apache2 yang rusak menyebabkan Monit salah mengidentifikasi proses tersebut sebagai tidak ada.

Setelah mengubah port dari 80 menjadi 8081, secara teori Monit seharusnya dapat mendeteksinya, bukan?

Namun, pada kenyataannya, terkadang masih muncul laporan "Eksekusi gagal ".

Setelah berjuang cukup lama, akhirnya saya menemukan penyebabnya sederhana: file PID rusak.

Bayangkan, Monit dengan panik memulai ulang Apache2, setiap kali secara paksa mematikan dan memulainya kembali, bolak-balik beberapa kali. Selama proses ini, file /var/run/apache2/apache2.pid mungkin menjadi 0 byte.

Dengan kata lain, file tersebut masih ada, tetapi kosong.

Saat Monit membaca file ini, ia tidak menemukan apa pun. Ia tidak mengenali Apache2 Anda, meskipun Apache2 Anda berjalan dengan baik di latar belakang; Monit menganggap proses tersebut tidak ada.

Saat melihat ini, saya terdiam sejenak.

Ini adalah kebuntuan. Monit gagal mendeteksi instance Apache 2, memulai ulang Apache2, merusak file PID selama proses memulai ulang, gagal dalam deteksi berikutnya, dan memulai ulang lagi. Siklus ini berlanjut hingga terjadi batas waktu habis.

Langkah-langkah Pemecahan Masalah dan Perbaikan untuk Pemantauan Apache2 di Lingkungan HestiaCP

Sejujurnya, proses investigasi tidak rumit, tetapi Anda perlu tahu ke arah mana harus melakukan investigasi.

Langkah pertama adalah menentukan port mana yang digunakan Apache2. Cukup ketikkan perintah di terminal.

netstat -tulpn | grep apache2

Alternatifnya, Anda dapat menggunakan perintah `ss`; efeknya sama.

ss -tulpn | grep apache2

Anda akan melihat output yang mirip dengan ini.

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

Sudah dipastikan bahwa angkanya adalah 8081, bukan 80. Itulah akar masalahnya.

Langkah kedua adalah memperbaiki file PID yang rusak. Ini lebih sederhana.

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

Pertama, jeda pemantauan Monit untuk mencegahnya mengganggu saat Anda memperbaiki masalah. Kemudian, mulai ulang Apache2 agar dapat menulis ulang PID yang bersih. Terakhir, gunakan `cat` untuk memeriksa isi file; file tersebut seharusnya berisi serangkaian angka, bukan string kosong.

Setelah langkah ini selesai, masalah pada dasarnya sudah terpecahkan.

Analisis Perbandingan Konfigurasi Proteksi Adaptif dan Agresif Tradisional Monit

Tutorial online tentang konfigurasi Apache2 dengan Monit umumnya terbagi menjadi dua kategori.

Salah satu jenisnya adalah "tipe adaptasi tradisional," yang menggunakan perintah `service` untuk mengelola layanan dan memeriksa port lokal tanpa menambahkan terlalu banyak batasan yang rumit. Konfigurasi ini dapat digunakan pada HestiaCP hanya dengan mengubah port, dan relatif stabil.

Pendekatan lain adalah metode "perlindungan agresif", yang menggunakan systemctl untuk mengelola layanan, menambahkan pembatasan proses anak, dan menerapkan logika deteksi yang lebih ketat. Sekilas tampak bagus, tetapi memiliki kelemahan fatal: perintah berhenti yang digunakan adalah `killall -9`.

Apa arti `killall -9`? Artinya mematikan perangkat secara paksa tanpa memperhatikan apa yang sedang dilakukannya. Operasi paksa ini dapat dengan mudah meninggalkan file PID yang rusak, yang merupakan masalah yang baru saja saya sebutkan.

Pengalaman pribadi saya menunjukkan bahwa membatasi jumlah proses anak dalam konfigurasi agresif memang bermanfaat. Ketika Apache2 Anda kewalahan oleh serangan CC, membatasi jumlah proses anak dapat mencegah server kehabisan memori. Namun, pendekatan `killall -9` benar-benar tidak dapat digunakan.

Jadi pada akhirnya saya berkompromi dan menggabungkan keunggulan dari kedua konfigurasi tersebut.

Konfigurasi Praktik Terbaik HestiaCP Apache2 Monit

Ubah file /etc/monit/conf.d/apache2 dengan konten 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 menjelaskan secara singkat logika di balik beberapa baris konfigurasi ini.

Tulis port 8081 agar sesuai persis dengan arsitektur reverse proxy HestiaCP; hentikan kesalahan penulisan pada port 80.

Gunakan perintah `systemctl stop` sebagai pengganti `killall -9` untuk menghentikan file PID, agar tidak merusaknya.

Batasan jumlah proses anak telah ditambahkan: jika jumlah proses anak melebihi 120, proses akan dimulai ulang setelah dua siklus berturut-turut untuk mencegah serangan CC, tetapi tidak terlalu agresif.

Logika untuk mendeteksi kegagalan telah dimodifikasi untuk menggunakan pendekatan "selama 2 siklus", yang berarti restart hanya dipicu setelah dua kegagalan berturut-turut, sehingga mengurangi false positive. Konfigurasi sebelumnya, yang melakukan restart setelah hanya satu deteksi, terus terang agak terlalu sensitif.

Ambang batas waktu habis akhir dilonggarkan menjadi 5 kali memulai ulang dalam 10 siklus, sehingga menyisakan toleransi kesalahan yang cukup.

HestiaCP Pemantauan pemantauanRingkasan Pemecahan Masalah Konfigurasi dan Berbagi Pengalaman

Setelah melakukan perubahan konfigurasi, saya memantau apache2, dan panel akhirnya menampilkan indikator "OK" berwarna hijau.

Bagaimana menggambarkan perasaan saya saat itu? Rasanya seperti menghabiskan dua hari bergelut dengan sebuah bug, hanya untuk mengetahui penyebabnya adalah satu baris konfigurasi yang salah. Itu membuat frustrasi sekaligus menggelikan.

Monit sendiri merupakan hal yang baik, dan memantau daemon adalah sesuatu yang seharusnya dilakukan setiap server. Namun masalahnya adalah banyak tutorial online didasarkan pada asumsi bahwa "Apache2 secara eksklusif menggunakan port 80," sementara HestiaCP menggunakan reverse proxy, yang berarti asumsi ini tidak benar.

Jika Anda mengikuti petunjuknya, masalahnya bukan pada Anda; masalahnya adalah tutorial tersebut berlaku untuk skenario yang berbeda dari skenario Anda.

Jadi, jika Anda juga menggunakan HestiaCP dan bereksperimen dengan Monit untuk memantau Apache2, ingatlah dua hal: Ubah port menjadi 8081, dan gunakan perintah `systemctl` untuk menghentikannya, bukan `killall -9`. Jika Anda melakukan kedua hal ini, Anda seharusnya dapat menghindari masalah lebih lanjut.

Karena Anda sudah membaca sampai sejauh ini, jika Anda merasa bermanfaat, silakan sukai dan bagikan. Jika Anda ingin menerima pembaruan lebih dulu, Anda juga bisa mengikuti saya!

Terima kasih telah membaca artikel saya. Sampai jumpa lagi.