Мониторинг
Мониторинг — это автоматическая проверка связности через туннель: awg-manager периодически отправляет пробы через интерфейс и поддерживает картину того, какие туннели сейчас реально доносят трафик до интернета, а какие — нет. На основе этих проб работает автоперезапуск упавших туннелей и принимаются решения в зависимых разделах (Маршрутизация, Sing-box Router). Раздел доступен на уровне использования Расширенный (см. Настройки — уровни использования) — на базовом уровне пункт скрыт.
Открыть раздел
В главном меню — пункт Мониторинг. Страница открывается на матричном виде: сверху — сводка по всем туннелям (всего / up / failed / средняя latency), ниже — основная таблица проверок.
Матрица проверок
Основной вид — таблица, в строках которой стоят цели мониторинга (внешние хосты, до которых проверяется доступность — например 8.8.8.8 или connectivitycheck.gstatic.com), а в колонках — все туннели, через которые проверка идёт параллельно. На пересечении — ячейка с последним замером latency и цветовой индикацией (зелёный <100ms / оранжевый 100–250ms / красный >250ms / failed). В одной из ячеек туннеля стоит отметка ★ — это активный pingcheck target, то есть цель, потеря связности с которой именно для этого туннеля считается триггером для срабатывания мониторинга и автоматического рестарта.
Такой вид сразу показывает закономерности: упала одна цель у всех туннелей — проблема в цели; упал один туннель по всем целям — проблема в туннеле. Клик на стрелку рядом с именем туннеля в шапке колонки открывает настройки pingcheck именно для этого туннеля.
Детализация по ячейке
Клик по любой ячейке открывает боковую панель с историей этой пары “цель × туннель”: спарклайн latency, агрегаты (avg / min / max / loss %) и таблица последних замеров. Этот вид нужен, когда суммарного цвета в матрице недостаточно — например, чтобы посмотреть, ровно ли держится задержка или есть проседания.
Kernel vs NativeWG
Под капотом мониторинг состоит из двух разных механизмов, и какой работает — определяется типом туннеля. Для Kernel-туннелей awg-manager сам гоняет цикл проверок (ICMP / HTTP 204 / TCP / TLS — в зависимости от настроек) и сам принимает решение о рестарте; никаких системных компонентов Keenetic для этого не требуется. Для NativeWG-туннелей awg-manager делегирует проверку встроенному компоненту Keenetic OS ping-check (NDMS): создаёт профиль с нужными параметрами, читает его статус и логирует переходы. Если компонент ping-check в прошивке не установлен, мониторинг NativeWG-туннелей просто недоступен — устанавливается через веб-интерфейс роутера (Управление → Общие настройки → Изменить набор компонентов → ping-check).
Окно настройки pingcheck визуально одинаковое для обоих типов туннелей — сверху быстрые пресеты (ICMP / TCP / TLS на популярные публичные адреса), поля хост / метод / порт, лимиты сбоев и тумблер Перезапуск при dead. Различается только backend, который эти настройки исполняет.
Что дальше
Журнал самих проверок (что именно сработало, какая была задержка, когда произошёл рестарт) живёт отдельно — на странице Диагностика → Журнал (/logs), вместе с остальными событиями приложения. Если туннель регулярно перезапускается мониторингом — см. Решение проблем; если речь идёт о sing-box-outbound’ах, у них своя система проверки задержки (Clash urltest), описанная в Sing-box Router; общее управление туннелями — Туннели.