> ## Documentation Index > Fetch the complete documentation index at: https://docs.axottle.com/llms.txt > Use this file to discover all available pages before exploring further. # Состояния и severity > Статусы отдельных проб, сводные состояния нод и схем, уровни серьёзности и логика кворума входных нод. Система здоровья работает с двумя слоями статусов: результат отдельной пробы (что показала конкретная проверка) и сводное состояние (ноды, схемы подключения, всего парка). Сводное состояние получается объединением проб по принципу «худший из значимых». Эта страница объясняет, что означает каждый статус и как из проб складывается общая картина. Для кого: администратор панели, SRE. Требуемые права: сессия администратора. ## Статусы отдельных проб Каждая проверка возвращает один из статусов ниже. Статус «не применимо» означает, что для этой цели проверка не требуется. | Статус | Что значит | Природа | | ---------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------- | | `ok` | Проверка пройдена | Успех | | `degraded` | Частичная деградация, работает с оговорками | Предупреждение | | `failed` | Проверка не пройдена | Сбой | | `timeout` | Ответ не получен за отведённое время | Сбой | | `unreachable` | Цель недостижима | Сбой | | `dns_failed` | Не удалось разрешить доменное имя | Сбой | | `port_closed` | Порт закрыт / соединение отклонено | Сбой | | `not_required` | Проверка намеренно неприменима к этой цели | Информационный, не сбой | | `absent` | Служба не установлена; трактуется слоем runtime | Информационный | | `skipped` | Проверка пропущена (например, базовая достижимость уже не прошла) | Информационный | | `not_implemented` | Проверка для этого случая пока не реализована | Информационный, служебное состояние | | `unsupported` | Проверка неприменима для этого типа цели | Информационный | | `unknown` | Данных пока нет | Нейтральный | | `external_probe_unavailable` | Нет доступного внешнего провайдера для региональной пробы (только уровень внешних проверок) | Информационный | Статусы `not_required`, `absent`, `skipped`, `not_implemented`, `unsupported` относятся к служебным состояниям и не повышают severity ноды. ## Статус WARP Для WARP используется отдельный набор состояний: `installed`, `missing`, `port_closed`, `unreachable`, `pending_install`, `not_required`, `unknown`. Если WARP по плану сборки схемы не требуется, статус — `not_required`, а не сбой. ## Сводные состояния Статусы проб сводятся в общее состояние ноды, схемы или всего парка: | Состояние | Что значит | Что делать | | ------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `healthy` | Проверено и всё в порядке | Ничего; поддерживать наблюдение | | `degraded` | Частичная потеря ёмкости или консультативная проблема | Диагностировать без паники: часть входных нод недоступна (но ≥ половины живо), проблемы на транзите/маршруте, отсутствует NET\_ADMIN, агент в degraded. См. [Runbook'и](/ru/health/runbooks) | | `critical` | Затронут пользовательский трафик | Действовать по runbook: шлюз недоступен, потерян кворум входных нод, нода отключена в Remnawave, устойчивый отказ сквозной пробы | | `unknown` | Данных пока нет — это **не** сбой | Дождаться первого прогона или запустить проверку вручную | | `unsupported` | Проверять нечего (например, схеме не назначены ноды) | Назначить ноды либо считать состояние ожидаемым | ## Severity и инциденты Уровень серьёзности инцидента выводится из сводного состояния: | Сводное состояние / событие | Severity инцидента | | ------------------------------------ | ------------------ | | `critical` | `error` | | `degraded` | `warning` | | Переход в `healthy` (восстановление) | `info` | | Действие аудита вида `*.failed` | `error` | ## Как складывается состояние ноды Панель объединяет три сигнала — состояние ноды в Remnawave, результаты health-проверок и heartbeat агента: * **critical** — Remnawave сообщает, что нода `disconnected`; **или** агент `offline`; **или** сетевая достижимость `unreachable`/`failed`. * **degraded** — достижимость `timeout`/`dns_failed`/`port_closed`; **или** агент `degraded`; **или** службы `failed`/`timeout`/`degraded`. * **healthy** — достижимость в порядке **и** службы `ok`/`not_implemented` (либо службы `ok` при онлайн-агенте). * **unknown** — пока ничего определённого. Недоступность SSH-порта фиксируется для диагностики, но сама по себе не повышает severity, если входные порты и агент доступны. Отказ входных портов переводит ноду и затронутые схемы в деградацию. ## Кворум входных нод у схемы подключения Для схемы подключения (Connection Unit) сводка учитывает роли нод — входные (entry) и транзитные (transit) — и работает по кворуму: | Условие | Итог | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Шлюз недоступен | **critical** | | Схеме не назначены ноды | **unsupported** (проверять нечего, это не деградация) | | Устойчивый отказ сквозной пробы со стороны ноды | принудительно **critical** | | Все входные ноды здоровы, ничего не падает | **healthy** | | Все входные здоровы, но есть отказы на транзите/маршруте | **degraded** (проблемы только на транзите не делают схему critical, пока жив здоровый входной путь) | | Здоровых входных нод — 0 | **critical** | | Здоровых входных нод 50 % и более | **degraded** | | Здоровых входных нод менее 50 % | **critical** | Пример: у сбалансированной схемы с тремя входными нодами отказ одного из них даёт **degraded**, а не **critical** — оставшиеся два держат больше половины ёмкости. ## Сводка по всему парку (глобальный дашборд) Глобальное состояние на дашборде становится **critical**, когда нода, схема или маршрут получает статус `critical`. Офлайн-агент повышает состояние максимум до `degraded`; доступность ноды отдельно проверяется сетевыми пробами. Состояние `healthy` требует хотя бы одной здоровой сущности и отсутствия сигналов `degraded`/`critical`; пустая установка даёт `unknown`. ## Причины сбоя (классификация «почему») Помимо статуса система фиксирует причину: недоступность шлюза, падение входной или транзитной ноды, остановка сервисной части, отсутствующий агент, дрейф конфигурации, некорректная условная связь, отсутствие или закрытый порт WARP, недоступность или отказ авторизации прокси, недоступность источника CDN, несоответствие DNS, истёкший TLS, отказ внешней региональной пробы, ожидание выбора цели и «неизвестно». Причина помогает выбрать правильное действие восстановления — см. [Восстановление](/ru/health/self-heal). ## Проверка Откройте **Здоровье** и нажмите **Запустить проверку**. Сводное состояние и причины отображаются на карточках дашборда. ## Откат Эта страница справочная — откатывать нечего. Изменяющие операции (подтверждение действия восстановления, подавление ноды) и их откаты описаны на страницах [Восстановление](/ru/health/self-heal) и [Подавление нод](/ru/health/suppression). ## Типовые ошибки `unknown` означает «данных ещё нет», а не «плохо». После первого прогона проверок или ручного запуска состояние уточнится. Пока жив здоровый входной путь и держится кворум (≥ 50 % входных нод), проблемы на транзите или потеря части нод дают именно degraded. Это by design. Так и задумано: сам по себе офлайн-агент не поднимает глобальное состояние выше degraded. Реальную недоступность ноды независимо покажут его пробы достижимости. Связанные страницы: [Уровни проверок](/ru/health/probes), [Дашборд здоровья](/ru/health/dashboard), [Восстановление](/ru/health/self-heal), [Жизненный цикл ноды](/ru/nodes/lifecycle). Проверено для версии Axottle текущей ветки. Дата проверки: 2026-07-11.