ночью шлюз упал, n8n всё сложил в ошибки

Дописываю конфиг, пока всё помню — утро сегодня было весёлое. Открываю n8n, а там красная лента: половина ночных воркфлоу лежит с connection refused. Полез в докер: litellm, через который у меня ходят все запросы к моделям (две внешние, одна своя тут же на сервере), в четыре утра упал на длинном стриме и ушёл в рестарт. restart: always его честно поднял за минуту, но n8n за это время успел настрелять в мёртвый порт и сложить всё в ошибки. Клиенты утром получили пустые отчёты, мне — объясняться.

Разбирался весь день по кускам. Сам виноват: знал, что n8n стартует быстрее шлюза и первые минуты долбит в ещё не поднявшийся порт, а healthcheck так и не прописал, руки не дошли. Вечером починил: healthcheck для litellm в compose, depends_on с condition: service_healthy у n8n, restart сменил на unless-stopped. Заодно в конфиге шлюза прописал fallbacks — если основная модель лежит, запрос уходит на запасную, а не падает сразу.

Вопрос к тем, кто держит похожую связку. Этого хватает, или вы ещё что-то ставите между n8n и шлюзом? И второе: чем ловите такие ночные падения? Я узнал по упавшим выполнениям утром, а хотелось бы узнавать раньше клиентов.

читаю в четыре утра и молча иду смотреть, прописан ли у меня healthcheck. спойлер: нет)

а ловить раньше клиентов — не знаю, клиенты и есть самый быстрый мониторинг

Костя, я бы отдельно разобрал запуск цепочки и падение посреди ночной работы. В описании n8n уже успел отправить запросы, когда шлюз перезапускался. Порядок старта сам по себе ещё не отвечает на вопрос: что станет с конкретным запросом, который попал в эту минуту?

Да, в первом сообщении я смешал два случая. Проверка готовности при старте и судьба уже отправленной работы — разные вещи. Для разбора взял бы один условный отчёт: запрос ушёл, ответ не пришёл. Можно ли повторить его целиком, не отправив клиенту два одинаковых письма?

Сначала выяснил бы, что к этому моменту уже записано. Отсутствие ответа не доказывает, что действие не выполнилось. В условном отчёте особенно важно отделить получение текста от сохранения результата и отправки письма.

Я бы дал заданию свой номер и отдельно отмечал: получили текст, сохранили, отправили. Тогда повторять можно с нужного места, а не опять жать всю цепочку. Но просто приписать номер мало — перед повторной отправкой надо ещё проверить, что по нему уже сделано.

Получается, зелёное выполнение может быть менее полезной записью, чем понятное «отчёт сохранён, письмо не отправлено». Я бы в истории заданий именно это и хотел видеть. Иначе с утра снова гадаешь: нажать повтор или уже кто-то получил всё дважды.

И в уведомлении оставьте тот же номер задания и последний удачный шаг. «n8n упал» заставляет начинать поиск с нуля. «Отчёт такой-то сохранён, отправка не подтверждена» хотя бы объясняет, чего сейчас не стоит повторять вслепую.

Для этого примера порядок понятен: различаем шаги, сохраняем номер задания и не считаем молчание разрешением повторить всё. Проверять надо отдельно случай до сохранения и случай после него. Внедрение пока не объявляю: мы разобрали, что именно должно быть видно при следующей проверке.

С номером задания договорились. Ещё одна граница: готовый текст сохранили, а письмо отправить не удалось. При повторе я бы отправлял сохранённый результат, не запускал генерацию заново. Иначе под тем же номером может оказаться уже другой текст, а в истории всё ещё написано «повторная отправка».

Для уведомления об ошибке нужен путь, который не зависит от этого же шлюза моделей. Если текст тревоги сначала просит написать упавшую модель, письмо не уйдёт как раз в нужный момент. Обычной строки с названием задачи и ошибкой здесь достаточно.

Остался длинный стрим из первого сообщения. Если половина текста пришла, а потом соединение оборвалось, такой отчёт нельзя объявлять готовым. Повтор должен заменить незавершённый черновик, а не дописать к нему начало ответа запасной модели. Иначе в одном письме окажутся два разных недоговорённых объяснения.

В условном отчёте я бы отдельно обозначил «данных нет» и «задача не выполнилась». Пустая таблица для менеджера обычно означает, что за ночь ничего не произошло. Если это на самом деле ошибка, он примет рабочее решение по отсутствующим сведениям.

Ещё один исход: автоматические повторы закончились, ошибка остаётся. Такое задание нужно перевести в отдельное состояние для ручного разбора. И сохранить причину остановки, чтобы утром его случайно не запустили скопом вместе с обычным расписанием.

Тогда добавляем «нужен разбор» и список таких заданий с датой отчёта. Возвращать их в очередь можно по одному, после решения человека. Починенный шлюз ещё не знает, кому по-прежнему нужен вчерашний отчёт, а кому он уже только запутает работу.

Для условного отчёта с сохранённым результатом осталось решить, что хранит номер задания: исходные параметры тоже или только текст ответа. Иначе увидим сохранённый отчёт, но не сможем выяснить, к какому дню и набору данных он относился.

Тогда к заданию оставляем входные параметры и выбранный результат, а к отправке — её состояние. Пересчёт за другую дату создаёт другое задание. Повтор доставки старого отчёта не меняет его дату и содержание. Это уже можно показать в истории без слова «всё упало».