Nginx http ヘルスチェックを構成する方法-Nginx-php.cn

Nginx http ヘルスチェックを構成する方法

WBOY

リリース： 2023-05-14 18:10:06

転載

1761 人が閲覧しました

パッシブチェック

パッシブヘルスチェックの場合、nginx および nginx plus はイベントの発生を監視し、失敗した接続の回復を試みます。それでも機能しない場合、nginx オープンソースと nginx plus はサーバーを利用不可としてマークし、再びアクティブとしてマークされるまで、サーバーへのリクエストの送信を一時的に停止します。

上流サーバーが使用不可としてマークされる条件は、ブロック内のサーバーディレクティブのパラメータ上流で上流サーバーごとに定義されます:

fail_timeout - セットサーバーマーク利用できない場合に複数の試行が失敗するまでの時間、およびサーバーが利用不可能としてマークされる時間 (デフォルトは 10 秒)。
max_fails - 失敗した試行の回数を設定します。この回数を超えると、fail_timeout サーバーは使用不可としてマークされます (デフォルトは 1 回の試行です)。次の例では、nginx がサーバーへのリクエストの送信に失敗するか、30 秒以内に 3 回応答を受信しない場合、サーバーが 30 秒以内に利用できなくなることを意味します:

upstream backend {
  server backend1.example.com;
  server backend2.example.com max_fails=3 fail_timeout=30s;
}

ログイン後にコピー

注意すべき点はい、サーバーグループが 1 つだけの場合、fail_timeout パラメーターと max_fails パラメーターは無視され、サーバーが使用不可としてマークされることはありません。

サーバーの起動が遅い

最近復元されたサーバーは簡単に接続が殺到する可能性があり、サーバーが再び使用不可としてマークされる可能性があります。スロースタートを使用すると、アップストリームサーバーが回復するか使用可能になった後、その重みをゼロから公称値まで徐々に復元できます。これは、アップストリームのサーバーモジュールの throw_start パラメータを指定することで実行できます。

upstream backend {
  server backend1.example.com slow_start=30s;
  server backend2.example.com;
  server 192.0.0.1 backup;
}

ログイン後にコピー

注: グループ内にサーバーが 1 つしかない場合、slow_start パラメータは無視され、サーバーが使用不可としてマークされることはありません。スロースタートは nginx plus の独自機能です

nginx plus のアクティブチェック

nginx plus は、特別なヘルスチェックリクエストを各サーバーに送信することでこれを実行できます。正しい応答を確認することで、上流サーバーの健全性を定期的にチェックします。

アクティブなヘルスチェックを有効にするには:

1. リクエスト (proxy_pass) を location ブロックの上流グループに渡すプロセスに、health_check ディレクティブを含めます:

server {
 location / {
   proxy_pass http://backend;
   health_check;
 }
}

ログイン後にコピー

このコードスニペットは、場所に対するすべてのリクエストを照合するサーバーを定義し、バックエンドと呼ばれるアップストリームグループに渡します。また、health_check ディレクティブを使用した高度なヘルス監視も有効になります。デフォルトでは、nginx plus はグループバックエンド内の各サーバーに「/」リクエストを 5 秒ごとに送信します。

通信エラーまたはタイムアウトが発生した場合 (サーバーから返されたステータスコードが 200 ～ 399 の範囲外である場合)、ヘルスチェックは失敗します。サーバーは異常としてマークされ、nginx plus はヘルスチェックに再度合格するまでクライアントリクエストをサーバーに送信しません。

もう 1 つのオプションオプション: ヘルスチェック用に別のポートを指定することもできます。たとえば、同じホスト上の多くのサービスの健全性を監視することができます。ディレクティブの port パラメーターを使用して、新しいポート health_check を指定します:

server {
 location / {
   proxy_pass  http://backend;
   health_check port=8080;
 }
}

ログイン後にコピー

2。アップストリームサーバーグループで、zone ディレクティブを使用して共有メモリ領域を定義します:

http {
 upstream backend {
   zone backend 64k;
   server backend1.example.com;
   server backend2.example.com;
   server backend3.example.com;
   server backend4.example.com;
 }
}

ログイン後にコピー

この領域は、上流グループ間で共有されるすべてのワーカープロセス間にあり、上流グループの構成が格納されます。これにより、ワーカープロセスは同じカウンターセットを使用して、グループ内のサーバーからの応答を追跡できるようになります。

アクティブなヘルスチェックのデフォルト値は、health_check ディレクティブの引数を使用してオーバーライドできます:

location / {
  proxy_pass http://backend;
  health_check interval=10 fails=3 passes=2;
}

ログイン後にコピー

ここでは、interval パラメーターにより、ヘルスチェック間の遅延がデフォルトの 5 秒から 10 秒に増加します。。 failed パラメーターでは、サーバーを異常としてマークするには、サーバーが 3 つのヘルスチェックに失敗する必要があります (デフォルト値から開始)。最後に、pass パラメーターは、サーバーがデフォルト値ではなく再び正常とマークされる前に、サーバーが 2 つの連続したチェックに合格する必要があることを意味します。

リクエストされた URL を指定します

health_check ディレクティブで uri パラメータを指定して、ヘルスチェックリクエストのルートを設定します:

location / {
  proxy_pass http://backend;
  health_check uri=/some/path;
}

ログイン後にコピー

指定された URI は、上流ブロックでサーバーに設定されたサーバードメイン名または IP アドレスに追加されます。上記で宣言されたバックエンドサンプルグループの最初のサーバーの場合、ヘルスチェックは URI http://backend1.example.com/some/path を要求します。

カスタム条件の定義

サーバーがヘルスチェックに合格するために応答が満たす必要があるカスタム条件を設定できます。条件は match ブロックで定義され、health_check ディレクティブの引数で参照されます。

1. http {} レベルで、match {} ブロックを指定し、名前を付けます。たとえば、ブロックの match パラメーターを指定して、「server_ok'

http {
 #... 
 match server_ok {
   # tests are here     
 }
}

ログイン後にコピー

2.health_check」と名前を付けます。パラメータブロックの名前:

http {
 #... 
 match server_ok {
   status 200-399;
   body !~ "maintenance mode";
 }
 server {
   #...     
   location / {
     proxy_pass http://backend;
     health_check match=server_ok;
   }
 }
}

ログイン後にコピー

と一致する応答のステータスコードが 200 ～ 399 の範囲にあり、その本文に文字列 'maintenance mode'

が含まれていない場合、ヘルスチェックに合格します。

match ディレクティブにより、nginx plus がステータスコード、ヘッダーフィールド、応答本文をチェックできるようになります。このディレクティブを使用して、ステータスが指定された範囲内にあること、応答にヘッダーが含まれていること、またはヘッダーまたは本文が正規表現と一致することを検証します。 match ディレクティブには、ステータス条件、本文条件、および複数のタイトル条件を含めることができます。サーバーがヘルスチェックに合格するには、応答が match ブロックで定義されたすべての条件を満たしている必要があります。

例如，下面的 match 指令匹配有状态代码响应 200，精确值 text/html 的content-type 标题，页面中的文字：'welcome to nginx!'.

match welcome {
  status 200;
  header content-type = text/html;
  body ~ "welcome to nginx!";
}

ログイン後にコピー

以下示例使用感叹号（!）来定义响应不得通过运行状况检查的特征。在这种情况下，健康检查在非 301，302，303，或 307状态码，同时并没有 refresh 头信息时将通过检查，。

match not_redirect {
  status ! 301-303 307;
  header ! refresh;
}

ログイン後にコピー

健康检查可以在其他非 http 协议中启用, 例如 fastcgi, , scgi, 甚至 tcp 和 udp。

很多很好的特性，就是需要 nginx plus 才能使用。

以上がNginx http ヘルスチェックを構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。