HTTP Health Checks
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
- For passive health checks, NGINX Open Source or NGINX Plus
- For active health checks and the live activity monitoring dashboard, NGINX Plus
- A load‑balanced group of HTTP upstream servers
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 thefail_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:
In the
location
that passes requests (proxy_pass
) to an upstream group, include thehealth_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.
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. Thezone
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). Thefails
requires the server to fail three health checks to be marked as unhealthy (up from the default one). Finally, thepasses
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 200
–399
, 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 301
, 302
, 303
, 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 FastCGI, memcached, SCGI, and uwsgi, and also for TCP and UDP.
HTTP Health Checks的更多相关文章
- Kong(V1.0.2) Health Checks and Circuit Breakers Reference
介绍 您可以让Kong代理的API使用ring-balancer,通过添加包含一个或多个目标实体的 upstream 实体进行配置,每个 target指向不同的IP地址(或主机名)和端口.ring-b ...
- TCP Health Checks
This chapter describes how to configure health checks for TCP. Introduction NGINX and NGINX Plus can ...
- UDP Health Checks
This chapter describes how to configure different types of health checks for UDP servers in a load-b ...
- Zookeeper Health Checks
Short Description: The article talks about the basic health checks to be performed when working on i ...
- Service Discovery And Health Checks In ASP.NET Core With Consul
在这篇文章中,我们将快速了解一下服务发现是什么,使用Consul在ASP.NET Core MVC框架中,并结合DnsClient.NET实现基于Dns的客户端服务发现 这篇文章的所有源代码都可以在G ...
- 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 ...
- 11g新特性:Health Monitor Checks
一.什么是Health Monitor ChecksHealth Monitor Checks能够发现文件损坏,物理.逻辑块损坏,undo.redo损坏,数据字典损坏等等.Health Monitor ...
- About Health Monitor Checks
About Health Monitor Checks Health Monitor checks (also known as checkers, health checks, or checks) ...
- oralce health monitor
1. Health Monitor简介 Health Monitor是11g里新增加的特性,用于数据库的各层和各个组建的诊断检查.例如可以检查:文件损坏.物理逻辑块损坏.redo和undo故障. ...
随机推荐
- SqlServer 技术点总结(持续更新)
本文是用于记录自己平时遇到的一些SQL问题或知识点,以便以后自己查阅,会持续的更新,增加内容.发在博客园也可以和各位博友共同学习交流,如文中记录的有错误之处希望指出,谢谢. 一.用SQL语句调用作业 ...
- 使用wubi安装ubuntu14.04出现的常见错误的解决办法
花了一天的时间终于安装上了Ubuntu14.04,过程坎坷,是血泪史,开始报“cannot download the metalink and therefore the ISO”错误,解决后,又报“ ...
- springMVC_02hello案例
1.导入jar包 commons-logging-1.1.1.jar jackson-annotations-2.5.4.jar jackson-core-2.5.4.jar jackson-data ...
- Android破解学习之路(十六)—— dll破解的IL指令
IL指令介绍 IL是.NET框架中中间语言(Intermediate Language)的缩写. 使用.NET框架提供的编译器可以直接将源程序编译为.exe或.dll文件,但此时编译出来的程序代码并不 ...
- 4.1 explain 之 id
一.id 是什么 select 查询的序列化,包含一组数字,表示查询中执行select子句或操作的顺序 二.三种情况 a. id相同,执行顺序由上至下 b. 如果是子查询,id的序号会递增,id值越大 ...
- STL中的Set用法(详+转)
set是STL中一种标准关联容器(vector,list,string,deque都是序列容器,而set,multiset,map,multimap是标准关联容器),它底层使用平衡的搜索树——红黑树实 ...
- 基于redis的分布式锁(不适合用于生产环境)
基于redis的分布式锁 1 介绍 这篇博文讲介绍如何一步步构建一个基于Redis的分布式锁.会从最原始的版本开始,然后根据问题进行调整,最后完成一个较为合理的分布式锁. 本篇文章会将分布式锁的实现分 ...
- express 对数据库数据增删改查
接着 http://www.cnblogs.com/cynthia-wuqian/p/6560548.html (1)概念 Schema(属性) :一种以文件形式存储的数 据库模型骨架,不具备数据库的 ...
- blfs(systemd版本)学习笔记-编译安装gnome桌面组件及应用
我的邮箱地址:zytrenren@163.com欢迎大家交流学习纠错! blfs中的gnome项目地址:http://www.linuxfromscratch.org/blfs/view/stable ...
- Flex 项目属性:flex 布局示例
flex属性: flex属性是flex-grow, flex-shrink 和 flex-basis的简写,默认值为0 1 auto.后两个属性可选. 该属性有两个快捷值:auto (1 1 auto ...