Мониторинг вывода развёртывания ловит ошибки runtime, которые не может валидация во время сборки. В то время как сборки ловят ошибки компиляции, несоответствия типов и нарушения lint перед запуском кода, мониторинг развёртывания ловит ошибки, которые появляются только когда ваше приложение фактически обслуживает запросы — необработанные исключения, отказы подключения к базе данных, HTTP 500 ошибки и сбои запуска.
Методы развёртывания
Pastukhov Code поддерживает два метода развёртывания, каждый с разными характеристиками мониторинга:
Debug Deploy (Локальный)
Debug развёртывания запускают ваше приложение как локальный процесс. С включённым shallowCopy (по умолчанию), изменённые файлы копируются во временный каталог перед запуском процесса, предоставляя изоляцию от вашего исходного дерева и позволяя перестроить приложение без проблем с блокировкой файлов. Потоки вывода передаются строка за строкой через stdout/stderr, записываются немедленно в .pastukhov/deploy/{name}.log и транслируются в реальном времени в UI через SignalR.
- Управление процессом — PID-файлы отслеживают запущенные процессы. При запуске устаревшие процессы от предыдущих сессий автоматически очищаются
- Лимит размера лога — Логи развёртывания ограничены 500 МБ. Когда превышено, лог очищается и развёртывание перезапускается автоматически
- Наблюдение за сборками — Развёртывания могут следить за именами сборок. Когда все наблюдаемые сборки завершаются успешно, развёртывание перезапускается с новым кодом
Docker Deploy (Удалённый)
Docker развёртывания отправляют ваше приложение на удалённый сервер через SSH и rsync, затем собирают и запускают его как контейнер. Процесс развёртывания выполняется как серия пронумерованных шагов, каждый зарегистрирован с stdout/stderr, и финальное состояние контейнера проверяется с помощью проверок здоровья.
⚠️ Экспериментальная функция — Docker Deploy ещё не тщательно протестирован. Используйте его с осторожностью и пожалуйста сообщайте о багах, если есть. Автор использует только debug развёртывания в изолированных контейнерах Docker, что легче управлять и не менее безопасно, чем Docker развёртывания.
- SSH + rsync — Исходные файлы передаются на удалённый сервер, исключая паттерны вроде
.git,node_modulesи.pastukhov - Жизненный цикл контейнера — Вытягивает базовый образ, удаляет существующий контейнер, собирает новый образ и запускает его с настроенными портами, томами, сетями и переменными окружения
- Проверки здоровья — После развёртывания проверяет, что контейнер запущен и опционально проверяет endpoint здоровья через HTTP
- Тайм-аут на команду — Каждый шаг развёртывания имеет настраиваемый тайм-аут. Если шаг превышает его, процесс убивается
Парсинг вывода развёртывания
Вывод runtime парсится в реальном времени с использованием .pastukhov/deploy.parser, который использует тот же формат блоков [ERROR]/[/ERROR], что и парсер сборки. Паттерны покрывают общие категории ошибок runtime:
- Необработанные исключения — Полные стековые трассировки, начинающиеся с “Unhandled exception.”
- Системные исключения — Отступные стековые трассировки для .NET, Java и других фреймворков
- Ошибки уровня лога — Строки, начинающиеся с
crit:,fail:илиerr:(формат Serilog/ILogger) - HTTP ошибки — Ответы с кодом состояния 500
- Отказы подключения — “Connection refused”, ECONNREFUSED, тайм-ауты
- Исключения базы данных — SqlException, NpgsqlException с отступными стековыми трассировками
- Отказы запуска приложения — “Application startup exception” с продолжением строк
Формат парсера
⚠️ Не пытайтесь редактировать файлы парсера вручную — попросите ИИ-модель сделать это за вас. Самый простой способ: выберите любой непарсенный текст в выводе развёртывания (Панель статуса или диалог развёртывания) и кликните на плавающую кнопку Fix parser — она отправляет выбранный текст ИИ с правильно отформатированным промптом для обновления deploy.parser. В качестве альтернативы, используйте .pastukhov/README.md как ссылку в чате.
- Строки комментариев, начинающиеся с
#, игнорируются - Однострочные паттерны — Регулярное выражение, которое должно точно соответствовать одной строке вывода
- Многострочные паттерны — Обёрнуты в
{{...}}, соответствуют нулю или более последовательным строкам, следующим за внутренним регулярным выражением
# Необработанные исключения со стековыми трассировками
[ERROR]
Unhandled exception.*
{{^\s+at\s+}} # Соответствует нулю или более строк, начинающимся с пробелов
[/ERROR]
# Уровни ошибок Serilog/ILogger
[ERROR]
(crit|fail|err):.*
[/ERROR]
# Предупреждения
[WARNING]
(warn|warning):.*
[/WARNING]Парсер работает последовательно: на каждой строке вывода он пытается применить паттерны каждого блока по порядку. Когда все паттерны в блоке соответствуют последовательно, те строки извлекаются как одна ошибка, и парсер продвигается мимо них. Ранние блоки имеют приоритет — как только найдено соответствие, более поздние блоки пропускаются для тех строк.
Предупреждения парсятся аналогично — предупреждения уровня лога, уведомления об устаревании и использование устаревших API. Чтобы добавить пользовательские паттерны для специфического формата ошибок вашего приложения, попросите ИИ-модель обновить deploy.parser. Парсер автоматически перезагружается при сохранении.
Отображение вывода развёртывания
Вывод развёртывания может стать очень большим — болтливое приложение или длинный процесс могут производить мегабайты данных лога. Без безопасных мер, рендеринг всего этого в браузере вызвал бы вялую прокрутку, высокое использование памяти и в конечном итоге сбои вкладок. Несколько мер применяются как на уровне сервера, так и на уровне клиента для сохранения отзывчивости UI независимо от объёма вывода.
Меры на стороне сервера
- Ограничение файла лога — Логи debug развёртывания ограничены 500 МБ. Когда лимит достигнут, лог очищается и развёртывание перезапускается автоматически, предотвращая неограниченный рост диска
- Усечение вывода — При чтении файлов лога (например, при загрузке страницы или открытии диалога), обслуживаются только последние 100 КБ. Ранний содержимое отбрасывается из ответа с маркером усечения, поэтому браузер никогда не получает полную историю
- Дросселирование SignalR — Вывод в реальном времени буферизируется и транслируется с интервалами 100 мс, а не отправляется каждая отдельная строка по мере её прибытия. Это уменьшает количество сообщений SignalR и избегает затопления браузера крошечными обновлениями
- Инкрементальная передача — Во время активных развёртываний вывод отправляется строка за строкой по мере его производства, а не как полные снимки. Клиент добавляет новые строки к существующему буферу вместо замены всего вывода при каждом обновлении
Меры на стороне клиента
- Лимит встроенной панели — Панель статуса показывает только последние 200 строк вывода развёртывания. Это сохраняет панель лёгкой и отзывчивой, даже когда полный лог намного больше
- Лимит диалога — Диалог вывода развёртывания показывает до 2000 строк (последняя часть лога). Это достаточно для просмотра последних ошибок и контекста без напряжения браузера
- Лимит отправки чата — При отправке вывода развёртывания в чат для анализа ИИ содержимое ограничивается 20 КБ. Это предотвращает чрезмерные сообщения от потребления чрезмерного контекста в разговоре
- Инкрементальное добавление — Клиент добавляет новые строки вывода к существующему буферу вместо замены всего вывода при каждом обновлении SignalR, минимизируя DOM-обновления и реактивные перерасчёты
- Кэширование спарсенного вывода — Выделения ошибок и предупреждений предварительно вычисляются в lookup map и повторно используются, поэтому парсер не пересканирует весь вывод при каждом рендеринге
Диалог развёртывания
Диалог вывода развёртывания показывается, когда вы кликаете на имя развёртывания на Панели статуса, предоставляя три вкладки для обзора вывода развёртывания:
- Лог — Необработанный, нефильтрованный вывод runtime. Показывает последние 2000 строк для debug развёртываний или полный пошаговый лог для Docker развёртываний
- Ошибки — Спарсенные записи ошибок, выделенные красным, извлечённые из парсера развёртывания
- Предупреждения — Спарсенные записи предупреждений, выделенные жёлтым
Каждая вкладка имеет действия копирования и отправки в чат. Отправка ошибок развёртывания в чат обёртывает их в кодовый блок build.log, чтобы ИИ мог анализировать отказы runtime и предлагать исправления. Выбор текста на любой вкладке раскрывает плавающую кнопку Fix parser для быстрого обновления deploy.parser для нераспознанных форматов ошибок.
Автоматический конвейер перезапуска
Развёртывания перезапускаются автоматически, когда все наблюдаемые сборки завершаются успешно, создавая непрерывный конвейер сборка-развёртывание-мониторинг:
- ИИ модифицирует файлы проекта
- Изменения файлов запускают соответствующие сборки после их настроенных задержек
- Парсер сборки извлекает ошибки и предупреждения из вывода сборки
- AutoFix направляет любые ошибки обратно ИИ для исправления (цикл повторяется, пока сборки не пройдут)
- Когда все сборки проходят, служба развёртывания уведомляется и перезапускает приложение
- Вывод развёртывания парсится в реальном времени для ошибок runtime
Этот конвейер работает без вмешательства. Вы можете мониторить его на Панели статуса или проверить позже для обзора результатов. Для debug развёртываний необязательное поле url в конфигурации показывает кликабельную кнопку, которая открывает развёрнутое приложение напрямую. Таким образом вам не нужно запоминать адрес или порт debug-экземпляра.
Эффективные паттерны валидации
- Используйте мониторинг развёртывания вместе со сборками — Сборки ловят статические ошибки; мониторинг развёртывания ловит ошибки runtime. Оба необходимы для полного покрытия
- Добавьте специфичные для приложения паттерны парсера — Если ваше приложение логирует ошибки в пользовательском формате, добавьте паттерны в
deploy.parser, чтобы они появлялись на вкладке Ошибки - Отправляйте ошибки runtime в чат — Когда вы видите ошибки развёртывания, кликните Отправить, чтобы ИИ проанализировал стековую трассировку и предложил исправление
- Мониторинг размера лога — Логи debug развёртывания ограничены 500 МБ. Если ваше приложение очень болтливое, рассмотрите настройку уровней лога или увеличение лимита
Для полной справки по функциям развёртывания см. Сборка и развёртывание. Для цикла обратной связи автоматических ошибок см. AutoFix. Для предотвращения ручных перезапусков развёртывания см. Хуки: Управление поведением модели.