Monitはウェブサイトの動的ページを監視し、ステータスコードが200ではないことを検出し、自動的にphp8.3-fpmを再起動します。

🚀 ウェブサイト上の動的ページに突然 200 以外のステータス コードが表示された場合、PHP8.3-FPM はどのようにして数秒で自己修復できるのでしょうか?

🔥 オペレーターの 90% が知らない PHP8.3-FPM の救命設定! Monit 動的ページ自己修復システムの実践的な指導。

PHP-FPM プロセスの生存を監視するだけで十分だと思いますか?完全に間違っています!
サーバー上の PHP-FPM が突然おかしくなった場合、単にプロセスの生存を確認するだけでは、温度計で癌を測定するのと同じで、致命的な問題はまったく検出されません。

ガードする人を見すぎたphp-fpm.sock監視が不十分だったため、その結果、Web サイトは長い間 404 の墓場と化していました。今日は、この運用とメンテナンスの幻想を打ち砕き、厳然たる真実をお見せしたいと思います。ライブ プロセス ≠ 通常のサービスです。

🌪️ 破壊的なシナリオ: ソケットは接続されているが、Web サイトが機能していない

確かなEコマースウェブサイトの監視では、PHP-FPM プロセスは正常に実行されていたが、ユーザーからは支払いの失敗に関する苦情が寄せられていた。

長い調査の後、サードパーティのライブラリのメモリリークが原因で、PHP プロセスは稼働しているものの、リクエストをまったく処理できない状態になっていることがわかりました。

現時点では、ソケット検出だけに頼るのはゾンビの脈拍をチェックするようなもので、脳は全く見つからない。死。

💥 認知を覆す二重殺害監視ソリューション

時代遅れの一次元監視を捨てましょう!最高の専門家は皆、プロセス層 + ビジネス層の二重絞め殺し戦略を採用しています。

次の構成により、問題が発生したときに運用および保守担当者がベッドから起き上がるよりも早くサーバーが自己修復できるようになります。

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"

🔍 パラメータに隠された致命的な詳細

• hostheaderパラメータは、CDN/負荷分散シナリオにおける命綱です。これらがなければ、暗視ゴーグルを装着したステルス戦闘機を探すようなものです。つまり、Host ヘッダーの欠落によって発生する中断状態を検出できません。

• for 3 cyclesこのバッファ期間の設計により、ネットワーク ジッタによる誤検知が完全に回避されます。それは、手の震えによって核ボタンが作動するのを防ぐために監視システムにショックアブソーバーを設置するようなものです。

• 最後exec "/usr/bin/systemctl restart hestia"それは究極の必殺技です。 PHP-FPM が 5 回連続で復活に失敗したとき、私はテーブルをひっくり返し、ホスティング パネル全体を再起動しました。これはウォール街の取引システムのサーキットブレーカー機構から私が盗んだトリックです。

🚨 痛みと苦しみから学んだ教訓：失敗につながる3つの罠

1. SSL証明書詐欺:アップグレード後、protocol https書き込まないと、監視で常に正常であると誤判断されてしまいます。後で、Monitの古いバージョンではデフォルトで証明書を検証していなかったことがわかり、年末ボーナスを失いました。
2. ログインページ401トラップ: ログインページを監視する際に追加するのを忘れるBasic Authenticationその結果、各テストは再起動をトリガーします。それは消火栓で庭に水をまくようなものだ。十分に強力だが、完全に間違っている。
3. ログブラックホール：一度/var/log/monit.logサイズが 50G に急上昇したとき、誰かが検出期間を 1 秒に設定していたことが判明しました。監視ログ自体が監視する必要があるオブジェクトであることを忘れないでください。

💡 検証とデバッグの手順

1. 構成構文のチェック:

   monit -t
   

2. オーバーロード構成:

   monit reload

最終テスト

1. 自殺テスト：直接kill -9PHP-FPM プロセスを終了し、監視ログの復活記録を確認します。まるでゾンビ映画を観ているようです！
2. ポイズンインジェクション: ログインページを意図的に変更して 503 ステータス コードを返すようにし、監視システムが正確に攻撃できるかどうかを観察します。私はこの方法を「デジタルワクチン」と呼んでいます。これは、監視システムの免疫反応を強制的に排除するために、事前に少量のウイルスをシステムに注入するものです。警報が激しく鳴り響き、サービスが自己修復すると、コードの世界で生き残ろうとする最もセクシーな意志が燃え上がるのがわかります。