Рубрики
Uncategorized

Конфигурация проверки работоспособности HTTP Nginx

Автор оригинала: David Wong.

Ссылка на оригинальный текст: Блог Хэ Сяодуна

Переведено с официальных документов

Пассивный осмотр

Для пассивной проверки работоспособности NGINX и NGINX Plus отслеживают событие, когда оно происходит, и пытаются восстановить неудачное соединение. Если он все еще не вернется в нормальное состояние, NGINX Open Source Edition и NGINX Plus пометят сервер как недоступный и временно прекратят отправку запросов на него, пока он снова не будет помечен как активный.

Условие, что вышестоящий сервер помечен как недоступный, определяется для каждого вышестоящего сервера, который содержит блоки сервер Параметры команд вышестоящий :

  • fail_timeout – Установка времени, когда сервер помечен как недоступный, требует нескольких неудачных попыток, а также времени, когда сервер помечен как недоступный (по умолчанию 10 секунд).
  • max_fails – установлен в fail_timeout Сервер помечается как количество неудачных попыток, которые должны произойти во время недоступности (по умолчанию-одна попытка).

В следующем примере, если NGINX не сможет отправить запрос на сервер в течение 30 секунд или не получит ответа три раза, сервер будет недоступен в течение 30 секунд:

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

Обратите внимание, что если существует только одна группа серверов, параметры fail_timeout и max_fails игнорируются, и сервер никогда не будет помечен как недоступный.

Медленный запуск сервера

Недавно восстановленные серверы могут быть легко затоплены подключениями, что может привести к тому, что серверы снова будут помечены как недоступные. Медленный запуск позволяет вышестоящим серверам постепенно восстанавливать свои веса с нуля до номинальных значений после восстановления или доступности. Это может указывать восходящий поток сервер Модульный медленный запуск Параметры для завершения:

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

Будьте осторожны: Если в группе только один сервер, slow_start Параметры будут игнорироваться, и серверы никогда не будут помечены как недоступные. Медленный запуск-это эксклюзивная функция NGINX Plus

Активная проверка NGINX Plus

NGINX Plus может периодически проверять производительность вышестоящего сервера, отправляя каждому серверу специальный запрос на проверку работоспособности и проверяя правильный ответ.

Чтобы включить проверку эффективности деятельности:

  1. пребывание местоположение Блок запросит( proxy_pass ) Процесс, переданный в вышестоящую группу, содержит директиву health_check :
server {
    location / {
        proxy_pass http://backend;
        health_check;
    }
}

Этот фрагмент кода определяет сервер, который соответствует всем запросам на местоположение/ Передачу на серверную часть вышестоящей группы вызова. Он также использует инструкцию health_check для включения расширенного мониторинга производительности: по умолчанию NGINX Plus отправляет серверную часть запроса “/” на каждый сервер в группе каждые пять секунд. Если возникает какая-либо ошибка связи или время ожидания (код состояния, возвращаемый сервером, превышает диапазон 200-399), проверка работоспособности завершается неудачно. Сервер помечен как неработоспособный, и NGINX Plus не отправляет на него клиентские запросы до тех пор, пока он снова не пройдет проверку состояния.

Другой вариант: вы можете указать другой порт для проверки производительности, например, для мониторинга производительности многих служб на одном хосте. Используйте параметр port инструкции, чтобы указать проверку работоспособности newport:

server {
    location / {
        proxy_pass   http://backend;
        health_check port=8080;
    }
}
  1. В группе вышестоящих серверов инструкция zone определяет область общей памяти:
http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        server backend4.example.com;
    }
}

Эта область является общей для всех рабочих процессов и хранит конфигурацию вышестоящей группы. Это позволяет рабочему процессу использовать один и тот же набор счетчиков для отслеживания ответов серверов в группе.

иметь доступ к health_check Параметры инструкции переопределяют значения по умолчанию для проверки состояния активности:

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

Здесь параметры интервал увеличивают задержку между проверками производительности с 5 секунд по умолчанию до 10 секунд. этот сбой Параметр требует, чтобы сервер был помечен как плохо работающий (начиная со значения по умолчанию) при сбое трех проверок. Наконец, передает Параметры означают, что сервер должен быть проверен дважды подряд, прежде чем его можно будет снова пометить работоспособным, а не значением по умолчанию.

Укажите URL – адрес запроса

оставайтесь health_check Параметр URL указан в инструкции для задания маршрута запроса на проверку работоспособности:

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

Указанный URI будет добавлен к восходящему доменному имени сервера или IP-адресу, заданному сервером в блоке. Для первого сервера в группе примеров, объявленной выше серверной части, проверка выполнения запрашивает URL-адрес http://backend1.example.com/s….

Определите пользовательские условия

Вы можете задать пользовательские условия, которым должен соответствовать ответ, чтобы сервер прошел проверку состояния. Условия определяются в блоке соответствия, на который ссылаются параметры инструкции health_check.

  1. оставайтесь на http {} Уровне, укажите соответствие {} блоку и назовите его, например:’server_ok’
http {
    #...

    match server_ok {
        # tests are here
        
    }
}
  1. health_check Путем указания блока соответствия Параметров и соответствия Имени блока параметров:
http {
    #...

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

Если код состояния ответа находится в области видимости, то передайте проверку времени выполнения 200-399, и ее тело не содержит строки: “режим обслуживания”.

Инструкция соответствия позволяет NGINX Plus проверять коды состояния, поля заголовка и текст ответа. Используя эту инструкцию, вы можете проверить, находится ли состояние в указанном диапазоне, содержит ли ответ заголовок или соответствует ли заголовок или текст регулярному выражению. Инструкция соответствия может содержать условие состояния, условие тела и несколько условий заголовка. Ответ должен удовлетворять всем условиям, определенным в блоке соответствия, чтобы сервер мог пройти проверку состояния.

Например, следующая директива соответствия соответствует заголовку типа содержимого ответа 200 с отслеживанием состояния кода, точному значению text/html и тексту на странице:”Добро пожаловать в nginx !”.

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

В следующем примере используется восклицательный знак (!) для определения характеристик ответа, который нельзя проверить на работоспособность. В этом случае проверка работоспособности будет выполняться для кодов состояния, отличных от 301, 302, 303 или 307, без информации заголовка обновления.

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

Проверки работоспособности могут быть включены в других протоколах, отличных от HTTP, таких как FastCGI, memcached, SCGI, uwsgi и даже TCP и UDP.

Многие из лучших функций-это Nginx Plus.

Кстати, порекомендуйте несколько брошюр хорошего качества, сходите и посмотрите их