# HG changeset patch # User Yaroslav Zhuravlev # Date 1490898404 -10800 # Node ID 37df1535ea91bacba9e3ac96efbf677a03db2d0f # Parent 88477c5d275108b76f8350b70211434e6371ac16 Moved info from http "health_check" and "match" to intro. diff -r 88477c5d2751 -r 37df1535ea91 xml/en/docs/http/ngx_http_upstream_hc_module.xml --- a/xml/en/docs/http/ngx_http_upstream_hc_module.xml Thu Mar 30 21:26:44 2017 +0300 +++ b/xml/en/docs/http/ngx_http_upstream_hc_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -9,7 +9,7 @@ + rev="2">
@@ -18,6 +18,25 @@ allows enabling periodic health checks of the servers in a group referenced in the surrounding location. +The server group must reside in the +shared memory. + + + +If a health check fails, +the server will be considered unhealthy. +If several health checks are defined for the same group of servers, +a single failure of any check will make the corresponding server be +considered unhealthy. +Client requests are not passed to unhealthy servers +and servers in the “checking” state. + + + + +Please note that most of the variables will have empty values +when used with health checks. + @@ -52,6 +71,41 @@ } } +With this configuration, nginx will send “/” requests to each +server in the backend group every five seconds. +If any communication error or timeout occurs, or a +proxied server responds with the status code other than +2xx or 3xx, the health check will fail, and the server will +be considered unhealthy. + + + +Health checks can be configured to test the status code of a response, +presence of certain header fields and their values, +and the body contents. +Tests are configured separately using the directive +and referenced in the match parameter +of the directive: + +http { + server { + ... + location / { + proxy_pass http://backend; + health_check match=welcome; + } + } + + match welcome { + status 200; + header Content-Type = text/html; + body ~ "Welcome to nginx!"; + } +} + +This configuration shows that in order for a health check to pass, the response +to a health check request should succeed, have status 200, +and contain “Welcome to nginx!” in the body.
@@ -149,72 +203,6 @@ - -For example, - -location / { - proxy_pass http://backend; - health_check; -} - -will send “/” requests to each -server in the backend group every five seconds. -If any communication error or timeout occurs, or a -proxied server responds with the status code other than -2xx or 3xx, the health check will fail, and the server will -be considered unhealthy. -Client requests are not passed to unhealthy servers -and servers in the “checking” state. - - - -Health checks can be configured to test the status code of a response, -presence of certain header fields and their values, -and the body contents. -Tests are configured separately using the directive -and referenced in the match parameter. -For example: - -http { - server { - ... - location / { - proxy_pass http://backend; - health_check match=welcome; - } - } - - match welcome { - status 200; - header Content-Type = text/html; - body ~ "Welcome to nginx!"; - } -} - -This configuration shows that in order for a health check to pass, the response -to a health check request should succeed, -have status 200, content type “text/html”, -and contain “Welcome to nginx!” in the body. - - - -The server group must reside in the -shared memory. - - - -If several health checks are defined for the same group of servers, -a single failure of any check will make the corresponding server be -considered unhealthy. - - - - -Please note that most of the variables will have empty values -when used with health checks. - - - diff -r 88477c5d2751 -r 37df1535ea91 xml/ru/docs/http/ngx_http_upstream_hc_module.xml --- a/xml/ru/docs/http/ngx_http_upstream_hc_module.xml Thu Mar 30 21:26:44 2017 +0300 +++ b/xml/ru/docs/http/ngx_http_upstream_hc_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -9,7 +9,7 @@ + rev="2">
@@ -18,6 +18,25 @@ позволяет активировать периодические проверки работоспособности серверов в группе, указанной в содержащем location. +Группа должна находиться в +зоне разделяемой памяти. + + + +Если проверка работоспособности была неуспешной, +то сервер признаётся неработоспособным. +Если для группы задано несколько проверок, +то при любой неуспешной проверке соответствующий сервер будет +считаться неработоспособным. +На неработоспособные серверы и серверы в состоянии “checking” +клиентские запросы передаваться не будут. + + + + +Обратите внимание, что при использовании проверок +большинство переменных имеют пустые значения. + @@ -52,6 +71,41 @@ } } +Каждому серверу группы backend +с интервалом в 5 секунд посылаются запросы “/”. +Если происходит ошибка или таймаут при работе с сервером, или +код ответа проксируемого сервера не равен +2xx или 3xx, проверка считается неуспешной и сервер +признаётся неработоспособным. + + + +Проверки работоспособности могут тестировать код ответа, +наличие или отсутствие определённых полей заголовка и их значений, +а также содержимое тела ответа. +Тесты настраиваются отдельно при помощи директивы +и указываются в параметре match. +Например: + +http { + server { + ... + location / { + proxy_pass http://backend; + health_check match=welcome; + } + } + + match welcome { + status 200; + header Content-Type = text/html; + body ~ "Welcome to nginx!"; + } +} + +В такой конфигурации успешный ответ на проверочный запрос +должен иметь код 200, тип содержимого “text/html” +и “Welcome to nginx!” в теле ответа.
@@ -149,71 +203,6 @@ - -В примере - -location / { - proxy_pass http://backend; - health_check; -} - -каждому серверу группы backend -с интервалом в 5 секунд посылаются запросы “/”. -Если происходит ошибка или таймаут при работе с сервером, или -код ответа проксируемого сервера не равен -2xx или 3xx, проверка считается неуспешной и сервер -признаётся неработоспособным. -На неработоспособные серверы и серверы в состоянии “checking” -клиентские запросы передаваться не будут. - - - -Проверки работоспособности могут тестировать код ответа, -наличие или отсутствие определённых полей заголовка и их значений, -а также содержимое тела ответа. -Тесты настраиваются отдельно при помощи директивы -и указываются в параметре match. -Например: - -http { - server { - ... - location / { - proxy_pass http://backend; - health_check match=welcome; - } - } - - match welcome { - status 200; - header Content-Type = text/html; - body ~ "Welcome to nginx!"; - } -} - -В такой конфигурации успешный ответ на проверочный запрос -должен иметь код 200, тип содержимого “text/html” -и “Welcome to nginx!” в теле ответа. - - - -Группа должна находиться в -зоне разделяемой памяти. - - - -Если для группы задано несколько проверок, -то при любой неуспешной проверке соответствующий сервер будет -считаться неработоспособным. - - - - -Обратите внимание, что при использовании проверок -большинство переменных имеют пустые значения. - - -