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

パッシブ チェック

パッシブ ヘルス チェックの場合、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 サイトの他の関連記事を参照してください。