過去数年間、私たちは数千の Web サイトにサービスを提供する複数の Apache サーバーの前で、キャッシュおよびロード バランサーとして Varnish を実行してきました。
また、varnish が停止した場合に再起動されるように monit を使用します。monitrc の varnish セクションは次のようになります。
# Check varnish on port 80
check process varnish with pidfile /var/run/varnishd.pid
start program = "/etc/init.d/varnish start"
stop program = "/etc/init.d/varnish stop"
if failed host 127.0.0.1 port 80 protocol http
and request "/monit-check-url"
then restart
これは少なくとも 3 年間は正常に動作しています。ポート 80 のチェックが時々失敗しますが、monit はそれに応じて varnish を再起動するため、通常はユーザーには気付かれません。
しかし、ここ数週間、こうした障害が数時間にわたって頻発しており、ユーザーは接続障害に気付いています。今日は特にひどい状況です。
次の「Varnish クラッシュ」セクションで示唆されているように、syslog には手がかりがありません (ちなみにこれは Debian ボックスです)。https://www.varnish-cache.org/docs/3.0/tutorial/troubleshooting.htmlそこに表示されているのは、monit がポート 80 のチェックに失敗し、varnish を停止して起動しているだけです。
さらに、通常よりも高い負荷で障害が発生していることを示唆するような、帯域幅の急増やバックエンド Web サーバーへのヒット数の増加は見られません。
私たちは Varnish 3.0.3 を実行していましたが、3.0.7 にアップグレードしましたが、問題は解決していません。このボックスには、問題の発生と一致するその他の変更は行われておらず、varnish の構成もかなり長い間変更されていません。
誰か、varnish に関して同様の経験をしたことがある人、またはこの問題をさらにトラブルシューティングするための提案はありますか? 何らかの攻撃である可能性がありますか?
ご協力やアドバイスをいただければ幸いです。
答え1
ここでのアプローチは、リクエストが失敗する理由は多数あり、そのすべてが Varnish の問題ではないため、少し強引すぎるように思われます (例: 接続の問題、バックエンドの障害など)。Varnish を再起動すると、再起動中に停止が発生するため、最後の手段としてのみ使用する必要があります。
何かを再起動する前に、varnish ボックスを実行して、varnish がバックエンドをどのような状態と見なしているかを確認することをお勧めしますvarnishadm debug.health。結果に応じて、さらにどこを確認するかを決定できます。
- バックエンドが正常でないと考えられる場合、問題は varnish とバックエンドの間 (またはバックエンド自体) にあります。バックエンドへのネットワークと、バックエンドの監視を確認してください。
- バックエンドが正常であると考えられる場合、問題は monit と varnish の間にあります。varnish サーバーへのネットワークを確認し、監視自体をデバッグします。
- varnishadm プロセスが接続を確立できない場合、問題は varnish 自体にあります。どの varnish プロセスが実行されているかを確認し、ログで varnish からのエラー メッセージを探します。