标签:cep group by ssi ima name and contex cal can
For UDP traffic, also include the udp
parameter. TCP is the default protocol for the stream
context, so there is no tcp
parameter to the listen
directive
Optionally, you can tune the size of two in?memory buffers where NGINX can put data from both the client and upstream connections.
stream { server { listen 12345; #TCP traffic will be forwarded to the "stream_backend" upstream group proxy_pass stream_backend; } server { listen 12346; #TCP traffic will be forwarded to the specified server proxy_pass backend.example.com:12346; proxy_buffer_size 16k; } server { listen 53 udp; #UDP traffic will be forwarded to the "dns_servers" upstream group proxy_pass dns_servers; } # ... }
Note that you do not define the protocol for each server, because that is defined for the entire upstream group by the parameter you include on the listen
directive in the server
block, which you have created earlier.
The health_check
directive enables the health?check functionality, while the health_check_timeout
directive overrides the proxy_timeout
value for health checks, as for health checks this timeout needs to be significantly shorter.
To enable health checks for UDP traffic, in the health_check
directive specify the udp
parameter and optionally the match
parameter with the name of a corresponding match
block of tests for verifying server responses (see Fine?Tuning UDP Health Checks):
server { listen 5053; proxy_pass dns_servers; health_check udp match=dns; health_check_timeout 5s; }
By default, NGINX Plus tries to connect to each server in an upstream server group every 5 seconds. If the connection cannot be established, NGINX Plus considers the health check failed, marks the server as unhealthy, and stops forwarding client connections to the server.
To change the default behavior, include these parameters to the health_check
directive:
interval
– How often (in seconds) NGINX Plus sends health check requests (default is 5 seconds)passes
– Number of consecutive health checks the server must respond to to be considered healthy (default is 1)fails
– Number of consecutive health checks the server must fail to respond to to be considered unhealthy (default is 1)server { listen 12345; proxy_pass stream_backend; health_check interval=10 passes=2 fails=3; }
You can verify server responses to health checks by configuring a number of tests. These tests are defined with the match
configuration block placed in the stream
context. Specify the match
block and set its name (here, tcp_test):
The conditions or tests under which a health check succeeds are set with send
and expect
parameters:
send
– The text string or hexadecimal literals (/x
followed by two hex digits) to send to the serverexpect
– Literal string or regular expression that the data returned by the server needs to matchIf both the send
and expect
parameters are specified, then the string from the send
parameter must match the regular expression from the expect
parameter:
stream { upstream stream_backend { zone upstream_backend 64k; server backend1.example.com:12345; } match http { send "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n"; expect ~* "200 OK"; } server { listen 12345; health_check match=http; proxy_pass stream_backend; } }
To fine?tune health checks for UDP, specify both send
and expect
parameters:
Example for DNS:
match dns { send \x00\x2a\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03\x73\x74\x6c\x04\x75\x6d\x73\x6c\x03\x65\x64\x75\x00\x00\x01\x00\x01; expect ~* "health.is.good"; }
Upstream server groups can be easily reconfigured on-the-fly using NGINX Plus REST API. Using this interface, you can view all servers in an upstream group or a particular server, modify server parameters, and add or remove upstream servers.
TODO:
Configuring NGINX to Accept the PROXY Protocol
标签:cep group by ssi ima name and contex cal can
原文地址:https://www.cnblogs.com/geeklove01/p/9192714.html