Мониторинг перезапустил службу и закрыл инцидент. Команда вернула успешный ответ, но пользователи всё ещё не входят в 1С.
Автоматика проверила действие, а не результат. Рабочая цепочка должна повторно войти в контрольную базу или выполнить другую прикладную операцию. Только после этого сервис можно считать восстановленным.
Один сценарий проверки для мониторинга и восстановления
Цепочка автовосстановления состоит из шести операций:
проверка → повторная проверка → действие → пауза → проверка → закрытие или эскалация
Плановый мониторинг и модуль восстановления должны использовать одну спецификацию проверки. Иначе монитор обнаружит отказ по одному признаку, а восстановление подтвердит успех по другому.
В архитектуре Vigil оба пути получают общие credentials, тайм-аут, настройки TLS и правила проверки ответа. Одна функция toCheckSpec() преобразует настройки монитора как для плановых проверок, так и для recovery-worker.
Для 1С это означает одинаковый маршрут до и после перезапуска. Если монитор обращается к контрольной базе через балансировщик, проверка восстановления идёт через него же.
Проверка процесса ragent для этого не подходит. Процесс может работать, пока менеджер кластера, СУБД, лицензирование или прикладная база недоступны.
| Уровень проверки | Что подтверждает | Какой отказ пропускает | Годится для автозакрытия |
|---|---|---|---|
| Состояние службы systemd | Процесс запущен и не завершился сразу | Зависание процесса, отказ СУБД, недоступность базы | Нет |
| Подключение к TCP-порту | Узел принимает соединение на нужном порту | Ошибку аутентификации, отказ кластера, зависший запрос | Нет |
| HTTP-ответ | Веб-сервис вернул ответ | Ошибочную страницу с кодом 200, сбой прикладной операции | Нет |
| Проверка содержимого | В ответе есть ожидаемый признак | Отказ другой зависимости по пользовательскому маршруту | Иногда |
| Операция с контрольной базой | Пользовательский маршрут работает целиком | Только сценарии, не охваченные контрольной операцией | Да |
Инцидент закрывает самая дальняя проверка, которая подтверждает пользовательский сценарий. Для серверной 1С это контрольный вход или короткий запрос к специально выбранной базе.
Zuzia рекомендует дополнять ping проверками HTTP и содержимого ответа. Ping показывает доступность узла, но не готовность приложения обслуживать запросы.
Контрольная база не должна участвовать в рабочем учёте. Создайте отдельного пользователя с минимальными правами и запретите ему изменение прикладных данных.
Если вход зависит от LDAP, проверяйте и этот участок. Схема прикладной проверки через балансировщик LDAPS помогает не принять доступность одного контроллера за доступность всего маршрута.
Повторная проверка отсекает короткие сбои
Один тайм-аут ещё не доказывает отказ 1С. DNS мог задержать ответ, балансировщик — вернуть временный 503, а СУБД — дольше обычного ждать ресурсы.
После первого отказа recovery-worker должен повторить исходную проверку. Только второй последовательный отказ переводит цепочку к действию.
Zuzia рекомендует тайм-аут запроса от 5 до 10 секунд и порог в 2–3 последовательных отказа. Эти значения подходят как отправная точка, но их нужно сверить с допустимым временем обнаружения.
Посчитаем окно для двух проверок. Берём тайм-аут 5 секунд и паузу 5 секунд:
5 секунд + 5 секунд паузы + 5 секунд = не более 15 секунд
Если инцидент нужно обнаружить быстрее 15 секунд, уменьшите тайм-аут или паузу. Если штатный вход занимает дольше 5 секунд, увеличьте тайм-аут и пересчитайте окно.
Экспоненциальная задержка нужна при нескольких повторах: каждая следующая пауза длиннее предыдущей. Jitter добавляет случайное смещение, чтобы несколько проверяющих узлов не обращались к сервису одновременно.
Для двух проверок сложная схема задержек обычно не нужна. Фиксированной паузы достаточно, а поведение легче проверить во время приёмки.
Действие должно соответствовать месту отказа
Подтверждённый отказ ещё не означает, что нужно перезапускать весь сервер. Сначала определите минимальный уровень воздействия: рабочий процесс, службу агента, узел кластера или операционную систему.
Перезапуск лишнего уровня увеличивает простой и затрагивает исправные компоненты. Перед автоматизацией выберите действие по схеме из руководства по уровням перезапуска 1С.
У каждого монитора должно быть одно заранее разрешённое действие. Recovery-worker вызывает заданный endpoint, а не выполняет произвольную команду в инфраструктуре.
В Vigil тело такого запроса подписывается HMAC-SHA-256. Получатель сначала проверяет подпись, затем разбирает содержимое запроса. Это защищает endpoint от неподписанных команд и подмены тела.
Для локального сервиса часть задачи можно передать systemd. В примере Red Hat параметр Restart=on-failure запускает сервис повторно после аварийного кода выхода или сигнала.
Один systemd видит только состояние процесса. Проверку контрольной базы после запуска всё равно выполняет внешний монитор или отдельная служба проверки.
Лимиты останавливают цикл перезапусков
Автовосстановление без ограничений превращает устойчивый отказ в бесконечный цикл. Сервис запускается, падает, снова запускается и отнимает ресурсы у диагностики.
В Vigil цепочку ограничивают по числу действий на инцидент, паузе, суточному пределу и сроку передачи человеку. После исчерпания попыток инцидент уходит в обычную эскалацию.
| Ограничитель | От чего защищает | Что записать в журнал | Когда звать администратора |
|---|---|---|---|
| Попытки на инцидент | От повторения бесполезного действия | Номер попытки, команда, ответ endpoint | После последней разрешённой попытки |
| Пауза между действиями | От перезапуска до завершения инициализации | Время действия и следующей проверки | Если сервис не поднялся за расчётное окно |
| Суточный предел | От серии коротких инцидентов с постоянными рестартами | Число действий за сутки и связанные инциденты | При достижении предела |
| Срок автоматического восстановления | От зависшей цепочки без уведомления | Время старта, текущий этап, последняя ошибка | После истечения срока |
| Проверка после действия | От ложного закрытия по ответу hook | Ответ endpoint и прикладной проверки отдельно | Если hook успешен, а база недоступна |
После достижения лимита автоматика прекращает действия. Проверки и уведомления продолжаются, чтобы администратор видел состояние сервиса.
Для systemd Red Hat приводит сочетание StartLimitBurst=2 и StartLimitIntervalSec=30. Оно останавливает непрерывные перезапуски после двух отказов за 30 секунд.
Это пример механики, а не готовая настройка для любой 1С. Интервал должен покрывать штатный запуск службы и первую прикладную проверку.
Суточный предел решает другую задачу. Сервис может восстанавливаться после каждого сбоя, но падать несколько раз за смену. Отдельные инциденты закроются успешно, хотя система останется неисправной.
Общую перегрузку нельзя лечить выводом узлов по одному
Локальная проверка отвечает на узкий вопрос: исправен ли конкретный узел. Она не должна принимать решения по состоянию общей зависимости.
Amazon применяет быстрые проверки балансировщика только к локальным сбоям сервера. Проблемы зависимостей и аномалии обрабатывают централизованные системы мониторинга.
Причина в обратной связи. При общей перегрузке узлы отвечают медленнее, проверки начинают падать, а балансировщик сокращает доступную ёмкость. Нагрузка на оставшиеся узлы растёт.
Для контура 1С разделите два сигнала. Локальный отказ процесса разрешает перезапуск этого процесса. Одновременное замедление нескольких узлов блокирует локальные действия и вызывает администратора.
То же правило действует при отказе СУБД, LDAP или хранилища. Перезапускать по очереди все серверы приложений бессмысленно, если общая зависимость недоступна.
Устаревшее задание не должно трогать исправный сервис
Между обнаружением отказа и выполнением действия проходит время. За это время администратор может восстановить сервис вручную или монитор создаст новый инцидент.
Задержавшийся worker способен получить старое задание и перезапустить уже исправную службу. Для пользователя это будет новый простой, созданный системой восстановления.
Vigil защищается номером поколения status_revision. Задание хранит ревизию состояния, при которой его создали. Перед действием worker сравнивает её с текущей.
Несовпадение означает, что инцидент уже закрыт или сменился другим. Такое задание отбрасывается без вызова endpoint.
Если вы собираете свою цепочку, передайте в задание идентификатор инцидента и номер поколения. Одного времени создания недостаточно: часы могут расходиться, а задания — выполняться параллельно.
Журнал должен показывать всю цепочку
Успешный ответ endpoint нельзя смешивать с результатом прикладной проверки. Первый подтверждает приём команды. Второй показывает, вернулась ли 1С к работе.
Vigil хранит эти ответы раздельно и собирает события в хронологию инцидента. Такой журнал отвечает, на каком этапе цепочка остановилась.
Записывайте минимум шесть событий:
- обнаружение отказа;
- повторную проверку перед действием;
- номер и тип попытки;
- ответ recovery-endpoint;
- проверку после паузы;
- ручное вмешательство или эскалацию.
Для каждой записи нужны время, идентификатор инцидента и ревизия состояния. Иначе события нескольких сбоев смешаются, а старое задание будет трудно отличить от актуального.
Не сохраняйте пароль контрольного пользователя и ключ HMAC в журнал. Для разбора достаточно идентификатора проверки, кода результата и длительности.
Начальная конфигурация для небольшого контура
Начните с двух проверок по 5 секунд и паузы 5 секунд. Верхняя граница окна до действия составит 15 секунд: 5 + 5 + 5.
Разрешите не больше двух автоматических действий за один инцидент. Это консервативное редакционное допущение, а не требование Vigil или systemd.
Лимит должен быть ниже числа перезапусков, после которого сервис теряет состояние или создаёт дополнительную нагрузку. Если вы не знаете эту границу, оставьте одно действие до испытаний.
После каждого действия выдерживайте отдельную паузу запуска. Затем повторяйте ту же прикладную проверку, которая обнаружила отказ.
Успешный ответ endpoint не закрывает инцидент. Закрытие происходит только после контрольного входа или другой операции по пользовательскому маршруту.
| Сценарий приёмки | Что должна сделать цепочка | Признак ошибки |
|---|---|---|
| Один короткий тайм-аут | Повторить проверку и не запускать действие после успеха | Сервис перезапустился |
| Устойчивый отказ | Выполнить разрешённое действие после второго отказа | Действие запущено после первой ошибки |
| Hook ответил успешно, база недоступна | Оставить инцидент открытым и передать его дальше | Инцидент закрыт по коду ответа hook |
| Администратор уже восстановил сервис | Отбросить старое задание по ревизии | Исправный сервис перезапущен |
| Достигнут лимит попыток | Прекратить действия, продолжить проверки и уведомить человека | Началась новая попытка |
| Несколько узлов замедлились одновременно | Заблокировать локальные рестарты и поднять общий инцидент | Узлы выводятся из работы по очереди |
Автовосстановление можно включать после прохождения всех шести сценариев. Amazon отдельно предупреждает о механизмах, которые нельзя полноценно испытать.
В Vigil восстановление выключено по умолчанию. Проект проверяет транзакции и гонки на настоящем PostgreSQL, а не на упрощённой имитации хранилища.
Для своей системы проверьте также обрыв связи с endpoint, повторную доставку события и параллельные ответы нескольких worker. Тестовый вызов не должен выполнять настоящее действие.
Правило, по которому принимают цепочку
Рабочая схема выглядит так:
прикладная проверка → повторная проверка → ограниченное действие → пауза → та же проверка → закрытие либо эскалация
Включайте её, если выполнены пять условий:
- монитор и recovery-worker используют одну проверку;
- действие ограничено одним компонентом и заранее задано;
- у цепочки есть предел попыток и срок эскалации;
- устаревшие задания отсекаются по поколению состояния;
- инцидент закрывает прикладной результат, а не ответ hook.
Такая автоматика возвращает отдельный сервис после локального отказа. Она не скрывает единственную точку отказа и не заменяет резервирование.
Если сбой узла должен пройти без перерыва для пользователей, нужен отказоустойчивый кластер 1С. Более настойчивый скрипт перезапуска эту задачу не решит.