# Мониторинг подключений

Компонент мониторинга подключений использует HTTP-пинги для проверки состояния подключения исходящих прокси. Результаты мониторинга могут использоваться другими компонентами, например, балансировщиком нагрузки.
В настоящее время доступны два режима: [observatory](#observatoryobject) (фоновый мониторинг подключений) и [burstObservatory](#burstobservatoryobject) (мониторинг параллельных подключений).
Выберите один из них в соответствии с вашими потребностями.

## ObservatoryObject

`ObservatoryObject` соответствует элементу `observatory` в файле конфигурации.

```json
{
  "observatory": {
    "subjectSelector": ["outbound"],
    "probeUrl": "https://www.google.com/generate_204",
    "probeInterval": "10s",
    "enableConcurrency": false
  }
}
```

> `subjectSelector`: \[ string \]

Массив строк, каждый элемент которого будет использоваться для сопоставления с префиксом тега исходящего подключения.
Например, для следующих тегов исходящих подключений: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` будет соответствовать `[ "a", "ab" ]`.

> `probeUrl`: string

URL-адрес, используемый для проверки состояния подключения исходящего прокси.

> `probeInterval`: string

Интервал между проверками.
Формат времени: число + единица измерения, например `"10s"`, `"2h45m"`.
Поддерживаемые единицы измерения: `ns`, `us`, `ms`, `s`, `m`, `h` (наносекунды, микросекунды, миллисекунды, секунды, минуты, часы).

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

> `enableConcurrency`: true | false

- `true` - проверять все соответствующие исходящие прокси одновременно, после чего сделать паузу на время, указанное в `probeInterval`.
- `false` - проверять соответствующие исходящие прокси по очереди, делая паузу на время, указанное в `probeInterval`, после проверки каждого прокси.

## BurstObservatoryObject

`BurstObservatoryObject` соответствует элементу `burstObservatory` в файле конфигурации.

```json
{
  "burstObservatory": {
    "subjectSelector": ["outbound"],
    "pingConfig": {}
  }
}
```

> `subjectSelector`: \[ string \]

Массив строк, каждый элемент которого будет использоваться для сопоставления с префиксом тега исходящего подключения.
Например, для следующих тегов исходящих подключений: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` будет соответствовать `[ "a", "ab" ]`.

> `pingConfig`: [PingConfigObject](#pingconfigobject)

### PingConfigObject

```json
{
  // Для каждого исходящего прокси выполняется 10 проверок в течение 10 минут, конкретное время проверок случайно
  // Если все они завершатся неудачей, узел будет помечен как неисправный в течение 10 ~ 20 минут
  // После сбоя достаточно одной успешной проверки, чтобы узел был помечен как исправный, на это потребуется не более 10 минут
  "destination": "https://connectivitycheck.gstatic.com/generate_204",
  "connectivity": "",
  "interval": "1m",
  "sampling": 10,
  "timeout": "5s",
  "httpMethod": "HEAD"
}
```

> `destination`: string

URL-адрес, используемый для проверки состояния подключения исходящего прокси.
Этот URL-адрес должен возвращать код состояния HTTP 204.
По умолчанию `"https://connectivitycheck.gstatic.com/generate_204"`.

> `connectivity`: string

URL-адрес, используемый для проверки подключения к локальной сети.
Этот URL-адрес должен возвращать код состояния HTTP 204.

Пустая строка означает, что проверка подключения к локальной сети не выполняется.

Эта проверка выполняется только тогда, когда проверка `destination` завершается неудачей. Это позволяет более четко отразить в журнале причину отсутствия сетевого подключения.

Внимание: в режиме прозрачного проксирования этот запрос может быть перехвачен прозрачным прокси и снова попасть в Xray для маршрутизации (в зависимости от вашей конфигурации). Необходимо принять дополнительные меры, чтобы он не был перехвачен прозрачным прокси, например, обход по IP-адресу URL, либо использование cgroup, pid-маршрутизации и других способов, чтобы запросы Xray полностью не перехватывались. Либо вы можете выбрать URL-адрес, который соответствует правилу прямого подключения, и позволить этому запросу быть перехваченным прозрачным прокси.

> `interval`: string

Ожидаемый **средний** интервал между проверками для каждого исходящего прокси.

Формат времени: число + единица измерения, например `"10s"`, `"2h45m"`.
Поддерживаемые единицы измерения: `ns`, `us`, `ms`, `s`, `m`, `h` (наносекунды, микросекунды, миллисекунды, секунды, минуты, часы).
По умолчанию `"1m"`. Минимальное допустимое значение — `"10s"`. Если указано меньше, будет использовано `"10s"`.

> `sampling`: number

Количество последних результатов проверок, которые нужно сохранить.
По умолчанию `10`.

> `timeout`: string

Время ожидания ответа при проверке.
Формат такой же, как и у `interval`.
По умолчанию `"5s"`.

> `httpMethod`: string

HTTP-метод, используемый для выполнения проверки (например, `"HEAD"`, `"GET"`).
По умолчанию `"HEAD"`.

::: tip
Принцип работы мониторинга параллельных подключений заключается в том, что каждые `interval` \* `sampling` (далее — цикл проверки) для каждого совпавшего исходящего прокси немедленно планируется задача проверки, но сама проверка выполняется в случайный момент времени в пределах цикла каждой задачи. Это означает, что по сравнению с `observatory` (фоновым мониторингом подключений) характерный шаблон этого детектора менее заметен. Но если `interval` задан слишком малым или `sampling` слишком большим, что приводит к частым проверкам, шаблон станет более заметным.

`interval` и `sampling` совместно влияют на чувствительность переключения при сбое и восстановления. Когда узел постоянно не проходит проверки, чтобы пометить его как неисправный, требуется минимум 1 цикл проверки и максимум 2 цикла проверки. Для восстановления после сбоя требуется одна успешная проверка, что зависит от плотности проверок; максимум на это уходит 1 цикл проверки.
:::