This article describes how to configure and use HTTP health checks in NGINX Plus and open source NGINX.

Overview

NGINX and NGINX Plus can continually test your upstream servers, avoid the servers that have failed, and gracefully add the recovered servers into the load‑balanced group.

Prerequisites

Passive Health Checks

For passive health checks, NGINX and NGINX Plus monitor transactions as they happen, and try to resume failed connections. If the transaction still cannot be resumed, NGINX and NGINX Plus mark the server as unavailable and temporarily stop sending requests to it until it is marked active again.

The conditions under which an upstream server is marked unavailable are defined for each upstream server with parameters to the server directive in the upstream block:

  • fail_timeout – Sets the time during which a number of failed attempts must happen for the server to be marked unavailable, and also the time for which the server is marked unavailable (default is 10 seconds).
  • max_fails – Sets the number of failed attempts that must occur during the fail_timeout period for the server to be marked unavailable (default is 1 attempt).

In the following example, if NGINX fails to send a request to a server or does not receive a response from it 3 times in 30 seconds, it marks the server as unavailable for 30 seconds:

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

Note that if there is only a single server in a group, the fail_timeout and max_fails parameters are ignored and the server is never marked unavailable.

Server Slow Start

A recently recovered server can be easily overwhelmed by connections, which may cause the server to be marked as unavailable again. Slow start allows an upstream server to gradually recover its weight from zero to its nominal value after it has been recovered or became available. This can be done with the slow_start parameter to the upstream server directive:

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

The time value sets the time for the server to recover its weight.

Note that if there is only a single server in a group, the slow_start parameter is ignored and the server is never marked unavailable.

Active Health Checks

NGINX Plus can periodically check the health of upstream servers by sending special health‑check requests to each server and verifying the correct response.

To enable active health checks:

  1. In the location that passes requests (proxy_pass) to an upstream group, include the health_check directive:

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

This snippet defines a virtual server that passes all requests (location /) to the upstream group called backend. It also enables advanced health monitoring with default parameters: every five seconds NGINX sends a request for / to each server in the backend group. If any communication error or timeout occurs (or the server responds with a status code outside the range from 200 through 399) the health check fails. The server is marked as unhealthy, and NGINX Plus does not send client requests to it until it once again passes a health check.

  1. Define a shared memory zone for the upstream server group with the zone directive:

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

    The zone directive defines a memory zone that is shared among worker processes and is used to store the configuration of the upstream group. This enables the worker processes to use the same set of counters to keep track of responses from the servers in the group. The zone directive also makes the group dynamically configurable.

    The defaults for active health checks can be overridden with parameters to the health_check directive:

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

    Here, the interval parameter increases the delay between health checks to 10 seconds (from the default 5 seconds). The fails requires the server to fail three health checks to be marked as unhealthy (up from the default one). Finally, the passes parameter means the server must pass two consecutive checks to be marked as healthy again (instead of the default one).

Specifying the Requested URI

Use the uri parameter to set the URI to request in a health check:

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

The specified URI is appended to the server domain name or IP address set for the server in the upstream block. For the first server in the sample backend group declared above, a health check requests the URI http://backend1.example.com/some/path.

Defining Custom Conditions

Finally, it is possible to set custom conditions that the response must satisfy for the server to pass the health check. The conditions are defined in a match block, which is referenced in the match parameter to the health_check directive.

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

Here the health check is passed if the status code of the response is in the range 200399, and its body does not contain the string maintenance mode.

The match directive enables NGINX Plus to check the status code, header fields, and the body of a response. Using this directive it is possible to verify whether the status is in a specified range, whether a response includes a header, or whether the header or body matches a regular expression. The match directive can contain one status condition, one body condition, and multiple header conditions. A response must satisfy all conditions defined in match block for the server to pass the health check.

For example, the following match directive matches responses that have status code 200, the exact value text/html in the Content-Type header, and the text Welcome to nginx! in the body:

match welcome {
status 200;
header Content-Type = text/html;
body ~ "Welcome to nginx!";
}

The following example uses the exclamation point (!) to define characteristics the response must not have to pass the health check. In this case, the health check passes when the status code is something other than 301302303, or 307, and there is no Refresh header.

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

Health checks can also be enabled for non-HTTP protocols, such as FastCGImemcachedSCGI, and uwsgi, and also for TCP and UDP.

 

HTTP Health Checks的更多相关文章

  1. Kong(V1.0.2) Health Checks and Circuit Breakers Reference

    介绍 您可以让Kong代理的API使用ring-balancer,通过添加包含一个或多个目标实体的 upstream 实体进行配置,每个 target指向不同的IP地址(或主机名)和端口.ring-b ...

  2. TCP Health Checks

    This chapter describes how to configure health checks for TCP. Introduction NGINX and NGINX Plus can ...

  3. UDP Health Checks

    This chapter describes how to configure different types of health checks for UDP servers in a load-b ...

  4. Zookeeper Health Checks

    Short Description: The article talks about the basic health checks to be performed when working on i ...

  5. Service Discovery And Health Checks In ASP.NET Core With Consul

    在这篇文章中,我们将快速了解一下服务发现是什么,使用Consul在ASP.NET Core MVC框架中,并结合DnsClient.NET实现基于Dns的客户端服务发现 这篇文章的所有源代码都可以在G ...

  6. Using HAProxy as an API Gateway, Part 3 [Health Checks]

    转自:https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-3-health-checks/ Achieving high ...

  7. 11g新特性:Health Monitor Checks

    一.什么是Health Monitor ChecksHealth Monitor Checks能够发现文件损坏,物理.逻辑块损坏,undo.redo损坏,数据字典损坏等等.Health Monitor ...

  8. About Health Monitor Checks

    About Health Monitor Checks Health Monitor checks (also known as checkers, health checks, or checks) ...

  9. oralce health monitor

    1. Health Monitor简介    Health Monitor是11g里新增加的特性,用于数据库的各层和各个组建的诊断检查.例如可以检查:文件损坏.物理逻辑块损坏.redo和undo故障. ...

随机推荐

  1. 【转载】 C#工具类:Csv文件转换类

    CSV是逗号分隔值格式的文件,其文件以纯文本形式存储表格数据(数字和文本).CSV文件由任意数目的记录组成,记录间以某种换行符分隔:每条记录由字段组成,字段间的分隔符是其它字符或字符串,最常见的是逗号 ...

  2. [android] 采用post的方式提交数据

    GET:内部实现是组拼Url的方式,http协议规定最大长度4kb,ie浏览器限制1kb POST和GET的区别比较了一下,多了几条信息 Content-Type:application/x-www- ...

  3. (9)Microsoft office Word 2013版本操作入门_文本框_word排版

    1.插入文本框 :[插入]---[文本框]可以自己画,也可以选择已有的模板 2.文本框设置 :点中文本框选择[格式]---[对齐文本]可以让文字上下居中,[形状填充]填充不同的颜色.[形状轮廓]可以改 ...

  4. Java 内部类及其原理

    Java中实现内部类 内部类相信大家都用过很多次了,就不说它是怎么用的了. 内部类 1.成员内部类 需要注意的是, 当成员内部类拥有和外部类同名的成员变量或这方法时, 默认情况下访问的是内部类的成员, ...

  5. (一):C++分布式实时应用框架----整体介绍

    C++分布式实时应用框架 (Cpp Distributed Real-time Application Framework) 版权声明:本文版权及所用技术归属smartguys团队所有,对于抄袭,非经 ...

  6. python爬虫入门urllib库的使用

    urllib库的使用,非常简单. import urllib2 response = urllib2.urlopen("http://www.baidu.com") print r ...

  7. div和span标签

    ------------------------ ------------------------ ------------------------ 块级标签独占一行,不和别的标签在同一行显示:行内标 ...

  8. MySQL 查看执行计划

    MySQL 使用 explain + sql 语句查看 执行计划,该执行计划不一定完全正确但是可以参考. EXPLAIN SELECT * FROM user WHERE nid = 3; selec ...

  9. JS之函数实际参数转换成数组的方法[].slice.call(arguments)

    实际参数在函数中我们可以使用 arguments 对象获得 (注:形参可通过 arguments.callee 获得),虽然 arguments 对象与数组形似,但仍不是真正意义上的数组. 我们可以通 ...

  10. iframe 标签属性解读

    iframe 元素会创建包含另外一个文档的内联框架(即行内框架)