Upstream Probe#
The module implements active health probes
for Upstream. Added in version 1.2.0: PRO Default — location Defines an active health probe for servers within the upstream groups
that are specified for proxy_pass, uwsgi_pass, and so on
in the same A server passes the probe if the request to it succeeds, considering all
parameter settings of the To make use of the probes,
the upstream must have a shared memory zone (zone).
One upstream may be configured with several probes. The following parameters are accepted: Mandatory name of the probe. Request URI to be added to the argument for proxy_pass,
uwsgi_pass, etc. By default — Alternative port number for the probe request. Interval between probes. By default — HTTP method of the probe request. By default — The condition to be checked during the request; defined as a string with variables.
If variable substitution yields If set, the initial state of the server is subject to verification
and client requests are not forwarded to it until the probe is passed. Setting this parameter requires enabling Number of consecutive failed requests that
renders the server unhealthy. By default — 1. Number of consecutive successful requests that
renders the server healthy. By default — 1. Maximum amount of memory for the response body. By default — Probe mode, depending on the servers' health: By default — Example: Details of probe operation: Initially, the server won't receive client requests
until it passes all The server is considered unhealthy and won't receive client requests,
if any of the probes configured for it hits its For an unhealthy server to be considered healthy again,
all probes configured for it must reach their respective The Name of the currently active upstream_probe. Server response body,
received during an upstream_probe;
its size is limited by Configuration Example#
server {
listen ...;
location /backend {
...
proxy_pass http://backend;
upstream_probe backend_probe
uri=/probe
port=10004
interval=5s
test=$good
essential
fails=3
passes=3
max_body=10m
mode=idle;
}
}
Directives#
upstream_probe (PRO)#
upstream_probe
name [uri=
address] [port=
number] [interval=
time] [method=
method] [test=
condition] [essential
[persistent
]] [fails=
number] [passes=
number] [max_body=
size] [mode=
always
| idle
| onfail
];location
context with the upstream_probe
directive.
Subsequently, Angie regularly performs requests according to the specified parameters
to each server in the upstream group.upstream_probe
directive and all parameters that
control how upstreams are used by the location
context where it is defined.
This includes the proxy_next_upstream and uwsgi_next_upstream
directives, etc.; also, proxy_set_header and so on.name
uri
/
.port
interval
5s
.method
GET
.test
""
or "0"
,
the probe is not passed.essential
persistent
essential
first;
persistent
servers that were working prior to a
configuration reload
start receiving requests without being required to pass this probe first.fails
passes
max_body
256k
.mode
always
— servers are probed regardless of their state;idle
— probes affect unhealthy servers and servers where
interval
has elapsed since the last client request.onfail
— only unhealthy servers are probed.always
.upstream backend {
zone backend 1m;
server backend1.example.com;
server backend2.example.com;
}
map $upstream_status $good {
200 "1";
}
server {
listen ...;
location /backend {
...
proxy_pass http://backend;
upstream_probe backend_probe
uri=/probe
port=10004
interval=5s
test=$good
essential
persistent
fails=3
passes=3
max_body=10m
mode=idle;
}
}
essential
probes configured for it
(skipping persistent
ones if the configuration was reloaded
and the server was deemed healthy prior to that).
If there are no such probes, the server is considered healthy.fails
threshold
or the server itself reaches the max_fails threshold.passes
thresholds;
after that, the max_fails threshold is considered.Built-in Variables#
http_upstream_probe
module supports the following built-in variables:$upstream_probe
(PRO)#$upstream_probe_body
(PRO)#max_body
.