<a id="adc-health-probes"></a>

# Проверки работоспособности серверов

Angie ADC включает пассивные и активные проверки работоспособности серверов (health probes). Если сервер начинает отвечать с ошибками, Angie ADC временно исключает его из пула доступных серверов.

<a id="adc-passive-upstream-probes"></a>

## Пассивные проверки

Пассивные проверки работают автоматически на основе реальных клиентских запросов.

Пример:

```nginx
upstream myapp1 {

   server srv1.example.com max_fails=2 fail_timeout=10s;
   server srv2.example.com;
   server srv3.example.com;
}
```

В этой конфигурации сервер помечается как недоступный после двух неудачных запросов подряд (`max_fails=2`).
Через десять секунд сервер снова проверяется на доступность (`fail_timeout=10s`).
Если он восстановился, запросы снова начинают отправляться на этот сервер.

<a id="adc-active-upstream-probes"></a>

## Активные проверки

Активные проверки позволяют оценить доступность сервера без участия клиентов.
Поддерживаются активные проверки для HTTP и TCP / UDP.
Проверки задаются с помощью директивы `upstream_probe`.
Для одного апстрима можно определить несколько проверок.
Можно гибко настраивать поведение проверок. Поддерживается отправка ICMP echo-запросов (ping).
Подробнее см. справочные материалы по активным проверкам [HTTP](https://angie.software//adc/docs/configuration_lb/reference/http/http_upstream_probe.md#adc-http-upstream-probe)
и [stream](https://angie.software//adc/docs/configuration_lb/reference/stream/stream_upstream_probe.md#adc-stream-upstream-probe).

### Пример для HTTP

```nginx
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`
  (пропуская помеченные как `persistent`, если конфигурация перезагружена
  и до этого сервер считался работающим).
  Если таких проверок нет, сервер считается работающим.
- Сервер считается неработающим и не получает клиентские запросы,
  если  *какая-либо* заданная для него проверка достигает своего порога `fails`
  или сам сервер достигает порога [max_fails](https://angie.software//adc/docs/configuration_lb/reference/http/http_upstream.md#adc-max-fails).
- Чтобы неработающий сервер снова мог считаться работающим,
   *все* заданные для него проверки должны достичь своего порога `passes`;
  после этого учитывается порог [max_fails](https://angie.software//adc/docs/configuration_lb/reference/http/http_upstream.md#adc-max-fails).

### Пример для TCP/UDP

```nginx
upstream backend {
    zone backend 1m;

    server a.example.com;
    server b.example.com;
}

map $upstream_probe_response $good {
    ~200    "1";
    default  "";
}

server {
    listen ...;

    # ...
    proxy_pass backend;
    upstream_probe_timeout 1s;

    upstream_probe backend_probe
        port=12345
        interval=5s
        test=$good
        essential
        persistent
        fails=3
        passes=3
        max_response=512k
        mode=onfail
        "send=data:GET / HTTP/1.0\r\n\r\n";
}
```

#### NOTE
Согласно спецификации RFC 2616 (HTTP/1.1) и RFC 9110 (HTTP Semantics),
заголовки HTTP должны разделяться последовательностью CRLF (`\r\n`), а
не просто `\n`.

Детали работы:

- Изначально сервер не получает клиентские запросы,
  пока не пройдет  *все* заданные для него проверки с параметром `essential`
  (пропуская помеченные как `persistent`, если конфигурация перезагружена
  и до этого сервер считался работающим).
  Если таких проверок нет, сервер считается работающим.
- Сервер считается неработающим и не получает клиентские запросы,
  если  *какая-либо* заданная для него проверка достигает своего порога `fails`
  или сам сервер достигает порога [max_fails](https://angie.software//adc/docs/configuration_lb/reference/stream/stream_upstream.md#adc-s-max-fails).
- Чтобы неработающий сервер снова мог считаться работающим,
   *все* заданные для него проверки должны достичь своего порога `passes`;
  после этого учитывается порог [max_fails](https://angie.software//adc/docs/configuration_lb/reference/stream/stream_upstream.md#adc-s-max-fails).
- Параметр `send` - отправляемые для проверки данные,
  а переменная `$upstream_probe_response` – ответ бекенда.

<a id="adc-icmp-probes"></a>

### Пример ICMP echo-запроса для HTTP

```nginx
http {
    upstream u {
        zone z 1k;

        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
    }

    server {
        listen ...;

        location / {
            proxy_pass http://u/;

            upstream_probe simple1
                 interval=3s
                 ping;

            upstream_probe simple2
                 interval=3s
                 ping ping_timeout=3s;
        }
    }
}
```

Детали работы:

- Используется проверка методом ICMP Echo вместо HTTP-запроса.
- ICMP-проверка проверяет доступность IP-адреса `127.0.0.1`.
  Порты `upstream` игнорируются.
- Сервер считается неработающим и не получает клиентские запросы, если не отвечает
  на запрос ICMP Echo в течение заданного таймаута.
  Первая проверка использует таймаут ожидания по умолчанию (1 секунда).
  Вторая проверка задает таймаут ожидания ответа явно (3 секунды).
- Единственным критерием прохождения проверки является успешное получение ICMP-ответа в пределах таймаута.