Self-Healing мониторинг инфраструктуры в n8n

Задача — автоматизировать первичную реакцию на типовые инфраструктурные сбои: падение контейнера, таймаут API, потерю авторизации или недоступность прокси. Система должна собрать диагностику, выполнить только заранее разрешённое восстановление, проверить результат и эскалировать инцидент человеку, если сервис не восстановился. Повторные сигналы одного сбоя не должны запускать параллельные перезапуски.

В n8n создан workflow self-healing оркестрации. Сигналы поступают через webhook от системы мониторинга или отдельного сборщика логов. Первым шагом сценарий нормализует событие, определяет сервис, критичность и fingerprint инцидента, после чего проверяет cooldown и наличие уже активного запуска.

Диагностическая ветка выполняет безопасные проверки через SSH и API: доступность endpoint, статус нужного контейнера, последние коды ошибок, состояние зависимого proxy или базы данных. Команды ограничены allowlist и конкретными сервисами. При подтверждённом типовом сбое сценарий перезапускает только целевой контейнер или процесс, затем ждёт готовность и повторно выполняет health-check.

Если восстановление не помогло, превышен лимит попыток или обнаружена неизвестная причина, автоматические действия прекращаются. n8n собирает краткий отчёт с таймлайном, диагностикой и выполненными командами и отправляет его разработчику в Telegram. Состояние инцидента и все переходы сохраняются в PostgreSQL для аудита.

Собран управляемый контур реакции на инфраструктурные инциденты: приём события, дедупликация, диагностика, ограниченная попытка восстановления, повторная проверка здоровья сервиса и эскалация. Сценарий не выполняет произвольные команды и прекращает автоматические действия при неизвестном состоянии.

Защита от повторов и cooldown предотвращают несколько одновременных рестартов одного сервиса. Каждая попытка получает журнал с исходным событием, результатами проверок, выполненным действием и итоговым health-check. Это позволяет быстро понять, что было исправлено автоматически, а что требует ручного вмешательства.

Практический результат — типовые аварии получают одинаковую первичную обработку, а разработчик получает уже собранный контекст вместо одиночного уведомления «сервис недоступен». Численные показатели uptime или сокращения времени восстановления не заявляются без отдельного эксплуатационного замера.