HestiaCPとApache2のクラッシュが頻繁に発生しますか？Monitによる自動監視とトラブルシューティングガイド（完全な設定方法付き）

HestiaCP環境でApache2のクラッシュやMonitの自動再起動が頻繁に発生していませんか？この記事では、Monitを使用してApache2を監視する際によくある落とし穴を回避するための実践的なガイドを提供します。PIDパスの不整合や権限のブロックといった一般的な問題を詳細に分析し、本番環境レベルのMonit自動化設定ファイルを提供します。今すぐ高可用性サーバーメンテナンス技術を習得し、障害発生時の第2レベルの自動復旧を実現しましょう！

Apache2の監視にMonitを使用する際に遭遇した落とし穴

先週の金曜日、真夜中にサーバーからMonitアラートが届きました。

ぼうぜんとパネルをちらりと見ると、apache2のステータス欄に赤い「タイムアウト」と表示されていた。

少し考えてみました。日中にサーバーにMonitの監視機能を追加したばかりで、オンラインチュートリアルの設定をコピー＆ペーストしただけです。問題はないはずですよね？

翌朝、再びタイムアウトが発生した。3度目のタイムアウトの後、モニターは完全に諦め、パネルには「監視対象外」と表示された。

私...

正直に言うと、最初は真剣に受け止めていませんでした。Apache2の監視？ネット上にテンプレート設定が山ほどあるから、コピー＆ペーストすればいいだけだろう、と。でも、そのペースト作業には本当に腹が立ちました。

HestiaCPのデフォルトアーキテクチャとMonitポート間の競合の根本原因

まず、私が大変苦労した設定をお見せしますので、あなたがご覧になったバージョンと全く同じかどうかご確認ください。

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

問題なさそうですよね？ポート80をチェックして、クラッシュしたら再起動します。5回再起動してもクラッシュする場合は、タイムアウトになります。

問題は、Apache2がポート80で実行されていないことです。

これはHestiaCPの落とし穴であり、多くの人が陥る根本原因です。HestiaCPのデフォルトアーキテクチャはNginx + Apache2のリバースプロキシで、Nginxが前面のポート80と443を占有し、Apache2が背面のローカルポート8081で動作します。

MonitにApache2のポート80での稼働状況を調べるように指示するのは、マクドナルドに行ってKFCを探すようなものです。サーバーはあなたをぼうぜんと見つめ、あなたとサーバーは互いに見つめ合います。最終的に、Monitはサーバーがダウンしていると判断し、慌てて再起動を開始します。

再起動後もポートは8081のままです。次にMonitはポート80のプローブを試みますが、これも失敗するため、再び再起動します。このサイクルは、Monitが修復不可能と判断してタイムアウトするまで繰り返されます。

初めてこの事実を知った時、本当に驚きました。オンラインで見つけたチュートリアルの10件中9件がポート80を使用していたのです。もしそれらのチュートリアルに従ったのなら、問題はあなたではなく、情報源そのものにあったのです。

Apache2のPIDファイルが破損していたため、Monitが誤ってそのプロセスを存在しないものとして認識してしまった。

ポートを80から8081に変更すれば、理論的にはMonitはそれを検出できるはずですよね？

しかし実際には、時折「実行に失敗しました」と報告されることがあります。

長い間苦労した末、ようやく原因が単純なものだと分かった。PIDファイルが破損していたのだ。

考えてみてください。MonitはApache2を必死に再起動し、その都度強制終了と再起動を繰り返していました。この過程で、ファイル/var/run/apache2/apache2.pidのサイズが0バイトになる可能性がありました。

つまり、ファイル自体は存在しているが、中身は空だということ。

Monit がこのファイルを読み取っても、何も見つかりません。たとえ Apache2 がバックグラウンドで正常に動作していても、Monit は Apache2 を認識しません。Monit はプロセスが存在しないと判断するのです。

これを見た時、私は一瞬言葉を失いました。

これはデッドロックです。MonitはApache 2インスタンスを検出できず、Apache2を再起動しますが、再起動プロセス中にPIDファイルが破損し、次の検出にも失敗して、再び再起動します。このサイクルはタイムアウトが発生するまで続きます。

HestiaCP環境におけるApache2監視のトラブルシューティングと修復手順

正直に言うと、調査プロセス自体は複雑ではないが、どの方向で調査すべきかを知っておく必要がある。

最初のステップは、Apache2がどのポートでリッスンしているかを確認することです。ターミナルでコマンドを入力するだけで簡単に確認できます。

netstat -tulpn | grep apache2

あるいは、`ss`コマンドを使用しても効果は同じです。

ss -tulpn | grep apache2

以下のような出力が表示されます。

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

80ではなく8081であることが確認されました。これが問題の根本原因です。

2つ目の手順は、破損したPIDファイルを修復することです。これはより簡単です。

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

まず、修正作業中にMonitの監視が邪魔にならないよう、Monitの監視を一時停止してください。次に、Apache2を再起動して、新しいPIDを書き換えてください。最後に、`cat`コマンドを使用してファイルの内容を確認してください。空の文字列ではなく、数字の文字列が含まれているはずです。

この手順が完了すれば、問題は基本的に解決します。

Monitの従来型適応型および攻撃型保護構成の比較分析

Apache2とMonitの設定に関するオンラインチュートリアルは、大きく分けて2つのカテゴリに分類されます。

1つのタイプは「従来型適応タイプ」で、`service`コマンドを使用してサービスを管理し、複雑な制約をあまり追加せずにローカルポートをチェックします。この設定はポートを変更するだけでHestiaCPで使用でき、比較的安定しています。

もう一つのアプローチは「積極的な保護」方式で、systemctlを使用してサービスを管理し、子プロセスの制限を追加し、より厳格な検出ロジックを採用します。これは素晴らしいように見えますが、致命的な欠陥があります。それは、停止コマンドが`killall -9`であることです。

`killall -9`とはどういう意味ですか？これは、デバイスが何をしているかに関わらず、強制的に終了させることを意味します。この力任せの操作は、簡単にPIDファイルを破損させてしまう可能性があり、それが先ほど述べた問題です。

私の経験上、攻撃的な構成で子プロセスの数を制限することは確かに有効です。Apache2がCC攻撃によって過負荷状態になった場合、子プロセスの数を制限することでサーバーのメモリ不足を防ぐことができます。しかし、`killall -9` という方法は実用的ではありません。

結局、私は妥協して両方の構成の利点を組み合わせることにしました。

HestiaCP Apache2 モニターのベストプラクティス設定

/etc/monit/conf.d/apache2 ファイルを以下の内容で変更してください。

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

これらの数行の設定の背後にある論理を簡単に説明しましょう。

HestiaCPのリバースプロキシアーキテクチャに正確に合わせるため、ポート8081を記述してください。愚かにもポート80を記述するのはやめてください。

PID ファイルを破損させないために、`killall -9` の代わりに `systemctl stop` コマンドを使用して PID ファイルを停止してください。

子プロセスの制限が追加されました。子プロセスの数が120を超えると、CC攻撃を防ぐために2回連続でサイクルが繰り返された後にプロセスが再起動されますが、過度に積極的な措置ではありません。

障害検出ロジックが「2サイクル」方式に変更されました。つまり、2回連続で障害が発生した場合にのみ再起動がトリガーされるため、誤検出が減少します。以前の設定では、1回の検出で再起動していましたが、正直言ってやや過敏すぎました。

最終的なタイムアウトのしきい値は、10サイクル以内に5回の再起動まで緩和され、十分な耐障害性が確保されています。

ヘスティアCP モニタリングの監視構成トラブルシューティングの概要と経験談

設定変更後、apache2を監視したところ、パネルにようやく緑色の「OK」表示が現れた。

当時の気持ちをどう表現すればいいだろうか？まるで2日間もバグと格闘した挙句、原因はたった1行の設定ミスだったと分かったようなものだ。苛立ちと同時に、滑稽さも感じた。

Monit自体は優れたツールであり、デーモンの監視はすべてのサーバーが行うべきことです。しかし問題は、多くのオンラインチュートリアルが「Apache2はポート80のみを使用する」という前提に基づいているのに対し、HestiaCPはリバースプロキシを使用するため、この前提は成り立たないということです。

指示通りに操作しているのに問題が解決しない場合、問題はあなたにあるのではなく、チュートリアルがあなたの状況とは異なるシナリオを想定して作成されている点にあります。

HestiaCPを使用していて、Monitを使ってApache2を監視している場合は、次の2点に注意してください。ポートを8081に変更すること、そして停止するには`killall -9`ではなく`systemctl`コマンドを使用することです。この2点を守れば、これ以上の問題は発生しないはずです。

ここまで読んでいただき、もしこの記事が役に立ったと感じていただけたなら、ぜひ「いいね！」やシェアをお願いします。最新情報をいち早く受け取りたい方は、フォローもお願いします！

私の記事を読んでいただき、ありがとうございました。また次回お会いしましょう。