Squid フォワードプロキシ向けの HAProxy ヘルスチェック
フォワードプロキシと対話する HAProxy ヘルスチェックを構築し、リスナーの到達性、CONNECT の受け入れ、オリジンからの取得を区別します。
プロキシホスト上の /check.txt というファイルは、明白なヘルスチェック対象に思えます。落とし穴は、Squid の明示的なフォワードリスナーが、そのホストのドキュメントルートを配信する普通のウェブサイトではないことです。
HEAD /check.txt HTTP/1.1 のようなオリジン形式のリクエストは、フォワードプロキシ経由の通常の HTTP リクエストで期待される絶対ターゲットを欠いています。設定によっては拒否されたり、別のローカルサービスが処理したりします。どちらの結果も、ダッシュボードが示唆するほど多くを語りません。
可用性を保つべきサービスを選ぶ
| チェック | 有用な証拠 |
|---|---|
| プロキシリスナーへの TCP 接続 | 到達可能なプロセスがその接続を受け入れます。 |
| 制御されたターゲットへの CONNECT | プロキシがそのトンネル要求を受け入れます。 |
| プロキシ経由の HTTP 取得 | 選択したリクエスト経路が期待どおりの応答を返せます。 |
3 番目のケースでは、リクエストにターゲットが必要です。例えば次のとおりです。
HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internalホスト名はあくまで例です。プロキシが解決でき、意図的に到達を許可している制御されたエンドポイントを使ってください。HAProxy の http-check send はメソッド、URI、バージョン、ヘッダーの指定に対応しています。オリジンサーバーの例をそのまま流用せず、そのリクエストを明示的に設定してください。
HEAD は応答ステータスとヘッダーを確認できます。転送されない応答本文を検証することはできません。ヘルス契約が本文中のマーカーを要求するなら、適切な GET チェックを選び、そのマーカーを検証してください。
プロキシ認証が関わる場合は、チェック用アカウントと送信元の制限を狭く保ってください。緑のチェックを得るためにリスナー全体を認証から除外すると、保護しているサービスそのものが変わってしまいます。
最後に、失敗したチェックが何を外すべきかを決めてください。制御されたオリジンの障害は、すべてのプロキシの転送チェックを同時に失敗させることがあります。それは測りたい依存関係そのものかもしれませんし、リスナーの健全性とエンドツーエンドの可用性を別々のシグナルとして保つ理由かもしれません。